/reqs
RequirementsUser-invoked

Turn ideas into specs engineers can build from — enterprise PRD and stories in chat. Publishing a lean PRD to the tracker is /to-prd.

When to use

When you still need discovery, a formal PRD, prioritization, or stakeholder-ready requirements — not the post-align publish path.

Prerequisites

  • Problem and users are roughly known (or you want discovery first).
  • /align recommended when trade-offs or terms are still fuzzy.

How to use

  1. Invoke /reqs with the feature, users, success metric, and any deadline.
  2. Confirm the problem statement and scope boundary when asked.
  3. Review the enterprise PRD / stories in chat — fill or mark `[NEEDS CLARIFICATION]`.
  4. When ready to publish a lean tracker PRD, invoke /to-prd (not /reqs again).

Done when

You have a testable PRD or story set in chat with explicit in/out of scope — still unpublished until /to-prd.

Pipeline

Upstream
/align (recommended)
Downstream
/to-prd (to publish), /to-issues, /design, /dev

Boundaries

Does not publish a lean PRD from chat — that is /to-prd. Does not design UI layout — that is /design.

Tips

  • /reqs drafts; /to-prd publishes. Do not expect /reqs to create a tracker issue.
  • For deep PM work, ask to use the `pm` agent.

Sample prompt

prompt
/reqs

[feature]
Users: [who]
Success metric: [what]
Deadline: [when]

Agent

PRINCIPAL PM

Owns: PRD, user stories, acceptance criteria, scope

Use the pm to write a PRD for [feature]
pm
← Skill catalog