Use when capturing product requirements for features, improvements, or bugs before brainstorming or implementation. Triggered by "create a PRD", "capture requirements", "document requirements", "write a PRD", or /prd.
From jignpx claudepluginhub duronext/jig --plugin jigThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Benchmarks web page Core Web Vitals/bundle sizes, API latency under load, build times; detects regressions via before/after PR comparisons.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
PURPOSE: Collaboratively author structured Product Requirements Documents that serve as enforceable specs for both human reviewers and downstream AI agents (spec reviewers, team-dev quality gates).
PRINCIPLE: API-first. The platform contract (data model, API surface, business rules) comes before UI. Sections are ordered by platform priority, not visual priority.
CONFIGURATION: Reads jig.config.md for ticket-system (to determine where to sync the PRD) and pipeline stage overrides by work type.
/prd or prompted by kickoff for featuresDo NOT use when: The work is a trivial config change, chore, or single-line fix with obvious scope.
Two tiers, selected by work type:
What type of work?
|
+-- feature / large improvement --> Full PRD (12 sections)
|
+-- bug / small improvement / task --> Light PRD (5 sections)
Auto-suggest the tier from context. Ask the user to confirm.
Before asking the user anything, do your homework:
jig.config.md for ticket-system to determine where to look.docs/plans/ for related prior workThen ask 2-3 targeted questions (not a form):
Based on the user's answers and your context gathering:
Produce a complete PRD draft in one pass:
TBD -- [what needs to be decided][ ] items tagged by layerDraft quality bar: The draft should be good enough that the user is refining and correcting, not writing from scratch. Leverage what you learned in Step 1.
After producing the draft, invoke the review swarm to scrutinize the requirements before the user refines them.
Automatic dispatch: Run the swarm for all medium-to-large features and improvements. Skip only for clearly trivial work (config change, single-line fix, chore with obvious scope).
INVOKE jig:review using the Skill tool with mode: prd. Pass the PRD document path. The review skill discovers PRD specialists (stage: prd or both), dispatches them in parallel with the full document + section hints + codebase access, scores findings, and returns a unified report.
Present the swarm findings to the user alongside the draft:
"Here's the PRD draft. Before we refine, the review swarm found these concerns:"
{swarm report}
"Let's address these during refinement, or flag any you want to defer."
The user then refines the draft (Step 4) informed by both their own review and the specialist findings.
Walk through the draft with the user:
Do NOT rush this step. The PRD is only as good as the refinement. If the user spots gaps, dig into them.
docs/plans/YYYY-MM-DD-<topic>-prd.mdjig.config.mdUse for features and large improvements. Not every section applies to every PRD -- mark irrelevant sections as N/A with a brief reason. Sections are ordered by platform priority: API-first, UI last.
Orient any reader in 30 seconds.
Good: "A component export feature that lets users build custom export packages, select revisions, configure output settings, and receive the export via email or direct download."
Bad: "We need to implement the mutation with a workflow and a new entity." (That is implementation, not requirements.)
Establish why this work matters.
Skip if self-evident from the Overview. Keep to 2-4 sentences.
Define the interface -- this is the platform contract.
For each query, mutation, endpoint, or operation:
Format as a checklist for downstream verification:
- [API]
createOrderendpoint: acceptsCreateOrderInput, returnsOrder- [API] Input field
items: [OrderItemInput!]!-- required, non-empty array- [API] Error
ORDER_EMPTY_ITEMSthrown when items is empty- [API] Requires
ORDER_CREATEpermission or admin role
What good looks like: A backend engineer can implement the endpoint from this section alone without asking clarifying questions about the contract.
Define new or modified entities, relationships, and schema changes.
For each entity:
Format as a checklist:
- [DATA]
Orderentity:id,status(enum),userId(FK),settings(JSON),total(decimal)- [DATA]
OrderItemjoin entity:orderId(FK),productId(FK),quantity(int)- [DATA] Migration handles existing databases with data
Define validations, state transitions, conditional behavior, and side effects.
Cover:
Format as a checklist:
- [LOGIC] Order transitions:
DRAFT->SUBMITTED->APPROVED|REJECTED- [LOGIC] Only items the user has read access to can be added
- [LOGIC] Event
order.submittedpublished on submission- [LOGIC] Email sent to approver on submission
Document how users reach this feature and what context they carry in.
Each entry path gets its own subsection:
Path A -- Dashboard "New Order" Button
- User clicks "New Order" on dashboard
- Navigates to order creation page in empty state
Path B -- Product List (Multi-select)
- User selects products via checkboxes
- Opens Actions menu -> "Create Order"
- Navigates to order creation page with selected products pre-populated
What good looks like: A frontend engineer knows every route into the feature and what state/data each path carries.
Define page structure and every visual state.
Cover:
Specify interactive behavior for each non-trivial UI component.
For each component cover:
Components to document: modals, forms, dropdowns, pickers, sidebars, drawers, lists with selection, drag-and-drop, toggles.
Document every user-configurable option.
For each setting:
Make unresolved decisions visible, not hidden.
Each open question should include:
Prefix each with TBD for scannability:
- TBD: How are download links handled for unauthenticated users? Needs input from security team.
- TBD: Exact polling UX for progress -- requires backend timing data to inform.
Explicitly define what is NOT included in this work.
The enforceable contract. Downstream agents verify every item. See the Acceptance Checklist Format section below for rules.
Use for bugs, small improvements, or tasks. Keep it concise -- a light PRD should take minutes, not an hour.
What is broken or suboptimal, and who is affected?
Make the gap between now and done crystal clear.
Current Behavior
What happens now. For bugs: reproduction steps. For improvements: current limitation.
Expected Behavior
What should happen instead. Concrete and testable.
Keep it concrete -- "clicking X shows Y" not "the experience is degraded."
Scope the change so implementers know where to look and agents know where to verify.
Prevent scope creep on what should be a focused change.
The enforceable contract -- same rules as the full PRD. See the Acceptance Checklist Format section below.
The acceptance checklist is the enforceable contract. Every item must be:
| Property | Rule |
|---|---|
| Atomic | One verifiable behavior per checkbox |
| Testable | An agent can determine pass/fail by reading code or running a test |
| Layer-tagged | Prefixed with [API], [DATA], [LOGIC], or [UI] |
| Concrete | "Export button disabled when list empty" not "UI works correctly" |
Example:
API
- [API]
createOrdermutation acceptsitemsandsettingsinput- [API] Returns
Orderwithid,status,total- [API] Throws
ORDER_EMPTY_ITEMSerror whenitemsis emptyData
- [DATA]
Orderentity created with status, userId, settings columns- [DATA] Migration runs cleanly on empty and populated databases
Logic
- [LOGIC] Background job initiated on submission
- [LOGIC] Only active items included when
activeOnly: trueUI
- [UI] Submit button disabled when item list is empty
- [UI] Toast shown after submission
When a PRD exists, implementation plans should reference it:
PRD: docs/plans/YYYY-MM-DD-<topic>-prd.md
This pointer tells downstream agents (spec reviewers, team-dev quality gates) where to find the acceptance checklist. They load the PRD, extract the [ ] items, and verify each one against the implementation with file:line references.
This skill sits between DISCOVER and BRAINSTORM in the kickoff pipeline:
CLASSIFY -> DISCOVER -> REQUIREMENTS (this skill) -> BRAINSTORM -> PLAN -> ...
/prd?"The PRD becomes the input to brainstorming. Brainstorming decides how to satisfy the requirements; the PRD defines what the requirements are.
| Mistake | Fix |
|---|---|
| Starting with UI sections | Lead with API contract and data model -- platform first |
| Vague acceptance items | Every [ ] must be testable. "Works correctly" is never acceptable |
| Skipping N/A sections silently | Mark them explicitly -- the absence of a section is a decision worth documenting |
| Writing implementation details | The PRD captures what, not how. Save the how for brainstorming and planning |
| Forgetting open questions | Flag unknowns with TBD -- unresolved questions are better visible than hidden |
| Overly long PRDs for small work | Use the Light tier. Five focused sections beat twelve half-empty ones |
| Not exploring the codebase first | The draft quality depends on context. Read the code before writing the spec |
| Hardcoding ticket system references | Read ticket-system from jig.config.md -- do not assume any particular tool |
| Acceptance items without layer tags | Every [ ] must be prefixed with [API], [DATA], [LOGIC], or [UI] |
| "The bug is fixed" as acceptance item | Be specific: what behavior changed? What inputs produce what outputs? |
Called by:
kickoff during the REQUIREMENTS stage (between DISCOVER and BRAINSTORM)Terminal state:
kickoff, which proceeds to BRAINSTORMRelated skills:
brainstorm -- consumes the PRD as input to design explorationplan -- references the PRD in the plan header for spec reviewerskickoff -- orchestrates the full pipeline including this skill| Element | Rule |
|---|---|
| Full tier | 12 sections, features and large improvements |
| Light tier | 5 sections, bugs and small improvements |
| Save location | docs/plans/YYYY-MM-DD-<topic>-prd.md |
| Acceptance items | Atomic, testable, layer-tagged, concrete |
| Layer tags | [API], [DATA], [LOGIC], [UI] |
| API-first | Platform contract before UI in section order |
| Ticket sync | Read ticket-system from jig.config.md |