/10x-plan - decisions before code

The pilgrimage knows its route before anyone takes a step - this skill charts the route of a change.This skill charts the route of a change before any code exists. /10x-plan runs interactive, skeptical planning: it scales the number of questions to the complexity and the artifacts provided, forces decisions where they are cheap, and writes plan.md with phases, success criteria and a Progress section - plus the two-page plan-brief.md.

/10X-PLAN // THE ROUTE IS SET BEFORE IMPLEMENTATION STARTS

WHYHyperion · The pilgrimage route

The problem: decisions made in passing

"On the map, a correction costs a pencil. On the road - a pilgrim."

- route arithmetic before setting out for the Time Tombs

Freestyle implementation makes the key decisions in the worst possible place: in the middle of writing code, in passing, with no comparison of options. /10x-plan pulls them out in front of the code - where changing your mind costs a text edit, not a refactor.

The skill is skeptical and interactive by design: it questions vague requirements, asks "why" and "what about case X", verifies the user's corrections with its own research, and does not write the plan in a single pass - it confirms the complexity, then the decisions, then the phase skeleton, and only at the end the details.

GOAL:

earns its keep when a change touches many files or carries decisions that are hard to reverse (data schema, public API) - decisions should be made before the code, not while writing it.

Marcin and Przemek inspect several routes through an alien canyon and choose one purple path with checkpoints — WHY → CHOOSE THE ROUTE BEFORE CODE
A plan turns many possible routes into one decision a person can review before costly implementation.

INPUT → OUTPUT

Every input artifact means fewer questions

The input is a task description plus artifacts from earlier steps. Every artifact provided means decisions already made - the skill reads them in full and does not ask about what the user has already written down. A frame closes the diagnostic questions (what the problem is), research - the questions about the state of the code; with both at once, only design decisions remain.

The scale is explicit: a task with no artifacts at MEDIUM complexity means 7-10 questions; with research 5-7; with a frame 4-6; with both 3-5. Re-asking about something settled in earlier steps is an explicitly named skill error, not overzealousness.

Input: a task description + optionally research.md and/or frame.md from the change folder
Output: plan.md - phases with success criteria + the Progress section (a state machine)
Output 2: plan-brief.md - a two-page summary with a table of key decisions and their sources
Bonus: the /10x-implement <change-id> phase 1 command copied to the clipboard

Marcin and Przemek turn evidence and constraints into an implementation route with checkpoints — INPUT → OUTPUT
Evidence and constraints become a route a person can approve before any code changes.

MECHANISM

From complexity to an approved skeleton

01 · Context: identifying artifacts from earlier steps, reading all the pointed-out files in full, plus parallel subagents for gaps the research did not cover.
02 · Complexity: a LOW / MEDIUM / HIGH assessment with justification, confirmed with the user; it sets the question budget: LOW 4-6, MEDIUM 7-10, HIGH 11-15.
03 · Questions: rounds of 1-4 questions; every option carries a recommendation and an explicit analysis: what it gives, what it costs. Categories match the domain (software / content / process), diagnostic questions are skipped when a frame is present.
04 · Implementation research: patterns, conventions and integration points the skill determines on its own from the code and earlier work - it does not ask the user about these.
05 · Skeleton: the proposed split into phases is approved before the details exist; corrections (too fine-grained / too coarse) are cheap at this stage.
06 · Write: plan.md per the template + plan-brief.md; the change status moves to planned; then iteration with the user until it lands.

RULE:

the plan describes the intent and the contract of the change, not finished code - every item separates Intent (what and why) from Contract (interface, signature, schema, invariant); a code snippet appears only for a non-obvious change.

Marcin and Przemek agree on three reversible plan phases with automatic and manual checkpoints — MECHANISM → PHASES AND CRITERIA
Every phase has an outcome and closure criteria; out-of-scope tasks stay outside the route.

ANATOMY

plan.md and plan-brief.md - the contract and the summary

The "What We're NOT Doing" section is a dam against scope creep, and Critical Implementation Details is explicitly optional: it appears only when there is a real catch (ordering, a race, a performance budget). A plan without it is not incomplete; a plan stuffed with boilerplate points is bloated.

At the bottom lives Progress - the only home of checkboxes and the state machine for /10x-implement: one entry per success criterion, split into Automated / Manual, with N.M indexes that are never renumbered. The phase blocks above carry plain bullets, no checkboxes.

Overview + states: what we are building and why; the current state with key discoveries (file:line); the target state with a verification method
What We're NOT Doing: an explicit list of things outside the scope of the change
Phases: Changes Required per file with an Intent / Contract pair; success criteria split into automated (commands) and manual (a human)
Progress: the plan's only checkboxes; N.M entries per criterion, Automated / Manual, read and ticked off by /10x-implement
plan-brief.md: What & Why, the starting point, the end state, a table of key decisions with their source (frame / research / plan), phases in a nutshell, risks

BRIEF:

reads in under 2 minutes and is written for someone who did not take part in the planning - the decision table shows the lineage: what was settled in earlier steps and what in this session.

Marcin and Przemek arrange a purple route from modular phases and separate checkpoints — ANATOMY → REVERSIBLE PHASES
Phases, criteria and non-goals form a clear contract for implementation and later review.

ANTI-PATTERNS

What a good plan does not contain

Open questions: none in the final plan - those encountered along the way stop the work until they are resolved; the plan must be complete and executable.
Finished code: the plan tells the implementer what to change and why, not how to write it; a routine edit = Intent in 1-2 sentences, Contract in one, done.
Repeated questions: zero re-asking about things settled in the frame or the research - it undermines trust in the earlier artifacts.
Boilerplate fillers: Critical Implementation Details skipped by default; generic advice ("use memoization") is not plan content.
Checkboxes in phases: phase blocks carry plain bullets; execution state lives exclusively in the Progress section.

ON THE CHAIN PAGE:

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

Marcin and Przemek stay on a safe purple route while tempting side roads disappear into a storm behind barriers — ANTI-PATTERNS → DO NOT CHASE EVERY SPARK
Explicit non-goals protect the plan from scope creep, accidental refactors and mid-implementation ideas.