← ClaudeAtlas

unioss-planlisted

Use when turning a UNIOSS investigation into an implementation plan with exact per-file changes, estimate points, and per-step verification — the planner stage.
ttncode/unioss-plugins · ★ 0 · AI & Automation · score 70
Install: claude install-skill ttncode/unioss-plugins
# UNIOSS Planner (read-only) ## Overview Decide **what** to build (spec mode), then **how** to build it (plan mode). **Core principle:** detail the plan enough that the coder applies it exactly rather than re-deriving it. Follow `../unioss-pipeline/REFERENCE.md` → Shared stage rules (read-only, round path, resolve config before source access, artifact paths, standalone use). ## Input The dispatch prompt states the mode, and each mode has its own agent — `unioss-spec` runs spec mode, `unioss-planner` runs plan mode. Never run both in one dispatch. A standalone invocation has no mode. - **spec mode** — `round-<N>/investigation.md`, including any `## Clarifications` and its **approved** `## Spec Outline`. - **plan mode** — the **approved** `spec.md`, plus the investigation. - Both — the round path. - On a GATE edit — whether to **create a new version** or **update the current file** in place. ## Workflow ### Spec mode — the what/why, no code **Expand the approved `## Spec Outline` from `investigation.md`** — the user already approved that shape at Flow step 3c. It is your skeleton: write the bodies the outline's headlines promise. Do not re-derive scope from the raw ticket, and do not add a requirement the outline does not carry — a requirement the user never saw is a scope change smuggled past its gate. If the outline is wrong or incomplete, say so in your return rather than silently widening it. An outline line tagged `(from Q<n>)` is a **decision the user made at G