One unit of work, six jumpssix steps

Creates the change folder in context/changes/<change-id>/. A "change" is one unit of work from start to finish: research, plan, implementation and review live in a single folder tied together by the change id.

Input: a kebab-case change-id plus an optional free-form intent - the first token becomes the identifier, the rest feeds the title and notes. Output: change.md - a small identity file with frontmatter (change_id, title, status: new, dates) and a Notes section for loose context.

Three gates before anything is created: kebab-case checked with a regex, identifier uniqueness across changes/ and archive/, and an existing context/changes/ directory. A missing directory means refusal, not auto-creation - it signals the repo is not prepared for this structure.

After creation, the skill suggests /10x-plan by default. Situationally: /10x-research when the intent suggests exploring the code before planning, or /10x-frame when the framing is suspicious - a "fix / bug / broken" report with a ready-made diagnosis inside. The suggested command lands in the clipboard.

It does not write research.md, plan.md or frame.md - that is the work of the next skills. It keeps no state file of any kind: the only source of truth about execution is the Progress section in plan.md.

Code research before planning: answer the research question with evidence from the repository and write it to disk - as a durable artifact, not the fleeting memory of a conversation.

Input: a research question plus any pointed-to files - read in full before anything else moves. Output: context/changes/<change-id>/research.md with frontmatter (date, commit, branch, topic) and sections: summary, detailed findings, code references as file:line, architectural conclusions, historical context and open questions.

The question is decomposed into areas, the scope refined with the user (breadth, depth, focus), and then 2-4 subagents run in parallel - each combing its own dimension: files and patterns, earlier decisions in context/changes/ and context/archive/, how the system behaves. Synthesis starts only once they have all returned.

The document is self-sufficient: paths, line numbers, cross-component patterns, GitHub permalinks when the commit is pushed. Follow-up questions go into the same file with a frontmatter annotation - one research artifact per change.

Subagents get read-only tasks and must return concrete file:line references, not generalities. Fresh research always comes before trusting history: earlier changes and the archive are supplementary context, not a substitute for reading the code.

Make the key decisions while they are cheap - in text, not in code. The plan is built interactively and skeptically - the skill challenges vague requirements, asks "why" and "what about case X" instead of writing down wishes.

Input: a task description plus artifacts from earlier steps - research.md and/or frame.md. Every artifact provided reduces the number of questions: nothing the user has already written down gets asked again. Output: plan.md (phases with success criteria and a Progress section) plus plan-brief.md - a two-page summary with a table of key decisions.

First a complexity assessment confirmed with the user (LOW: 4-6 questions, MEDIUM: 7-10, HIGH: 11-15), then questions in rounds - every option with a recommendation and an analysis of benefits and costs. The phase skeleton is approved before the details are written.

Overview, current state, target state, "what we are NOT doing" (a dam against scope creep), phases with criteria split into automated verification (commands) and manual (a human). At the bottom, the Progress section - the only place for checkboxes and the state machine for /10x-implement.

No open questions in the final plan - everything resolved before it is saved. The plan describes the intent and the contract of the change, not finished code: a snippet appears only for a non-obvious change. And zero re-asking about things already settled in the frame or the research.

Execute the approved plan phase by phase with verification, instead of one giant diff. The philosophy: follow the plan's intent while adapting to the code you find - and on divergence, stop and present the problem instead of quietly improvising.

Input: context/changes/<change-id>/plan.md, optionally a phase number. Output: a commit per phase in the Conventional Commits convention plus a checked-off Progress section, where every phase row gets the short SHA of its closing commit appended.

The Progress section in plan.md is the only source of truth - no state files on the side. The first unchecked row marks the starting point - after a break you do not guess what is already done. The skill modifies Progress only; the phase blocks are read-only.

Automated criteria pass → the manual verification gate (a human confirms the tests) → staging explicitly by path from the set of files touched in the phase (never git add -A) → commit message approval → the SHA written back into Progress.

It does not check off manual tests without the user's confirmation. Divergence from the plan escalates as a question with three exits - adapt and continue, skip, go back to planning - instead of deciding for the human.

Compare the actual implementation against the plan before drift, dangerous decisions and convention violations have time to pile up. Two scopes: a quick review of a single phase or a full review of the whole plan before merge.

Input: plan.md plus the actual state of the repo - the diff computed from the plan's date. Output: a report in context/changes/<change-id>/reviews/ with an APPROVED / NEEDS ATTENTION / REJECTED verdict and a list of findings ready for triage.

Two parallel subagents: the first detects drift - for every planned change a MATCH / DRIFT / MISSING / EXTRA verdict; the second checks security, performance, reliability and compliance with the repo's patterns. On top of that, the skill runs the commands from the automated success criteria and compares the results with the claims in Progress.

ID, severity (CRITICAL / WARNING / OBSERVATION), impact (how much deliberation the decision requires - a dimension orthogonal to severity), a file:line location, evidence in the form "the plan said X, the code does Y" and a proposed fix with a trade-off analysis.

An interactive loop over the findings: fix now, fix differently, skip, or record as a lesson in context/foundation/lessons.md. Every decision is written back into the saved report, so triage can be paused and resumed later from the PENDING position.

Close out a finished unit of work: confirm it is complete, move the knowledge into the durable project context, and free up changes/. "Done" should mean done - on the record, not from memory.

Input: the change folder context/changes/<change-id>/ after review. Output: lessons appended to context/foundation/lessons.md and the folder moved to context/archive/ - preserving the full history (change, research, plan, reviews).

Before archiving, the skill checks state consistency: every phase in Progress should have a commit (short SHA). A purely manual phase creates no commit and stays without a SHA - that is an informational warning, not an error, but it is recorded explicitly so "closed out" does not quietly mean "skipped".

What this change taught you - recurring pitfalls, decisions worth remembering - lands in context/foundation/lessons.md, shared across the whole project. The next changes start from that knowledge instead of rediscovering it.

It does not change code or the plan - it operates on already-closed work. The archive is a historical record: nothing reads from it routinely, but it is all there if you ever need to return to the context of an old change.