[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GV0VC60WAVV90K1FGJBBE2":3,"skill-same:01M6GV0VC60WAVV90K1FGJBBE2":62},{"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":17,"publishedAt":24,"linkOnly":25,"markdownContent":26,"markdownBody":27,"frontMatter":28,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":35,"ownerHtmlUrl":36,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":37,"install":38,"resources":51},"01M6GV0VC60WAVV90K1FGJBBE2","goat-plan",null,"Use when creating, updating, reconciling, or resuming milestone plans.","blundergoat\u002Fgoat-flow","blundergoat","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F260647401?v=4","01M6GTR7WK4KVYK7N5DEQGA7BT","01M6GTR84KH4BAF65ZV9V9DNG9",32,"MIT","https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat-plan\u002FSKILL.md",[],[18,19,20,21,22,23],"plan","goat plan","goat","use","milestone","plans","2026-11-10 10:12:30",false,"---\nname: goat-plan\ndescription: \"Use when creating, updating, reconciling, or resuming milestone plans.\"\ngoat-flow-skill-version: \"1.18.0\"\n---\n# \u002Fgoat-plan\n\n## Shared Conventions\n\nRead `.goat-flow\u002Fskill-docs\u002Fskill-preamble.md`; Modes R\u002F1\u002F3\u002F4 also read `.goat-flow\u002Fskill-docs\u002Fskill-conventions.md`.\n\nMode selection discharges the shared Quick\u002FFull depth choice; ceremony follows the preamble's complexity table.\n\n## When to Use\n\nUse for milestones, replans, rescope, or plan resume in `.goat-flow\u002Fplans\u002F\u003Cactive>\u002F`.\n\n## Boundary Commands\n\n- **NEVER:** Implement or do another skill's work.\n- **ALWAYS:** Keep the selected mode for the current request; new explicit intent runs Step 0 again.\n- **DEFER TO:** Direct tests\u002Fquestions or the matching goat-* skill.\n\n| Excuse | Reality |\n|--------|---------|\n| \"Show milestones first, files later\" | File-Write creates milestone artifacts immediately. Read-Only Analysis is for inline plans. |\n| \"Vague tasks are fine - implementer will figure it out\" | Cold-start tasks need one action, a target, and a done condition; supporting detail belongs beneath them. |\n| \"Proof is obvious - skip it\" | Agent skipped the AI proof gate after the first milestone. The gate caught what it missed. |\n| \"Bare task path means start implementing\" | Path-only context is data, not delegation. Bare task paths must not update .active, milestone status, checkboxes, or code. |\n\n## Step 0 - Intake\n\n1. **Classify the input shape before any plan-state read.** Path-only guard runs first: a task\u002Fmilestone path alone or ambiguous context phrase selects **Path-Only Intake \u002F Read-Only Orientation**. Do NOT update `.active`, milestone status fields, task checkboxes, or code. Switching a mismatched `.active` needs approval. Code or plan changes need an explicit action verb.\n\n2. **Run learning-loop retrieval before mode-specific reads.** Follow the preamble's INDEX-first retrieval and emit `Relevant prior learnings:`. Use brief\u002Fplan terms; add decisions for architecture, policy, or setup. For path-only intake, search only for plan-orientation and task-state failure classes. Do not retrieve implementation-domain learnings from the task path; open entries only when a hit affects safe orientation.\n\n3. **Inspect existing plan state only after retrieval.**\n- Explicit plan paths select that directory; milestone paths select their parent. Otherwise scan the valid advisory `.active` subdir.\n- If missing\u002Finvalid, list non-archive dirs and recent `M*.md`, ask which is current, and offer to update `.active`; this is not setup failure.\n- For stale plans, compare code and modification dates.\n\n### Reconcile Existing Plan State\n\nPlans are local workflow state, not a setup invariant. Mode R is read-only: report each canonical Status token with a plain-language explanation.\n\n**Starting fresh:** name the build, main risk, and kill criteria.\n\n4. **Pick exactly one mode.** First match:\n\n**0: Path-Only Intake \u002F Read-Only Orientation** - path-only or ambiguous task path. Summarize status, ask next action, stop.\n\n**No-file guard: Mode R or 2** - reporting-only\u002Fno-file constraints forbid writes: reconcile\u002Faudit requests select read-only Mode R; other requests select Mode 2. No-implementation alone does not forbid plan edits. Conflicting write\u002Fno-write instructions preserve bytes and require clarification.\n\n**Existing plan: resume to ACT** - start, resume or implement the current or a named milestone of an existing plan (its path, or the valid `.active` plan) writes no new milestones: confirm the milestone (ask when the plan records none), apply Phase 3 lane eligibility, then continue to ACT; Phase 3 gates it. A new build brief is never a resume.\n\n**Build handoff: Mode 3 or 4** - a `\u002Fgoat` `return-to-implement` build\u002Fchange brief authorizes gitignored planning artifacts, never Mode 2 or Ask First boundaries: Hotfix\u002FSmall Feature selects Mode 3; Standard+ selects Mode 4. Post-plan return then continues to ACT; Phase 3 gates each milestone.\n\n**1: Named-File Update** - explicit plan edits, including reconcile-and-fix with implementation prohibited. A path alone is not write approval; use Phase 2 § Mode 1, never implement code.\n\n**R: Reconcile Existing Plan State** - reconcile\u002Faudit without requested edits: compare evidence, propose corrections, stop without writes.\n\n**2: Read-Only Analysis** - inline planning without artifact authority. File mode requires authorization.\n\n**3: Small File-Write** - explicit planning artifacts for Hotfix \u002F Small Feature (1-2 milestones); use Mode 4's write path with compact ceremony.\n\n**4: File-Write (Standard+)** - explicit planning artifacts for Standard \u002F System \u002F Infrastructure; resolve missing destination\u002Fscope before writing.\n\n**CHECKPOINT (Path-Only Intake):** \"Mode: Path-Only Intake. Plan pointer: [state]. Active set: [IDs\u002Fstatuses]. Cap provenance: [value; config\u002Fdefault\u002Fsession override]. Session milestone: [ID\u002Funselected]. Next item: [item]. Action needed.\"\n\n**CHECKPOINT (Reconcile):** \"Mode R. State: [status]. Corrections: [changes]. No writes.\"\n\n**CHECKPOINT (Named-File Update):** \"Mode 1. Edit [file] in place for [delta]. Boundary: [scope].\"\n\n**CHECKPOINT (Resume):** \"Resume [milestone]. Lane eligibility: [state]. Next item: [bounded task or proof]. Continue authorized ACT; Phase 3 gates remain.\"\n\n**CHECKPOINT (planning modes):** \"Mode: [selected mode]. Milestones: [feature]. Risk: [risk]. Kill criteria: [criteria].\"\n\n## Phase 1 - Milestone Breakdown\n\nBudget determines must-deliver scope, ranked stretch work, and cut order. Risk sets proof; split for uncertainty, independent value, or a decision gate.\n\n### Milestone Archetypes\n\nArchetypes are optional lenses: **Prove It Works**, **Make It Real**, **Make It Solid**, **Make It Shine**. Merge shared outcomes\u002Fproof; omit valueless lenses.\n\n**Spike-first rule:** Library\u002FAPI, performance or integration uncertainty belongs in Milestone 1 as a spike, not Milestone 3 as a risk.\n\nNever drop a spike, intake, or kill criteria for milestone count, deadline, or reduced ceremony.\n\n### For each milestone, produce:\n\nChoose a Small, Standard, or high-risk rendering from `references\u002Fmilestone-examples.md`. Include outcome, Status, agent-time estimate, scope, executable Tasks, binary Exit, claim-based Proof, and Stop\u002Frescope. Standard+ adds `## What problem are we solving` and `## Who benefits and how` between Objective and Context, one plain line each. Actual, dependencies, context, assumptions, Mid-implementation proof, boundaries, rollback, deferred work, and maintenance are conditional.\n\n### Risk-weighted task ordering\n\nOrder **[RISKY]** unknowns\u002Fintegrations\u002Fspikes, **[CORE]** logic, then **[SAFE]** docs\u002Fpolish. Uncertainty requires a [RISKY] task.\n\n### Proof format\n\nState claim, evidence and proof-class tag. Omit inapplicable classes; manual proof is conditional. Static analysis is not behavioural proof. High-risk work keeps distinct compatibility, rollback and security evidence. Store literal commands once.\n\n### Quality rules\n\n**Tasks:** One action, target and done condition; supporting rationale\u002Fpaths\u002Fproof only when needed. Pin paths for downstream dependencies.\n\nStart task text with the operation; prefer about 25 words excluding tags and estimates. Validation, saving and history loading are separate observable changes: give each its own counted task. Separate test authoring from test execution. Read `references\u002Fmilestone-examples.md` → Short task example before rendering checkboxes.\n\nVerify paths\u002Fsymbols\u002Fbehavior against the target revision. Label proposed paths new and unresolved anchors `(confirm: what)`; investigate before dependent implementation.\n\nFor every ISSUE draft, PR, or handoff export, read `references\u002Fissue-format.md` → Human-facing exports before drafting and delivery; it owns audience checks and saved-draft proof.\n\n**Effort estimate (agent-time):** Count positive agent-owned Task\u002FProof\u002FMid-proof plus one admin; exclude `[HUMAN]` and zero-minute items. `Forecast basis:` records agent work units, rates, and historical `source:` quantiles. Use `1.0-2.5-6 min\u002Funit` until three eligible bases, then `plans check` evidence. Never use duration intuition; ~70\u002F20\u002F10 stays advisory. If scope changes, reforecast before implementation; `reforecast required` blocks. Execution uses `references\u002Fmilestone-examples.md` → Timing receipts. `Forecast range:` is required with a basis; legacy points and range-only estimates remain valid.\n\nBefore authoring or revising forecasts, read `references\u002Fmilestone-examples.md` → Effort Estimates for work counting, history selection, fast-case evidence and immutable revisions. Read `references\u002Fissue-format.md` → Forecast presentation when summarizing delivery.\n\n**Readable narrative, specific tasks:** Preamble prose routing applies; `references\u002Fissue-format.md` owns audience-specific task guidance.\n\n**Cold-start bar:** Identify files, conventions, scope, commands, and recovery.\n\n**Handoff-grade artifacts:** Use Standard+ drift context; Small File-Write stays compact.\n\n### Assumption tracking\n\nTick validated assumptions. Record invalidation and stop dependent work; amend only when mode\u002Fapproval permits. At human gates, propose and wait.\n\nFor Standard+, answer \"If this plan fails, the most likely cause is ...\" in an existing task, assumption, or kill criterion.\n\n**CHECKPOINT:** Read-Only Analysis stops inline. Write modes enter Phase 2; no Phase 1 approval pause.\n\n## Phase 2 - Deliver Milestones\n\nUse only the Step 0 mode's delivery block.\n\n### Mode 0: Path-Only Intake \u002F Read-Only Orientation\n\n- Read filenames plus Status, Lane, and Depends on; run the source-compatible `plans check \u003Cplan-path> --strict`. Checker errors stop body reads.\n- Use `--max-active` only when the operator supplied it for this session; otherwise omit it for canonical config or default one. Never infer a cap from the active count or borrow an earlier override; if an absent override is needed, stop and ask.\n- Active means `in-progress`, `testing-gate`, or `human-verification-pending`. An absent or empty Lane means `default`. Check the final join below before source work or timing.\n- One session owns one milestone. An explicit path or user instruction selects it; select the sole active milestone automatically. With several active milestones and no selection, report each bounded next item, then ask which milestone this session owns.\n- Read only the bounded next item: implementation task, executor proof, or human item according to status. Report other lanes as state, never implementation authority. With no active work, report eligible choices.\n- Do NOT mutate `.goat-flow\u002Fplans\u002F.active`, milestone status, checkboxes, or code.\n- Present the plan pointer, active set, cap provenance, session milestone, and next item. Ask for the next action and stop.\n\n### Mode R: Reconcile Existing Plan State (read-only)\n\nCompare HEAD and uncommitted state with status, tasks, assumptions, and evidence. Propose exact amendments; do NOT edit plans, `.active`, status\u002Fcheckboxes, or code.\n\n### Mode 1: Named-File Update (edit in place)\n\nEdit the named file in place; a path alone does not qualify. Preserve unaffected title\u002Fstatus. Present the delta and apply the progress rule for adopted plans; stop on scope spill.\n\n### Mode 2: Read-Only Analysis (no files)\n\nPresent Phase 1 inline and stop; no files or `.goat-flow\u002Fplans\u002F` changes. Skip Phase 3.\n\n**Transition out:** When the user explicitly requests files for an inline plan, reuse Phase 1: Hotfix\u002FSmall Feature selects Mode 3; Standard+ selects Mode 4. Across turns, re-read instructions, `.active`, and named sources; do not repeat breakdown. Clarify an ambiguous \"let's go ahead\".\n\n### Mode 3: Small File-Write (Hotfix \u002F Small Feature)\n\nDirect Hotfix invocation uses Mode 3. Write compact artifacts immediately; present paths and summary.\n\n### Mode 4: File-Write (Standard+)\n\nWrite Standard or triggered high-risk artifacts immediately. Do NOT invoke\u002Fask about `\u002Fgoat-critique`; run it only on request.\n\n### File Artifact Rules (Modes 3 and 4)\n\nFresh plan: honour supplied destinations; otherwise create a slugged directory. Write zero-padded `M*.md`, `investigation-notes` (empty allowed; no filler), and `_PROGRESS.md` containing only `# Plan and implementation progress`; follow the plans README. Existing plans adopt notes\u002Fprogress only explicitly. Only explicit active-plan selection updates `.active`. Existing plan: identify its prior final join covering every participating lane; amend a missing join first. Append: new `Depends on` prior join. Insert before prior: preserve its existing dependencies and add new. Re-derive `ISSUE.md` bands and totals.\n\n**Rendering:** Mode 3 uses compact Small; Mode 4 uses Standard plus triggered high-risk fields. Omit empty sections; retain Phase 1 core and claim-based Proof.\n\n**ISSUE.md:** Standard+ writes `ISSUE.md` using `references\u002Fissue-format.md` as read-only guidance; Small only for a requested GitHub brief, multiple milestones, or shared requirements\u002Fbudget.\n\n**Backlog:** Deferred items need `backlog.md` with Next, Later, and Maybe tiers.\n\n**CHECKPOINT:** \"Wrote [files created] to `.goat-flow\u002Fplans\u002F\u003Cactive>\u002F`. Ready to start implementation.\"\n\n**Validate:** Resolve inline references, then run `goat-flow plans check .goat-flow\u002Fplans\u002F\u003Cactive> --strict`; fix errors before the checkpoint.\n\n**Post-plan return:** After Phase 2 finishes, Modes 3\u002F4 apply the progress rule. `return-to-implement` hands ordinary ACT the existing build authorization; new Ask First boundaries still gate. Plan-only stops; Phase 3 gates milestones.\n\n## Phase 3 - Between Milestones\n\n**Progress:** For adopted plans, apply `references\u002Fissue-format.md` → Plan progress updates after meaningful planning or implementation batches, at handoff, and for material approval\u002Fcheck\u002Frework changes. Skip unchanged resumes. Carry this rule into execution handoffs; always run scoped `goat-clarity` before delivering new or revised entries.\n\n**Lane eligibility:** Activate not-started work only when every dependency is complete, its lane is free, and the active count is below the cap. For lane or capacity contention, show eligible IDs, lanes, and dependencies; ask, never select by number. Lanes grant no writer ownership; use disjoint scopes, applicable write claims, and an agreed merge boundary. Read `references\u002Fmilestone-examples.md` → Lane lifecycle for downgrade recovery.\n\n**Final join:** Exclude `abandoned`, `superseded`, and `deferred`; `blocked` still participates. Require one participating dependency sink whose transitive dependency closure covers every other participating milestone. Authors join every participating lane tip. `plans check --strict` fails a plan with open work that breaks this join; a fully complete plan gets an advisory instead. Multiple sinks or uncovered work requires a plan amendment before source work or timing; never guess.\n\nCompleted implementation enters `testing-gate`. If the milestone changed source, run `goat-clarity` on the paths it wrote before proof, so remediation renames cannot stale it. Apply the preamble's Proof Gate; audit tasks and exit, rerun only stale\u002Ffailed checks or when risk requires it.\n\nSuccessful AI proof records structured `Actual:` and sets `human-verification-pending`; only human-owned items stay open. Each milestone retains its own receipt and blocking human gate; unrelated active lanes keep their state and receipts. Follow `references\u002Fmilestone-examples.md` → Timing receipts: finalize before Actual or declare retrospective\u002Funavailable\u002Fincomplete instead of inventing minutes. Calibration eligibility starts at `complete`.\n\n**BLOCKING GATE (Human Verification):** Present files, exit evidence, estimate versus Actual, and assumptions. \"Approve this milestone and eligible follow-up work, or adjust?\"\n\nAfter approval for a non-final milestone, capture learnings, complete it, re-read\u002Fupdate the selected eligible milestone; start it only when `Depends on` permits and lane capacity allows. Human-requested changes return the milestone to `in-progress`; this applies only to the reviewed milestone; never amend silently. For exceptional states, use `references\u002Fmilestone-examples.md` → Status reason; remove stale reasons on ordinary states. Rerun strict validation after each transition.\n\nThe final pending milestone enters the combined Phase 4 review; do not mark it complete in Phase 3.\n\n## Phase 4 - Plan Complete\n\nBegin only when the unique final join is `human-verification-pending`, every other participating milestone and every join dependency is complete, and no sibling active work remains. Cap-one plans keep one final review.\n\n### AI Verification Gate\n\nVerify every implementation task and, when `ISSUE.md` exists, every ISSUE Tasks item is closed. Require fresh exit\u002FProof evidence, resolved assumptions, coherent statuses and required learning-loop updates. Keep Requirements stable and mapped to outcomes\u002Fproof. Reconcile ISSUE delivery bands with its headline separately: `plans check` reads milestones only. Aggregate gaps\u002FUNVERIFIED; reuse fresh evidence.\n\n### Human Verification Gate\n\n**BLOCKING GATE:** Present files changed, milestone states, exit evidence, invalidated assumptions, and UNVERIFIED items. \"Final evidence is ready. Review before I close this plan.\" Human approval is mandatory.\n\n### After Human Approval\n\n- Set the final milestone `complete` and confirm the plan snapshot.\n- Leave plan files in place; archival remains the human's decision.\n- Do not create a completion log unless the human requests one.\n\n## Constraints\n\n- MUST use claim-based Proof, risk-first tasks, and mid-proof before switching modules or after a bounded edit batch.\n- MUST stop dependent work on invalidated assumptions, kill criteria, scope changes, or conflicting evidence.\n- MUST preserve failing evidence and obtain approval before amendments or lifecycle transitions.\n- MUST keep every milestone and final completion behind AI proof plus human sign-off.\n- MUST NOT invoke or prompt for `\u002Fgoat-critique`; run it only on explicit request.\n- MUST NOT include self-deletion, self-archival, commit, or push instructions.\n\n## Output Format\n\nEmit the selected mode's result: resume checkpoint then authorized ACT; 0 orientation; R reconciliation; 1 delta; 2 inline milestones; 3\u002F4 paths, milestone names\u002Fobjectives, task\u002Fexit\u002Ftest counts, risks, and stop condition.\n\n**Terse-first:** One sentence per bullet; preserve gate prompts and evidence.\n","# \u002Fgoat-plan\n\n## Shared Conventions\n\nRead `.goat-flow\u002Fskill-docs\u002Fskill-preamble.md`; Modes R\u002F1\u002F3\u002F4 also read `.goat-flow\u002Fskill-docs\u002Fskill-conventions.md`.\n\nMode selection discharges the shared Quick\u002FFull depth choice; ceremony follows the preamble's complexity table.\n\n## When to Use\n\nUse for milestones, replans, rescope, or plan resume in `.goat-flow\u002Fplans\u002F\u003Cactive>\u002F`.\n\n## Boundary Commands\n\n- **NEVER:** Implement or do another skill's work.\n- **ALWAYS:** Keep the selected mode for the current request; new explicit intent runs Step 0 again.\n- **DEFER TO:** Direct tests\u002Fquestions or the matching goat-* skill.\n\n| Excuse | Reality |\n|--------|---------|\n| \"Show milestones first, files later\" | File-Write creates milestone artifacts immediately. Read-Only Analysis is for inline plans. |\n| \"Vague tasks are fine - implementer will figure it out\" | Cold-start tasks need one action, a target, and a done condition; supporting detail belongs beneath them. |\n| \"Proof is obvious - skip it\" | Agent skipped the AI proof gate after the first milestone. The gate caught what it missed. |\n| \"Bare task path means start implementing\" | Path-only context is data, not delegation. Bare task paths must not update .active, milestone status, checkboxes, or code. |\n\n## Step 0 - Intake\n\n1. **Classify the input shape before any plan-state read.** Path-only guard runs first: a task\u002Fmilestone path alone or ambiguous context phrase selects **Path-Only Intake \u002F Read-Only Orientation**. Do NOT update `.active`, milestone status fields, task checkboxes, or code. Switching a mismatched `.active` needs approval. Code or plan changes need an explicit action verb.\n\n2. **Run learning-loop retrieval before mode-specific reads.** Follow the preamble's INDEX-first retrieval and emit `Relevant prior learnings:`. Use brief\u002Fplan terms; add decisions for architecture, policy, or setup. For path-only intake, search only for plan-orientation and task-state failure classes. Do not retrieve implementation-domain learnings from the task path; open entries only when a hit affects safe orientation.\n\n3. **Inspect existing plan state only after retrieval.**\n- Explicit plan paths select that directory; milestone paths select their parent. Otherwise scan the valid advisory `.active` subdir.\n- If missing\u002Finvalid, list non-archive dirs and recent `M*.md`, ask which is current, and offer to update `.active`; this is not setup failure.\n- For stale plans, compare code and modification dates.\n\n### Reconcile Existing Plan State\n\nPlans are local workflow state, not a setup invariant. Mode R is read-only: report each canonical Status token with a plain-language explanation.\n\n**Starting fresh:** name the build, main risk, and kill criteria.\n\n4. **Pick exactly one mode.** First match:\n\n**0: Path-Only Intake \u002F Read-Only Orientation** - path-only or ambiguous task path. Summarize status, ask next action, stop.\n\n**No-file guard: Mode R or 2** - reporting-only\u002Fno-file constraints forbid writes: reconcile\u002Faudit requests select read-only Mode R; other requests select Mode 2. No-implementation alone does not forbid plan edits. Conflicting write\u002Fno-write instructions preserve bytes and require clarification.\n\n**Existing plan: resume to ACT** - start, resume or implement the current or a named milestone of an existing plan (its path, or the valid `.active` plan) writes no new milestones: confirm the milestone (ask when the plan records none), apply Phase 3 lane eligibility, then continue to ACT; Phase 3 gates it. A new build brief is never a resume.\n\n**Build handoff: Mode 3 or 4** - a `\u002Fgoat` `return-to-implement` build\u002Fchange brief authorizes gitignored planning artifacts, never Mode 2 or Ask First boundaries: Hotfix\u002FSmall Feature selects Mode 3; Standard+ selects Mode 4. Post-plan return then continues to ACT; Phase 3 gates each milestone.\n\n**1: Named-File Update** - explicit plan edits, including reconcile-and-fix with implementation prohibited. A path alone is not write approval; use Phase 2 § Mode 1, never implement code.\n\n**R: Reconcile Existing Plan State** - reconcile\u002Faudit without requested edits: compare evidence, propose corrections, stop without writes.\n\n**2: Read-Only Analysis** - inline planning without artifact authority. File mode requires authorization.\n\n**3: Small File-Write** - explicit planning artifacts for Hotfix \u002F Small Feature (1-2 milestones); use Mode 4's write path with compact ceremony.\n\n**4: File-Write (Standard+)** - explicit planning artifacts for Standard \u002F System \u002F Infrastructure; resolve missing destination\u002Fscope before writing.\n\n**CHECKPOINT (Path-Only Intake):** \"Mode: Path-Only Intake. Plan pointer: [state]. Active set: [IDs\u002Fstatuses]. Cap provenance: [value; config\u002Fdefault\u002Fsession override]. Session milestone: [ID\u002Funselected]. Next item: [item]. Action needed.\"\n\n**CHECKPOINT (Reconcile):** \"Mode R. State: [status]. Corrections: [changes]. No writes.\"\n\n**CHECKPOINT (Named-File Update):** \"Mode 1. Edit [file] in place for [delta]. Boundary: [scope].\"\n\n**CHECKPOINT (Resume):** \"Resume [milestone]. Lane eligibility: [state]. Next item: [bounded task or proof]. Continue authorized ACT; Phase 3 gates remain.\"\n\n**CHECKPOINT (planning modes):** \"Mode: [selected mode]. Milestones: [feature]. Risk: [risk]. Kill criteria: [criteria].\"\n\n## Phase 1 - Milestone Breakdown\n\nBudget determines must-deliver scope, ranked stretch work, and cut order. Risk sets proof; split for uncertainty, independent value, or a decision gate.\n\n### Milestone Archetypes\n\nArchetypes are optional lenses: **Prove It Works**, **Make It Real**, **Make It Solid**, **Make It Shine**. Merge shared outcomes\u002Fproof; omit valueless lenses.\n\n**Spike-first rule:** Library\u002FAPI, performance or integration uncertainty belongs in Milestone 1 as a spike, not Milestone 3 as a risk.\n\nNever drop a spike, intake, or kill criteria for milestone count, deadline, or reduced ceremony.\n\n### For each milestone, produce:\n\nChoose a Small, Standard, or high-risk rendering from `references\u002Fmilestone-examples.md`. Include outcome, Status, agent-time estimate, scope, executable Tasks, binary Exit, claim-based Proof, and Stop\u002Frescope. Standard+ adds `## What problem are we solving` and `## Who benefits and how` between Objective and Context, one plain line each. Actual, dependencies, context, assumptions, Mid-implementation proof, boundaries, rollback, deferred work, and maintenance are conditional.\n\n### Risk-weighted task ordering\n\nOrder **[RISKY]** unknowns\u002Fintegrations\u002Fspikes, **[CORE]** logic, then **[SAFE]** docs\u002Fpolish. Uncertainty requires a [RISKY] task.\n\n### Proof format\n\nState claim, evidence and proof-class tag. Omit inapplicable classes; manual proof is conditional. Static analysis is not behavioural proof. High-risk work keeps distinct compatibility, rollback and security evidence. Store literal commands once.\n\n### Quality rules\n\n**Tasks:** One action, target and done condition; supporting rationale\u002Fpaths\u002Fproof only when needed. Pin paths for downstream dependencies.\n\nStart task text with the operation; prefer about 25 words excluding tags and estimates. Validation, saving and history loading are separate observable changes: give each its own counted task. Separate test authoring from test execution. Read `references\u002Fmilestone-examples.md` → Short task example before rendering checkboxes.\n\nVerify paths\u002Fsymbols\u002Fbehavior against the target revision. Label proposed paths new and unresolved anchors `(confirm: what)`; investigate before dependent implementation.\n\nFor every ISSUE draft, PR, or handoff export, read `references\u002Fissue-format.md` → Human-facing exports before drafting and delivery; it owns audience checks and saved-draft proof.\n\n**Effort estimate (agent-time):** Count positive agent-owned Task\u002FProof\u002FMid-proof plus one admin; exclude `[HUMAN]` and zero-minute items. `Forecast basis:` records agent work units, rates, and historical `source:` quantiles. Use `1.0-2.5-6 min\u002Funit` until three eligible bases, then `plans check` evidence. Never use duration intuition; ~70\u002F20\u002F10 stays advisory. If scope changes, reforecast before implementation; `reforecast required` blocks. Execution uses `references\u002Fmilestone-examples.md` → Timing receipts. `Forecast range:` is required with a basis; legacy points and range-only estimates remain valid.\n\nBefore authoring or revising forecasts, read `references\u002Fmilestone-examples.md` → Effort Estimates for work counting, history selection, fast-case evidence and immutable revisions. Read `references\u002Fissue-format.md` → Forecast presentation when summarizing delivery.\n\n**Readable narrative, specific tasks:** Preamble prose routing applies; `references\u002Fissue-format.md` owns audience-specific task guidance.\n\n**Cold-start bar:** Identify files, conventions, scope, commands, and recovery.\n\n**Handoff-grade artifacts:** Use Standard+ drift context; Small File-Write stays compact.\n\n### Assumption tracking\n\nTick validated assumptions. Record invalidation and stop dependent work; amend only when mode\u002Fapproval permits. At human gates, propose and wait.\n\nFor Standard+, answer \"If this plan fails, the most likely cause is ...\" in an existing task, assumption, or kill criterion.\n\n**CHECKPOINT:** Read-Only Analysis stops inline. Write modes enter Phase 2; no Phase 1 approval pause.\n\n## Phase 2 - Deliver Milestones\n\nUse only the Step 0 mode's delivery block.\n\n### Mode 0: Path-Only Intake \u002F Read-Only Orientation\n\n- Read filenames plus Status, Lane, and Depends on; run the source-compatible `plans check \u003Cplan-path> --strict`. Checker errors stop body reads.\n- Use `--max-active` only when the operator supplied it for this session; otherwise omit it for canonical config or default one. Never infer a cap from the active count or borrow an earlier override; if an absent override is needed, stop and ask.\n- Active means `in-progress`, `testing-gate`, or `human-verification-pending`. An absent or empty Lane means `default`. Check the final join below before source work or timing.\n- One session owns one milestone. An explicit path or user instruction selects it; select the sole active milestone automatically. With several active milestones and no selection, report each bounded next item, then ask which milestone this session owns.\n- Read only the bounded next item: implementation task, executor proof, or human item according to status. Report other lanes as state, never implementation authority. With no active work, report eligible choices.\n- Do NOT mutate `.goat-flow\u002Fplans\u002F.active`, milestone status, checkboxes, or code.\n- Present the plan pointer, active set, cap provenance, session milestone, and next item. Ask for the next action and stop.\n\n### Mode R: Reconcile Existing Plan State (read-only)\n\nCompare HEAD and uncommitted state with status, tasks, assumptions, and evidence. Propose exact amendments; do NOT edit plans, `.active`, status\u002Fcheckboxes, or code.\n\n### Mode 1: Named-File Update (edit in place)\n\nEdit the named file in place; a path alone does not qualify. Preserve unaffected title\u002Fstatus. Present the delta and apply the progress rule for adopted plans; stop on scope spill.\n\n### Mode 2: Read-Only Analysis (no files)\n\nPresent Phase 1 inline and stop; no files or `.goat-flow\u002Fplans\u002F` changes. Skip Phase 3.\n\n**Transition out:** When the user explicitly requests files for an inline plan, reuse Phase 1: Hotfix\u002FSmall Feature selects Mode 3; Standard+ selects Mode 4. Across turns, re-read instructions, `.active`, and named sources; do not repeat breakdown. Clarify an ambiguous \"let's go ahead\".\n\n### Mode 3: Small File-Write (Hotfix \u002F Small Feature)\n\nDirect Hotfix invocation uses Mode 3. Write compact artifacts immediately; present paths and summary.\n\n### Mode 4: File-Write (Standard+)\n\nWrite Standard or triggered high-risk artifacts immediately. Do NOT invoke\u002Fask about `\u002Fgoat-critique`; run it only on request.\n\n### File Artifact Rules (Modes 3 and 4)\n\nFresh plan: honour supplied destinations; otherwise create a slugged directory. Write zero-padded `M*.md`, `investigation-notes` (empty allowed; no filler), and `_PROGRESS.md` containing only `# Plan and implementation progress`; follow the plans README. Existing plans adopt notes\u002Fprogress only explicitly. Only explicit active-plan selection updates `.active`. Existing plan: identify its prior final join covering every participating lane; amend a missing join first. Append: new `Depends on` prior join. Insert before prior: preserve its existing dependencies and add new. Re-derive `ISSUE.md` bands and totals.\n\n**Rendering:** Mode 3 uses compact Small; Mode 4 uses Standard plus triggered high-risk fields. Omit empty sections; retain Phase 1 core and claim-based Proof.\n\n**ISSUE.md:** Standard+ writes `ISSUE.md` using `references\u002Fissue-format.md` as read-only guidance; Small only for a requested GitHub brief, multiple milestones, or shared requirements\u002Fbudget.\n\n**Backlog:** Deferred items need `backlog.md` with Next, Later, and Maybe tiers.\n\n**CHECKPOINT:** \"Wrote [files created] to `.goat-flow\u002Fplans\u002F\u003Cactive>\u002F`. Ready to start implementation.\"\n\n**Validate:** Resolve inline references, then run `goat-flow plans check .goat-flow\u002Fplans\u002F\u003Cactive> --strict`; fix errors before the checkpoint.\n\n**Post-plan return:** After Phase 2 finishes, Modes 3\u002F4 apply the progress rule. `return-to-implement` hands ordinary ACT the existing build authorization; new Ask First boundaries still gate. Plan-only stops; Phase 3 gates milestones.\n\n## Phase 3 - Between Milestones\n\n**Progress:** For adopted plans, apply `references\u002Fissue-format.md` → Plan progress updates after meaningful planning or implementation batches, at handoff, and for material approval\u002Fcheck\u002Frework changes. Skip unchanged resumes. Carry this rule into execution handoffs; always run scoped `goat-clarity` before delivering new or revised entries.\n\n**Lane eligibility:** Activate not-started work only when every dependency is complete, its lane is free, and the active count is below the cap. For lane or capacity contention, show eligible IDs, lanes, and dependencies; ask, never select by number. Lanes grant no writer ownership; use disjoint scopes, applicable write claims, and an agreed merge boundary. Read `references\u002Fmilestone-examples.md` → Lane lifecycle for downgrade recovery.\n\n**Final join:** Exclude `abandoned`, `superseded`, and `deferred`; `blocked` still participates. Require one participating dependency sink whose transitive dependency closure covers every other participating milestone. Authors join every participating lane tip. `plans check --strict` fails a plan with open work that breaks this join; a fully complete plan gets an advisory instead. Multiple sinks or uncovered work requires a plan amendment before source work or timing; never guess.\n\nCompleted implementation enters `testing-gate`. If the milestone changed source, run `goat-clarity` on the paths it wrote before proof, so remediation renames cannot stale it. Apply the preamble's Proof Gate; audit tasks and exit, rerun only stale\u002Ffailed checks or when risk requires it.\n\nSuccessful AI proof records structured `Actual:` and sets `human-verification-pending`; only human-owned items stay open. Each milestone retains its own receipt and blocking human gate; unrelated active lanes keep their state and receipts. Follow `references\u002Fmilestone-examples.md` → Timing receipts: finalize before Actual or declare retrospective\u002Funavailable\u002Fincomplete instead of inventing minutes. Calibration eligibility starts at `complete`.\n\n**BLOCKING GATE (Human Verification):** Present files, exit evidence, estimate versus Actual, and assumptions. \"Approve this milestone and eligible follow-up work, or adjust?\"\n\nAfter approval for a non-final milestone, capture learnings, complete it, re-read\u002Fupdate the selected eligible milestone; start it only when `Depends on` permits and lane capacity allows. Human-requested changes return the milestone to `in-progress`; this applies only to the reviewed milestone; never amend silently. For exceptional states, use `references\u002Fmilestone-examples.md` → Status reason; remove stale reasons on ordinary states. Rerun strict validation after each transition.\n\nThe final pending milestone enters the combined Phase 4 review; do not mark it complete in Phase 3.\n\n## Phase 4 - Plan Complete\n\nBegin only when the unique final join is `human-verification-pending`, every other participating milestone and every join dependency is complete, and no sibling active work remains. Cap-one plans keep one final review.\n\n### AI Verification Gate\n\nVerify every implementation task and, when `ISSUE.md` exists, every ISSUE Tasks item is closed. Require fresh exit\u002FProof evidence, resolved assumptions, coherent statuses and required learning-loop updates. Keep Requirements stable and mapped to outcomes\u002Fproof. Reconcile ISSUE delivery bands with its headline separately: `plans check` reads milestones only. Aggregate gaps\u002FUNVERIFIED; reuse fresh evidence.\n\n### Human Verification Gate\n\n**BLOCKING GATE:** Present files changed, milestone states, exit evidence, invalidated assumptions, and UNVERIFIED items. \"Final evidence is ready. Review before I close this plan.\" Human approval is mandatory.\n\n### After Human Approval\n\n- Set the final milestone `complete` and confirm the plan snapshot.\n- Leave plan files in place; archival remains the human's decision.\n- Do not create a completion log unless the human requests one.\n\n## Constraints\n\n- MUST use claim-based Proof, risk-first tasks, and mid-proof before switching modules or after a bounded edit batch.\n- MUST stop dependent work on invalidated assumptions, kill criteria, scope changes, or conflicting evidence.\n- MUST preserve failing evidence and obtain approval before amendments or lifecycle transitions.\n- MUST keep every milestone and final completion behind AI proof plus human sign-off.\n- MUST NOT invoke or prompt for `\u002Fgoat-critique`; run it only on explicit request.\n- MUST NOT include self-deletion, self-archival, commit, or push instructions.\n\n## Output Format\n\nEmit the selected mode's result: resume checkpoint then authorized ACT; 0 orientation; R reconciliation; 1 delta; 2 inline milestones; 3\u002F4 paths, milestone names\u002Fobjectives, task\u002Fexit\u002Ftest counts, risks, and stop condition.\n\n**Terse-first:** One sentence per bullet; preserve gate prompts and evidence.\n",{"name":5,"description":7,"goat-flow-skill-version":29},"1.18.0","main","369a5f67ee6d91bd7cda2b7d745dd5c256980543","workflow\u002Fskills\u002Fgoat-plan",2,"https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow","https:\u002F\u002Fgoat-flow.com","https:\u002F\u002Fgithub.com\u002Fblundergoat","2026-11-12 03:36:32",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":50},[40,43,46],{"tool":41,"command":42},"npx","npx skills add blundergoat\u002Fgoat-flow --skill goat-plan",{"tool":44,"command":45},"bunx","bunx skills add blundergoat\u002Fgoat-flow --skill goat-plan",{"tool":47,"command":48},"pnpm","pnpm dlx skills add blundergoat\u002Fgoat-flow --skill goat-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat-plan\u002FSKILL.md",true,[52,58],{"path":53,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":56,"sourceHtmlUrl":57},"references\u002Fissue-format.md","REFERENCE","参考文档",19117,"https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat-plan\u002Freferences\u002Fissue-format.md",{"path":59,"resourceType":54,"resourceTypeDesc":55,"sizeBytes":60,"sourceHtmlUrl":61},"references\u002Fmilestone-examples.md",21930,"https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat-plan\u002Freferences\u002Fmilestone-examples.md",[63,77,94,117,139,153],{"skillNo":64,"name":20,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":73,"publishedAt":24},"01M6GV2QNW1KRHYPSNXA2F0A3G","Use when you describe an outcome and need the right goat-* workflow chosen for you.","https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat\u002FSKILL.md",[68],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[20,74,21,75,76],"you","outcome","workflow",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":88,"publishedAt":24},"01M6GV2AQBX5PYWK2CT1B9D82R","goat-security","Use when assessing security implications of code changes, architecture decisions, or new features.","https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat-security\u002FSKILL.md",[83],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[89,90,20,21,91,92,93],"security","goat security","architecture","decisions","code",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":104,"publishedAt":24},"01M6GV1W3W2Q94F9GSNFC5PS7Z","goat-review","Use when reviewing a diff, PR, or set of code changes, or auditing a codebase area for quality issues. Triggers: 'review this', 'code review', 'audit X', 'look at these changes'.","https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat-review\u002FSKILL.md",[100,103],{"categoryNo":101,"categoryName":102,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[105,106,20,107,93,108,109,110,111,21,112,113,114,115,116],"review","goat review","diff","issues","audit","SET","quality","look","triggers","at","pr","code review",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":127,"publishedAt":24},"01M6GV17R6Z0D01Q69MX2FDNQZ","goat-qa","Use when evaluating test coverage gaps, planning test strategy, or assessing testing risk for code changes.","https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat-qa\u002FSKILL.md",[123,126],{"categoryNo":124,"categoryName":125,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[20,128,129,130,131,132,133,93,134,135,136,137,21,138],"goat qa","qa","test strategy","testing","test","coverage gaps","planning","risk","strategy","coverage","test coverage",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":146,"publishedAt":24},"01M6GV0B1S1D5C7NR86VP2BH9R","goat-debug","Use when diagnosing a bug, unexpected behaviour, system failure, or unfamiliar code that needs structured investigation.","https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat-debug\u002FSKILL.md",[145],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},[147,20,148,93,149,150,21,151,152],"goat debug","debug","investigation","system","bug","structured",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"publishedAt":24},"01M6GTZVWV3QCZSWWA1J91ARF1","goat-critique","Use when a decision or analysis needs multi-lens critique to surface blind spots before shipping.","https:\u002F\u002Fgithub.com\u002Fblundergoat\u002Fgoat-flow\u002Fblob\u002Fmain\u002Fworkflow\u002Fskills\u002Fgoat-critique\u002FSKILL.md",[159],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},[20,161,162,163,164,21,165,166,167,168],"critique","goat critique","analysis","decision","spots","lens","multi","shipping"]