From ralph-ban
Decomposes plans, design docs, and requirements into epics and tasks with EARS specs for ralph-ban board orchestration. Creates worker-ready cards via bl CLI with priorities, dependencies, and epic grouping.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ralph-ban:rb-planning [plan, design doc path, or requirement description][plan, design doc path, or requirement description]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Break down $ARGUMENTS into epics and tasks on the bl board. The rb-orchestrator will dispatch workers from these cards, so every card must be self-contained and worker-ready.
Break down $ARGUMENTS into epics and tasks on the bl board. The rb-orchestrator will dispatch workers from these cards, so every card must be self-contained and worker-ready.
Skip this phase when:
rb-brainstorm (already contains Architecture and Decisions sections)Run this phase when:
Steps:
mkdir -p .agent-history/ and save decisions to .agent-history/YYYY-MM-DD-<topic>-design.mdRead the plan, outline, or context provided. If $ARGUMENTS references files, read them. If it describes work verbally, use that directly.
Identify the codebase context:
bl ready and bl list --status backlog for existing board state (never full bl list which dumps the large done column)Group related work into epics. Each epic is a theme (e.g., "New Widgets", "Rendering Improvements"). Tasks within an epic share a concern but can often be worked independently.
Epic guidelines:
Task guidelines:
For each task, write all three parts: description, specs, and metadata.
The description is the worker's primary context. It must answer:
Include reference file paths when prior art exists (e.g., .cloned-sources/ projects, existing similar code in the repo). A worker with a good description and no other context should be able to complete the card.
End every description with:
REMINDER: Read existing code patterns in the target package before implementing.
Specs are acceptance criteria. The bl CLI blocks the review transition until all specs are checked off. For notation patterns and examples, read references/ears-guide.md.
Specs describe the task; the oracle exercises it. Every task card carries an
## Oracle block telling rb-oracle how to drive the change.
## Oracle
kind: terminal | browser | cli | http | library | none
exercise: <one or two sentences naming what to drive and what to look for>
Surface choices:
task for implementation, epic for grouping--blocked-by <id> when task B needs task A's output--epic <id> to group under a parentMap the dependency graph before creating cards:
For research-dependent work, split into two cards:
Before creating cards, present the full plan to the user:
Revise based on feedback. This catches decomposition problems before cards are created.
Use bl to create the cards. Create epics first, then tasks with --epic and --blocked-by flags. All cards start in backlog, then promote to todo when specs and file scope are verified.
bl create "Epic title" --type epic -p1 --status backlog --description "..."
bl create "Task title" --epic <epic-id> -p1 --status backlog --blocked-by <dep-id> \
--description "..." \
--spec "When X, the system shall Y" \
--spec "The module shall be registered as 'name' in Registry" \
--spec "Unit test: <specific test scenarios>"
After creating cards with specs, promote to todo:
bl update <id> --status todo
Before presenting the board, verify:
## Oracle block with kind and exercisekind: none, the description includes a rationale a skeptic would accept (changes that lint+tests cannot catch are not none)After verification, run bl ready --tree and present the board to the user:
"Board ready for orchestrator dispatch?"
npx claudepluginhub kylesnowschwartz/ralph-ban --plugin ralph-banDecomposes specs into ordered, verifiable tasks with acceptance criteria using vertical slicing and dependency graphs. Use for large tasks, scope estimation, or parallel agent work.
Decomposes feature requests into phased task boards with dependency mapping, parallelization flags, risk flags, edge cases, and test matrices.
Convert technical designs into actionable, tracked task hierarchies with sizing, dependencies, and acceptance criteria. Invoke whenever task involves any interaction with work decomposition — breaking down features into subtasks, slicing work items, creating task lists, or writing decomposition documents.