From ralph-dev
Breaks PRDs into atomic, testable tasks using the Ralph-dev CLI for modular file storage and sequential task creation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ralph-dev:phase-2-breakdownThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Break down the PRD into atomic, testable tasks (each <30 minutes), create task files via CLI, and get user approval before implementation.
Break down the PRD into atomic, testable tasks (each <30 minutes), create task files via CLI, and get user approval before implementation.
.ralph-dev/prd.mdIMPORTANT: This skill requires the Ralph-dev CLI. It will build automatically on first use.
# Bootstrap CLI - runs automatically, builds if needed
source ${CLAUDE_PLUGIN_ROOT}/shared/bootstrap-cli.sh
# Verify CLI is ready
ralph-dev --version
# Context-compression resilience: Verify current phase
CURRENT_PHASE=$(ralph-dev state get --json 2>/dev/null | jq -r '.phase // "none"')
echo "Current phase: $CURRENT_PHASE"
# Expected: breakdown
# Ensure .ralph-dev is gitignored (add if missing)
git check-ignore -q .ralph-dev 2>/dev/null || {
echo ".ralph-dev/" >> .gitignore
git add .gitignore && git commit -m "chore: gitignore .ralph-dev temp files"
}
# Verify PRD exists
[ -f ".ralph-dev/prd.md" ] || { echo "ERROR: PRD not found"; exit 1; }
Read .ralph-dev/prd.md and extract:
For each user story, create 1-3 tasks following these rules:
Task Breakdown Rules:
Task Naming Convention: {module}.{feature}.{aspect}
auth.signup.ui, auth.signup.api, auth.signup.testsCRITICAL: Create tasks one at a time for context-compression resilience.
CRITICAL — write the FULL enriched body, not just a description. Every task
MUST carry the complete 8-section contract (see Task File Format below).
Author it into a temporary Markdown file and pass it with --body-file, so the
contract is preserved verbatim and reaches the implementer in Phase 3. A bare
--description task is the thin version the system must refuse to ship.
# Initialize tasks
ralph-dev tasks init --project-goal "..." --language "..."
# For each task: write the enriched 8-section body to a temp file …
BODY_FILE="$(mktemp -t ralph-task.XXXXXX.md)"
cat > "$BODY_FILE" <<'EOF'
# {Task Title}
## Context
{Why this task exists and where it fits in the system}
## Spec Basis
{Cite the PRD or design-doc clauses this task implements}
## Interface / Contract
{Inputs, outputs, type signatures, error returns}
## TDD
{The failing tests to write first and the cases to cover}
## Edge Cases & Failure Modes
{Boundary conditions, concurrency, errors, rollback}
## Files Touched
{Files to be created or modified}
## Definition of Done
{Verifiable definition-of-done checklist}
## Acceptance Criteria
1. {Testable criterion}
2. {Testable criterion}
EOF
# … then create the task with the body attached (one at a time, not batched)
ralph-dev tasks create \
--id "{module}.{feature}" \
--module "{module}" \
--priority {N} \
--estimated-minutes {M} \
--description "{one-line summary}" \
--criteria "Criterion 1" \
--criteria "Criterion 2" \
--body-file "$BODY_FILE" \
--json
rm -f "$BODY_FILE"
# Verify creation
ralph-dev tasks list --json
The
--criteriaflags still populate the indexed projection (used for quick listing). The## Acceptance Criteriasection in the body should mirror them.
Display the task plan and ask for user approval:
📋 Task Plan
**Total Tasks**: {N} tasks
**Estimated Time**: {X} hours
## Tasks by Module
### Module: {name} (Priority {range})
1. [P{n}] {task.id} - {description} ({minutes} min)
...
Use AskUserQuestion tool:
case "$ANSWER" in
"Yes, proceed"*)
ralph-dev state update --phase implement
;;
"Modify first"*)
echo "Edit files in: .ralph-dev/tasks/"
echo "Resume with: /ralph-dev resume"
exit 0
;;
"Cancel"*)
ralph-dev state clear
exit 1
;;
esac
REQUIRED Output Format:
---PHASE RESULT---
phase: breakdown
status: complete
tasks_created: {N}
tasks_dir: .ralph-dev/tasks
estimated_hours: {X}
next_phase: implement
---END PHASE RESULT---
Tasks use an 8-section contract. The frontmatter is managed by the CLI and regenerated on every status change; the body below it is author-owned and preserved verbatim — status transitions never wipe it.
---
id: {module}.{task-name}
module: {module-name}
priority: {number}
status: pending
estimatedMinutes: {number}
dependencies: [{task-ids}]
---
# {Task Title}
## Context
{Why this task exists and where it fits in the system}
## Spec Basis
{Cite the PRD or design-doc clauses this task implements}
## Interface / Contract
{Inputs, outputs, type signatures, error returns}
## TDD
{The failing tests to write first and the cases to cover}
## Edge Cases & Failure Modes
{Boundary conditions, concurrency, errors, rollback}
## Files Touched
{Files to be created or modified}
## Definition of Done
{Verifiable definition-of-done checklist}
## Acceptance Criteria
1. {Testable criterion}
2. {Testable criterion}
How it is persisted: author this body into a temp file and pass it via
ralph-dev tasks create --body-file <path> (see Step 4). The CLI stores it
verbatim; tasks start/done/fail only rewrite the frontmatter, so the enriched
sections survive the full task lifecycle.
header: ≤12 chars (e.g., "Approval")| Error | Action |
|---|---|
| PRD not found | Fail, prompt to run Phase 1 |
| Task creation fails | Retry once, then report error |
| User rejects plan | Save state, allow manual editing |
npx claudepluginhub mylukin/ralph-dev --plugin ralph-devBreaks PRDs into ordered production-ready engineering tasks with embedded success criteria, tests, benchmarks, and non-functional requirements for /execute-task execution. Use for PRD-to-tasks conversion and feature planning as mergeable PRs.
Generates ordered task YAML from PRD markdown file with sequential IDs, dependencies, descriptions, and acceptance criteria. Use after creating or reviewing a PRD for implementation planning.
Generates PRDs from task descriptions, manages parallel story execution with dependency resolution, and provides context-filtered agents for multi-story development.