Start with one small reversible unit of work with an explicit goal and boundaries.
SKILL // CHAIN STEP 01
/10x-new - one unit of work
Before a battle, Ender sets up the game field - this skill sets up the field for a change.This skill sets up the field for a change before any work begins. /10x-new creates the context/changes/<change-id>/ folder with a small identity file, change.md, and points to the next skill. One change = one unit of work from research to review, tied together by a single identifier.
/10X-NEW // FROM A FUZZY INTENT TO A UNIT OF WORK ON DISK
The problem: work without an identity
"Before you head into the Battle Room, name the battle you are playing."
- briefing rule before every simulationResearch, plan, implementation and review need one shared place on disk - otherwise artifacts scatter across the repository and the conversation memory. /10x-new gives the change an identity: a folder named with the change-id and a small change.md file where everything that follows will live. A "change" is one unit of work from start to finish.
It is deliberately the shortest skill in the chain: it does one thing (creates the folder), then immediately passes the baton, suggesting the next step with a ready-made command in the clipboard.
opened at the very start of every change - before any research, frame or plan exists, there must be a folder for them to land in.
Instead of sending an agent into the whole backlog, choose one small change that can be verified and reversed.
From a loose intent to an identity file
The input is a change-id in kebab-case plus an optional free-form intent: the first token of the argument becomes the identifier, and everything else feeds the title and the Notes section. Path references are accepted too (@context/changes/oauth-login/) - then the identifier is the last path segment.
The intent is a hint, not a literal: the skill writes a concise title from it (up to 80 characters) and drops the full intent verbatim into Notes as a context seed. Without an intent, the title is derived from the identifier itself, expanded into words, and Notes gets a hint comment.
- Input
- change-id (kebab-case) + an optional free-form intent or a path
- Output
- change.md in context/changes/<change-id>/ with status new
- Bonus
- the suggested next-step command copied to the clipboard
A sprawling task becomes one reversible unit of work, ready for evidence-based repository research.
Four moves, zero magic
- 01 · Parsing
- the argument splits on the first whitespace: the first token → change-id (after stripping "@" and a trailing "/"), the rest → the intent. No argument = instructions and stop.
- 02 · Validation
- three gates before anything is created: kebab-case checked with a regex, uniqueness of the identifier across changes/ and archive/, an existing context/changes/ directory. Every refusal is a clear error message and a stop.
- 03 · Creation
- the context/changes/<change-id>/ folder + change.md: frontmatter (change_id, title, status: new, dates, archived_at: null) and a Notes section with the intent or a hint.
- 04 · Next step
- by default /10x-plan; situationally /10x-research (the intent suggests code exploration) or /10x-frame (a "fix / bug / broken" report arriving with a ready-made diagnosis). The command lands in the clipboard.
a missing context/changes/ directory means refusal, not auto-creation - it signals that the repo is not yet prepared for the context structure (that is what /10x-init is for).
Explicit boundaries prevent drift: the agent knows what to deliver and what it must deliberately leave alone.
change.md - the identity file of a change
The file is deliberately small: frontmatter plus one notes section. It is a record, not a state machine - statuses log the lifecycle, nothing enforces them, and skipping a step is allowed (/10x-status catches the gaps via missing artifacts).
The status lifecycle: new → preparing (research or frame) → planned → plan_reviewed → implementing → implemented → impl_reviewed → archived; from anywhere manually to blocked and back. Every skill in the chain bumps the updated field on its transition.
- change_id
- kebab-case, must match the folder name
- title
- a human-readable title (from the intent or expanded from the identifier)
- status
- new → ... → archived; a lifecycle record, it enforces nothing
- created / updated
- dates of creation and of the last lifecycle change
- Notes
- loose context: links, ad hoc decisions that research/frame/plan cannot hold
no artifacts.* block (it follows from the folder contents) and no phase counters - execution progress lives exclusively in the Progress section of plan.md.
The goal, boundaries and status live in one durable artifact instead of only in chat history.
What /10x-new does not do
- Does not write artifacts
- frame.md, research.md and plan.md are born in their own skills - only the identity of the change is created here.
- Does not track state
- zero state files on the side - the only source of truth about execution is the Progress section in plan.md.
- Does not enforce transitions
- change.md is record-only; statuses describe what happened, they do not police the order.
- Does not create structure
- no context/changes/ = refusal; preparing the repo is a separate decision, not a side effect.
back to step 01 (new) on the Core Skills Chain page - the context of the whole chain and the neighboring steps.
What the change excludes is as explicit as its goal, preventing scope growth during implementation.