Implementation Loop

Overview

A multi-ticket project runs as a resumable loop recorded in a control note. Each cycle implements ONE ticket, proves the result with evidence, and stops at the gate. Whoever resumes (you tomorrow, another agent, a worker) needs only the note and git.

Principle: the loop finishes tickets, not sessions. A ticket closes only with evidence + an approved gate; without both it is not done, however done it looks.

Optional conceptual background: the harness-loop skill (Loop × Harness separation). This skill is the execution template.

When to Use

• "Implement project/epic X", "do the tickets in the plan", "resume the loop".
• Work that won't fit in one session or will be continued by another agent/worker.

Don't use for an isolated single-ticket change — just implement it.

Step 0 — User decisions (before any code)

Ask in a single message, showing the suggested default for each item, and record the answers in the note under "User decisions — <date>". The project may already answer some of them in CLAUDE.md/AGENTS.md, memories, or a previous loop note: if so, present that answer for confirmation. No answer, no code. "Go with the defaults" is an answer: record the defaults.

Step 1 — Control note

Create the note from template.md (in this folder). Location: the project's convention (e.g. a loops/ folder in the docs/Obsidian vault mentioned in CLAUDE.md); with no convention, docs/loops/Implementation <project>.md. Write the note in the project's documentation language. Fill the verification table with the project's REAL commands (read CLAUDE.md, package.json, pyproject, etc.) and the "Project rules in the cycle" section with the per-ticket obligations from the project's instructions (final builds, deploy checklist, report, comment language...).

Resuming without a note (missing or inconsistent with git): rebuild the state from git and the plan in a "Reconstruction cycle", show it to the user, and only then proceed.

The cycle (one ticket at a time)

1. Context: reread the project instructions, the plan, and the note. Check git status/git log against the last recorded cycle; on divergence the code wins — fix the note.
2. Selection: the first pending ticket whose dependencies have an approved gate. Extract tasks, DoD, and tests; state which go into this increment.
3. Branch per the recorded decision (when resuming, use the existing one).
4. Implement the increment, with tests for the changed behavior, applying clean-code (see "With /clean-code"). Scope is locked: nothing beyond the ticket without user confirmation.
5. Verify: run the table. Record command, directory, result, and exit code. A command not run, a missing tool, or an environmental failure is pending, never a success.
6. Self-review the full diff before asking to commit: security, data isolation, business rules, duplication, conventions, and the clean-code checklist. Fix and re-verify whatever was affected. This is NOT the gate: the gate is the formal decision in step 8, with a recorded verdict.
7. Commit (with authorization) and record the full hash in the note.
8. Close: assemble the gate package (commits, commands and results, evidence for each DoD criterion, limitations). STOP and hand it to the user.
9. Record: update the note at the end of EVERY cycle, including interrupted ones, ending with the exact next step.

Stop rules

With /orchestration

If the decision is to use workers: REQUIRED SUB-SKILL: use orchestration to dispatch, wait for, and read each delivery. You are the coordinator: write the ticket spec (record its path in the note) with the clean-code requirement in its Constraints, review the worker's diff as in step 6, and decide the gate. A worker never marks a ticket done; only the coordinator does, after review. Record run/task/dispatch IDs in the note.

Parallelism: tickets with no dependency on each other may go to different workers at the same time, each with its own cycle and gate. A ticket is dispatched only when all its dependencies have an approved gate.

With /clean-code

Every implementation: REQUIRED SUB-SKILL: use clean-code while writing the code (step 4) and when self-reviewing the diff (step 6), whether the implementer is you or a worker. When the execution is via /orchestration, the ticket spec carries the clean-code checklist under Constraints and the coordinator checks it in the worker's diff before the gate. Record in the gate package the checklist result and any justified exception.

Scope and precedence: clean-code is a set of design heuristics, not a license to refactor beyond the ticket or change behavior. The project's instructions (CLAUDE.md/AGENTS.md) win on conflict — e.g., when the project requires comments explaining the why, keep them and remove only redundant or noise comments. Apply it to the code the ticket touches, without reformatting unrelated code.

Checklist (in the diff of each ticket):

• Size & responsibility: each new or changed function does one thing at one level of abstraction; long functions (≈ 20+ lines) are split or justified.
• Naming: intention-revealing, searchable names (nouns for classes, verbs for methods); no disinformation.
• Comments: no redundant or noise comments; the why comments required by the project stay.
• Arguments: 0–2 per function; 3+ only with justification (prefer a parameter object).
• Error handling: domain exceptions/errors per the project, not return codes; no returning or passing null where the language/project offers a better alternative.
• Tests: a focused test that fails without the change exists for each changed behavior (F.I.R.S.T.).
• No smells: no duplication, needless complexity, hidden side effects, or Law of Demeter chains introduced by the diff.

Rationalizations vs. reality

Red flags — stop

• Starting ticket N+1 without ticket N's gate.
• Writing "done" without the verification table filled in.
• Handing over the gate package without the clean-code checklist result.
• Control note out of date relative to git.

Créditos / Credits

• Autor / Author: hanspeterdietiker — skill e template.md.

Sub-skills referenciadas / Referenced sub-skills: