kickoff

name	kickoff
description	Start or continue an execution session for a DevFlow plan. The span argument sets the scope — one sprint, a sprint range (batch), or a whole phase. Collects the maintainer's review sign-off interactively when the previous unit is unsigned; continue mode resumes from the ledgers, reconciles HEAD, and requires a green start.
argument-hint	{sprint <N> | sprint <N>-<M> | phase <N>} [continue]

request-devflow-plan:kickoff

Start or resume execution of a DevFlow plan. $ARGUMENTS: a target unit (sprint N, sprint N-M, or phase N) and optionally continue — in either order (kickoff continue sprint 1 and kickoff sprint 1 continue are equivalent).

Flow

Step 1 — Locate the plan folder

Scan the target repo's docs/*/ for a DevFlow plan: a README containing a doc map with a 00-iron-rules.md beside it. Confirm with the user; list options if several match. Only one plan executes actively in a repo at a time — starting a second requires the first to be finished, or paused at a commit boundary with its session record written.

Step 2 — Build plan memory

Read: README.md (doc map, global gates, cross-repo dependencies), PROGRESS.md (done vs pending), implementation-notes.md (latest session records + deviations), and the target unit's sprint doc(s).

Step 3 — Branch

Fresh start (no continue, no existing progress on the unit) → template A semantics

1. Check the previous unit's maintainer sign-off in PROGRESS.
   • Unsigned → collect the review results interactively, one question at a time: (1) quiz passed? — the quiz grades itself in the maintainer's browser and records nothing by design; their answer here IS the record; (2) one reply per open deviation, offering the maintainer guide's safe default for each; (3) any adjustment instructions. Write the answers into PROGRESS (sign-off row) and the Deviations status column yourself — the maintainer never needs to edit ledgers by hand (hand-filling first is allowed; then this step sees the sign-off and skips the questions). Handle adjustments first, as normal commits with gates. (This is the same content template B's review-results section carries in the copy-paste flow.)
   • Signed → proceed.
2. Start per template A: full plan read-through, baseline gates, entry conditions, publish the HTML implementation plan, then TDD.

Resume (continue) → template B semantics (resume flavor)

1. Read the last session record's "next step" in implementation-notes §3.
2. Batch protocol: reconcile the ledgers against HEAD.
3. Green start: all gates green before touching anything.
4. Confirm entry conditions; publish or refresh the HTML implementation plan, then continue TDD.

Post-audit fixes never run as loose adjustments: a FAIL audit becomes a remediation unit (plan skill, remediation mode), which then starts here as a normal fresh unit.

Step 4 — Span

• sprint N (default): sprint by sprint; stop at sprint end and wait for review (template A stop semantics).
• sprint N-M (batch): run the range; produce each sprint's report and verification without stopping. Deviations accumulate in the ledger under conservative continuation — there is deliberately no batch safety valve.
• phase N: batch the whole phase; the phase boundary is a mandatory stop.

First line of the session output: plan path, target unit, span.

Next steps block (every stop ends with one)

Print full, copy-paste-ready command lines — always the complete /request-devflow-plan:<command> <args> form with the actual unit numbers substituted. Shorthand and unfilled placeholders in the printed output are violations. Recommended command first; alternatives after, each with one line on when to choose it. Every follow-up command here runs in a fresh context — print the /clear advisory line immediately before the command lines. Example of a correct block after finishing sprint 2 of a 5-sprint plan:

Next steps — after you review the report, pass the quiz, and answer the open deviations:
Run /clear (or open a new session) to empty the context, then:
▶ /request-devflow-plan:kickoff sprint 3        — next unit (your sign-off is collected there)
  /request-devflow-plan:kickoff sprint 3-4      — batch the remaining units, one review at the end

Per state:

• Unit complete, feature units remain → the block above, with the real next unit number.
• Unit complete and it was the last feature unit → recommend /request-devflow-plan:audit, stating explicitly: run it in a NEW session — the plan's acceptance unit is next.
• Stopped mid-unit (context exhausted, interruption) → recommend /request-devflow-plan:kickoff continue sprint <actual current unit number>.

Design principles

• The plan folder is the single source of truth; this skill launches it and copies no rules. When an older plan folder and newer skill semantics disagree, the plan folder wins; ledgers it predates (e.g. audit-log.md) are created on first use.
• The plan's kickoff-prompts.md is the portable fallback — everything works by copy-paste without this plugin.
• Sign-off collection is interactive and never assumes success.

Never

• Modify plan documents (or repair the executor's acceptance evidence)
• Launch past an unsigned previous unit without collecting the review
• Start on red gates