[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71RP2W9AYTFZNEAM0BCW9BJ":3,"skill-same:01M71RP2W9AYTFZNEAM0BCW9BJ":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":25,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M71RP2W9AYTFZNEAM0BCW9BJ","garrison-plan",null,"Reproduce Claude Code plan mode autonomously - explore the request and codebase with read-only Explore subagents, design with Plan subagents, then write a concise, durable implementation plan file. Does NOT call native EnterPlanMode\u002FExitPlanMode (they fail in agent and auto contexts) and never mutates the system except the plan file. This is the planning step of a Garrison run, distinct from garrison-implement (writing code) and garrison-test (verifying it). Invoked by the Garrison run engine as its planning step, or standalone only when the user explicitly asks for it. Do NOT auto-invoke this skill from task inference - Garrison decides when its phase skills run.","gongiskhan\u002Fagent-garrison","gongiskhan","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1997392?v=4","01M71RKMFR53TKXE308C22QTNZ","01M71RKMJA57KZHNDCBNKTWZRR",1,"MIT","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fduty-plan\u002F.apm\u002Fskills\u002Fgarrison-plan\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"garrison plan","plan","request","run","native","auto-invoke","phase","code","when","invoke","writing","auto","only","implementation plan","design","mode","explore","skills run","never","standalone","2026-11-10 13:02:02",false,"---\nname: garrison-plan\ndescription: Reproduce Claude Code plan mode autonomously - explore the request and codebase with read-only Explore subagents, design with Plan subagents, then write a concise, durable implementation plan file. Does NOT call native EnterPlanMode\u002FExitPlanMode (they fail in agent and auto contexts) and never mutates the system except the plan file. This is the planning step of a Garrison run, distinct from garrison-implement (writing code) and garrison-test (verifying it). Invoked by the Garrison run engine as its planning step, or standalone only when the user explicitly asks for it. Do NOT auto-invoke this skill from task inference - Garrison decides when its phase skills run.\n---\n\n# garrison-plan\n\n## Policy-read preamble (soft - D5\u002FD12)\n\nAt the start of every invocation, look for the compiled Orchestrator policy at\n`~\u002F.garrison\u002Forchestrator\u002Fpolicy.json` (or `$GARRISON_POLICY_PATH`).\n\n- **Policy present** (a Garrison run): it is the single authority. This skill\n  carries NO model\u002Feffort pins - its execution parameters come from the policy\n  matrix cell for its phase (`matrix[\u003Cphase>][\u003Ctier>]`), and its gate duties\n  from the bindable phase-skill contract (the Orchestrator fitting's\n  PHASE_SKILL_CONTRACT.md): do the phase's work in the run context handed to you\n  (runDir, card, phase), write the phase's gate-status entry under the runDir,\n  and print the phase's `GATE \u003Cphase>: \u003Cverdict>` line before choosing the next\n  list.\n- **Policy absent** (standalone, any repo): proceed with the caller-supplied\n  context and sensible defaults - NEVER stop. Report to the caller rather than\n  writing gate-status\u002Frun artifacts, and skip any board\u002Frun-engine steps.\n\n\nReproduces the **exploration + planning quality** of Claude Code's native plan mode without using the native plan-mode tools. Native plan mode cannot be driven autonomously — `EnterPlanMode` throws in agent\u002Fsubagent contexts and `ExitPlanMode` always raises a human approval dialog — so this skill copies plan mode's *prompts and read-only discipline* instead, and produces a durable plan file a build phase can execute.\n\n**Hard prohibition (the skill's whole reason to exist):** NEVER call `EnterPlanMode` or `ExitPlanMode`, and NEVER spawn `claude -p` or the Agent SDK against Anthropic endpoints. The verbatim plan-mode prompts this skill embeds are in `references\u002Fplan-mode-prompts.md` — read that file before Phase 1; it is the authoritative source of the discipline and the subagent system prompts.\n\n## The binding read-only rule (paraphrased from the plan-mode system-reminder, block A2)\n\nPlanning mode is active. Do NOT make any edits, run any non-read-only tools (including changing configs or making commits), or otherwise change the system — **with the single exception of the plan file**. This supersedes any other instruction to make edits. Research comprehensively, write the plan to the plan file, then hand it to the gate. Make no file changes and run no system-modifying tools until the plan is approved by the gate (in garrison's autonomous context, \"approval\" is garrison's own sequencing gate — see Phase 5).\n\nA skill cannot truly gate tools, so treat this as an absolute behavioral contract: until the plan is handed off, the plan file is the ONLY thing you may write — plus, **only when garrison invokes it**, this run's spec + control-plane records (`RUN_SPEC.md`, the sentinel `turnCap`, `gatesConfig`, and RUN_LOG entries — planning's own output under `\u003CrunDir>` + the per-session sentinel, **never target source**; see \"Run-shaping when invoked by garrison\").\n\n## Autonomous adaptation (when invoked by garrison or in any auto\u002Funattended context)\n\nNative plan mode uses `AskUserQuestion` to clarify ambiguities. **In an autonomous context, do NOT ask — resolve each open question with a recommended answer and record the assumption in the plan** (for garrison runs, in the RUN_SPEC assumptions ledger). The operator prefers Claude to make the call and proceed. (When a human is genuinely driving this skill interactively and a choice is truly load-bearing, `AskUserQuestion` is still permitted — but default to deciding.) The one operator-authorized exception is `--ask-questions` (default OFF): it permits exactly ONE pause, AFTER `RUN_SPEC.md` is written, and never any other pause — see \"Run-shaping when invoked by garrison\".\n\n## The plan file (durable — never plan only in context)\n\nWorkflow\u002Fsubagent intermediate state lives in script variables and only a final result returns to context, so the plan MUST be a durable file the build phase and the resume scan can re-read. **Never a shared, fixed path** — concurrent plan\u002Fbuild runs in other sessions must not clobber each other.\n- **Caller-supplied path wins.** When garrison invokes this skill it passes a **per-run** path — `docs\u002Fautothing\u002Fruns\u002F\u003CrunId>\u002FFLOW_PLAN.md` in the target repo. Write exactly there (never a shared `docs\u002FFLOW_PLAN.md`), following the FLOW_PLAN slice-table shape garrison expects (`assets\u002Fdocs\u002FFLOW_PLAN.md` in the garrison skill).\n- **Standalone default:** mirror native plan-mode semantics but make the path **unique** — write to `~\u002F.claude\u002Fplans\u002F\u003Cslug>-\u003CYYYYMMDD-HHMMSS>.md` (slug = short kebab summary; the timestamp keeps concurrent standalone plans from colliding). Create with Write; make incremental edits with Edit.\n- This plan file is the ONLY file you may create or edit during planning — **plus, when garrison invokes it, this run's spec + control-plane records**: `\u003CrunDir>\u002FRUN_SPEC.md` and the sizing-derived writes to the sentinel `turnCap` \u002F `gatesConfig` \u002F `RUN_LOG` (see \"Run-shaping when invoked by garrison\"). Those are planning's own durable output under `\u003CrunDir>` + the per-session sentinel — **never target source**; the codebase stays read-only (no source edits, no commits). Standalone, the plan file is the only writable artifact.\n\n## The 5-phase workflow\n\nRead `references\u002Fplan-mode-prompts.md` first. Then:\n\n### Phase 0 — Acquire the planning gate (advisory; only when coord-mcp is present)\nIf the **coord-mcp** planning-gate tools are available (the Garrison coord stack is connected), call `begin_planning(repo, summary)` BEFORE exploring — coord-mcp serializes planning so only one session plans a repo at a time:\n- **GRANTED** → read the returned read-bundle (the last released plan + recent plans + in-flight intents\u002Fdecisions) and fold it into your plan, so you build on other sessions' context instead of planning blind. Hold the lock through Phases 1–4; `plan_heartbeat` if planning runs long.\n- **WAIT** → another session is planning this repo. Honor the bounded wait and re-check; if you are autonomous and cannot acquire within budget, **park the task and surface it — never hang.**\n- Call `end_planning(repo)` once the plan file is written (Phase 4), so the next planner inherits your summary.\n\nIf the coord tools are absent (no Garrison, or the MCP is not connected — including this kind of direct session), **skip this entirely and plan as normal; never hard-block on it.** This is what makes garrison-plan compose with coord-mcp's \"one planner per repo at a time\" guarantee.\n\n### Phase 1 — Initial Understanding (Explore subagents ONLY)\nGain a comprehensive understanding of the request and the code it touches.\n- **Launch 1–3 `Explore` subagents IN PARALLEL** (single message, multiple Agent tool calls, `subagent_type: \"Explore\"` — Haiku, context-isolated, cheap). Use **1** agent when scope is isolated to known files; **multiple** when scope is uncertain, several areas are involved, or you must learn existing patterns before planning. **Quality over quantity — usually just 1.** Give each agent a **specific search focus** and a thoroughness hint (`quick | medium | very thorough`).\n- The built-in `Explore` agent already runs the block-A4 system prompt; embedding it in `references\u002Fplan-mode-prompts.md` preserves the behavior if you ever must run the prompt inline (e.g. the built-in agent is unavailable).\n- After exploring, **resolve ambiguities with recommended answers** (autonomous rule above) rather than asking.\n\n### Phase 2 — Design (Plan subagents)\nLaunch `Plan` subagent(s) (`subagent_type: \"Plan\"`, inherit the main model) to design the implementation from Phase-1 findings. **Pass comprehensive context** — filenames, code-path traces, the patterns Phase 1 found. The Plan subagent runs the block-A5 system prompt (architect; read-only; ends with a \"Critical Files for Implementation\" list).\n\n### Phase 3 — Review\nRead the critical files the agents identified to deepen understanding; ensure the design aligns with the original request; **resolve any remaining questions by deciding** (not asking).\n\n### Phase 4 — Write the final plan\nWrite the final plan to the plan file. **Recommended approach only — not every alternative.** Concise enough to scan, detailed enough to execute. Include the **paths of critical files to modify** and the **verification steps \u002F success criteria**.\n- **Keep it short.** Production data: plan files p50 ≈ 4,906 chars, p90 ≈ 11,617; rejection rises with length (under 2K ≈ 20% rejected, over 20K ≈ 50%). **Target a few thousand characters; hard-cap if it grows past ~12K** — move detail into the build, not the plan.\n- **When garrison invokes this — spec-first + slice sizing.** For significant runs (**above ~3 slices**) write `\u003CrunDir>\u002FRUN_SPEC.md` FIRST and DERIVE the FLOW_PLAN slice table from it; **split any slice sized > ~8** (of the 100-point sizing) into gated sub-slices. Then apply the sizing-derived control-plane writes — profile, `turnCap`, `deliberateRed`\u002F`mutation` defaults — and, if `--ask-questions` is set, take the one operator pause. All of this is detailed in \"Run-shaping when invoked by garrison\" below.\n\n### Phase 5 — Gate (stand-in for ExitPlanMode — NEVER call ExitPlanMode)\nThe plan is now written to the plan file. **Hand it to garrison's approval\u002Fsequencing gate** instead of calling `ExitPlanMode`:\n- When invoked by garrison: return control; garrison reads the plan file and proceeds to bootstrap + the build loop. State, in your final message, the plan-file path and a one-line summary (the plan content lives in the file, not the message — mirroring ExitPlanMode semantics, block A7).\n- When standalone: announce the plan-file path and that planning is complete; let the human drive execution. Do not ask \"is this plan okay?\" — writing the file + announcing it IS the handoff.\n- **If you acquired the planning gate in Phase 0, call `end_planning(repo)` now** — release the lock so the next session can plan and inherit your summary.\n\n## Run-shaping when invoked by garrison (sizing → spec, profile, turn cap, gates)\n\nWhen garrison invokes this skill, the SAME sizing Phases 1–3 produce — a slice count plus a per-slice size estimate on garrison's 100-point scale — shapes the run. These are planning's own control-plane writes under `\u003CrunDir>` + the per-session sentinel; **never target source, the codebase stays read-only.** Every timestamp comes ONLY from `date -u +%Y-%m-%dT%H:%M:%SZ`. (Standalone — no runDir\u002Fsentinel — none of this applies; the plan file is the only artifact.)\n\n- **RUN_SPEC.md for significant runs (Part 10.1).** When sizing puts the work **above ~3 slices**, write `\u003CrunDir>\u002FRUN_SPEC.md` BEFORE slicing: **what\u002Fwhy** (one paragraph), **acceptance criteria**, **non-goals**, and an **ASSUMPTIONS LEDGER** — every decision planning made on the operator's behalf, each with the **chosen answer AND the alternative**. The FLOW_PLAN slice table then DERIVES from the spec. At or below the threshold, FLOW_PLAN acceptance alone suffices — no ceremony for small work. The assumptions ledger is what makes default fully-autonomous mode reviewable after the fact.\n- **`--ask-questions` (Part 10.2, default OFF).** Without the flag: current behavior — decide, record in the assumptions ledger, proceed; **never pause.** With the flag: exactly ONE pause, **AFTER `RUN_SPEC.md` is written** — present the open decisions + assumptions as a numbered queue, wait for the operator's answers, fold them into the spec, mark the spec **locked**, then run fully autonomously to the end. **Sentinel-arming mechanic (garrison's Phase 0, not this skill's):** with `--ask-questions`, arming the goal-loop sentinel is DEFERRED until the answers arrive (so the goal loop does not fight the pause) — signal garrison to arm the sentinel once the spec is locked. This pause is exempt from the never-ask rule **by explicit operator request** and happens **before any code exists.** The flag is recorded in `gatesConfig` so a resume knows the spec was operator-locked.\n- **Profile assignment (Part 11.2).** The same sizing assigns the run **profile** — `patch` (≤ ~1 sizing point) \u002F `feature` (1–3 slices) \u002F `build` (≥ 4 slices) — unless the operator forced one; record it in `gatesConfig` and in the RUN_LOG **`RUN-START`** entry, replacing the `pending-sizing` placeholder.\n- **Plan-derived turn cap (Part 5.6).** After sizing, UPDATE the sentinel `turnCap` to **`max(300, 80 × slices)`** (a large upward buffer — the cap is a runaway brake, never a schedule) and log the resize as a **`DECISION`** entry in RUN_LOG.\n- **Max slice size (Part 5.8).** SPLIT any slice whose size estimate exceeds **~8** (of the 100-point sizing) into sub-slices with their own gates — an oversized slice spans sessions and its interruptions land mid-work instead of on gate boundaries. Intermediate free-form checkpoints remain allowed but are the fallback, not the plan.\n- **deliberate-red + mutation defaults (Parts 5.5 \u002F 9.2).** For runs **≥ 3 slices**, set `deliberateRed` + `mutation` **ON** in `gatesConfig` (an operator `--no-deliberate-red` \u002F `--no-mutation` overrides to OFF); below 3 slices they default **OFF**.\n\n## Discipline summary (do \u002F never)\n- DO: read `references\u002Fplan-mode-prompts.md`; spawn real `Explore`\u002F`Plan` subagents in parallel; write ONE durable plan file; decide instead of asking; keep the plan small. When garrison invokes it: write `RUN_SPEC.md` for work above ~3 slices, split slices sized > ~8, and set the sizing-derived profile \u002F `turnCap` \u002F gate defaults.\n- NEVER: call `EnterPlanMode` \u002F `ExitPlanMode`; spawn `claude -p` or an Anthropic-endpoint Agent SDK call; edit any target source (write only the plan file, plus this run's spec + control-plane records when garrison invokes it); ship every alternative in the plan; block waiting for the user in an autonomous run (except the single operator-requested `--ask-questions` pause after `RUN_SPEC.md`).\n\n## Files\n- `references\u002Fplan-mode-prompts.md` — the verbatim plan-mode prompt corpus (blocks A2–A8): the read-only system-reminder, the 5-phase reminder, the Explore subagent system prompt, the Plan subagent system prompt, the EnterPlanMode trigger heuristic, the ExitPlanMode semantics, and Anthropic's recommended Explore→Plan→Implement→Commit workflow. Read it before Phase 1; the wording is community-reverse-engineered (Piebald-AI \u002F how-claude-code-works \u002F Ronacher) and approximate in later phases — the structure and read-only discipline are authoritative.\n","# garrison-plan\n\n## Policy-read preamble (soft - D5\u002FD12)\n\nAt the start of every invocation, look for the compiled Orchestrator policy at\n`~\u002F.garrison\u002Forchestrator\u002Fpolicy.json` (or `$GARRISON_POLICY_PATH`).\n\n- **Policy present** (a Garrison run): it is the single authority. This skill\n  carries NO model\u002Feffort pins - its execution parameters come from the policy\n  matrix cell for its phase (`matrix[\u003Cphase>][\u003Ctier>]`), and its gate duties\n  from the bindable phase-skill contract (the Orchestrator fitting's\n  PHASE_SKILL_CONTRACT.md): do the phase's work in the run context handed to you\n  (runDir, card, phase), write the phase's gate-status entry under the runDir,\n  and print the phase's `GATE \u003Cphase>: \u003Cverdict>` line before choosing the next\n  list.\n- **Policy absent** (standalone, any repo): proceed with the caller-supplied\n  context and sensible defaults - NEVER stop. Report to the caller rather than\n  writing gate-status\u002Frun artifacts, and skip any board\u002Frun-engine steps.\n\n\nReproduces the **exploration + planning quality** of Claude Code's native plan mode without using the native plan-mode tools. Native plan mode cannot be driven autonomously — `EnterPlanMode` throws in agent\u002Fsubagent contexts and `ExitPlanMode` always raises a human approval dialog — so this skill copies plan mode's *prompts and read-only discipline* instead, and produces a durable plan file a build phase can execute.\n\n**Hard prohibition (the skill's whole reason to exist):** NEVER call `EnterPlanMode` or `ExitPlanMode`, and NEVER spawn `claude -p` or the Agent SDK against Anthropic endpoints. The verbatim plan-mode prompts this skill embeds are in `references\u002Fplan-mode-prompts.md` — read that file before Phase 1; it is the authoritative source of the discipline and the subagent system prompts.\n\n## The binding read-only rule (paraphrased from the plan-mode system-reminder, block A2)\n\nPlanning mode is active. Do NOT make any edits, run any non-read-only tools (including changing configs or making commits), or otherwise change the system — **with the single exception of the plan file**. This supersedes any other instruction to make edits. Research comprehensively, write the plan to the plan file, then hand it to the gate. Make no file changes and run no system-modifying tools until the plan is approved by the gate (in garrison's autonomous context, \"approval\" is garrison's own sequencing gate — see Phase 5).\n\nA skill cannot truly gate tools, so treat this as an absolute behavioral contract: until the plan is handed off, the plan file is the ONLY thing you may write — plus, **only when garrison invokes it**, this run's spec + control-plane records (`RUN_SPEC.md`, the sentinel `turnCap`, `gatesConfig`, and RUN_LOG entries — planning's own output under `\u003CrunDir>` + the per-session sentinel, **never target source**; see \"Run-shaping when invoked by garrison\").\n\n## Autonomous adaptation (when invoked by garrison or in any auto\u002Funattended context)\n\nNative plan mode uses `AskUserQuestion` to clarify ambiguities. **In an autonomous context, do NOT ask — resolve each open question with a recommended answer and record the assumption in the plan** (for garrison runs, in the RUN_SPEC assumptions ledger). The operator prefers Claude to make the call and proceed. (When a human is genuinely driving this skill interactively and a choice is truly load-bearing, `AskUserQuestion` is still permitted — but default to deciding.) The one operator-authorized exception is `--ask-questions` (default OFF): it permits exactly ONE pause, AFTER `RUN_SPEC.md` is written, and never any other pause — see \"Run-shaping when invoked by garrison\".\n\n## The plan file (durable — never plan only in context)\n\nWorkflow\u002Fsubagent intermediate state lives in script variables and only a final result returns to context, so the plan MUST be a durable file the build phase and the resume scan can re-read. **Never a shared, fixed path** — concurrent plan\u002Fbuild runs in other sessions must not clobber each other.\n- **Caller-supplied path wins.** When garrison invokes this skill it passes a **per-run** path — `docs\u002Fautothing\u002Fruns\u002F\u003CrunId>\u002FFLOW_PLAN.md` in the target repo. Write exactly there (never a shared `docs\u002FFLOW_PLAN.md`), following the FLOW_PLAN slice-table shape garrison expects (`assets\u002Fdocs\u002FFLOW_PLAN.md` in the garrison skill).\n- **Standalone default:** mirror native plan-mode semantics but make the path **unique** — write to `~\u002F.claude\u002Fplans\u002F\u003Cslug>-\u003CYYYYMMDD-HHMMSS>.md` (slug = short kebab summary; the timestamp keeps concurrent standalone plans from colliding). Create with Write; make incremental edits with Edit.\n- This plan file is the ONLY file you may create or edit during planning — **plus, when garrison invokes it, this run's spec + control-plane records**: `\u003CrunDir>\u002FRUN_SPEC.md` and the sizing-derived writes to the sentinel `turnCap` \u002F `gatesConfig` \u002F `RUN_LOG` (see \"Run-shaping when invoked by garrison\"). Those are planning's own durable output under `\u003CrunDir>` + the per-session sentinel — **never target source**; the codebase stays read-only (no source edits, no commits). Standalone, the plan file is the only writable artifact.\n\n## The 5-phase workflow\n\nRead `references\u002Fplan-mode-prompts.md` first. Then:\n\n### Phase 0 — Acquire the planning gate (advisory; only when coord-mcp is present)\nIf the **coord-mcp** planning-gate tools are available (the Garrison coord stack is connected), call `begin_planning(repo, summary)` BEFORE exploring — coord-mcp serializes planning so only one session plans a repo at a time:\n- **GRANTED** → read the returned read-bundle (the last released plan + recent plans + in-flight intents\u002Fdecisions) and fold it into your plan, so you build on other sessions' context instead of planning blind. Hold the lock through Phases 1–4; `plan_heartbeat` if planning runs long.\n- **WAIT** → another session is planning this repo. Honor the bounded wait and re-check; if you are autonomous and cannot acquire within budget, **park the task and surface it — never hang.**\n- Call `end_planning(repo)` once the plan file is written (Phase 4), so the next planner inherits your summary.\n\nIf the coord tools are absent (no Garrison, or the MCP is not connected — including this kind of direct session), **skip this entirely and plan as normal; never hard-block on it.** This is what makes garrison-plan compose with coord-mcp's \"one planner per repo at a time\" guarantee.\n\n### Phase 1 — Initial Understanding (Explore subagents ONLY)\nGain a comprehensive understanding of the request and the code it touches.\n- **Launch 1–3 `Explore` subagents IN PARALLEL** (single message, multiple Agent tool calls, `subagent_type: \"Explore\"` — Haiku, context-isolated, cheap). Use **1** agent when scope is isolated to known files; **multiple** when scope is uncertain, several areas are involved, or you must learn existing patterns before planning. **Quality over quantity — usually just 1.** Give each agent a **specific search focus** and a thoroughness hint (`quick | medium | very thorough`).\n- The built-in `Explore` agent already runs the block-A4 system prompt; embedding it in `references\u002Fplan-mode-prompts.md` preserves the behavior if you ever must run the prompt inline (e.g. the built-in agent is unavailable).\n- After exploring, **resolve ambiguities with recommended answers** (autonomous rule above) rather than asking.\n\n### Phase 2 — Design (Plan subagents)\nLaunch `Plan` subagent(s) (`subagent_type: \"Plan\"`, inherit the main model) to design the implementation from Phase-1 findings. **Pass comprehensive context** — filenames, code-path traces, the patterns Phase 1 found. The Plan subagent runs the block-A5 system prompt (architect; read-only; ends with a \"Critical Files for Implementation\" list).\n\n### Phase 3 — Review\nRead the critical files the agents identified to deepen understanding; ensure the design aligns with the original request; **resolve any remaining questions by deciding** (not asking).\n\n### Phase 4 — Write the final plan\nWrite the final plan to the plan file. **Recommended approach only — not every alternative.** Concise enough to scan, detailed enough to execute. Include the **paths of critical files to modify** and the **verification steps \u002F success criteria**.\n- **Keep it short.** Production data: plan files p50 ≈ 4,906 chars, p90 ≈ 11,617; rejection rises with length (under 2K ≈ 20% rejected, over 20K ≈ 50%). **Target a few thousand characters; hard-cap if it grows past ~12K** — move detail into the build, not the plan.\n- **When garrison invokes this — spec-first + slice sizing.** For significant runs (**above ~3 slices**) write `\u003CrunDir>\u002FRUN_SPEC.md` FIRST and DERIVE the FLOW_PLAN slice table from it; **split any slice sized > ~8** (of the 100-point sizing) into gated sub-slices. Then apply the sizing-derived control-plane writes — profile, `turnCap`, `deliberateRed`\u002F`mutation` defaults — and, if `--ask-questions` is set, take the one operator pause. All of this is detailed in \"Run-shaping when invoked by garrison\" below.\n\n### Phase 5 — Gate (stand-in for ExitPlanMode — NEVER call ExitPlanMode)\nThe plan is now written to the plan file. **Hand it to garrison's approval\u002Fsequencing gate** instead of calling `ExitPlanMode`:\n- When invoked by garrison: return control; garrison reads the plan file and proceeds to bootstrap + the build loop. State, in your final message, the plan-file path and a one-line summary (the plan content lives in the file, not the message — mirroring ExitPlanMode semantics, block A7).\n- When standalone: announce the plan-file path and that planning is complete; let the human drive execution. Do not ask \"is this plan okay?\" — writing the file + announcing it IS the handoff.\n- **If you acquired the planning gate in Phase 0, call `end_planning(repo)` now** — release the lock so the next session can plan and inherit your summary.\n\n## Run-shaping when invoked by garrison (sizing → spec, profile, turn cap, gates)\n\nWhen garrison invokes this skill, the SAME sizing Phases 1–3 produce — a slice count plus a per-slice size estimate on garrison's 100-point scale — shapes the run. These are planning's own control-plane writes under `\u003CrunDir>` + the per-session sentinel; **never target source, the codebase stays read-only.** Every timestamp comes ONLY from `date -u +%Y-%m-%dT%H:%M:%SZ`. (Standalone — no runDir\u002Fsentinel — none of this applies; the plan file is the only artifact.)\n\n- **RUN_SPEC.md for significant runs (Part 10.1).** When sizing puts the work **above ~3 slices**, write `\u003CrunDir>\u002FRUN_SPEC.md` BEFORE slicing: **what\u002Fwhy** (one paragraph), **acceptance criteria**, **non-goals**, and an **ASSUMPTIONS LEDGER** — every decision planning made on the operator's behalf, each with the **chosen answer AND the alternative**. The FLOW_PLAN slice table then DERIVES from the spec. At or below the threshold, FLOW_PLAN acceptance alone suffices — no ceremony for small work. The assumptions ledger is what makes default fully-autonomous mode reviewable after the fact.\n- **`--ask-questions` (Part 10.2, default OFF).** Without the flag: current behavior — decide, record in the assumptions ledger, proceed; **never pause.** With the flag: exactly ONE pause, **AFTER `RUN_SPEC.md` is written** — present the open decisions + assumptions as a numbered queue, wait for the operator's answers, fold them into the spec, mark the spec **locked**, then run fully autonomously to the end. **Sentinel-arming mechanic (garrison's Phase 0, not this skill's):** with `--ask-questions`, arming the goal-loop sentinel is DEFERRED until the answers arrive (so the goal loop does not fight the pause) — signal garrison to arm the sentinel once the spec is locked. This pause is exempt from the never-ask rule **by explicit operator request** and happens **before any code exists.** The flag is recorded in `gatesConfig` so a resume knows the spec was operator-locked.\n- **Profile assignment (Part 11.2).** The same sizing assigns the run **profile** — `patch` (≤ ~1 sizing point) \u002F `feature` (1–3 slices) \u002F `build` (≥ 4 slices) — unless the operator forced one; record it in `gatesConfig` and in the RUN_LOG **`RUN-START`** entry, replacing the `pending-sizing` placeholder.\n- **Plan-derived turn cap (Part 5.6).** After sizing, UPDATE the sentinel `turnCap` to **`max(300, 80 × slices)`** (a large upward buffer — the cap is a runaway brake, never a schedule) and log the resize as a **`DECISION`** entry in RUN_LOG.\n- **Max slice size (Part 5.8).** SPLIT any slice whose size estimate exceeds **~8** (of the 100-point sizing) into sub-slices with their own gates — an oversized slice spans sessions and its interruptions land mid-work instead of on gate boundaries. Intermediate free-form checkpoints remain allowed but are the fallback, not the plan.\n- **deliberate-red + mutation defaults (Parts 5.5 \u002F 9.2).** For runs **≥ 3 slices**, set `deliberateRed` + `mutation` **ON** in `gatesConfig` (an operator `--no-deliberate-red` \u002F `--no-mutation` overrides to OFF); below 3 slices they default **OFF**.\n\n## Discipline summary (do \u002F never)\n- DO: read `references\u002Fplan-mode-prompts.md`; spawn real `Explore`\u002F`Plan` subagents in parallel; write ONE durable plan file; decide instead of asking; keep the plan small. When garrison invokes it: write `RUN_SPEC.md` for work above ~3 slices, split slices sized > ~8, and set the sizing-derived profile \u002F `turnCap` \u002F gate defaults.\n- NEVER: call `EnterPlanMode` \u002F `ExitPlanMode`; spawn `claude -p` or an Anthropic-endpoint Agent SDK call; edit any target source (write only the plan file, plus this run's spec + control-plane records when garrison invokes it); ship every alternative in the plan; block waiting for the user in an autonomous run (except the single operator-requested `--ask-questions` pause after `RUN_SPEC.md`).\n\n## Files\n- `references\u002Fplan-mode-prompts.md` — the verbatim plan-mode prompt corpus (blocks A2–A8): the read-only system-reminder, the 5-phase reminder, the Explore subagent system prompt, the Plan subagent system prompt, the EnterPlanMode trigger heuristic, the ExitPlanMode semantics, and Anthropic's recommended Explore→Plan→Implement→Commit workflow. Read it before Phase 1; the wording is community-reverse-engineered (Piebald-AI \u002F how-claude-code-works \u002F Ronacher) and approximate in later phases — the structure and read-only discipline are authoritative.\n",{"name":5,"description":7},"main","31458d7e0e08a7b3494c27bf2b912ed41c87a138","fittings\u002Fseed\u002Fduty-plan\u002F.apm\u002Fskills\u002Fgarrison-plan",0,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison","https:\u002F\u002Fgongiskhan.github.io\u002Fagent-garrison\u002F","https:\u002F\u002Fgithub.com\u002Fgongiskhan","2026-11-07 05:27:23",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add gongiskhan\u002Fagent-garrison --skill garrison-plan",{"tool":65,"command":66},"bunx","bunx skills add gongiskhan\u002Fagent-garrison --skill garrison-plan",{"tool":68,"command":69},"pnpm","pnpm dlx skills add gongiskhan\u002Fagent-garrison --skill garrison-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fduty-plan\u002F.apm\u002Fskills\u002Fgarrison-plan\u002FSKILL.md",true,[],[74,86,96,107,119,147],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":46},"01M71RTFA0HD83YBE1TE7DCE6B","pinned-helper","An owned skill the human has pinned so the Improver must not touch it.","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fimprover\u002Fskills\u002Fpinned-helper\u002FSKILL.md",[],[81,82,83,84,85],"pinned helper","helper","human","touch","it",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":46},"01M71RTDKBG0WQHPHKFZKFWDHF","legacy-helper","A rarely used helper kept around from an earlier workflow.","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fimprover\u002Fskills\u002Flegacy-helper\u002FSKILL.md",[],[93,82,94,95],"Legacy","legacy helper","workflow",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":46},"01M71RTCC6ZVVJ9MHHESXPHWA6","human-notes","A human-authored skill not deployed by APM (loose, not in the lock).","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fimprover\u002Fskills\u002Fhuman-notes\u002FSKILL.md",[],[103,83,104,105,106],"notes","human notes","lock","apm",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":46},"01M71RTB83ZP6VK6XH19Z93FAC","garrison-helper","Helps compose and station Garrison Fittings into Faculty role slots.","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fimprover\u002Fskills\u002Fgarrison-helper\u002FSKILL.md",[],[82,114,115,116,117,118],"garrison","garrison helper","slots","role","compose",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":128,"publishedAt":46},"01M71RT6MBGJC4QQZBGHF4H1M8","walkthrough","Record a short, narrated, captioned video walkthrough that proves a finished coding task and shows how it behaves, then self-verify the video via vision on extracted frames and publish it as one scrubbable Tailscale link. Use after completing a change\u002Ffix\u002Ffeature on a web project (Next.js\u002FReact etc.) when the user wants visual proof of work, a demo of a user flow, or to avoid manually retesting and watching a long raw screen recording. Triggers on requests like \"record a walkthrough\", \"show me it working\", \"make a demo video of this\", \"prove the feature\", or finishing a UI\u002Froute\u002Fform\u002FAPI change worth demonstrating. Not for walking through a full from-scratch project build.","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002FSKILL.md",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",[121,34,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146],"project","project build","api","react","change","demo video","publish","recording","Video","show me","work","short","fix","show","route","me","next","self",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":46},"01M71RT54T0SQS42XEP5FVQ28K","Trello","Manage tasks via Trello REST API.","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Ftrello\u002F.apm\u002Fskills\u002Ftrello\u002FSKILL.md",[],[154,155,156,131,157,158,159],"trello","tasks","REST","manage","rest api","via"]