
ralph
by MillionthOdin16
Clawds exploration of itself - discoveries, memory system, capabilities, lessons learned
SKILL.md
name: ralph description: Spec-driven development with task-by-task execution. Transforms feature ideas into structured specs (research, requirements, design, tasks) then executes them autonomously with fresh context per task. Supports parallel task execution with [P] markers.
Ralph Loop Skill
Spec-driven development for autonomous agent workflows. Transform vague feature ideas into executable specs, then execute task-by-task with fresh context.
When to Use This Skill
Use when you need to:
- Build features systematically: Research → Requirements → Design → Tasks → Implementation
- Execute complex multi-step tasks: Task-by-task with progress persistence
- Handle long-running implementations: Fresh context per task prevents context overflow
- Parallelize independent tasks: Mark tasks with [P] for concurrent execution
- Maintain quality gates: [VERIFY] checkpoints and POC-first workflow
Quick Start
# Smart entry: resume or create new spec
/ralph:start feature-name Add JWT authentication
# Quick mode: auto-generate all specs and execute
/ralph:start "Add user auth" --quick
# Step-by-step
/ralph:new user-auth Add JWT authentication
/ralph:research
/ralph:requirements
/ralph:design
/ralph:tasks
/ralph:implement
Commands
| Command | Purpose |
|---|---|
/ralph:start [name] [goal] | Smart entry: resume existing or create new |
/ralph:start [goal] --quick | Quick mode: auto-generate and execute |
/ralph:new <name> [goal] | Create new spec, start research |
/ralph:research | Run/re-run research phase |
/ralph:requirements | Generate requirements from research |
/ralph:design | Generate technical design |
/ralph:tasks | Break design into executable tasks |
/ralph:implement | Execute tasks one-by-one (or parallel) |
/ralph:status | Show all specs and progress |
/ralph:switch <name> | Change active spec |
/ralph:cancel | Cancel loop, cleanup state |
/ralph:help | Show help |
The Ralph Loop
Feature Request
|
v
+-----------------+
| Research | <- Analyzes feasibility, codebase, web search
+-----------------+
|
v
+-----------------+
| Requirements | <- User stories, acceptance criteria
+-----------------+
|
v
+-----------------+
| Design | <- Architecture, patterns, decisions
+-----------------+
|
v
+-----------------+
| Tasks | <- POC-first task breakdown
+-----------------+
|
v
+-----------------+
| Implementation | <- Task-by-task with fresh context
+-----------------+
|
v
Feature Done
Parallel Task Execution
Mark tasks with [P] for parallel execution:
- [ ] 1.1 [P] First parallel task
- [ ] 1.2 [P] Second parallel task (runs with 1.1)
- [ ] 1.3 [P] Third parallel task (runs with 1.1, 1.2)
- [ ] 1.4 Sequential task (breaks group, runs alone)
- [ ] 1.5 [VERIFY] Checkpoint (never parallel)
Rules
- Consecutive
[P]tasks form a parallel group - Non-[P], [VERIFY], or [SEQUENTIAL] tasks break the group
- [VERIFY] and [SEQUENTIAL] override [P] if on same line
- Max 3 concurrent executors per batch
- Partial failures preserve successful task progress
Sub-Agents
| Agent | File | Role |
|---|---|---|
| research-analyst | agents/research-analyst.md | Web search, codebase analysis |
| product-manager | agents/product-manager.md | User stories, acceptance criteria |
| architect-reviewer | agents/architect-reviewer.md | Technical design, architecture |
| task-planner | agents/task-planner.md | POC-first task breakdown |
| spec-executor | agents/spec-executor.md | Autonomous task implementation |
| qa-engineer | agents/qa-engineer.md | Quality verification |
| plan-synthesizer | agents/plan-synthesizer.md | Plan synthesis |
Project Structure
skills/ralph/
├── SKILL.md <- This file
├── agents/ <- Sub-agent definitions
│ ├── research-analyst.md
│ ├── product-manager.md
│ ├── architect-reviewer.md
│ ├── task-planner.md
│ ├── spec-executor.md
│ ├── qa-engineer.md
│ └── plan-synthesizer.md
├── commands/ <- Slash command definitions
│ ├── start.md
│ ├── new.md
│ ├── research.md
│ ├── requirements.md
│ ├── design.md
│ ├── tasks.md
│ ├── implement.md
│ ├── status.md
│ ├── switch.md
│ └── cancel.md
├── templates/ <- Spec file templates
│ ├── research.md
│ ├── requirements.md
│ ├── design.md
│ ├── tasks.md
│ └── progress.md
├── schemas/ <- Validation schemas
│ └── spec.schema.json
├── hooks/ <- Lifecycle hooks
│ └── hooks.json
└── scripts/ <- Utility scripts (future)
Spec Files Location
Specs live in ./specs/ in your project:
./specs/
├── .current-spec <- Active spec name
└── my-feature/
├── .ralph-state.json <- Loop state (deleted on completion)
├── .progress.md <- Progress tracking
├── research.md
├── requirements.md
├── design.md
└── tasks.md
State Management
.ralph-state.json- Runtime state: phase, taskIndex, parallelGroup, taskResults.progress.md- Learnings, completed tasks, current statustasks.md- Task list with checkboxes [ ] / [x]
POC-First Workflow (Mandatory)
All specs follow 4 phases:
- Phase 1: Make It Work - POC validation, skip tests
- Phase 2: Refactoring - Code cleanup
- Phase 3: Testing - Unit, integration, e2e
- Phase 4: Quality Gates - Lint, types, CI, PR
Quality checkpoints ([VERIFY]) inserted every 2-3 tasks.
Task Format
- [ ] 1.1 Task name
**Do**: Exact implementation steps
**Files**: File paths to create/modify
**Done when**: Success criteria
**Verify**: Command to verify completion
**Commit**: Conventional commit message
Task Completion Protocol
Spec-executor must output TASK_COMPLETE for the stop-handler to advance. If missing, task retries up to 5 times then blocks with error.
Verification Layers
The stop-handler enforces:
- Contradiction detection - Rejects completion if output mentions manual action
- Uncommitted files check - Validates tasks.md and .progress.md are committed
- Checkmark verification - Confirms task marked [x] in tasks.md
- Signal verification - Requires TASK_COMPLETE
Parallel Execution Flow
- Coordinator parses tasks.md for
[P]markers - Detects consecutive parallel groups
- Spawns multiple spec-executors via Task tool (all in ONE message)
- Each executor writes to isolated
.progress-task-N.md - Coordinator merges temp files after batch completes
- Advances taskIndex past entire group
Example Workflow
# Start a new spec
/ralph:start analytics-dashboard Build real-time analytics dashboard
# Research phase (auto-runs in quick mode)
/ralph:research
# Generate requirements
/ralph:requirements
# Create design
/ralph:design
# Break into tasks
/ralph:tasks
# Execute (parallel tasks marked with [P])
/ralph:implement
# Check status
/ralph:status
# Switch to different spec
/ralph:switch another-feature
Tips
- Use
--quickflag for rapid prototyping - Use
[VERIFY]for quality checkpoints - Use
[P]for independent tasks that can run in parallel - Use
[SEQUENTIAL]to force sequential execution even if [P] is present - Progress persists across sessions via spec files
- Cancel and start fresh with
/ralph:cancel
Framework Execution Rules (MANDATORY)
The Non-Negotiable Rules
-
DELEGATION IS MANDATORY
- You MUST invoke
scripts/spec-executor.pyfor task execution - You MUST NOT execute tasks yourself directly
- Even simple tasks require delegation
- You MUST invoke
-
GIT COMMIT DISCIPLINE
- Every task = one commit
- Use EXACT commit message from Commit field
- Commit tasks.md, progress file, and code together
-
TASK_COMPLETE SIGNAL
- spec-executor MUST output exactly
TASK_COMPLETE - No output = task not complete
- The stop-hook checks for this signal
- spec-executor MUST output exactly
-
STATE FILE MANAGEMENT
- Only
scripts/coordinator.pymodifies.ralph-state.json - spec-executor MUST NOT touch state file
- Read-only access only
- Only
-
PROGRESS FILE UPDATES
- Write to
.progress.md(or.progress-task-N.mdfor parallel) - Follow exact format: ## Completed Tasks, ## Current Task, ## Learnings, ## Next
- Include commit hash for each completed task
- Write to
Helper Scripts
These scripts ENFORCE Ralph framework rules:
scripts/new-spec.py
python /home/opc/clawd/skills/ralph/scripts/new-spec.py <name> [goal]
Creates new spec with all required files and initializes state.
scripts/coordinator.py
python /home/opc/clawd/skills/ralph/scripts/coordinator.py <spec-name>
Coordinator implementation:
- Reads state to determine current task
- Invokes spec-executor for each task (DELEGATION)
- Updates state after each task
- Handles parallel task groups
scripts/spec-executor.py
python /home/opc/clawd/skills/ralph/scripts/spec-executor.py <spec-name> <task-index> [progress-file]
Spec-executor implementation:
- Executes ONE task from tasks.md
- Runs verification command
- Commits with exact commit message
- Updates progress file
- Outputs
TASK_COMPLETE
Correct Execution Pattern
# WRONG ❌ - What I did before:
# - Executed tasks myself
# - No git commits
# - No TASK_COMPLETE signals
# - Modified state directly
# CORRECT ✅ - How to use Ralph framework:
1. python scripts/new-spec.py my-feature "Add auth"
2. Fill in research.md, requirements.md, design.md, tasks.md
3. python scripts/coordinator.py my-feature
└── Invokes spec-executor.py for each task
└── spec-executor.py:
- Executes task
- Verifies
- Commits (exact message)
- Updates progress
- Outputs TASK_COMPLETE
└── coordinator.py checks for TASK_COMPLETE
└── coordinator.py advances taskIndex
4. Repeat until all tasks complete
Related Files
- Templates:
templates/*.md- Spec file structures - Schema:
schemas/spec.schema.json- State validation - Agents:
agents/*.md- Sub-agent definitions - Commands:
commands/*.md- Command implementations - Scripts:
scripts/*.py- Helper scripts that enforce rules
Testing
Run unit tests to verify spec-executor functionality:
python /home/opc/clawd/skills/ralph/scripts/test_spec_executor.py
Tests cover:
- Function extraction from Do field
- Python code generation
- File name parsing
- Task section parsing
- Integration tests
Troubleshooting
Verification Fails
- Check that Verify command runs correctly in the spec directory
- Ensure dependencies are installed
- Verify the generated code matches requirements
Task Not Found
- Check that tasks.md uses proper format (
- [ ] 1.1) - Ensure task hasn't already been marked complete
Commit Failed
- Verify git is initialized
- Check that files exist before committing
State File Issues
- Never edit
.ralph-state.jsonmanually - Let coordinator.py manage state
- If stuck, delete state file and restart
Quick Reference
Command Cheat Sheet
| Command | Script | Purpose |
|---|---|---|
| Create spec | new-spec.py <name> <goal> | Initialize new spec |
| Execute tasks | coordinator.py <name> | Run all tasks |
| Single task | spec-executor.py <name> <idx> | Run one task |
| Test | test_spec_executor.py | Run unit tests |
File Locations
skills/ralph/
├── SKILL.md ← Main documentation
├── agents/ ← 7 sub-agent definitions
├── commands/ ← 13 slash commands
├── templates/ ← 5 spec templates
├── schemas/ ← JSON schema validation
├── hooks/ ← Stop handler
└── scripts/ ← Python utilities
├── new-spec.py
├── coordinator.py
├── spec-executor.py
├── test_spec_executor.py
└── quick-start.py
Common Issues
| Issue | Solution |
|---|---|
| Verification fails | Check verify command syntax |
| Git lock timeout | Wait 30s, git operation in progress |
| State file stuck | Delete .ralph-state.json and restart |
| Parallel tasks fail | Ensure tasks marked [P] consecutively |
Environment Variables
None required. All paths are absolute.
スコア
総合スコア
リポジトリの品質指標に基づく評価
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
レビュー
レビュー機能は近日公開予定です