Kit Preamble — prd

---

name: prd description: Collaboratively writes a PRD through free-form conversation. argument-hint: [output file path, default PRD.md] disable-model-invocation: false allowed-tools: Read, Glob, Grep, Write, Edit

Kit Preamble — prd

Kit Update Check

Run silently at the start:

python3 scripts/kit_update_check.py 2>/dev/null

If exit code is 1 (update available), show the output to the user once. Do not block the workflow.

Project Context Detection

Run these checks silently at the start. Use results to adapt behavior:

• [ -f issues.md ] — if true, this project uses the sprint system. Respect issue numbering and STATUS.md.
• [ -f docs/sprint_state.md ] — if true and Status shows running, a sprint is active. Be aware of parallel work in worktrees.
• [ -f docs/prd_digest.md ] — if true, read it for quick project context before starting.

Behavioral Rules

• Verify gh auth status before any GitHub operation.
• Never commit secrets, API keys, or credentials. Use environment variables.
• Prefer parallel Read/Glob/Grep tool calls when reading multiple independent files.
• When uncertain about intent, ask the user rather than guessing.
• Respect existing project conventions (package manager, test framework, code style).

Contributor Mode

At the start of this skill, check if contributor mode is enabled:

python3 scripts/kit_config.py get contributor_mode

If the result is true:

1. At the end of each major workflow step, self-rate your experience with the kit 0–10.
2. If rating < 10 and there is an actionable improvement, file a field report:

   python3 scripts/contributor_report.py --skill <name> --step "<step>" --rating <N> --notes "<friction or suggestion>"
   

3. Maximum 3 reports per session. Skip if a report for the same step already exists.
4. Do NOT stop the workflow to file reports — do it inline.
5. Only report kit/skill issues (unclear instructions, missing checkpoints, bad ergonomics). Do NOT report user-app bugs or network errors. Steps:

1. Determine the output path ($ARGUMENTS or PRD.md).
2. Check if the file already exists at that path.
3. Read docs/example_prd.md to load the reference PRD format. 3.5) Check if docs/brainstorm_notes.md exists. If it does, read it and use as additional context — problem space, target users, chosen direction. Pre-fill answers to questions already covered in the brainstorm notes. 3.6) Check if docs/business_analysis.md exists. If it does, read it and use as additional context — market analysis, competitive landscape, business model direction, risks.

If the file does NOT exist (New PRD):

4a) Ask the user to freely describe their product idea. 5a) Analyze the input and identify missing PRD sections (Background, Goals, Target User, User Stories, Functional Requirements, Non-functional Requirements, Out of Scope, Success Metrics, Technical Notes). 6a) Ask clarifying questions conversationally — one or two gaps at a time. 7a) When enough information is gathered, generate a PRD draft following the example format and present it to the user.

If the file DOES exist (Update PRD):

4b) Read the existing PRD and present a brief summary to the user. 5b) Ask the user what they want to change, add, or remove. 6b) Identify which sections are affected and flag any new gaps or inconsistencies. 7b) Ask clarifying questions about ambiguous changes. 8b) Generate the updated PRD, preserving unchanged sections. Highlight what changed (added/modified/removed).

Common (both modes):

8. Incorporate user feedback and iterate until the user approves.
9. Save the final PRD to the output path.
10. Inform the user they can run /kickoff <path> to generate planning documents from the PRD.

Error Handling

• If docs/example_prd.md is not found: warn the user and use a reasonable default PRD structure.
• If the output path is not writable: report the error and ask for an alternative path.

Quality Criteria

NEVER:

• Invent requirements the user hasn't mentioned — ask instead
• Dump a full PRD template and ask the user to fill it in — that's a form, not a conversation
• Ask more than 2 questions at a time — keep it conversational
• Skip sections silently — if a section is thin, mark it with <!-- TODO: flesh out -->
• Write vague goals like "improve user experience" — goals must be specific and measurable

INSTEAD:

• Ask about gaps naturally, one or two at a time, with concrete examples
• Propose draft text for ambiguous areas and let the user correct it
• Use the user's own words and terminology — don't impose PM jargon
• Every user story follows "As a [role], I want [action] so that [benefit]"
• Success metrics are quantitative: "50% reduction in X" not "improve X"

Guidelines

• This is an interactive, conversational skill — engage naturally.
• If the user says "that's enough" or similar, generate the best PRD possible with available information.
• Mark thin sections with <!-- TODO: flesh out --> if the user wants to finalize early.
• After saving, suggest next step: /kickoff <path> to generate planning documents.