Ralph Tasks
Create ralph-tasks.md for unattended TDD implementation
Claude CodeGeneric
---
allowed-tools: Bash(cat:*), Bash(grep:*), Bash(test:*), Bash(find:*), Bash(touch:*), Bash(ls:*), Bash(echo:*), Read, Write, Glob, Agent, AskUserQuestion
description: Create ralph-tasks.md for unattended TDD implementation
---
## Context
Current spec directory: specs/
**Purpose**: Generate `ralph-tasks.md` formatted for **unattended** TDD execution via the
Ralph loop. ralph tasks have no approval gates and include all context needed for a fresh
Claude session.
**Standalone — derived directly from the approved design.** This command does **not** require
`tasks.md` or `.tasks-approved`. It is a peer alternative to `/spec:tasks`: from an approved
design (`.design-approved`) you run *either* `/spec:tasks` (attended path) *or*
`/spec:ralph-tasks` (unattended path) — not both. The ralph task list is generated straight
from `requirements.md` + the accepted ADRs. (If a `tasks.md` happens to exist from an earlier
attended pass, ignore it — the source of truth is the approved design.)
**Sub-agent**: Drafting the ralph task list is delegated to a sub-agent
(`subagent_type: "Plan"`, **`model: "opus"`**). `Plan` has no `Write`/`Edit`/`NotebookEdit`,
which makes it much harder to accidentally write the file (the prompt still forbids writing
via `Bash`), while still allowing Read/Glob/Grep to verify test/impl paths. The sub-agent reads the
requirements and ADRs and RETURNS the ralph task list as text. The main agent runs the
validation checklist and writes the file. See `.claude/commands/spec/README.md` →
"Sub-agents & model policy".
## Your Task
### Step 1: Gather Context
1. Read `specs/.current-spec` to determine the active specification directory
2. Verify `.design-approved` exists in that directory (ralph-tasks derives from the approved design)
3. Read `specs/{current-spec}/requirements.md` for requirement context
4. Read `specs/{current-spec}/.adr-list` to see all ADRs
5. Read each ADR from `docs/adr/` to understand design decisions
Do **not** read or depend on `tasks.md` — ralph-tasks is generated directly from the approved
design, independent of the attended `/spec:tasks` path.
### Step 2: Verify Prerequisites
- `.design-approved` MUST exist (ralph-tasks derives from the approved design)
- All ADRs MUST have Status "Accepted"
If prerequisites not met, inform user and exit. Do NOT launch the sub-agent. (Note: there is
**no** `.tasks-approved` prerequisite — that marker belongs to the attended `/spec:tasks` path.)
### Step 3: Launch Sub-Agent to Draft ralph-tasks.md
**Verify inputs with the user before launching (MAIN agent).** The `Plan` sub-agent is
one-shot and has no `AskUserQuestion` — it cannot ask the user anything once launched. And
because the ralph-tasks it produces are later executed **unattended** (no approval gates),
any ambiguity must be resolved now. So before launching, review the requirements and ADRs for
open decisions that affect unattended execution (task granularity, ordering, scope boundaries,
anything that would need a human judgement call mid-loop) and resolve them with the user via
`AskUserQuestion`. Then launch the sub-agent with the clarified inputs folded in. All user
interaction stays in the main agent — never the sub-agent.
Launch an `Agent` with `subagent_type: "Plan"` and **`model: "opus"`**. The
prompt MUST include:
1. The full text of `requirements.md` and each ADR (or their paths to read). The sub-agent
decomposes the approved design into atomic ralph tasks itself — there is no `tasks.md` to
reformat.
2. The document structure, task format, key differences, and quality rules below.
3. An explicit instruction: **RETURN the complete ralph-tasks.md content as markdown text.
Do NOT write any file.** The sub-agent may use Read/Glob/Grep to verify the test/impl
file paths and `RALPH-VERIFY` filters it references are realistic.
#### Document Structure (include in the sub-agent prompt)
```markdown
# Ralph Tasks: {spec-name}
> Auto-generated from tasks.md for unattended TDD execution.
> Each task is self-contained with all context a fresh Claude session needs.
## Spec Context
- **Spec**: {spec-name}
- **Requirements**: specs/{current-spec}/requirements.md
- **ADRs**: {list of ADR file paths}
## Tasks
{task list}
Task Format (include verbatim in the sub-agent prompt)
CRITICAL: Each task MUST follow this exact format:
- [ ] **[Brief behavior description]**
- **Behavior**: [Precise behavioral specification - what should happen when X]
- **Test file**: `tests/[Project]/[When_condition_should_behavior.cs]`
- **Test should verify**:
- [Verification point 1]
- [Verification point 2]
- **Implementation files**:
- `src/[Project]/[File.cs]` - [What to add/change]
- **RALPH-VERIFY**: `dotnet test tests/[Project]/ --filter "FullyQualifiedName~When_condition_should_behavior"`
- **References**: [ADR numbers, requirement sections, existing code files to read]
How ralph-tasks differ from the attended /spec:tasks output (include in the sub-agent prompt)
ralph-tasks are written for an unattended loop, so they differ from what /spec:tasks
produces for the attended path:
| Feature | /spec:tasks (attended) |
ralph-tasks.md (unattended) |
|---|---|---|
| Approval gates | ⛔ STOP HERE after each test |
None |
/test-first directive |
USE COMMAND: /test-first ... |
None |
| Verification command | None | RALPH-VERIFY: with exact dotnet test filter |
| Context references | Assumes human context | References: section with files/ADRs to read |
| Atomicity | Grouped by phase | Strictly one behavior per task |
Do not emit ⛔ STOP HERE or /test-first directives — those belong to the attended path.
Quality Rules (MANDATORY — include in the sub-agent prompt)
Apply these rules to EVERY task:
- One thing per task: Single endpoint, component, migration, or behavior. Never combine.
- Testable in isolation: Af
Maintain Ralph Tasks?
Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.
[](https://getagentictools.com/loops/brightercommand-ralph-tasks-spec-name?ref=badge)