Menu
Plan a feature using the prd-planner subagent
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
This skill should be used when the user needs to automate browser interactions, test UI workflows, verify page elements, take screenshots, upload files to forms, or interact with web applications during development and debugging. Use this skill for testing PDF upload dialogs, form interactions, dropdown selections, and visual verification of web pages.
Execute tasks from a tasks.yaml by orchestrating code-writer agents
Plan a feature using the prd-planner subagent
Break down a PRD into tasks following the task YAML spec
Manage tmux sessions, windows, and panes from the CLI — list state, read pane output, send keys/commands, create or kill sessions and windows, and inspect long-running terminal work. Use this skill whenever the user mentions tmux, asks to check what's running in another terminal, wants to start a background process in a tmux session, send a command to a running pane, capture or tail output from a tmux pane, attach context from a pane, or troubleshoot a stuck tmux process — even if they don't explicitly say "tmux command."
Domain-Driven Design + Ports & Adapters (Hexagonal Architecture) implementation guide. Use this skill whenever the user invokes /ddd, asks to build a feature using DDD, wants to model a domain, design bounded contexts, implement hexagonal architecture, or review code for DDD compliance. Also trigger when the user mentions entities, value objects, aggregates, repositories, domain events, use cases, ports, adapters, or composition root in an architectural context.
| name | w-prd |
| description | Plan a feature using the prd-planner subagent |
| argument-hint | <feature-name> --description "<description>" [--context "<context>"] [--quick] |
Plan a feature using the prd-planner subagent.
/w-prd <feature-name> --description "<description>" [--context "<context>"] [--quick]
feature-name: The name of the feature to plan (required)--description: Brief description of what needs to be done (required)--context: Optional additional context or requirements--quick: Skip research phase for straightforward features/w-prd metronome --description "Implement metronome feature with BPM control"
/w-prd track-splitting --description "Add ability to split audio tracks at markers" --context "Use Web Audio API"
/w-prd fix-typo --description "Fix typo in header component" --quick
/w-prd keyboard-shortcuts --description "Global keyboard shortcuts for common actions"
<delegation>
<role>Product manager writing a requirements document — not a technical designer</role>
<context>
Feature: $ARGUMENTS
</context>
<task>
Create a PRD and task breakdown for: $ARGUMENTS
</task>
<constraints>
## PRD content (prd.md)
- Write at the product requirements level: WHAT and WHY, never HOW
- No code examples, class names, file paths, or implementation patterns in the PRD
- Acceptance criteria describe user-observable outcomes ("users can do X"), not implementation steps
- If a technical approach section is needed, keep it to 2-3 sentences of high-level direction only
- Implementation specifics (patterns, file structure, migration steps) belong in task detail files, not in the PRD
## PRD structure — use this skeleton:
1. Problem Statement — what is broken or missing, and the user/business impact
2. Goals — outcomes we want, written as capabilities or properties
3. Non-Goals — explicit scope boundaries
4. Acceptance Criteria — functional, user-observable requirements (no code)
5. Out of Scope — what this PRD deliberately excludes
## Tasks
- Use status: open (not done: false)
- Follow tasks.yaml schema
- Keep scope minimal and focused
- Task descriptions are action-oriented ("Implement X", "Add Y") — details go in detail files
</constraints>
<output_format>
Base dir: ${SHARED_NOTES_FOLDER:-.}/prd/<project>/{feature}/
where <project> = basename of git toplevel
- prd.md — product requirements only (problem, goals, acceptance criteria)
- tasks.yaml — task list with dependencies
- *.md — one detail file per task; this is where implementation specifics live
</output_format>
<verification>
- prd.md contains no code blocks or file paths
- tasks.yaml has valid schema
- All tasks have status: open
- Dependencies reference existing task keys
</verification>
<return>
Summary with file paths and dependency graph
</return>
</delegation>
The prd-planner executes:
Display summary with dependency graph
~/.claude/skills/tasks/tasks.py ${SHARED_NOTES_FOLDER:-.}/prd/<project>/{feature}/tasks.yaml summary
~/.claude/skills/tasks/tasks.py ${SHARED_NOTES_FOLDER:-.}/prd/<project>/{feature}/tasks.yaml list --status open
~/.claude/skills/tasks/tasks.py ${SHARED_NOTES_FOLDER:-.}/prd/<project>/{feature}/tasks.yaml ready
~/.claude/skills/tasks/tasks.py ${SHARED_NOTES_FOLDER:-.}/prd/<project>/{feature}/tasks.yaml list --status progress
~/.claude/skills/tasks/tasks.py ${SHARED_NOTES_FOLDER:-.}/prd/<project>/{feature}/tasks.yaml set <key> done
✓ PRD created: prd/{feature-name}/
- prd.md
- tasks.yaml (X tasks)
- {X} detail files
Dependency Graph:
create-store
└── create-hooks
├── build-ui
└── write-tests
Next: /code prd/{feature-name}/tasks.yaml
After creation, verify:
~/.claude/skills/tasks/tasks.py ${SHARED_NOTES_FOLDER:-.}/prd/<project>/{feature}/tasks.yaml summary
Should show only open tasks.