Kickoff Phase

---
name: kickoff-phase
description: Build ONE scoped phase of an existing multi-phase plan in a fresh session — re-verify the plan against the live code, interview the user sharply on real forks, then implement only that phase behind plan-mode approval with runnable verification and a fresh-eyes review. Invoke explicitly when starting a phase (the cross-platform form of /tale-mode:kickoff-phase; on Codex, name the plan-file + phase in your prompt). On Claude Code, use the /tale-mode:kickoff-phase command instead of this skill.
---

# Kick off a phase

> **Cross-platform note.** This is the skill form of the `/tale-mode:kickoff-phase` Claude Code
> command, for hosts where slash commands don't exist (e.g. Codex). The two are kept in sync — if
> you edit one, mirror the other. On Codex there is no `$ARGUMENTS`: take **the plan-file path and
> the phase/chunk id from the user's prompt**.
>
> **Arm the phase loop (skill-invoked hosts only).** When this runs as a *skill*, the phase-marker
> hook may never see the kickoff (it matches the prompt text, which a prose invocation may not
> carry), so write the pending marker yourself — your first action once you're allowed to write
> (immediately, or right after plan approval if your host blocks writes in plan mode), **run from
> the project root** (the Stop hook only looks for it there):
>
> ```bash
> [ -f .claude/tale-mode.phase.pending.json ] || printf '%s\n' \
>   '{"session":"pending","rounds":0,"max_rounds":50,"needs_user":null}' \
>   > .claude/tale-mode.phase.pending.json
> ```
>
> The Stop hook claims that file for your session at the first turn-end and then enforces the
> committed `.claude/tale-mode.json` gates while the tree is dirty — IF the user has trusted that
> config's content-hash (inert otherwise; the `trust` skill has the commands — surface them, never
> run them). For a goal the committed gates don't cover, additionally write
> `.claude/active-goal.json` (the ad-hoc loop). On Claude Code the `/tale-mode:kickoff-phase`
> command arms this automatically — don't double-arm there.

**If your host has a plan mode, enter it now** and stay in it through the investigate-and-confirm
steps below — no edits until the user approves. **Recon prompt-hygiene (plan mode prompts on any
shell it can't prove read-only):** prefer the host's dedicated read tools over shell; keep shell
recon to plain single-purpose read-only commands (on Claude Code, `ls`/`cat`/`grep`/`git log` and
simple chains of them auto-approve via the bundled plan-mode hook); route loop-heavy sweeps through
read-only sub-agents, so the user isn't walled with permission prompts. Read the named plan file
(and any roadmap/README it points to) in full. Implement only the named chunk.

**Before writing any code, interview the user — but interview SHARP.** Re-verify the plan's claims
for this chunk against the actual code (the code is ground truth; the plan is a snapshot), and
confirm any external framework/SDK/CLI setup against current docs (Context7/web), not memory. Then
split the open decisions and handle them differently:

- **Engineering calls → DECIDE and proceed (don't ask).** Anything settle-able from the code + best
  practice: file/module placement, data shape, library choice, error handling, naming, API surface.
  Make the call a senior engineer shipping production would make — never an MVP/temp-workaround unless
  explicitly asked. State the decision + a one-line rationale and move on. When two options trade off,
  first check whether the *best* answer combines them. Escalate to a question only if it's genuinely
  hard to reverse and you're torn, or it secretly carries a product/cost choice.
- **Judgment calls → ASK (batched, one round).** Only what needs the user's preference, priorities, or
  authority: product/UX behaviour, scope/priority trade-offs, cost/vendor choices, and steps only they
  can do (credentials, dashboards, go/no-go). Phrase every option **outcome-first** (the real-world
  result), then a one-line technical note in parens. Label each option's authority — **"In plan"** /
  **"Engineering alternative"** / **"Out of scope"** — and flag any shortcut *as a shortcut*.

**Follow the plan; auto-defer (and record in the plan) any in-plan item that won't fit the session
budget and regresses nothing — don't ask, just log it.** Don't re-decide what the plan settled. If
the plan's approach is wrong, say **"recommend changing the plan"** and cite the exact line. Batch
every real question into one round.

Once the user answers: present the concrete approach — **with an executor named per workstream**
(builder/codex/runner/main-loop, per the owner's CLAUDE.md roles table) — and **get approval to start
editing** (exit plan mode). Only then implement, on a dedicated branch, **routing each workstream to
its named executor: the main loop DRIVES, delegates TYPE. Keep on the main loop only taste-carrying
(UI/copy) or genuinely interdependent pieces, one-line justification each; announce every offload as
you dispatch it. Not delegating a workstream the plan routed away is a plan deviation — say so out
loud. The brief always feels more expensive than it is; typed code is re-read every turn forever.**
**Approval authorizes EDITING, not committing — get
explicit sign-off before EVERY commit and EVERY push** (pause and summarize what you'd commit each
time).

Then **prove it by running it, not by reading the diff** (Claude Code: `/verify` to confirm behavior,
`/run` to boot/drive the live app, whenever runnable — Codex: run the test / drive the app yourself and
observe). Review per the owner's CLAUDE.md review ladder — default ONE fresh-eyes pass; the full
battery only for dangerous diffs.

A **cross-model metered** reviewer (Greptile / the CodeRabbit `code-review` skill) is the strongest §5
pass — **but it is OWNER-TRIGGERED and credit-metered: do NOT auto-run it, comment `@…`, or push-loop
it (every push to an open PR re-triggers it = real money).** Surface that it's available; let the user
decide. If they run it, fix every P0/P1, then ask before pushing (batch fixes into one push).

Before declaring done, emit a short DONE/MISSING line-up only for the checks the review ladder
actually required. **If a behavioral
check can't run yet** (needs external provisioning), record it as a named, owned deferral in the plan's
progress and treat the chunk as not-done until discharged. Merge only on the user's go-ahead. When done,
update the plan file's progress with a one-line outcome (commit hash + any drift). Don't start any later
chunk. If new questions arise mid-build, pause and ask rather than guess.