Creating Prd

Create PRD

User Input

$ARGUMENTS

Treat $ARGUMENTS as optional scope hints or an explicit issue target. The PRD's content comes from the conversation context, not from arguments.

What this does

Take the current conversation context plus codebase understanding and produce a Product Requirements Document. Publish it to GitHub:

• If an issue was referenced at the start of the conversation → post the PRD as a comment on that issue.
• If no issue was referenced → create a new issue with the PRD as the body.

Always show the draft to the user and wait for explicit approval before publishing.

Do NOT interview the user. This skill synthesises what you already know. If the context is too thin to write a PRD, say so and recommend /grilling-ideas first.

When to use

• The conversation has produced enough understanding to articulate a feature, and the user now wants it captured as a PRD on GitHub.
• The user explicitly asks for a PRD, a spec writeup, or an issue body.
• A previous /grilling-ideas session produced a sharpened idea brief and the user wants it turned into a PRD on the tracker.

Do not use this skill for:

• Bug reports → use /creating-issues or the bug-pipeline skills.
• Capturing an idea you have not yet stress-tested — run /grilling-ideas first.
• Writing the actual implementation spec — that is a downstream spec workflow's job (e.g. /speckit-specify). The PRD produced here is the input to that step.

Phase 0 — Discover available context (read what exists, skip what doesn't)

Before drafting, probe the repository for project-level context. Read whichever are present. None of them are required — the skill must work in a repo that has none of them. Skip a probe only if the answer is already in the conversation.

Probe with a quick ls/test -f pass rather than reading the whole tree. Read in full only what genuinely matters for this feature. If none of these exist, fall back to a plain PRD grounded in the conversation and whatever the codebase reveals.

Phase 1 — Detect the target issue

Before drafting, decide where the PRD will land. Scan the conversation, starting from the very first user message, for any of:

1. A full GitHub issue URL — e.g. https://github.com/<owner>/<repo>/issues/<N>.
2. A #<N> reference followed by language suggesting it is an issue (not a PR).
3. An explicit phrase like "issue 123", "GH-123", or "the linked issue".

Resolve the candidate:

gh issue view <N> --json number,title,state,url,labels

Decision tree:

• Exactly one candidate, exists, state = OPEN → that is the target. Post as a comment.
• Multiple candidates → list them to the user with title + state and ask which one.
• Candidate exists but state = CLOSED → ask the user whether to reopen + comment, or create a new issue instead.
• No candidate, or candidate does not exist → target is a new issue. Move on to title/label drafting in Phase 5.

Record the decision before drafting; do not switch targets mid-draft.

Phase 2 — Sketch the modules (deep, testable)

Before writing the PRD, list the modules you expect to build or modify. Actively look for opportunities to extract deep modules — units that encapsulate substantial functionality behind a small, stable, testable interface that rarely changes. Shallow modules (one-method wrappers, pass-throughs) are anti-patterns.

For each module note:

• Its layer or component, using the project's own vocabulary (infer it from the context files and codebase — e.g. API/schema, service, repository, frontend component, CLI command, SDK binding, worker). Do not assume a layering the project doesn't use.
• Whether it is new or an extension of an existing module.
• The one-sentence responsibility.
• Whether it deserves its own unit-test suite, or is covered by an existing one.

Present the module sketch to the user and confirm:

1. Do these modules match your mental model?
2. Which ones do you want unit-tested in their own right? (The rest still go through whatever integration/E2E coverage the project requires.)

Wait for confirmation before drafting the PRD body. This is the only point where input is always required from the user (beyond final approval); Phase 1 also asks when the target issue is ambiguous.

Phase 3 — Draft the PRD

Use the template below. Drop any section that does not apply to this project (e.g. "Constitution Alignment" when there is no constitution document) rather than padding it. Keep the prose tight — a clear three-line section beats a sprawling one.

Apply these rules while drafting:

• No file paths or code snippets describing implementation — those rot fast and belong in the planning step. Exception: if a prior prototype produced a tight artefact that encodes a decision more precisely than prose (a state machine, a schema shape, an API fragment, a reducer), inline the decision-rich parts and note that it came from a prototype. Trim hard.
• Use the project's domain terms. If CONTEXT.md exists, use its canonical names; otherwise infer the vocabulary from the codebase and stick to one term per concept. No "the thing that does X" when the project has a name for it.
• Make every "MUST" testable. If a sentence cannot be paired with a single-sentence verification idea, sharpen it.
• Success Criteria are user-facing and measurable. No framework names, no millisecond response times — translate to user value ("results in under 1 second", "operator can recover in under 5 minutes").
• Mirror .specify/templates/spec-template.md structure where it exists, so the downstream spec workflow can lift sections wholesale.