| name | plan-phase |
| description | Plan the next pohunek phase interactively — review the roadmap and current state, resolve open questions ONE at a time with the user deciding, then write a complete end-to-end NEXT.md (no PoC, no shortcuts). Use when the user says "napiš plán na novou fázi", "naplánuj NEXT.md", "udělej NEXT.md pro další fázi", "poďme naplánovat další fázi", "plan the next phase", "co je dál v plánu", or asks to design the next milestone before implementing it. |
plan-phase — plan the next phase into NEXT.md
Produces the spec that the milestone skill later implements: a complete,
end-to-end NEXT.md for the next phase, arrived at through an interactive
question-and-decision pass with the user. Planning is where this project refuses
shortcuts — the point is a full design, not a minimal proof of concept.
Steps
-
Ground yourself in the current state. Read the direction and status docs
before proposing anything: docs/ROADMAP.md, docs/phases/,
docs/architecture.md (authoritative scope), any relevant docs/design/*.md,
and the current NEXT.md if one exists. Skim the crates the phase will touch
so the plan is grounded in the real code, not assumptions.
-
Frame the phase. State what this phase is for and where it sits in the
roadmap. List the key assumptions explicitly. Respect the repo's hard
constraints (single operator, no central server, PTY/TUI-first, remote over
NetBird not SSH, providers shell-out and client-only, no back-compat shims).
-
Resolve open questions — one at a time. This is the core of the skill and
how the user works: for each unresolved question, ask it on its own, describe
what the problem is, and offer 2-3 concrete options with trade-offs. Wait for
the user's decision before moving to the next question. Do not batch every
question at once, and do not silently pick an answer. ("Dej mi postupně na
každou nevyřešenou otázku dotaz a popiš v čem je problém a jaké jsou návrhy
řešení.")
-
Write the complete NEXT.md. Once the questions are settled, write
NEXT.md at the repo root covering the phase end to end: scope, the design
decided above, the crates/surfaces affected (protocol ripples into
client/daemon/cli/gui-core if the wire changes), knowledge-bundle and
docs/public-api.md impact, and an explicit, testable definition-of-done list
the milestone and milestone-review skills will check against.
-
Confirm. Summarize the plan and the DoD, and note that NEXT.md is ready
to implement (via the milestone skill).
Hard rules
- No PoC, no minimal versions, no shortcuts unless the user explicitly asks
for a reduced scope. The plan must describe the full solution. ("Ano zapiš
plný rozsah, žádné zkratky, žádné kompromisy.")
- Best solution over fastest — never trade correctness or completeness for
implementation speed during planning.
NEXT.md is transient and uncommitted; it is consumed and replaced each
milestone (see the merge-advance skill). Design docs that outlive a
milestone belong under docs/design/.
