tt-implement-phase

Contents

• How this skill runs
• Input
• Run contract
• The steps
• TaskTracker discipline
• Returning
• Invocation
• Related skills

Reference files (open one when a step points to it):

• references/dispatch.md: Dispatching Work by Role
• references/insight-cookbook.md: Insight Cookbook — logDefect / logLearning / logFriction
• references/phase-result.md: PHASE_RESULT and the Blocker Protocol
• references/step-guide.md: Step Guide

Execute a single phase whose spec lives in TaskTracker: a phase task with sub-tasks, linked requirements and acceptance criteria. This session leads the phase; role agents do the volume work; TaskTracker records everything; the phase ends with one PHASE_RESULT.

How this skill runs

• Inline: this session leads. The procedure runs in the session that invoked it: yours, or the plan session of /tt-implement-plan or /tt-workflow-run. A forked lead can't hear back from its own agents, because their reports arrive in the top-level session, so the lead stays here.
• Agents report back asynchronously. An Agent call returns at once; the agent's report arrives later as a message in this session. After dispatching, do whatever independent work is left (TaskTracker bookkeeping, the next brief); when nothing is, end the turn with one line naming what you are waiting for, and the report resumes you. Never poll with sleep or wait loops, never say you will wait and then wander off the phase, and never do a dispatched agent's work yourself meanwhile.
• Keep the in-flight list. Before ending a turn, note which agents are running and for which sub-task (those sub-tasks are in_progress in TaskTracker too), so a resumed or compacted session knows what is still outstanding.
• You lead; roles do the work. You judge: you write the briefs, map acceptance criteria to tests, decide fix rounds, classify blockers, and keep TaskTracker accurate. While the Agent tool is available you don't write code; a user asking for "foreground" work or "no background agents" means don't poll, not "write it yourself". Run the session on Opus 5.5 (or Fable 5.1) for this judgement; the volume work goes to cheaper role agents:

Briefs, the escalation rules and the fallback when an agent isn't installed → references/dispatch.md.

• Blockers go to the user. You are in the user's session: pause time tracking and ask, with two or three options and your recommendation first (references/phase-result.md). Return a BLOCKED PHASE_RESULT instead only when the input says Unattended: yes.
• If Agent isn't in your tool list, do each role's work yourself in this context. Every gate still applies.

Input

Project ID:       [TaskTracker project UUID]
Phase Task ID:    [phase task UUID — required]
Caller:           [optional — the skill or loop that invoked you, e.g. "tt-implement-plan";
                   omit when standalone. Decides the active-task step in Step 8.]
Plan context:     [optional — surfaced from the caller]
Skip Steps:       [optional]
TDD Mode:         [enabled | disabled]
Checkpoints:      [optional — none (default) | per-unit: report after every implementer unit
                   and its mechanic check, then carry on]
Unattended:       [optional — yes when no one can answer questions (an unattended loop):
                   return BLOCKED instead of asking]
Resume From Step: [optional — after an interruption or a BLOCKED return: the step to restart
                   at (with the unit, for Step 1), the decision taken, and the earlier
                   PHASE_RESULT if there is one]

Scope comes from the phase itself (Step 0: the setActiveTask digest, getTask, getChildTasks). The phase description is the locked contract; the sub-tasks are the work plan. Don't re-derive scope from anywhere else.

Run contract

Steps 0–8 run in order, across several turns, because agents report asynchronously. Between checkpoints (when Checkpoints: per-unit) and the final PHASE_RESULT, keep going: don't stop to report progress or wait for confirmation, and record each step's status as you go.

run Step 0                                   # always, also on a resume
step = Resume From Step or 1
while step <= 8:
    run(step)       # dispatch, end the turn while agents work, continue on their reports
    PASS    → step += 1
    FAIL    → fix round, re-run the step     # out of rounds → FAILED
    BLOCKED → ask the user                   # Unattended: yes → return BLOCKED
finish with PHASE_RESULT (PASS)

The run ends only with PASS after Step 8, FAILED, or a BLOCKED return in an unattended run. Test failures, lint and build errors, type errors, review findings and transient API errors are fix rounds, not blockers. A test that failed and then passed is FLAKY, and counts as a failure until a fix round explains it with evidence and removes it.

The steps

Detail for every step, with the exact TaskTracker calls → references/step-guide.md.

The unit check is mandatory. After every implementer unit the mechanic re-runs the build and tests independently, and the unit counts only when the mechanic's run is green. Don't take the implementer's own counts as the check: on the Strago run the independent check confirmed them every time and caught a flaky allocation test the implementer had reported as PASS.

Checkpoints. With Checkpoints: per-unit, after each unit's check print three lines: the unit, the mechanic's pass/fail counts per test project (with any NOT RUN or FLAKY), and the next unit. Then carry on, unless the user asked to confirm each step.

Fix rounds. A failed gate goes back to the implementer with the failure facts (log paths, findings with file:line), then the gate re-runs. Rounds one and two use the implementer's default model; round three passes model: "opus"; after round three the phase is FAILED: put it to the user, or return FAILED when unattended. Review findings are fixed the same way: every BLOCKING and RECOMMENDATION finding is fixed and re-reviewed, while NOTEs never trigger a round and go into the result.

TaskTracker discipline

These hold whichever way the work is done:

• Active task. The phase is active during Step 0 and Steps 2–8; each sub-task is active while it is worked in Step 1. Don't switch or pause the active task while an agent is working on it.
• Heartbeats, never timers. Time is booked only while TaskTracker calls keep arriving; a segment closes after ~5 minutes without one. You can't heartbeat while you wait for an agent (your turn has ended), so the agents carry it: every brief includes the heartbeat rule and every report must confirm it with a HEARTBEAT: line. A report without one means its time went unbooked; note that in the result's time line. Follow the rule yourself when working in-context. Never call startTimer: started timers absorb other sessions' cost (one phase read 12h18m against 3h16m of real work).
• Versions. Every updateTaskStatus passes the version from your latest read of that task, or from your previous write to it.
• Locked phase body. Never edit the phase description (HTTP 422). Decisions, discovered gaps, ADR references and notes become sub-tasks; the table is in references/step-guide.md.
• Insights, not chat. Defects, learnings and frictions go through logDefect / logLearning / logFriction (references/insight-cookbook.md); problems with TaskTracker itself go upstream with reportToTaskTracker. Candidate principles are surfaced in the result, never auto-added.

Returning

The phase ends with the PHASE_RESULT block, written in this session: status, evidence, insights, what each role did, and, on a BLOCKED return, the step, the options and the drift baseline. A caller reads it from the conversation and continues. Schema, what to leave out, and the blocker protocol → references/phase-result.md. On every exit, run Step 8's active-task step first: with a Caller, leave the phase active for the caller to clear; standalone, clear it.

Invocation

From /tt-implement-plan or /tt-workflow-run:

Skill(skill="tt-implement-phase", args=<this block>)

Execute Phase <N>.
Caller: tt-implement-plan            # or tt-workflow-run
Project: <name + id>
Phase task id: <uuid>
Phase title: <title>
Sub-tasks: <list from getChildTasks>
Requirements: <list of (id, title, criteria)>
Principles: <surfaced from the setActiveTask digest>
Checkpoints: <per-unit when the user wants a report after each step>
Unattended: <yes only for an unattended loop>
Resume From Step: <only when picking a phase up again>

Execute all quality gates and finish with PHASE_RESULT.

The Skill call loads this procedure into the calling session, which then leads the phase until it writes the PHASE_RESULT. Run manually with /tt-implement-phase <phase-task-uuid>; with no Caller, the active task is cleared at the end.

Related skills

• verification-loop (Step 2, via the mechanic), devflow:code-review (Step 4) and devflow:security-review (Step 4.5, via the reviewer), adr (Step 5). Always use the full devflow: names for these two: the bare names are Claude Code's built-in reviews.
• continuous-learning (Step 8, only when the phase solved something non-obvious).
• /tt-implement-plan, /tt-workflow-run: the callers. They run this procedure in their own session, then act on its PHASE_RESULT and clear the active task.
• /implement-phase: the same pipeline for phases in a markdown plan.