complexity-first-planning · diff
git:20260614.b4b5bec to git:20260614.7f3e278
40 added, 9 removed. Audit A to A.
---
name: complexity-first-planning
description: "Use when staging multi-component or uncertain work — tackle the load-bearing unknown first (risk-first decomposition), not the easy parts first."
source: package
domain: engineering
status: active
model_tier: medium
tier: senior
context_spine: [repo]
workspaces:
- agent-config-maintainer
packs:
- meta
---
# complexity-first-planning
Part of the Reasoning Discipline Protocol. Engage per
[`rdp-gate`](../../contexts/execution/rdp-gate.md) (skip on trivial / linear
tasks; light touch on a strong-reasoning host).
> **Provenance.** This is an **RDP derivation from general engineering discipline
> (risk-first / critical-path / pre-mortem)** — it is **not** an Anthropic-
> documented Fable behavior. Fable's "start at the top of your difficulty range"
> is about *task selection* (give the model harder tasks), not intra-task order.
> The skill stands on its own merit; it is not sold as a frontier-model transplant.
## When to use
- Staging multi-component work where the hardest/most-uncertain part is not yet proven.
- A plan whose later steps depend on an assumption that could collapse.
Do NOT use for single-step, linear, or fully-specified tasks (no load-bearing
unknown to resolve), or when the user has already fixed the sequence.
+ ## When the agent should load this
+
+ - The user asks to "plan", "break down", or "stage" work that spans ≥2 components
+ and at least one part is unproven.
+ - A multi-step plan is forming whose later steps assume something untested.
+ - Mid-task: a step just failed because an earlier, easier step baked in a wrong
+ assumption — reload this and re-sequence risk-first.
+
## Procedure
- 1. **Name the unknowns.** List the components + which carry real uncertainty
- (technical feasibility, an unverified integration, an ambiguous requirement).
- 2. **Rank by load-bearing risk.** The load-bearing unknown is the one whose
- failure invalidates the most dependent work — not the one that is merely hard.
+ 1. **Inspect and name the unknowns.** Read the affected components first, then
+ list which carry real uncertainty (technical feasibility, an unverified
+ integration, an ambiguous requirement) — analyze the existing system before
+ planning any change.
+ 2. **Assess and rank by load-bearing risk.** The load-bearing unknown is the one
+ whose failure invalidates the most dependent work — not the one that is merely hard.
3. **Resolve it first.** Spike / probe / prototype the load-bearing unknown
before building anything that depends on it. Record the result in the notes
file (see [`notes-first-reasoning`](../../rules/notes-first-reasoning.md)):
prediction → result → lesson.
4. **Cascade.** Once the riskiest assumption holds (or is corrected), sequence
the dependent work. If it fails, the cheap early failure saved the rework.
## Output
A short ordered plan that leads with the load-bearing unknown + how it will be
proven, then the dependent steps. One recommendation, not a survey.
## Do NOT
- Build the easy parts first to show progress, then discover the hard part breaks them.
- Treat "hardest" as "most code" — rank by *dependency blast radius*, not effort.
- Over-plan a strong-reasoning host (it sequences risk natively — keep it light).
- ## See also
+ ## Gotchas
- - [`rdp-gate`](../../contexts/execution/rdp-gate.md) — engagement gate.
- - [`feature-planning`](../feature-planning/SKILL.md) — composes this for the breakdown.
- - [`notes-first-reasoning`](../../rules/notes-first-reasoning.md) — where the
- prediction/result/lesson of the spike is recorded.
+ - **Mistaking effort for risk.** A 400-line but well-understood refactor is *low*
+ load-bearing risk; a 5-line call into an unverified third-party API is *high*.
+ Ranking by size instead of dependency blast radius is the classic failure.
+ - **"Resolved on paper".** Reasoning that the unknown "should work" is not
+ resolving it — the spike must actually run / compile / return before dependent
+ work starts. Record prediction → result, not prediction → assumption.
+ - **Spike sprawl.** The probe answers exactly one question (does the load-bearing
+ assumption hold?), then stops. Turning it into the real implementation defeats
+ the cheap-early-failure purpose.
+
+ ## Related Skills
+
+ **WHEN to use this**
+
+ - Staging multi-component work where the hardest / most-uncertain part is unproven.
+ - A plan whose later steps rest on an assumption that could collapse.
+
+ **WHEN NOT to use this**
+
+ - Single-step, linear, or fully-specified work — no load-bearing unknown to
+ resolve; the [`rdp-gate`](../../contexts/execution/rdp-gate.md) filters these.
+ - Breaking a feature into tasks in general — route to
+ [`feature-planning`](../feature-planning/SKILL.md), which composes this skill.
+ - Recording the spike's prediction / result / lesson — that belongs in
+ [`notes-first-reasoning`](../../rules/notes-first-reasoning.md).