| name | task-writing |
| description | Use this skill when writing TASKS.md for Builder RALPH loops. Ensures tasks are properly scoped, ordered, and actionable for autonomous execution. |
Writing Excellent TASKS.md for Builder RALPH Loops
Overview
When FULLSEND decides to build a tool, it spawns a RALPH loop for Builder. The quality of the TASKS.md directly determines whether the RALPH loop succeeds or fails. This skill teaches you how to write tasks that Builder's Claude Code instances can execute autonomously.
The RALPH Loop Mental Model
Each task in TASKS.md will be executed by a fresh Claude Code instance that:
- Has NO memory of previous tasks (except via STATUS.md)
- Can only see: the task description, STATUS.md context, and the codebase
- Must complete autonomously without human intervention
- Must know exactly when it's "done"
This means each task must be self-contained and verifiable.
Task Anatomy
- [ ] TASK-001: [Action Verb] [Specific Target] [Measurable Outcome]
Good Examples
- [ ] TASK-001: Research GitHub API pagination and rate limits, document findings in STATUS.md
- [ ] TASK-002: Write core github_scraper function with pagination support in tools/github_scraper.py
- [ ] TASK-003: Add rate limiting (max 30 requests/minute) to github_scraper
- [ ] TASK-004: Run smoke test with octocat/Hello-World repo and verify dict return format
- [ ] TASK-005: Git commit and register tool in Redis
Bad Examples
- [ ] TASK-001: Set up the project # Too vague - what does "set up" mean?
- [ ] TASK-002: Make it work # No specificity
- [ ] TASK-003: Handle edge cases # Which edge cases?
- [ ] TASK-004: Test thoroughly # No concrete success criteria
The 7 Rules of RALPH Tasks
Rule 1: Start with Action Verbs
Every task starts with a concrete action:
- Research - Investigate APIs, docs, patterns
- Write - Create new code/files
- Add - Extend existing code with new functionality
- Fix - Resolve a specific issue
- Run - Execute tests/commands
- Update - Modify existing content
- Commit - Git operations
Rule 2: One Logical Unit Per Task
Each task should do ONE thing. If you find yourself using "and" or "then", split the task.
Too big:
- [ ] TASK-001: Write the scraper, add error handling, and test it
Just right:
- [ ] TASK-001: Write core scraper function with basic API calls
- [ ] TASK-002: Add try/except error handling with partial result returns
- [ ] TASK-003: Run smoke test with test repo
Rule 3: Include Success Criteria
The Claude Code instance needs to know when it's done. Include verification in the task or make it implicit.
Implicit verification (code tasks):
- [ ] TASK-002: Write github_scraper in tools/github_scraper.py following Builder tool contract
(Success = file exists with correct structure)
Explicit verification:
- [ ] TASK-004: Run smoke test, verify output is {result, success, error} dict format
Rule 4: Reference Concrete Paths
Claude Code navigates by file paths. Be explicit.
Vague:
- [ ] TASK-002: Write the tool
Concrete:
- [ ] TASK-002: Write github_scraper function in tools/github_scraper.py
Rule 5: Put Research First
If the task requires understanding external APIs, docs, or patterns, make research TASK-001.
- [ ] TASK-001: Research LinkedIn API rate limits and auth flow, document in STATUS.md
- [ ] TASK-002: Write linkedin_enricher using researched approach
This puts knowledge into STATUS.md where future tasks can read it.
Rule 6: End with Commit + Register
Builder's contract requires git commit and Redis registration. Make this the final task.
- [ ] TASK-00N: Git add tools/{tool_name}.py, commit with message "Add {tool_name} tool - {description}", register in Redis with HSET tools:{tool_name}
Rule 7: 4-8 Tasks is the Sweet Spot
- < 4 tasks: Probably too coarse, each task doing too much
- 4-8 tasks: Good granularity for autonomous execution
- > 8 tasks: Consider if you're over-engineering or building multiple tools
Task Templates by Tool Type
Simple API Tool (4-5 tasks)
# Tasks
Context:
- Tool: {tool_name}
- PRD: {brief description}
- Output: tools/{tool_name}.py
- [ ] TASK-001: Research {API} endpoints, auth, rate limits - document in STATUS.md
- [ ] TASK-002: Write core {tool_name} function with API calls in tools/{tool_name}.py
- [ ] TASK-003: Add error handling with partial result returns
- [ ] TASK-004: Run smoke test with realistic inputs, verify dict return format
- [ ] TASK-005: Git commit and Redis registration
Complex Scraper Tool (6-8 tasks)
# Tasks
Context:
- Tool: {tool_name}
- PRD: {brief description}
- Output: tools/{tool_name}.py
- [ ] TASK-001: Research {target} API/page structure, identify data extraction points
- [ ] TASK-002: Write core {tool_name} function with basic scraping logic
- [ ] TASK-003: Add pagination support (handle next_page tokens or page numbers)
- [ ] TASK-004: Add rate limiting (max N requests per minute)
- [ ] TASK-005: Add retry logic for transient failures (3 retries, exponential backoff)
- [ ] TASK-006: Add error handling returning partial results on failure
- [ ] TASK-007: Run smoke test with {test_target}, verify output format
- [ ] TASK-008: Git commit and Redis registration
Multi-File Tool (7+ tasks)
# Tasks
Context:
- Tool: {tool_name}
- PRD: {brief description}
- Output: tools/{tool_name}.py + tools/{tool_name}_utils.py
- [ ] TASK-001: Research {domain} patterns, plan module structure
- [ ] TASK-002: Write utility functions in tools/{tool_name}_utils.py
- [ ] TASK-003: Write main {tool_name} function importing utilities
- [ ] TASK-004: Add configuration handling (env vars or defaults)
- [ ] TASK-005: Add error handling and logging
- [ ] TASK-006: Run unit tests on utility functions
- [ ] TASK-007: Run integration smoke test on main function
- [ ] TASK-008: Git commit all files and Redis registration
STATUS.md: The Memory Bridge
Each RALPH iteration reads STATUS.md for context. Structure it to help future tasks:
# Status
## PRD Summary
Name: github_scraper
Description: Scrape GitHub stargazers with pagination
Inputs: repo (str), limit (int, optional)
Outputs: list of {username, profile_url, email}
## Research Findings
(TASK-001 will populate this)
- GitHub API: api.github.com/repos/{owner}/{repo}/stargazers
- Rate limit: 60/hr unauthenticated, 5000/hr with token
- Pagination: Link header with next page URL
## Implementation Notes
(Tasks will add notes here as they complete)
## Files Changed
(Track what was created/modified)
Common Pitfalls
Pitfall 1: Assuming Context
Wrong: "TASK-003: Continue building the scraper"
Right: "TASK-003: Add pagination to github_scraper in tools/github_scraper.py"
Each task must stand alone - the Claude Code instance doesn't remember what "continue" means.
Pitfall 2: Vague Verification
Wrong: "TASK-004: Test the tool"
Right: "TASK-004: Run smoke test with repo='octocat/Hello-World', limit=5, verify returns dict with result, success, error keys"
Pitfall 3: Missing Dependencies
If TASK-003 needs info from TASK-001, make sure TASK-001 writes that info to STATUS.md.
Wrong:
- [ ] TASK-001: Research the API
- [ ] TASK-003: Implement using the API patterns # What patterns? Where are they?
Right:
- [ ] TASK-001: Research the API, document endpoints and auth in STATUS.md
- [ ] TASK-003: Implement using API patterns from STATUS.md research section
Pitfall 4: Scope Creep
Each task should take ~1 Claude Code session. If you're describing multiple features or "and then also", split the task.
Quick Reference Checklist
Before finalizing TASKS.md, verify:
