# 03 Work

> Execute plan units with TDD enforcement and checkpoint resume. Use when a plan path is ready for implementation.

- Skill: `leing2021/03-work` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add leing2021/03-work`
- Raw SKILL.md: https://api.skillmd.com/api/skills/leing2021/03-work/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: leing2021 (https://skillmd.com/u/leing2021)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/leing2021/03-work

---


# Work

Use this skill when there is a plan path or tightly scoped bare prompt ready for execution.

See [shared pipeline instructions](../references/pipeline-config.md) for model routing and pipeline behavior.

## Core rules

1. Load project rules before writing any code: detect language via repo markers (map in Workflow step 2), then load `rules/common/development-workflow.md`, `rules/common/testing.md`, matching `rules/{lang}/` files, plus `rules/web/` for frontend/browser concerns. Emit a `Rules loaded:` manifest — **no manifest, no implementation**
2. **Priority:** project-level `{repo-root}/rules/` overrides package defaults
3. **Distinguish input:** plan path vs bare prompt
4. Derive tasks from plan **implementation units**
5. **Execution mode:** **inline mode** — all plan units execute inline in the current session. No built-in subagent tools.
6. Use **`session_checkpoint`** to track progress and enable resume; before executing a plan, flip its Status header to `executing`
7. Use **`task_splitter`** to analyze dependencies before execution
8. If in **worktree** (via `07-worktree`), execute inside it
9. End by recommending `04-review`
10. When designing/restructuring modules, use the deep-module vocabulary (`../references/module-design.md`) — evaluate depth and seam placement.
11. **Continuous execution:** do not pause between units for confirmation. Progress goes to `session_checkpoint`; report once at completion. Four — and only four — valves may stop and ask: (1) stop-the-line failure that cannot self-heal, (2) 3-failure cap on the same unit, (3) destructive or irreversible operations (delete, overwrite, force-push, or anything without an undo path), (4) spec ambiguity or plan gap discovered mid-execution — record as blocker, ask, never guess. Do not automate past any valve.

> **Advanced:** If you need external child agent delegation (background runs, parallel audits), install `pi-subagents` separately. Super Pi does not require it.

## Hard gates — TDD enforcement

Every step follows **RED → GREEN → REFACTOR**:

**Blocking violations** — stop and ask if:
- Code written before RED test
- RED fails for wrong reason
- Missing evidence test failed before implementation
- Missing evidence test passed after implementation
- Tests added only after code

## Stop-the-line rule (Hard gate)

When any unexpected failure occurs during execution:

1. **STOP** adding features or making changes
2. **PRESERVE** evidence (error output, repro steps)
3. **DIAGNOSE** root cause — follow debug discipline (`references/debug-discipline.md`): build feedback loop first, then reproduce → hypothesise → instrument → fix
4. **FIX** the root cause, not the symptom
5. **GUARD** with a regression test
6. **RESUME** only after verification passes

Anti-rationalization — when a gate fails or evidence is missing:
- Do not rationalize, downgrade, or explain away the failure.
- Stop, report the blocker with evidence, and either fix the root cause or ask for direction.
- Do not continue unrelated implementation after failed verification.

Common rationalizations and their reality:

| Excuse | Reality |
|--------|---------|
| "Close enough — the gate almost passed" | A failed gate means not done. Fix it or stop and report; those are the only exits. |
| "One more retry will converge" | Past the 3-failure cap, retries do not converge — the failure is structural. Ask for direction. |
| "The fix is tiny, skip re-verification" | Unverified fixes are how regressions land. Every fix ends with verification. |
| "This failure is a special case" | No evidence, no exception. Treat it like every other failure. |

This is a hard gate — do not push past a failing test or broken build to continue implementation. Errors compound.

## Error compaction after recovery

After a stop-the-line failure is diagnosed, fixed, and verified:

1. Replace full traces with `ERROR(resolved): <root cause>`; keep only the final repro, root cause, fix summary, and verification result
2. Remove stale debug output and failed exploratory runs; update `session_checkpoint` with the compacted state only

If the same tool, command, or implementation unit fails 3 consecutive times, stop retrying and ask the user for direction with a concise evidence summary.

## Workflow

1. **Load context**: consume latest handoff before any broad file reads — `context_handoff load` or read `.context/compound-engineering/handoffs/latest.md`. If found, use `activeFiles`, `blocker`, `verification`, `activeRules` as starting point; `activeRules` may already list loaded rules — verify against the repo, do not blindly trust. If not found, proceed normally. Read `CONTEXT.md` if it exists at root — see `../references/domain-language.md`.
2. **Load project rules** (blocking — no implementation before this completes):
   - Detect language: merge `{repo-root}/rules/language-detection.md` (project-level map, same marker wins) with the built-in table: `tsconfig.json`/`package.json`→typescript, `Cargo.toml`→rust, `go.mod`→golang, `pyproject.toml`/`requirements.txt`→python; others in [language detection](../references/language-detection.md)
   - Check `{repo-root}/rules/` first (overrides package defaults); then load `rules/common/development-workflow.md`, `rules/common/testing.md`, matching `rules/{lang}/` files, `rules/web/` only for frontend/browser concerns
   - Emit manifest before any code: `Rules loaded: language=<lang> (via <marker>[, project-level map]), common=<files>, lang=<files>, web=<files or N/A>`
   - **Same-session re-entry:** if the transcript already contains a `Rules loaded:` manifest for the same language, do not re-read the rule files — reuse them, cite the earlier manifest, and note the skip
3. Detect input type (plan path vs bare prompt)
4. Read implementation units if plan path
5. Load `session_checkpoint` to skip completed units
6. Use `task_splitter` for dependency analysis
7. Execute: **inline mode** — all units run in the current session
8. Follow TDD per unit: RED → minimal code → GREEN → refactor → unit-level **verification**
9. **Source-driven gate:** Before implementing framework/library-specific code, verify the API or pattern against official documentation. Flag unverified patterns as UNVERIFIED in output.
10. Record progress via `references/progress-update-format.md`
11. Save `session_checkpoint` after each unit
12. On failure: `session_checkpoint` `fail` → `retry` → follow strategy
13. Provide completion report (see `references/completion-report.md`) — include the `Rules applied` section
14. **Save handoff**: `context_handoff save` with current stage, next stage, activeFiles, blocker, verification, activeRules (carry loaded rules in `activeRules`)
15. Handoff to `04-review` using `references/handoff.md`

Before finishing this skill, apply the completion checklist in [shared pipeline instructions](../references/pipeline-config.md).