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.

Idea
Questions
Scope
Decompose
Write PRD
Review
Handoff
Build

Two modes

Workshop Mode

For vague ideas

Guided 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

terminal
/prd:new

Express Mode

For clear requirements

One-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

terminal
/prd:express

What a spec contains

Every PRD has seven required sections. Each one serves a specific purpose in the build process.

1

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.

2

User Stories

What users can do when the feature is complete.

e.g. As a registered user, I can reset my password via email.

3

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.

4

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

5

API Design

Endpoints, request/response shapes, error codes, rate limits.

e.g. POST /api/auth/forgot-password → 200 OK | 429 Too Many Requests

6

Quality Gates

8 automated checks that must pass before shipping.

e.g. Build 0 errors, Types 0 errors, Tests 80%+ coverage, 0 console.log

7

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:newDiscovery

Start a new guided specification from scratch. Claude asks adaptive questions until it fully understands what you want to build.

/prd:expressDiscovery

Fast one-shot spec from clear requirements. Best when you already know exactly what you want.

Refinement

/prd:discussRefinement

Deep-dive into a specific area of your spec. Explore edge cases, data models, or API design in detail.

/prd:reviewRefinement

Quality check before handing off to implementation. Flags missing acceptance criteria, vague goals, and incomplete data models.

/prd:decomposeRefinement

Split large projects into smaller, manageable PRDs. Each sub-PRD is independently buildable.

/prd:network-mapRefinement

Visualize connections and dependencies between all your PRDs. Generates a Mermaid diagram.

Handoff

/prd:handoffHandoff

Export a finished spec to the target project. Copies the PRD file and prepares it for /plan.

/prd:promptHandoff

Generate a handoff prompt for a completed PRD. Use this to start a new Claude session focused on one feature.

Management

/prd:statusManagement

View all projects and their current progress. Shows which specs are draft, complete, or in progress.

/prd:resumeManagement

Continue working on a previous specification. Loads context and picks up where you left off.

/prd:archiveManagement

Archive completed or abandoned specs. Keeps your workspace clean without losing history.

/prd:templateManagement

Create 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.

terminal
# 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