process — the phase-gate operating loop

On-demand: load this when starting/advancing/closing a phase, or when scope, risk, or "where are we" comes up. The canon is PROCESS.md at the repo root — phases, gates, templates, and rationale live THERE (single source of truth; it wins on any conflict). This skill is the map of how that document runs in this repo: where state lives, what enforces it, and who does what. Never restate gate checklists here — read them from PROCESS.md.

The pieces

The operating loop

1. Session start: read phase-state.md — the current phase frames what work is in-bounds. Gate debt listed there is visible work, not history.
2. During a phase: work normally; the phase's domain skills carry the how (map below). When a risk appears → log it in the risk register now. When scope is proposed → parking lot (roadmap.md) by default; promotion needs the written gate (§3.3) and a decision-log line. When an experiment is proposed → it gets a written question + time/compute budget first (§3.6).
3. Phase boundary: run /gate. Evidence, not assent. BLOCKED verdicts leave gate debt — keep working the phase, don't slide forward.
4. Session end: /wrapup records the current phase + open gate debt in the session note.
5. After shipping (P6): the retro edits PROCESS.md itself and bumps its version — the process is a versioned artifact (Part V).

Projects gate; ad-hoc asks don't

The loop above governs the project thread. A one-off analytical ask — "plot this CSV", "is there a correlation here", "summarize this table" — is served directly: eda/visualization/ statistics still apply (they're about honesty, not ceremony), but no phase check, no gate, no records beyond the conversation. The boundary: the moment ad-hoc work starts informing the project's modeling decisions or produces artifacts the project will reuse, it enters the process (findings recorded, splits respected). Unsure which mode the user is in? Ask — never bureaucratize a quick question.

Phase → skill map (who carries the "how" of each phase)

Who runs this — deliberately NO project-manager agent

Same design call as governance's "no governance-manager agent": process is applied where the work happens, by the main session, because gates need the user in the loop (evidence, sign-off, kill/pivot calls) and subagents can't interview the user. The main session wears the project-lead hat; /gate is the moment it does so deliberately (PROCESS.md §3.7's hat-switching, made mechanical). Specialist agents (data-engineer, ml-engineer, …) do phase work and flag gate-relevant findings back up; they never advance phases.

Gotchas

• The phase-state file is written by /gate only. Editing it by hand to advance a phase is the deliberate human override — never do it on the user's behalf; surface the blocked gate instead.
• Iteration backward is free; skipping forward is not. P5 results sending you back to P2/P4 is the process working. Starting P5 work while P4's gate is open is the process failing.
• Don't duplicate the artifacts. Experiment log = MLflow; parking lot = roadmap.md; feature hypotheses = the feature dictionary. One home each — a second copy is how one goes stale.