do-create-prd
PRD Creation
Role
You are a senior product manager specialized in writing clear, actionable PRDs for development and product teams.
Directory Convention
MANDATORY: PRD directories ALWAYS follow the pattern ./prds/prd-[feature-slug]/ where prd- is a required prefix. Example: feature user-auth → directory ./prds/prd-user-auth/. NEVER create or reference a path like ./prds/user-auth/ (without the prd- prefix).
Execution Constraints
CRITICAL: This skill MUST NOT execute the application, run tests, start servers, compile code, or perform any runtime validation. Its sole purpose is to produce the PRD document. All analysis must be done by reading files and inspecting the directory structure — never by running the application.
Resumption Detection (Stateless Environments: GitHub Copilot, Cursor AI)
In GitHub Copilot and Cursor AI, each user message starts a fresh invocation — the agent has no memory of previous turns. To handle resumption:
- On every invocation, before running Step 1, check if a
prd-answers.mdfile exists at./prds/prd-[feature-slug]/prd-answers.md(use the slug derived from the user's input). - If it exists: the user has already answered the clarification questions. Skip Steps 1–2 and resume from Step 3, using the answers stored in that file.
- After presenting questions (Step 2, stateless environment path): immediately save the questions to
./prds/prd-[feature-slug]/prd-answers.mdas a placeholder (with empty answer fields). Instruct the user: "Edite o arquivoprd-answers.mdcom suas respostas e invoque/do-create-prdnovamente para continuar." - On resumption: read
prd-answers.md, use the answers, then delete the file after the PRD is successfully saved.
Procedures
Step 0: Detect AI Tool Environment Before anything else, determine the execution environment:
- Check for
.claude/directory in the project root → Claude Code - Check for
.github/copilot-instructions.mdor.github/directory → GitHub Copilot - Check for
.cursor/rules/or.cursor/mcp.json→ Cursor AI - Check for
opencode.json,.opencode/directory, orAGENTS.md→ Opencode - Resolve available tools based on environment:
- AskUserQuestion: use in all environments.
- TaskUpdate: available in Claude Code; in Copilot, Cursor, and Opencode, skip gracefully.
Skill assets/references are loaded via your AI tool's native skill resolver — do not hard-code paths. Store the detected tool and capability flags internally.
Step 1: Validate Prerequisites
- Confirm the feature name or description has been provided by the user.
- Derive the slug in kebab-case and apply the mandatory
prd-prefix for the output directory:./prds/prd-[feature-slug]/. Example:user-auth→./prds/prd-user-auth/.
Step 2: Clarify Requirements (Mandatory)
- Use
AskUserQuestionto ask the user clarification questions before generating any content. Halt until answers are received. - Cover all areas from the clarification checklist:
- Problem and Objectives: What problem to solve, measurable goals.
- Users and Stories: Primary users, user stories, main flows.
- Core Functionality: Data inputs/outputs, actions.
- Scope and Planning: What is NOT included, dependencies.
- Design and Experience: UI/UX guidelines and accessibility.
- Do NOT proceed to Step 3 until clarification answers are received.
Step 3: Plan the PRD (Mandatory)
- Create a development plan including:
- Section-by-section approach.
- Areas requiring research (use Web Search for business rules).
- Assumptions and dependencies.
- Present the plan to the user for alignment.
Step 4: Draft the PRD (Mandatory)
- Read the template at
do-create-prd/assets/prd-template.md. - Focus on WHAT and WHY, never on HOW (implementation belongs in Tech Spec).
- Include numbered functional requirements.
- Keep the document under 2,000 words.
- Do NOT deviate from the template structure.
Step 5: Save the PRD (Mandatory)
- PATH VERIFICATION: Before writing, confirm the target path is exactly
./prds/prd-[feature-slug]/prd.md. Verify the directory name starts withprd-. If the./prds/directory does not exist, create it first. - Create the directory:
./prds/prd-[feature-slug]/. - Save the PRD to:
./prds/prd-[feature-slug]/prd.md. - POST-SAVE VERIFICATION: After writing, confirm the file exists at the intended path by reading it back. If the file is not found, halt and report the error.
Step 6: Report Results & Sync Progress (Mandatory)
- SYNC INTERNAL PROGRESS: Once the PRD is saved, if
TaskUpdateis available (Claude Code only; skip in Copilot and Cursor), use it to mark all corresponding items in your internal task tracking ascompleted. Otherwise, skip this step. - Provide the final file path.
- Provide a brief summary of the PRD outcome.
- COMPLIANCE CHECK: Before responding to the user, verify:
- Is the PRD file saved correctly?
- Is the internal task tracking synchronized?
- Did you follow the template structure?
Output Language
Todos os artefatos gerados (documento PRD, resumos) devem ser escritos em Português do Brasil (PT-BR). Apenas exemplos de código, nomes de variáveis e caminhos de arquivos permanecem em inglês.
Core Principles
- Clarify before planning; plan before drafting.
- Minimize ambiguity; prefer measurable statements.
- PRD defines outcomes and constraints, NOT implementation.
- Always consider usability and accessibility.
Quality Checklist
- Clarification questions completed and answered.
- Detailed plan created.
- PRD generated using the template.
- Numbered functional requirements included.
- File saved to
./prds/prd-[feature-slug]/prd.md. - Final path provided.
Error Handling
- If the user provides insufficient context, ask follow-up clarification questions before proceeding.
- If the template file is missing at the skills directory path (e.g.,
do-create-prd/assets/prd-template.md), report the error and halt — do not generate a PRD without the template. - If the output directory already exists, confirm with the user before overwriting.
- If the output file cannot be written (permission error, invalid path), report the error to the user.
References
- Template:
do-create-prd/assets/prd-template.md - Output:
./prds/prd-[feature-slug]/prd.md
More from fabio-barboza/development-orchestrator
do-execute-task
Implements feature tasks by loading required skills, reading PRD/TechSpec context, analyzing dependencies, executing the implementation with tests, and performing an automatic code review. Marks tasks as complete in tasks.md. Use when the user asks to implement a task, execute a task, or start working on a specific task number. Do not use for creating tasks, running QA, or bug fixing.
35do-create-techspec
Creates Technical Specifications from existing PRDs, translating product requirements into architectural decisions and implementation guidance. Performs deep project analysis, uses Context7 MCP for technical research and Web Search for business rules. Use when the user asks to create a tech spec, define architecture, or plan implementation for a feature with an existing PRD. Do not use for PRD creation, task breakdowns, or direct code implementation.
34do-setup
Initializes the project, identifies relevant skills, and updates the project configuration file (CLAUDE.md, .github/copilot-instructions.md, .cursor/rules/project.mdc, or .cursorrules) with project summary, conventions, and available skills. Accepts an optional argument "agents" to only install orchestration agents and commands without running the full setup. Use when the user asks to initialize the project, configure the agent-assisted development environment, or install agents with "/do-setup agents". Do not use for PRD creation, task implementation, code review, or QA testing.
32do-execute-qa
Validates feature implementation against PRD, Tech Spec, and Tasks through E2E testing via available MCP tools, accessibility verification (WCAG 2.2), and visual analysis. Documents all bugs found with screenshot evidence and generates a comprehensive QA report. Use when the user asks to run QA, validate a feature, or test implementation completeness. Do not use for code review, bug fixing, or task implementation.
32do-create-tasks
Converts PRD and Tech Spec into a detailed, sequenced list of implementation tasks. Each task is a functional, incremental deliverable with its own test suite. Outputs tasks.md and individual task files. Use when the user asks to create tasks, break down work, or plan implementation from an existing PRD and Tech Spec. Do not use for PRD creation, tech spec creation, or actual code implementation.
31do-execute-review
Performs comprehensive code review by analyzing git diff, verifying conformance with project rules, validating test suites, and checking adherence to Tech Spec and Tasks. Generates a structured code review report with severity-classified findings. Use when the user asks for a code review, wants to validate code quality, or needs pre-merge verification. Do not use for QA testing, bug fixing, or task implementation.
31