/10x-implement - execution stage by stage

The Rocinante corrects course at checkpoints instead of reaching its target on a single burn.A large change grows from checkpoint to checkpoint instead of arriving as one diff. /10x-implement executes an approved plan.md phase by phase: each one ends with verification, a manual confirmation gate and a commit, and the Progress section in the plan is the only state machine - an interrupted session resumes from the last green stage.

/10X-IMPLEMENT // EVERY PHASE IS A RETURN POINT

WHYThe Expanse · Flip & burn

The problem: one big diff with no checkpoints

"Half the way under thrust, flip, half the way braking - and corrections along the way."

- a flight profile that can be aborted at any point

A change executed in one continuous burn has no places where it can be safely interrupted, verified or rolled back. /10x-implement cuts the execution into the plan's phases: a phase ends only when its success criteria are green, a human has confirmed the manual tests, and the change sits in a commit with its SHA written into Progress.

The philosophy: follow the plan's intent, adapting to the code you find. Plans are designed carefully, but reality gets messy - on divergence the skill stops and presents the problem (expected / found / why it matters) instead of quietly improvising.

GOAL:

for long or interrupted work, every phase is a return point: a commit plus green criteria instead of one giant diff at the end.

Marcin and Przemek work in an orbital shipyard where each part of a solution is built in a separate bay — WHY → DELIVER IN PHASES
The agent executes an approved plan in small phases instead of one opaque batch of changes.

INPUT → OUTPUT

From an approved plan to commits per phase

The input is plan.md from the change folder, optionally with a phase number (/10x-implement oauth-login phase 2). The skill reads the plan in full, every file the plan refers to, and lessons.md - the team's accepted rules shape every implementation decision in this run.

The output is a series of commits in the Conventional Commits convention - one per phase, in the form type(change-id): phase title (pN) - and a ticked-off Progress section in which every closed row carries the short SHA of the closing commit.

Input: plan.md (change-id or a path) + an optional phase number
Output: a commit per phase (Conventional Commits) + Progress with a SHA on every row
Status: change.md: implementing on entry, implemented after the last phase and the epilogue

Marcin and Przemek execute an approved plan in phases on a controlled code assembly line — INPUT → OUTPUT
The plan is executed phase by phase, and the next step unlocks only after the previous one is verified.

MECHANISM

The end-of-phase ritual - a mandatory sequence of steps

01 · Start: the first unchecked Progress row marks the starting point; completed work is trusted - verification only when something looks suspicious.
02 · Implementation: a phase is completed in full before the next one; every edited file goes into the touched-files set - the canonical staging input, overriding git status heuristics.
03 · Verification: commands from the automated criteria must pass; problems are fixed before moving on; Progress rows are ticked off - one per step.
04 · Manual gate: the skill lists the manual tests from the plan and waits for human confirmation; on the last phase it adds a combined list of outstanding manual items from earlier phases.
05 · Commit: staging explicitly by paths from the touched set (never git add -A); unrelated dirty paths trigger a question instead of silent inclusion; the commit message is approved by the user.
06 · SHA and onward: the short SHA goes back into every row of the phase in Progress; then a decision: continue, clear the context (a resume command in the clipboard) or review the phase with /10x-impl-review.
07 · Epilogue: after the last phase, a closing epilogue commit seals the last phase's SHA and the implemented status - without it, archiving will stop on uncommitted changes.

RULE:

on divergence from the plan, three exits, human decision: adapt and continue, skip this fragment, or stop and go back to planning.

Marcin and Przemek pass an implementation phase through a green check and stop work when red drift appears — MECHANISM → VERIFY OR STOP
A green verification closes the phase. Structural drift returns the decision to a person instead of triggering guesses.

ANATOMY

Progress - a state machine without state files

The Progress section at the bottom of plan.md is the only source of truth about execution: no JSON on the side, no markers in comments, no helper file. State is not stored but derived: the first unchecked row = the next step; the current phase = the header above it; completion = the ratio of checked rows to all of them.

The skill mutates Progress only - the phase blocks (Overview, Changes Required, Success Criteria) are read-only. Mid-phase, checked rows without a SHA are a valid intermediate state; SHAs are added in bulk at the end of the phase, after the closing commit.

Row: a checkbox + an N.M index + the criterion title; once the phase closes, the commit's short SHA is added
Split: Automated (commands, tests, types) and Manual (a human looks at the result) subsections per phase
Indexes: 1-based, unique within a phase, never renumbered; removed steps leave gaps
Phases without a diff: a purely manual phase creates no commit and stays without a SHA - /10x-archive reports it as an informational warning, not an error

"WHERE AM I?":

the answer always comes from parsing Progress - which is why an interrupted session resumes from the last green stage, not from zero, and the state cannot drift away from reality.

Marcin and Przemek install a module whose red test turns green before the next phase opens — ANATOMY → VERIFY, SAVE, CONTINUE
Every phase ends with verification and a separate saved state, so work can resume safely.

BOUNDARIES

What /10x-implement does not do

Does not tick off for the human: manual items wait for the user's confirmation - no exceptions.
Does not commit in bulk: no git add -A and no git add . - staging happens exclusively with explicit paths from the touched-files set.
Does not bypass gates: never --no-verify or --amend; after a failed hook, the problem gets fixed and a new commit is made - history is not rewritten.
Does not edit the plan: phase blocks are read-only; only the Progress section and change.md are mutated.
Does not execute from the archive: a plan in context/archive/ = refusal and a pointer to /10x-new.

ON THE CHAIN PAGE:

back to step 04 (implement) on the Core Skills Chain page - the context of the whole chain and the neighboring steps.

Marcin stops an implementation line at a red structural fault while Przemek closes the next module bay — BOUNDARIES → HARD STOP
When a problem exceeds the approved plan, the agent stops and returns the decision to a person.