---
name: work
description: Execute the "Do". Use after Approach is defined. Break down strategy into atomic, verifiable units. Enforces verification before marking complete.
---

# Work (The Execution)

## Philosophy

You are not just "doing tasks." You are producing **evidence of progress**.

**The Iron Law**: If it isn't verified, it isn't done. It's just typing.

## When to Use

- User says "Implement this"
- User says "Let's start coding"
- An **Approach** document is ready

## The Process

1. **Decompose the Approach**:
   - Break strategy into atomic, verifiable units
   - **Atomic**: Can be completed in one commit or turn
   - **Verifiable**: Has a concrete pass/fail check

2. **Draft the Work Document**:
   - Create file: `docs/work/<date>-<slug>.md`
   - Use the template below.

3. **Execute Loop**:
   - Pick an item
   - Implement it
   - Run the verification command
   - Mark `[x]` only after verification passes
   - Record evidence in the audit trail

## The Template

```markdown
# Work: [Title]

## Intent
Link to: docs/intent/...

## Approach  
Link to: docs/approach/...

## Checklist

- [ ] **W001**: [Action]
  - Verification: `[command to prove it works]`
- [ ] **W002**: [Action]
  - Verification: `[command]`

## Verification Evidence

- [timestamp] W001: `[command]` → [result summary]
- [timestamp] W002: `[command]` → [result summary]

## Notes

Decisions, blockers, and learnings during execution.
```

## When the Plan Breaks

Reality doesn't always match the Approach. Use this heuristic:

**Note and continue** if:
- Implementation detail changes (different library, different API)
- Minor friction that doesn't affect architecture
- Add a note in the Work doc explaining the deviation

**Stop and escalate to Approach** if:
- A core assumption is wrong
- The architecture needs to change
- The strategy won't achieve the Intent

When escalating:
1. Document what broke and why in the Work doc
2. Update the Approach doc with the new strategy
3. Resume Work with revised plan

## Validation

Before starting a Ralph loop or handing off, validate the Work doc:

**Required sections:**
- [ ] Intent link (reference to `docs/intent/...`)
- [ ] Approach link (reference to `docs/approach/...`)
- [ ] Checklist with `W001`, `W002`, etc. format
- [ ] Verification command for each checklist item
- [ ] Evidence section (can be empty at start)

**Each checklist item must have:**
- [ ] Clear action description
- [ ] Verification command that produces pass/fail

**Warnings:**
- Item marked `[x]` without corresponding evidence entry
- Verification command missing or vague ("check it works")
- Checklist item too large (should be atomic)

Run validation by reviewing the doc against this checklist before starting work.

## Rules

- **Evidence Over Confidence**: Never say "I implemented X." Say "I implemented X and verified it with Y."
- **Small Batches**: If a work item takes more than ~10 minutes to verify, break it down.
- **Trace to Intent**: Does this work item actually serve the original intent?
