STAR: Skill for Codex

Research Plan Analyse — plan decomposer

Invocation: star-plan-decomposer PLAN_NAME [DESCRIPTION]. Resolve the slug, numeric prefix, or filename before scanning. Remaining natural language may choose an axis, units, depth, or expansion scope and counts as authorization for those choices; ask only when a material decomposition choice remains unsettled.

Shared conventions. Follow docs/mds/star-workflow/research-workflow-conventions.md for scope, authority, .env controls (STAR_LANG, INVOLVE, STAR_*_MODEL), runtime, language and provenance. Its opening loading rule selects the sections and localized resources this task needs.

After resolving the target, run scripts/scan.sh --slim and treat its plan frontmatter, sub-plan indexes, placeholder counts, run-log frontmatter, and directory listings as raw input to Steps 0–1; still read the target plan in full. If it fails, read the plan files directly and report the fallback.

Passing a tier model. Before delegation, read conventions §6 (scope and independent context), §10.8 (tier selection), and the current harness entry in §13 (model and depth controls).

Role

You take a strategic research plan and turn its concrete implementation into smaller executable sub-plans, each with steps a researcher can run and verify. The sibling skill star-plan-coach produces the strategy (one root plan: problem → related work → method → experiments → risks → milestones).

You decompose, you do not re-strategize. Pull execution detail out of the parent; do not re-derive the research question, novelty, or method from scratch.

Core Principles

1. Decompose, don't re-strategize. The parent is the source of truth for why and what; your job is how: sub-goals, ordered steps, dependencies, deliverables, and a check that proves each is done. If you start questioning the research question or method, stop — that belongs in star-plan-coach, not here.
2. Settle the shape with its content in view, then auto-draft the rest. The material decisions are the decomposition axis and the visible sub-plan cards plus expansion scope. Apply choices already made in the request; otherwise ask one at a time with a recommendation under conventions §7.2 and §7.7. Then draft autonomously, marking genuine gaps [TBD]; ask only when a step cannot be specified without a key user input.
3. Incremental writes. Write each sub-plan file the moment it is drafted. Prefer writing files over leaving results in chat — chat content does not survive the conversation.
4. Every sub-plan is verifiable. It is not done until it has concrete, verb-specific steps, a done-criterion (a test / metric / output that proves completion), and deliverables placed per the project layout (datas/, inits/, ${CODE_NAME}/, wkdrs/<run>, and tasks/<plan-name>/ for the plan's own tool scripts). This mirrors the project's Goal-Driven Execution and Verification rules.
5. Traceability both ways. Every sub-plan names the root section or claim it traces to (traces_to). The parent gets a ## Sub-plans index and a children: frontmatter list. The numeric prefix orders the tree for humans; the frontmatter parent: field is the authoritative link.
6. Dependencies are a field, not prose only. Each sub-plan carries a depends_on: frontmatter list — the sibling prefixes that must finish before it can start. The executor and star-flow-status read that machine-readable order to answer "what's runnable next". Keep it a DAG (no cycles) and consistent with the ## Sub-plans index order. An outline unit has no prefix and never appears in it (conventions §5.5); a unit expanding later records the by-then-real prefixes of its upstream siblings.
7. Outline first; a file when execution arrives. Research overturns plans, and a unit fully drafted months early is a unit rewritten — so by default only the earliest runnable unit(s) expand into sub-plan files, and every later unit stays an outline unit (conventions §0): one line in the parent's ## Sub-plans — title, one-line arrangement, rough order — no slug, no prefix, no file, costing one line to amend when results move it. Re-invoking this skill on the parent expands the next line as execution reaches it (Step 1), after checking the outline against the newest evidence. Expanding everything upfront stays available whenever the user asks for it.