用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/leetusik/bootstrap_agentic_workspace.sh --skill do-whole-phase命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
How to run product visual design in this workspace — Claude Design + the operator do the design; you write the handoff, wait, read it back, land it, build a runnable mockup the operator approves, and implement. Use when a phase or slice touches a design system, a redesign, mockups, a design gate, brand/palette/typography, or the look of user-facing pages. NOT for non-visual "design" (schema, API, architecture).
Review a completed phase against its objective and record a pass / changes_requested / blocked verdict.
Continue the active phase by completing exactly one slice, then stop.
| name | do-whole-phase |
| description | Finish the active phase end-to-end, including the review and any fix slices. |
| allowed-tools | Bash(python3 scripts/workflow.py:*), Read, Edit, Write, Glob, Grep, Bash, Agent, EnterPlanMode, ExitPlanMode |
| disable-model-invocation | true |
Read CLAUDE.md and the phase's phase.md — the bounded phase notebook (## Slices generated from slice.json, ## Decisions, ## Doc impact, ## Operator Questions, ## Notes for later slices, ## Now) — run python3 scripts/workflow.py next for the pointer, then finish every remaining slice in the current phase only. Read docs/current/ sections just in time, as the slices reach them, never the whole doc set up front. If you are ever unsure of the operator's intent, consult intent.md — the confirmed record of what was asked. next reports the current stream's active phase: on the default stream it skips phases opted into parallel mode (printing parallel_phases_elsewhere=<P>:<branch>), and in a phase-branch worktree it sees only that phase (printing a stream= line); python3 scripts/workflow.py parallel-status shows every stream. If next prints a hint: line offering python3 scripts/workflow.py parallel-start <P> for a planned phase waiting behind this one, relay it to the operator as a suggestion, never a default, and carry on with this phase unless they opt in (see the parallel-phase skill).
You are the ORCHESTRATOR (main thread): you plan each slice, verify, commit, move workflow state, and talk to the operator. Every slice — decomposition, implementation, fix, and the phase review — is delegated to a slice-executor tier subagent (slice-executor-mid or slice-executor-high), one at a time and sequentially. One exception, and it is narrower than it used to be: a co-work (design) slice runs inline → dispatched → inline. The DesignSync work is never dispatched — the read-back and the SIGNOFF regroup stay on the main thread, because DesignSync is main-thread only and no executor has it — but the mockup build is the one dispatched span inside it (slice-executor-high, no DesignSync, built from the round's build-prompt.md). See the design-cowork skill; either way the slice ends the run at a pending stop. Same contract as do-next-slice, looped over the phase.
Rules:
If a slice or the phase is pending (shown [~]; next prints WAITING ON OPERATOR), STOP the loop: it needs operator co-work (validation or an operator-run action). Report what you need and do not start, finish, or advance past it. Resume only after the operator clears pending back to in_progress. When the phase is pending because its operator acceptance gate is open (next also prints acceptance_gate=open and the walkthrough), relay that walkthrough as-is: it clears with python3 scripts/workflow.py accept-gate <P> --clear [--note "..."], not with set-phase-status. If you hit such a point mid-slice, set it pending with set-slice-status <slice_id> pending and STOP. A co-work design slice stops pending twice and the engine cannot tell the two windows apart — both are status: pending on the same slice and both print the same line — so the difference lives entirely in what you report; say which one this is (the co-work rule below). (In parallel mode a pending item halts only its own stream.)
After each slice, re-read the phase's phase.md and the executor's returned verdict — that pair is the handoff, and the notebook was rewritten, not appended to, so the previous read is stale. Drop the per-slice re-read of works/backlog.md (and works/state.json): next prints the pointer, and the dashboards are generated from the same state.
Default is auto — plan inline → executor, straight through, no approval pause. With no mode word (an explicit auto, or "run unattended", means the same), do not enter plan mode (no EnterPlanMode / ExitPlanMode): for each slice, plan inline → Write plan.md verbatim and in full (no harness plan file exists to copy, since plan mode is never entered — the default persistence path is Write, not cp) → dispatch the executor → validate (state integrity) → finish → commit → next, to the end of the phase. Free-form, no template; pull context from phase.md, let the plan incorporate any operator note, and never pre-fill another slice's (the operator's verbatim intent lives in the phase's , not duplicated per slice). The default waives only the plan-approval pause — the safety halts still apply: a slice/phase, any / return, or a failed/empty return, STOPS the loop. An (or a failed/empty return from ) does not stop the loop: revise the plan and re-dispatch the slice to without a pause. For a slice already (), skip the inline planning too — its operator-approved already exists; dispatch from it directly.
plan.mdintent.mdpendingneeds_operatorblockedslice-executor-highescalateslice-executor-midslice-executor-highready[r]plan.mdgate (operator opt-in) restores manual-approval mode — plan → operator approves the readied plan → executor, repeated. Use it only when the operator invokes the skill with gate (e.g. /do-whole-phase gate); then the operator must approve each slice's readied plan before its executor runs. The orchestrator advances on its own only between slices: after each slice it automatically enters plan mode to plan the next — it never stops to ask permission to start planning. For each slice: in Claude Code, call the EnterPlanMode tool to enter plan mode, do read-only research (surface any clarifying questions), then call ExitPlanMode to present the readied plan for the operator's approval. The only pause is approving the finished plan — never a pause before planning begins. After approval (the harness exits plan mode), persist the plan by copying the harness plan file — the exact path the harness named for this planning session; never glob ~/.claude/plans/ and never pick by modification time — to that slice's own plan.md, after confirming its opening lines match the plan just approved (the harness reuses one plan file per session, so a skipped step can leave an earlier slice's plan sitting there); copy immediately after approval, before the next EnterPlanMode, which overwrites the file. Free-form, no template; pull context from phase.md, let the plan incorporate any operator note, and append any slice-local addition (an ## Escalation section, for example) after the copy, never a rewrite of the copied body; then dispatch the executor; then re-read state and head straight into planning the next slice (EnterPlanMode again). Never pre-fill another slice's plan.md. The operator's verbatim intent lives in the phase's intent.md, not duplicated per slice. When the loop reaches a slice already ready ([r]) — its plan.md was operator-approved in an earlier plan only pass — skip plan mode for it: re-read its plan.md and phase.md and dispatch the executor directly, re-planning through the gate only if the workspace state has visibly drifted from the plan.
plan only (operator opt-in) readies every plan without executing. If the operator invokes the skill with plan only (e.g. /do-whole-phase plan only), ready the phase's plans instead of finishing the phase. If the DECOMP slice is not done, run it first exactly as gate mode does (plan at the gate → operator approves → dispatch slice-executor-high → verdict → finish-slice → validate → commit) — the middle slices must exist before they can be planned. Then for each remaining middle slice in order (skip done and already-ready slices): plan it at the gate as in gate mode (EnterPlanMode → read-only research → ExitPlanMode for approval), after approval persist the plan by copying the harness plan file to that slice's own plan.md — the same confirm-then-copy rule as gate mode above — mark it python3 scripts/workflow.py set-slice-status <slice_id> ready (shown [r] — plan approved, awaiting execution), commit, and head straight into planning the next. No executor dispatch and no start-slice/finish-slice for these slices. Stop before anything whose plan depends on something that has not landed yet. That is one rule with four faces: the REVIEW slice (its plan depends on the implementation results), a P<N>.DECOMP2 following a research slice (its plan depends on findings nobody has produced yet), a P<N>.DECOMP2 following the design round(s) under build-after (its plan depends on the landed design), and — under the paired style, which has no DECOMP2 — each apply slice, whose bare folder already exists but whose plan.md is written at its turn from the round that just came back. So plan only readies a research slice but stops before its DECOMP2, and in a design-bearing phase readies the slices up to and including the first design slice whose round has not landed, and stops there; when only such slices remain unreadied, run python3 scripts/workflow.py validate, report which slices were readied, and STOP. plan only is always gated — it exists to produce operator-approved plans, so it runs the approval gate even though the default mode is auto; if auto also appears, ignore it and keep the gate. The safety halts (pending, blocked) still stop the loop.
kind: co-work (a design slice) runs inline → dispatched → inline, and stops the loop twice. The DesignSync work is never dispatched (no executor has it); the mockup build is dispatched to slice-executor-high like any code slice. Per the design-cowork skill, and with python3 scripts/workflow.py set-slice-status <slice_id> pending at each stop:
handoff.md, push the branch, commit, and STOP the loop at PENDING #1.DesignSync, run the card-contract and concreteness checks, land the record as-is, commit.slice-executor-high (built from build-prompt.md, no DesignSync, stubbed data, verified in the ## Operator Runtime), handle its verdict exactly as any delegated slice below — needs_operator also covers a record too thin, wrong or inconsistent to build from, and you raise it rather than filling the gap — then commit and STOP the loop at PENDING #2, the gate.SIGNOFF.md, do the regroup, finish-slice, commit, and continue the loop.Four commits, two loop stops. Report the two pending windows differently: at PENDING #1 say plainly that this is a mechanical wait, not an approval — the handoff is pushed, name its path and the card contract, and ask the operator to run the Claude Design session; at PENDING #2 say that you are asking for approval — the run command, the mockup route's URL, the viewports, what is real and what is stubbed, and that only their literal words close the round.
Delegated slices (decomposition, research, implementation, fix, review — every kind except co-work, whose DesignSync spans stay inline but whose mockup span dispatches exactly like these): dispatch the executor via the Agent tool as a background task (the default — never pass run_in_background: false) and wait for its completion notification, doing nothing else in the meantime except the optional read-only preparation for the next slice described in the next bullet — never run it synchronously inline in the main session, never write to the repo or move workflow state while it runs, and one executor at a time: wait for it to return before dispatching the next (read-only research is not an executor and does not count against that limit). Tier: decomposition, research and review always → slice-executor-high, by kind and whatever their risk says; risk exactly low → slice-executor-mid (a one-line, or few-line, code edit, or docs — route to it only when plan.md asks for nothing more); anything else → slice-executor-high, where essentially all code writing and every cross-file change belongs (bump UP to high, never down, when planning reveals complexity) — to do the slice's job against plan.md; it writes result.md (verdict block first), edits the phase notebook under its budget, and returns a structured verdict. Then trust the verdict: read it and the head of result.md (its verdict block is that return's durable copy — read further only on a verdict other than done, or when you want the detail), and run python3 scripts/workflow.py validate (state integrity only — do not re-run the slice's tests; the phase review validates all slices together). On needs_operator, set the slice pending, report, and STOP; on blocked, record the blocker and STOP; on escalate — or a failed/empty return from slice-executor-mid (an escalation with no findings) — append an ## Escalation: mid → high section to the slice's plan.md with the executor's escalation findings and re-dispatch the slice to slice-executor-high (present the revised plan for approval only in gate mode — in the default re-dispatch straight away; max 1 escalation per slice); on a failed or empty return from slice-executor-high, treat the slice as not done and STOP. A done verdict proceeds.
While executor N runs you are idle on the main thread — you may use that window to prepare for slice N+1 (do-whole-phase only; do-next-slice never prefetches). Once N is dispatched as a background task you are simply waiting, and the wait is yours to spend on whatever will make plan N+1 better: dispatch a read-only research subagent (Claude Code's built-in Explore is the natural fit), read files inline yourself, think the slice through, or just wait. None of it is required and no mechanism is prescribed — choose per slice, and prefer waiting when there is nothing useful to learn yet. The goal is efficient, high-quality work, not a procedure to follow.
workflow.py state commands, no commits, and never any part of slice N+1's actual work; dispatch no second executor (read-only research is not an executor and does not count against the one-at-a-time rule); never block — executor N's completion notification always wins, so anything not ready by then is dropped rather than waited for, finish-slice / validate / the commit are never delayed for it, and nothing is carried on into the slice after next; discard whatever you gathered on any verdict other than done (escalate, blocked, needs_operator, a failed or empty return) — the world it assumed did not happen, so plan (or re-plan for slice-executor-high) from the current tree; keep notes in the session scratchpad, never in a slice folder (a slice owns exactly two context files, and a stale draft must never be readable as an approved plan). What you gather is advisory input to your plan, never an approved plan: in gate mode the operator's approval gate does not move — they still approve plan N+1 after seeing slice N's result.md, verdict, and updated phase.md.DECOMP (the middle slices do not exist yet) or research (its findings are what decides the work after it), when the current slice is co-work (its mockup span is a dispatched executor and does have an idle window, but a short one wedged between two operator stops, and the loop stops at PENDING #2 right after it — so there is rarely a next slice worth preparing), when the next slice is REVIEW (never pre-planned), P<N>.DECOMP2 or a paired apply slice (never pre-planned — their plans come from what has not landed yet: a research slice's findings, or the landed design) or already ready ([r] — an operator-approved plan.md exists), when the phase or any slice is pending (the loop stops there anyway), or when the next slice's files sit inside what N is rewriting (anything read there may be stale by the time N returns). Weigh these; do not tick them off.phase.md, intent.md), and the paths N is mutating right now as explicit exclusions. Ask a few sharp questions rather than "research this slice", and ask for a compact advisory brief: relevant files with one line each on why they matter, patterns and utilities to reuse, constraints and risks, open questions, and an explicit "not read / possibly stale" list. Never a plan, never a file dump. A shallow brief that arrives in time beats an exhaustive one that does not.finish-slice / validate / commit are unchanged; then plan N+1, reconciling whatever you gathered against what N actually changed (its files_changed, the verdict block at the head of its result.md, and the rewritten phase.md) instead of re-reading everything. Do a full research pass when you prepared nothing, dropped what you had, or the state visibly drifted from what it assumed.auto) loop and in gate (in the default the reconciliation feeds the inline plan; in gate it feeds the plan-mode pass). plan only runs no executor, so there is no idle window to use.When the slice is a decomposition (kind: decomposition), it runs the same path as any slice: you plan it, then dispatch slice-executor-high, whose job is to create the phase's middle slices with new-slice (bare folders — never pre-filling their plan.md) and record the breakdown, findings, and notes in phase.md. Set each slice's --risk deliberately — it selects the executor tier (low → slice-executor-mid, else → slice-executor-high), so it is the phase's main cost lever; rate a slice low only when its work is a one-line, or few-line, code edit or docs — anything that writes real code, and anything touching more than one file, is high. When the phase cannot be cut past a point without learning something first, that is what the research kind is for: the executor cuts a research slice (--kind research --risk high — findings-only, no product code, findings landed in phase.md) plus a <P>.DECOMP2 ordered after it, instead of guessing at the slices beyond; DECOMP2 re-cuts the rest from what was learned. That is DECOMP2's second origin, as ordinary as the design one — usually, not always: findings that change nothing about the remaining breakdown need no re-cut, and a third pass, if one is genuinely needed, is DECOMP3. When the phase touches product visual design, its shape follows the operator-confirmed style — build-after, design-only or paired, recorded in the phase's intent.md under ## Design Style (read the design-cowork skill). In every style this DECOMP creates the design slice(s) (--kind co-work --risk high — one per design round, and how many rounds there are is decided here) and records the build inventory — what to build, not how — in phase.md. The rest follows the style: build-after — the groundwork slices plus a second decomposition slice <P>.DECOMP2 after the last design slice and no build slices (DECOMP2 cuts them once the design has landed, backend first and the design implementation after); design-only — a single pass, DECOMP → design slice(s) → REVIEW, the apply phase being a separate phase created at /create-phase; paired — the design/apply pairs as bare folders, one apply slice per round and no DECOMP2. If intent.md carries no ## Design Style, ask the operator here: suggest a style with a reason, set the slice pending, and stop — design-only cannot be chosen from inside DECOMP (its apply phase needs new-phase, which the executor may not run), so that answer goes back to the main thread and /create-phase. The loop will stop at each design slice's pending windows; that is expected, not a failure. Declare the phase's operator acceptance gate at this boundary: right after finish-slice <P>.DECOMP, in the same commit, run python3 scripts/workflow.py accept-gate <P> --require when the phase changes anything the operator can see, or python3 scripts/workflow.py accept-gate <P> --waive --note "why nothing operator-visible changes" when it does not — decided from intent.md and the decomposition. A phase that ships a mockup takes --require, with no judgment call left in it — the operator opens a running route, which is an operator-visible surface by definition, so a design-only phase can no longer be waived; and when DECOMP had to ask the design style, that answer must land before you declare the gate, because the declaration depends on it. Never by omission: review-phase --verdict pass refuses an undeclared phase and names both flags. Phases created before workspace v32 carry no acceptance block and need no declaration.
When a slice finishes (its result.md written and the notebook edited by the executor), run finish-slice <slice_id> --outcome "<one line>" — the outcome comes from the executor's verdict summary and fills that slice's row in the notebook's generated ## Slices table; omitting it warns, never errors — then python3 scripts/workflow.py validate.
Durable-doc versioning happens only at the phase review (see below): implementation, fix, and decomposition slices never run doc-new-version — when they change durable truth they append a one-line "Doc impact" note to phase.md for the review to consolidate. In parallel mode the consolidation moves off the branch entirely — to the serialized post-merge step on the default stream (parallel-merge-finish → doc-new-version per note → parallel-consolidated <P>), since doc versions come from one shared index.
Commit at every clean slice boundary by default, following the Commit Convention (do not branch unless the operator asks; never push — except inside the documented parallel-phase integration flow, where opting the phase in was the ask: slice commits land on the phase branch and the branch is pushed to open and merge its PR, each push still passing the permission prompt). Commits are the orchestrator's job — the executor never commits.
When you reach the phase review slice, delegate it to slice-executor-high like any slice. Plan it so the executor validates all of the phase's slices together (each slice's validation commands plus python3 scripts/workflow.py validate), reviews against the objective / intent.md / docs, and — only on a passing review, and only outside parallel mode — consolidates the phase's "Doc impact" notes from phase.md into new doc versions (writing only docs, never source). In parallel mode (the phase carries an execution block with mode: "parallel") a passing review creates no doc versions: it verifies the "Doc impact" list is complete and returns doc_versions: none — deferred to post-merge consolidation (parallel mode). A non-passing verdict stops the executor before that consolidation and hands the phase back to you: it completes validation and judgment first (so you receive the whole picture in one cycle, not one finding per cycle), then returns the verdict with numbered findings and proposed fix slices rather than doing any pass-only work. The review does not produce a phase explainer — explaining is a separate operation the operator runs. When the phase's gate is required: true, plan the review to run the gate stages too: the executor opens the running product itself in the ## Operator Runtime manifest runtime and spot-checks the phase's headline claims (never passing on other slices' reports alone), walks it once with fresh eyes as a first-time user, re-runs the whole ## Regression Checklist smoke list and appends this phase's headline checks, and routes every ## Operator Questions entry into the walkthrough or into a deferred job for you to file (see the review-phase skill). It returns a review_verdict, the fixed explain: not written — run /explain for this phase pointer, and — on a gated phase — a walkthrough.
On pass with a required acceptance gate, the loop ends before the verdict is recorded. Run python3 scripts/workflow.py accept-gate <P> --open --walkthrough "<the walkthrough the executor returned>" — the phase goes pending — file any deferred jobs the review listed, validate, commit, report the walkthrough to the operator, and STOP the loop, exactly as any pending item stops it. The operator walks the running product; accepting clears the gate (python3 scripts/workflow.py accept-gate <P> --clear [--note "..."] — theirs to run, or yours on their explicit say-so) and returns the phase to in_progress. On the resume run the REVIEW slice is still in_progress with its result.md carrying review_verdict: pass and the gate showing cleared_at: record the pass without re-dispatching the review. Operator-reported failures are recorded instead as python3 scripts/workflow.py review-phase <P> --verdict changes_requested --note "operator-reported: ..." (never refused; it resets the gate) and become fix slices the loop completes before re-reviewing. A waived phase, and a legacy phase with no acceptance block, record the verdict straight away as before.
Record the verdict: python3 scripts/workflow.py review-phase <P> --verdict pass|changes_requested|blocked --reviewer slice-executor-high --note "...", then python3 scripts/workflow.py validate.
If the verdict is changes_requested, create the executor's proposed fix slices with python3 scripts/workflow.py new-slice --phase <P> --slice <P.Fn> --name "..." --kind fix, complete them (via the executor), then re-review (which consolidates the docs once it passes).
Only a pass verdict marks the phase done and closes the REVIEW slice — review-phase does both for you, so do not run a separate finish-slice for the review slice (the general "run finish-slice when a slice finishes" rule above does not apply to the review slice).
If the phase is running in parallel mode, a pass is what opens its integration: run the parallel-phase sequence from the branch — parallel-gate <P> → push → gh pr create → gh pr checks --watch → gh pr merge --merge → on the default stream parallel-merge-finish → the deferred doc consolidation (doc-new-version per "Doc impact" note → rebuild-docs) → parallel-consolidated <P> → parallel-teardown <P> → commit. A closed gate or a red check means STOP and report — never merge past it.
A passing review leaves the phase done in active/; do not archive it here. Archiving is a separate manual step — later, when the operator asks, use archive-all once every active phase is done, rotate-backlog to archive just the done phases while others continue, or archive-phase <P> for one phase.
Do not continue into the next phase.