PRD Workshop
The heart of effectum
The PRD Workshop bridges “I have an idea” and “Claude builds it autonomously.” It transforms vague requirements into structured, verifiable specifications that drive the entire implementation lifecycle.
What is the PRD Workshop?
A PRD (Product Requirements Document) in effectum is not a traditional multi-page document. It is a structured spec file that Claude uses as the single source of truth when building your feature. Each section has a specific job — the problem statement guides decisions, the acceptance criteria map to tests, the completion promise exits the Ralph Loop.
effectum is the perfect mix of generative AI intelligence and the structure of a program. The PRD is the structure. Claude is the intelligence.
The complete workflow
From idea to production — every PRD follows the same pipeline. Optional steps (like Decompose) only apply to large features.
Two modes
Workshop Mode
For vague ideasGuided discovery process. Claude asks adaptive questions about your idea — problem, users, constraints, edge cases — until it fully understands what to build.
Best for: Exploring new concepts, unclear scope, complex domains
/prd:newExpress Mode
For clear requirementsOne-shot spec from clear requirements. Paste your requirements and get a complete PRD in seconds. Best when you already know exactly what you want.
Best for: Well-defined features, CRUD operations, familiar patterns
/prd:expressWhat a spec contains
Every PRD has seven required sections. Each one serves a specific purpose in the build process.
Problem & Goal
What we're solving and why it matters. The goal must be measurable.
e.g. Users cannot reset their password without contacting support.
User Stories
What users can do when the feature is complete.
e.g. As a registered user, I can reset my password via email.
Acceptance Criteria
Given/When/Then format. Each criterion maps directly to one test.
e.g. Given I enter my email, When I click Reset, Then I receive an email within 60s.
Data Model
Tables, fields, types, and RLS policies. No ambiguity allowed.
e.g. password_resets: id, user_id (FK), token (hashed), expires_at, used_at
API Design
Endpoints, request/response shapes, error codes, rate limits.
e.g. POST /api/auth/forgot-password → 200 OK | 429 Too Many Requests
Quality Gates
8 automated checks that must pass before shipping.
e.g. Build 0 errors, Types 0 errors, Tests 80%+ coverage, 0 console.log
Completion Promise
A verifiable statement Claude uses as the exit condition for the Ralph Loop.
e.g. All 12 tests pass, build succeeds, 0 lint errors, password reset flow works end-to-end.
All 12 PRD commands
Commands are grouped by phase. Start with Discovery, refine your spec, then hand off to the implementation workflow.
Discovery
/prd:newDiscoveryStart a new guided specification from scratch. Claude asks adaptive questions until it fully understands what you want to build.
/prd:expressDiscoveryFast one-shot spec from clear requirements. Best when you already know exactly what you want.
Refinement
/prd:discussRefinementDeep-dive into a specific area of your spec. Explore edge cases, data models, or API design in detail.
/prd:reviewRefinementQuality check before handing off to implementation. Flags missing acceptance criteria, vague goals, and incomplete data models.
/prd:decomposeRefinementSplit large projects into smaller, manageable PRDs. Each sub-PRD is independently buildable.
/prd:network-mapRefinementVisualize connections and dependencies between all your PRDs. Generates a Mermaid diagram.
Handoff
/prd:handoffHandoffExport a finished spec to the target project. Copies the PRD file and prepares it for /plan.
/prd:promptHandoffGenerate a handoff prompt for a completed PRD. Use this to start a new Claude session focused on one feature.
Management
/prd:statusManagementView all projects and their current progress. Shows which specs are draft, complete, or in progress.
/prd:resumeManagementContinue working on a previous specification. Loads context and picks up where you left off.
/prd:archiveManagementArchive completed or abandoned specs. Keeps your workspace clean without losing history.
/prd:templateManagementCreate a reusable spec template. Useful for repeating patterns like API endpoints, auth flows, or CRUD features.
Quality checklist
Run /prd:review before handoff. A good spec passes all of these.
Every acceptance criterion has exactly one test mapped to it
The goal is measurable, not vague ('users can' not 'improve UX')
The data model includes field types and RLS policies
Error cases are documented alongside happy paths
The completion promise is 100% verifiable by running commands
Red flag: Vague goal like 'make it better' or 'improve performance'
Red flag: Acceptance criteria without Given/When/Then structure
Red flag: Missing error handling in API design
Red flag: Completion promise that cannot be verified by running a command
Example workflow
A complete flow from vague idea to autonomous build — step by step.
# 1. Start with a vague idea — Claude asks questions
/prd:new
# → "What problem does this solve?"
# → "Who are the users?"
# → "What does success look like?"
# 2. Discuss a specific area in depth if needed
/prd:discuss "the data model for password resets"
# 3. If scope is too large, split into sub-PRDs
/prd:decompose
# → Creates PRD-001-auth.md, PRD-002-email.md, etc.
# 4. Review the spec for completeness
/prd:review
# → "AC-3 is missing the error case"
# → "Completion promise is not verifiable"
# 5. Hand off to the target project
/prd:handoff
# 6. In your project: plan, build, verify
/plan docs/prds/001-password-reset.md
/ralph-loop "Build password reset per PRD" --max-iterations 30