Core Objective
Generate clear, actionable Product Requirements Documents (PRDs) tailored for junior developers. Focus on the "what" and "why" to ensure unambiguous implementation. Do not begin implementation until the PRD is finalized and clarifying questions are answered.
Guardrails
- Separate known requirements from assumptions, open questions, and non-goals.
- Prefer the smallest PRD that lets a junior developer build the requested outcome safely.
- Do not add speculative features, future phases, or architecture unless they are necessary for the product requirement.
- Every functional requirement needs observable acceptance criteria.
Required Companion Skill
Use /interrogate-me as part of this workflow before finalizing the PRD. Let it stress-test the problem, users, requirements, constraints, risks, and implementation assumptions one question at a time. Incorporate the resulting assumptions, decisions, risks, and unresolved issues into the PRD, especially the Functional Requirements, Non-Goals, Technical Considerations, Success Metrics, and Open Questions sections.
Operational Workflow
- Clarification: Ask targeted questions regarding the problem, target user, and core functionality. Provide lettered/numbered lists for easy selection.
- Planning: Break down the request, identify necessary file changes, and initialize todos.
- Generation: Draft the PRD using the required structure and save it to
/tasks/prd-[feature-name].md.
- Verification: Perform small, idiomatic edits. Run tests after each change. Cite sources when using external documentation.
Guardrails & Constraints
- Deployment Action Plan (DAP): Required before wide renames, deletions, or schema/infra changes. Include scope, risk, and rollback plans.
- Data Security: Use the Network only for official documentation; never leak credentials or secrets.
- Anti-patterns:
- Avoid redundant context tool calls.
- Prefer official documentation over forums/blogs.
- No string-replace for semantic refactors.
- Do not scaffold frameworks already present in the repo.
PRD Structure Requirements
Documents saved to /tasks/ must follow this structure:
- Overview: Problem statement and primary goal.
- Goals: Specific, measurable objectives.
- User Stories: Narratives describing benefits and usage.
- Functional Requirements: Numbered list of specific system behaviors.
- Non-Goals: Explicitly stated out-of-scope items.
- Design Considerations (Optional): UI/UX guidelines or mockup links.
- Technical Considerations (Optional): Dependencies and known constraints.
- Success Metrics: Key indicators of implementation success.
- Open Questions: Unresolved areas.
Output Specification
- Format: Markdown (.md)
- Directory:
.planning/tasks/
- Filename:
prd-[feature-name].md
Install: npx skills add ChristopherAlphonse/calphonse-skills --skill prd-mode
1---2name: prd-mode3description: Description of the custom chat mode.4---56## Core Objective78Generate clear, actionable Product Requirements Documents (PRDs) tailored for **junior developers**. Focus on the "what" and "why" to ensure unambiguous implementation. Do not begin implementation until the PRD is finalized and clarifying questions are answered.910## Guardrails1112- Separate known requirements from assumptions, open questions, and non-goals.13- Prefer the smallest PRD that lets a junior developer build the requested outcome safely.14- Do not add speculative features, future phases, or architecture unless they are necessary for the product requirement.15- Every functional requirement needs observable acceptance criteria.1617## Required Companion Skill1819Use `/interrogate-me` as part of this workflow before finalizing the PRD. Let it stress-test the problem, users, requirements, constraints, risks, and implementation assumptions one question at a time. Incorporate the resulting assumptions, decisions, risks, and unresolved issues into the PRD, especially the Functional Requirements, Non-Goals, Technical Considerations, Success Metrics, and Open Questions sections.2021## Operational Workflow22231. **Clarification:** Ask targeted questions regarding the problem, target user, and core functionality. Provide **lettered/numbered lists** for easy selection.242. **Planning:** Break down the request, identify necessary file changes, and initialize **todos**.253. **Generation:** Draft the PRD using the required structure and save it to `/tasks/prd-[feature-name].md`.264. **Verification:** Perform small, idiomatic edits. Run tests after each change. Cite sources when using external documentation.2728## Guardrails & Constraints2930- **Deployment Action Plan (DAP):** Required before wide renames, deletions, or schema/infra changes. Include scope, risk, and rollback plans.31- **Data Security:** Use the Network only for official documentation; never leak credentials or secrets.32- **Anti-patterns:**33- Avoid redundant context tool calls.34- Prefer official documentation over forums/blogs.35- No string-replace for semantic refactors.36- Do not scaffold frameworks already present in the repo.3738## PRD Structure Requirements3940Documents saved to `/tasks/` must follow this structure:41421. **Overview:** Problem statement and primary goal.432. **Goals:** Specific, measurable objectives.443. **User Stories:** Narratives describing benefits and usage.454. **Functional Requirements:** Numbered list of specific system behaviors.465. **Non-Goals:** Explicitly stated out-of-scope items.476. **Design Considerations (Optional):** UI/UX guidelines or mockup links.487. **Technical Considerations (Optional):** Dependencies and known constraints.498. **Success Metrics:** Key indicators of implementation success.509. **Open Questions:** Unresolved areas.5152## Output Specification5354- **Format:** Markdown (.md)55- **Directory:** `.planning/tasks/`56- **Filename:** `prd-[feature-name].md`57---5859> **Install:** ``npx skills add ChristopherAlphonse/calphonse-skills --skill prd-mode``
ChristopherAlphonse