[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71RJAC4NNEQSYBDSY3NZS73":3,"skill-same:01M71RJAC4NNEQSYBDSY3NZS73":102},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M71RJAC4NNEQSYBDSY3NZS73","autospec",null,"Use when the user wants to ship a feature end-to-end across multiple commits — bootstraps repo if missing, brainstorms a design spec, decomposes into linked GitHub issues, or splits an existing spec into issues, then runs an autonomous implementation loop with auto-merge.","berlinguyinca\u002Fautospec","berlinguyinca","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F16364?v=4","01M71R7C0SWBG05FNHQE4XQ7Y3","Gert Wohlgemuth","01M71R7C1VY5K3Q715RNDDBVGQ",3,"MIT","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"design spec","use","missing","repo","commits","feature","github issues","implementation loop","ship","merge","across","when","loop","auto","autonomous","design","issues","end","ship a feature","2026-11-10 13:02:02",false,"---\nname: autospec\ndescription: Use when the user wants to ship a feature end-to-end across multiple commits — bootstraps repo if missing, brainstorms a design spec, decomposes into linked GitHub issues, or splits an existing spec into issues, then runs an autonomous implementation loop with auto-merge.\n---\n\n# autospec workflow (harness-neutral)\n\nTake the following feature request and ship it through the full pipeline:\n**bootstrap repo (if missing) → investigate → design → spec → decomposed GitHub issues → autonomous implementation with auto-merge → periodic status updates → final report.**\n\nIf the request asks to split, materialize, roadmap, decompose, or turn an\nalready-written spec into GitHub issues, use **Existing spec mode** below:\nselect a tracked `docs\u002Fspecs\u002F*.md` file, skip Phases 1-2, run Phase 3 and\nPhase 3.5 against that spec, then continue to the Phase 3 pre-impl gate.\n\nManage your own context — never exceed 60%. Delegate to subagents whenever your harness supports it; do not investigate, write code, or design directly in the main conversation when a subagent can do it.\n\n\u003C!-- autospec-block:startup-self-update SKILL_NAME=autospec -->\n\n## Self-update mode\n\nDecide this purely from the request text the harness handed you. Do NOT\nshell out (no `grep`, `sed`, `[[ =~ ]]`, command substitution, etc.) to\ntest the user's free-form request — passing it through a shell is what\nhistorically tripped harness permission engines (e.g. parse errors near\nbacktick\u002Fpipe characters in the user's prose). Read the request, normalize\nit in your reasoning (collapse whitespace, trim, lowercase), and if the result is\nexactly `update`, this skill enters self-update mode and does NOT run the\nnormal pipeline.\n\n1. **Detect harness** by checking which install path exists for this skill:\n   - Claude Code: `~\u002F.claude\u002Fskills\u002Fautospec\u002FSKILL.md`\n   - OpenCode:    `~\u002F.config\u002Fopencode\u002Fagent\u002Fautospec.md`\n   - Codex CLI:   `~\u002F.codex\u002Fprompts\u002Fautospec.md`\n2. **Re-install the full autospec suite from `main`** by piping the canonical installer:\n   ```bash\n   curl -fsSL https:\u002F\u002Fraw.githubusercontent.com\u002Fberlinguyinca\u002Fautospec\u002Fmain\u002Fbootstrap.sh | bash -s -- --skill all --harness all --update\n   ```\n   Run this one-liner once; it refreshes all autospec skills across all harnesses.\n3. **Show the diff** between the prior installed file(s) and the freshly fetched copy (e.g. `diff \u003C(cat \u003Cprior>) \u003C(curl -fsSL ...SKILL.md)` or the equivalent recorded by the installer).\n4. **Stop.** Do not enter Phase 0 \u002F Phase 1 \u002F any pipeline phase. Print the upgrade summary and return to the user.\n\nIf no install path is detected, print `Self-update: no installed copy of autospec found; run install.sh first.` and exit.\n\n## Stop mode\n\nApply the same read-and-normalize approach used for self-update mode (do\nNOT shell out the user's request). If the normalized request is exactly\n`stop`, or `stop` followed by one or more `--\u003Cword>` flags (examples:\n`stop`, `stop --graceful`, `stop --immediate`, `stop --status`,\n`stop --resume`, `stop --help`, `stop --flag`), this skill enters stop\nmode and does NOT run the normal pipeline. When dispatching, pass any\n`--\u003Cflag>` tokens the user provided as separate words to the helper.\n\n1. Dispatch to `bash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fautospec-stop.sh\" \u003Cargs>`.\n2. Print the helper's stdout to the user.\n3. Stop. Do not enter Phase 0 or any pipeline phase.\n\n## Feature request\n\n{FEATURE_DESCRIPTION}\n\n---\n\n\n## Continuous loop mode (--loop)\n\nWhen the operator invokes `\u002Fautospec --loop \"\u003Cinitial prompt>\"` (alias\n`--continuous`), this skill runs the full pipeline (Phases 1-6) once, then\nharvests the Phase 6 final report (`.autospec\u002Frun-summary.md` written by\n`autospec-write-run-summary.sh`) and re-iterates until one of six\ntermination conditions trips. The loop is driven by the shared library at\n`lib\u002Fautospec-loop.sh` — the single source of truth shared with\n`\u002Fautospec-refine --continue` and `\u002Fautospec-continue --loop`.\n\nFlags:\n- `--loop` (alias `--continuous`) — enable continuous-iteration mode.\n- `--max-iterations N` — cap the loop at N iterations (default 5, env\n  override `AUTOSPEC_LOOP_MAX_ITERATIONS`).\n- `--skip-refine` — pipe the harvested next-prompt straight into the next\n  \u002Fautospec invocation without first running `\u002Fautospec-refine` on it.\n\nTermination conditions (priority order):\n1. `evidence_based_stop` — the run-summary contains a `STOP: \u003Creason>` marker.\n2. `convergence_clean` — harvest returns empty \u002F `(none — converged)`.\n3. `oscillation_detected` — iteration N+1's harvested prompt hash equals\n   iteration N's (same work proposed twice in a row).\n4. `operator_stop` — `~\u002F.autospec\u002Fstop.flag` or\n   `~\u002F.autospec\u002Frefine-loop-stop.flag` present at iteration boundary.\n5. `budget_cap_reached` — `AUTOSPEC_LOOP_TOKEN_CAP` (default 2M tokens) or\n   `AUTOSPEC_LOOP_TIME_CAP` (default 6h \u002F 21600s) exceeded.\n6. `round_cap_reached` — `--max-iterations` hit without any of the above.\n\nPer-iteration loop:\n1. Run the full \u002Fautospec pipeline (Phase 1-6) on the current prompt.\n2. Read `$REPO_ROOT\u002F.autospec\u002Frun-summary.md` and pass it to\n   `autospec_loop_harvest_next_prompt` from the shared library.\n3. If harvest is empty → `convergence_clean`. If it returns\n   `STOP::\u003Creason>` → `evidence_based_stop`. Otherwise the harvested text\n   becomes the next iteration's prompt.\n4. Unless `--skip-refine` is set, run the harvested prompt through\n   `\u002Fautospec-refine` (4 lenses) before the next \u002Fautospec invocation.\n5. Hash the harvested prompt; oscillation trips when the hash matches\n   the previous iteration's.\n\nOutput artifacts:\n- `.autospec\u002Floop-summary.md` — markdown table with one row per iteration\n  + final status + iterations executed.\n- `\u003Cartifact-dir>\u002F\u003Cslug>-loop.json` — per-iteration JSON record validated\n  against `schemas\u002Fautospec-refinement-loop.schema.json`.\n\nSafety guardrails inherit from the existing autonomy gate\n(`autospec-autonomy-gate.sh`) — destructive remote actions still\nsurface for confirmation per iteration. The rate limit + injection guard\nfrom `autospec-continue.sh` (PR #704) also apply.\n\nDefault behavior (no `--loop`) is unchanged: a single end-to-end pipeline\nrun with no harvest\u002Fre-iteration.\n\n## Existing spec mode\n\nUse this mode when the request asks to split, materialize, roadmap, decompose,\nor turn an existing spec into GitHub issues. Examples:\n`split existing spec`, `split latest spec`, `turn this spec into GitHub issues`,\n`roadmap docs\u002Fspecs\u002F2026-05-01-example-design.md`, or\n`materialize the newest spec`.\n\nDo not run Phase 1 or Phase 2 in this mode. The design already exists; this\nmode is a shortcut into Phase 3 using the same issue decomposition and Phase 3.5\nclassification path as the normal pipeline.\n\n1. **Verify repo.** Run the Phase 0 repo probes. If the current directory is\n   not a git repo with a GitHub remote, use Phase 0 bootstrap before selecting\n   a spec.\n2. **Resolve candidate specs.**\n   - If the request contains an explicit `docs\u002Fspecs\u002F*.md` path, use that file.\n   - Otherwise list tracked and untracked local files matching `docs\u002Fspecs\u002F*.md`.\n   - Sort by ISO date in the filename (`YYYY-MM-DD-...`) descending. For files\n     without a date prefix, sort after dated files by filesystem modified time.\n   - The first item is the default \"newest\" spec.\n3. **Ask on ambiguity.**\n   - If zero specs exist, stop with: `No docs\u002Fspecs\u002F*.md files found. Create or\n     point me at a spec before running existing spec mode.`\n   - If exactly one spec exists and no explicit path was provided, use it.\n   - If more than one spec exists and no explicit path was provided, ask the user\n     to confirm the default newest spec or choose another path. Show at most the\n     five newest candidates with relative paths. Do not file issues until the\n     user answers.\n4. **Verify selected spec is filed.**\n   - The selected path must be under `docs\u002Fspecs\u002F` and end in `.md`.\n   - The selected file must be tracked on `origin\u002Fmain` before Phase 3, so child\n     issues can cite a stable GitHub URL. Verify with:\n     `git fetch origin` and `git cat-file -e origin\u002Fmain:\u003Cspec-path>`.\n   - If the selected file is missing from `origin\u002Fmain`, stop and tell the user:\n     `Selected spec is not on origin\u002Fmain yet: \u003Cspec-path>. Land the spec first,\n     or run normal \u002Fautospec so Phase 2 can create and merge the spec PR.`\n5. **Continue at Phase 3.** Capture `{selected_spec_path}` and its GitHub URL as\n   `https:\u002F\u002Fgithub.com\u002F{repo}\u002Fblob\u002Fmain\u002F{selected_spec_path}`. Run Phase 3 and\n   Phase 3.5 using that selected spec. Then proceed to the existing Phase 3\n   pre-impl gate.\n\n\u003C!-- autospec-block:harness-adapter -->\n\n### Managed Project registration after Phase 0 bootstrap\n\nWhen Phase 0 creates a GitHub repository, register it only after the required\nremote read-back succeeds. Set `REPO` to the exact `owner\u002Fname` slug and set\n`SPAWNED_FROM` to the source-spec URL when one already exists, otherwise to the\ncurrent Autospec run identity (or `bootstrap:\u003Cowner\u002Fname>` when neither exists):\n\n```bash\ngh repo view \u003Cowner>\u002F\u003Cname> --json url,defaultBranchRef\nREPO=\"\u003Cowner>\u002F\u003Cname>\"\nSPAWNED_FROM=\"${SOURCE_SPEC_URL:-${AUTOSPEC_RUN_ID:-bootstrap:$REPO}}\"\nREGISTRATION_JSON=$(\"${AUTOSPEC_BIN:-autospec}\" project onboard --repo-dir \"$PWD\" --repo \"$REPO\" --spawned-from \"$SPAWNED_FROM\") || {\n  printf '%s\\n' 'ERROR: managed Project repository registration failed before durable admission' >&2\n  exit 1\n}\ncase \"$(printf '%s' \"$REGISTRATION_JSON\" | jq -r '.outcome \u002F\u002F empty')\" in\n  reconciled) ;;\n  journaled_projection_pending)\n    printf '%s\\n' 'WARNING: managed Project repository projection is durably journaled and pending' >&2 ;;\n  *) printf '%s\\n' 'ERROR: managed Project repository registration returned no supported typed outcome' >&2; exit 1 ;;\nesac\n```\n\nNever run registration when remote verification fails. A typed pending outcome\ndoes not roll back, delete, or recreate the verified repository; the managed\nProject journal retains the pending projection for a later `project sync`.\nPropagate every hard registration failure.\n\n## Physical STL \u002F CAD design guardrails\n\nWhen the request involves STL, CAD, 3D-printable fixtures, workholding,\nvacuum, pneumatic, hydraulic, dust-collection, hose, fitting, gasket, or\nother physical models, carry these requirements into Phase 2 specs, Phase 3\nchild issues, and Phase 4 verification:\n\n- Treat physical function as acceptance criteria, not visual intent. Verify\n  mountability, tool access, fitting clearance, gasket compression, storage fit,\n  printer build volume, and expected operating orientation.\n- Do not allow blocked ports, obstructed hoses\u002Ftubes, capped passages, hidden\n  dead-end channels, or geometry that interferes with the model's purpose.\n- Around every port, fitting, connector, tap bore, hose socket, screw head, and\n  service tool path, require at least 5 mm of free working clearance in every\n  direction unless the user explicitly specifies a tighter envelope.\n- Around every gasket path, require at least 5 mm of continuous plastic margin\n  outside the gasket. Gasket grooves must not expose an edge or be crossed by\n  mounts, screws, ribs, channels, holders, or workpiece contact geometry.\n- For NPT or other tapped ports, prove the tap and installed fitting can enter\n  straight or along the specified angled axis without collisions. Ports and\n  fitting bosses must be integrated into reinforced body geometry, not left as\n  fragile stand-alone protrusions.\n- For low-flow vacuum systems, do not add relief valves, vents, restriction\n  orifices, small balancing holes, or intentional leaks unless the user\n  explicitly asks for them and the spec records why the pump can tolerate them.\n- For sealed or flowing parts, require gas\u002Ffluid\u002Fvacuum\u002Fdust-flow simulation or\n  deterministic geometry checks that prove no leaks, no disconnected internal\n  circuits, no blocked passages, and adequate inlet-to-outlet connectivity.\n- For dust collection, preserve maximum practical duct cross-section and\n  suction path continuity. No vacuum tubing, air port, dust passage, or hose\n  connection may be narrowed or blocked by ribs, mounts, bosses, decorative\n  geometry, or slicer support assumptions.\n- For functional openings such as dust hood mouths, plenum intakes, vacuum\n  channels, gasket windows, and hose throats, add deterministic projection or\n  section keepout checks. Prove that reinforcements, sockets, bosses, ribs, and\n  cutters do not intrude into the working opening from any operating angle.\n- For every generated STL, require visual QA from at least 16 angles: right,\n  left, front, back, top, bottom, top-right 45, top-left 45, top-front 45,\n  top-back 45, front-right 45, front-left 45, back-right 45, back-left 45,\n  bottom-right 45, and bottom-left 45. Renders must be nonblank, well-framed,\n  and reviewed for obvious gaps, overlaps, obstructions, unsupported fragile\n  features, and unexpected protrusions.\n- Regenerate from a clean build directory before release, then verify the build\n  directory contains every expected STL plus any PDFs, sections, renders, and\n  acceptance artifacts named by the spec.\n\n---\n\n## Harness detection (run once at skill start, before Phase 0)\n\nDetect your harness by checking available tools before any phase:\n\n1. **Claude Code** — the `Agent` tool with a `subagent_type` parameter is available.\n   - `TIER_A` = `opus` + `ultrathink`  (the alias, which resolves to the current Claude Opus generation)\n   - `TIER_B` = `sonnet`               (the alias, which resolves to the current Claude Sonnet generation)\n\n2. **OpenCode** — a `task` tool with model\u002Ftier configuration is available (no `subagent_type`).\n   - `TIER_A` = top-tier task model + high reasoning\n   - `TIER_B` = smaller-tier task model + medium reasoning\n\n3. **Codex CLI** — neither `Agent` nor a configurable `task` tool is available; `apply_patch` is the primary edit tool.\n   - `TIER_A` = current top GPT model + `reasoning_effort=high`\n   - `TIER_B` = the spark \u002F cost-optimized variant of the configured model when one exists, else the configured model + `reasoning_effort=medium`\n\n**Fallback rule:** If `TIER_B` is not available in your harness (model unknown, quota\u002Fcapacity failure, authorization failure, or tool call returns an error for that model), silently retry the same subagent dispatch with `TIER_A`. Preserve the parent context on retry; for Codex native subagents, fork\u002Finherit the current conversation context and use the latest top GPT model instead of moving the work into the main session. Never ask the user.\n\nHold `TIER_A` and `TIER_B` for the entire skill run. Every \"Tier A\" and \"Tier B\" reference below resolves to these harness-specific values.\n\n## Project configuration preflight\n\nBefore Phase 0, look for `.autospec\u002Fautospec.yml` at the repository root.\n\nIf the file is missing and the current directory is already inside a git repo,\nrun `\u002Fautospec-sweep init` behavior first:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fautospec-sweep-wizard.sh\" init\n```\n\nAccept the wizard defaults unless repo findings require a project-specific\nanswer. The generated `.autospec\u002Fautospec.yml` is tracked project source and\nmust be committed with the next autospec spec\u002Fconfig change. After it exists,\nread it before deciding which autospec phases are enabled.\n\nIf the file is missing because Phase 0 must bootstrap a brand-new repo, create\nit immediately after the initial repo scaffold and before Phase 1. Use all\nsteps enabled by default, strict isolation, `team_personality: auto`, and\ncontinuous improvement enabled for docs, tests, and code.\n\n## Phase 0-3.5 — Delegate to \u002Fautospec-define\n\nThe define half (bootstrap, investigate, design, decompose, classify) is\nowned by `\u002Fautospec-define`. Do NOT run these phases inline in this skill —\nthe full procedure lives in that skill, and re-inlining it here is exactly\nthe duplication this router removes.\n\n> **MUST** read `skills\u002Fautospec-define\u002FSKILL.md` (section \"## Phase 0 — Bootstrap repo\") and invoke `\u002Fautospec-define` (via the `skill` tool) to run Phases 0-3.5.\n\n**Gate override.** `\u002Fautospec-define` ends at its own pre-impl gate, whose\ndefault is `defer`. When the work was entered through `\u002Fautospec` (this\nskill), override that default to **`run`** — the user invoked the umbrella\nend-to-end skill expecting shipping, not plan-only. Pass the override into\n`\u002Fautospec-define` so its gate question highlights `run`.\n\nAfter `\u002Fautospec-define` completes (spec merged, issues filed, gate\nanswered), continue to the Phase 3 portfolio admission gate, then the\nPhase 3 pre-impl gate below.\n\n## Phase 3 portfolio admission gate\n\nPhase 3 decomposes into issues through the typed portfolio transaction when\nthe binary exposes it; when it does not, the documented `gh issue create`\npath applies. When the portfolio path applies, one verified primary Project\nmust exist before any issue is admitted, and the apply transaction is the\nsole provisioning\u002Fmaterialization entry point — there are no separate\npublic record or add commands, and no bare `gh issue create` fallback for\nplanned issues.\n\n**Probe the capability, do not assert it.** Binaries older than the\nportfolio commands (#3432) do not expose `portfolio`; a missing subcommand\nis a degraded capability, not a Phase 3 blocker, and the fallback must stay\nopen while the primary is unavailable:\n\n```bash\nif \"${AUTOSPEC_BIN:-autospec}\" portfolio --help >\u002Fdev\u002Fnull 2>&1; then\n  PORTFOLIO_AVAILABLE=1\nelse\n  PORTFOLIO_AVAILABLE=0\n  printf '%s\\n' 'NOTE: autospec portfolio unavailable; using gh issue create path' >&2\nfi\n```\n\nSteps 1-2 run only when `PORTFOLIO_AVAILABLE=1`. When it is 0, file the\nplanned issues through the `gh issue create` path used for draft issues\n(each starts as `needs-classify`, never `auto-implement`), and the\n`## Delivery portfolio` handoff in step 3 is omitted for that run.\n\n1. **Freeze the plan (pure validation).** Render the planned YAML manifest —\n   source spec, `project_owner`, target repositories, local parent sets,\n   planned children, audit node, and dependency edges — then run the\n   read-only validation before any remote mutation:\n\n   ```bash\n   \"${AUTOSPEC_BIN:-autospec}\" portfolio validate --manifest \"$MANIFEST\"\n   ```\n\n   Validation is pure: manifest lint, safety lint, DAG validation, and\n   per-repository read\u002Fwrite capability probes. A non-zero exit here (the\n   probe passed, so this is a validation failure, not a missing command)\n   blocks Phase 3 — fix the manifest and re-run. A repository that cannot\n   accept issues is a blocking prerequisite, never a silently omitted lane.\n2. **Apply before filing.** The apply transaction then files, in order: the\n   primary umbrella; secondary repository trackers; implementation and\n   prerequisite children; the source-repository audit. Every issue starts as\n   `needs-classify`, never `auto-implement`, and blocked prerequisites keep\n   their blocking label:\n\n   ```bash\n   APPLY_JSON=$(\"${AUTOSPEC_BIN:-autospec}\" portfolio apply --manifest \"$MANIFEST\") || {\n     printf '%s\\n' 'ERROR: primary portfolio provisioning failed; no issue is admitted' >&2\n     exit 1\n   }\n   ```\n3. **JSON handoff.** Parse `APPLY_JSON` with `jq`; hand the verified\n   portfolio ID and canonical Project URL into every child's\n   `## Delivery portfolio` section and into the pre-impl gate below. Pass\n   the plan's `project_owner` through unchanged — never derive or substitute\n   an owner at this step.\n4. **Blocked failure handling.** Any apply failure, parent-record or\n   cross-repository graph persistence failure, or unacknowledged Project\n   projection blocks admission: stop, leave the filed issues unadmitted, and\n   report the exact blocker. Resume with the frozen manifest and its\n   checkpoints; never re-decompose a partially applied plan.\n5. **Final admission ordering.** Only after every body mutation finishes\n   (Phase 3.5 model-fit labels and shared contracts) does final lint and\n   Rust safety admission transition eligible nodes from `needs-classify`\n   to `auto-implement`. The audit stays dependency-blocked until every\n   deliverable is terminal-success.\n\n## Phase 3 pre-impl gate\n\nAfter Phase 3 decomposition completes (and Phase 3.5 review-and-label has\napplied `ctx:*` \u002F `reasoning:*` labels), end Phase 3 by asking the user\nthis verbatim question (no auto-launch — always ask explicitly, per spec\n§3.3):\n\n> `\"Spec written, N issues filed. Start \u002Fautospec-run now, defer to your external daemon, or keep refining? [run \u002F defer \u002F refine]\"`\n\nSubstitute `N` with the actual issue count from Phase 3. Default highlight\nis **`run`** for `\u002Fautospec` (the umbrella end-to-end skill — the user\ninvoked `\u002Fautospec` expecting end-to-end shipping, so the gate defaults\nto `run`).\n\n- **`run`** (default for `\u002Fautospec`) — proceed to Phase 4 by delegating to\n  `\u002Fautospec-run` (the run-half pointer below).\n- **`defer`** — print\n  `\"Issues are ready. Your external monitor will pick them up. Exiting.\"`\n  and stop. For `\u002Fautospec`, this means skipping Phase 4–6 entirely; the\n  just-filed `auto-implement` queue persists on the GitHub side so an\n  external daemon (or a later `\u002Fautospec-run` invocation) can pick it up.\n- **`refine`** — re-enter Phase 2 from question 1 (Architecture).\n\nNo daemon auto-detection — always ask explicitly.\n\nOnce `run` is selected and `\u002Fautospec-run` starts, do not ask operator questions again for this run unless a true hard blocker requires explicit manual recovery.\n\n## Phase 4-6 — Delegate to \u002Fautospec-run\n\nThe run half (implement, monitor, final report) is owned by\n`\u002Fautospec-run`. Do NOT run these phases inline in this skill — the full\nmonitor pseudocode, recovery ladder, and end-of-run flow live in that\nskill, and re-inlining them here is exactly the duplication this router\nremoves.\n\n> **MUST** read `skills\u002Fautospec-run\u002FSKILL.md` (section \"## Phase 4 — Background autonomous monitor\") and invoke `\u002Fautospec-run` (via the `skill` tool) to run Phases 4-6.\n\n`\u002Fautospec-run` handles the background autonomous monitor, periodic status\nupdates, and the Phase 6 final report (including the `.autospec\u002Frun-summary.md`\nharvest contract that `--loop` mode consumes). It ends when the queue is\ndrained (`ALL_DONE`) or the operator stops the run.\n\n---\n\n## Constraints (apply throughout)\n\n- **Cadence**: sub-hour polling needs an in-session background subagent or a local cron. Cloud cron services (e.g. Anthropic remote routines) typically have a 1-hour minimum and are not appropriate.\n- **TDD non-negotiable** per AGENTS.md. Real services in tests, no DB mocks.\n- **Branch-per-issue**, conventional commits, no force-push, no hook bypass.\n- **Auto-merge** on success per AGENTS.md. Do not ask.\n- **Context budget**: stay under 60%. Delegate everything possible.\n- **Failure isolation**: a failed issue restores its `auto-implement` label so the next monitor cycle picks it up; it does not block the cascade unless dependent issues are downstream.\n- **Fresh repo**: if Phase 0 created the repo, the very first commit is the scaffold (incl. `AGENTS.md`); the spec lands as the second commit; child branches branch off that `main`.\n- **Small-LLM target**: child issues are sized and pre-staged for 32B-class local LLMs (e.g. qwen3-32B \u002F Qwen3-30B-A3B on Ollama, 48 GB-class Macs). Bias toward smaller issues, sectional spec anchors, pre-staged file pointers, checkbox AC, and one Primary smoke test.\n\n## Autonomous mode\n\n`\u002Fautospec --autonomous \"\u003Crequest>\"` skips all user-facing confirmation gates\nin this end-to-end pipeline. Spec is generated directly from conversation\ncontext + repo evidence; pre-implementation gate defaults to `run`; issue\ncreation runs without approval.\n\nTriggers (any one enables autonomous mode):\n\n1. **Explicit flag** — `\u002Fautospec --autonomous \"\u003Crequest>\"`.\n2. **Operator preference** — `~\u002F.autospec\u002Fautonomous.flag` exists; every\n   `\u002Fautospec` invocation defaults to autonomous.\n3. **autospec-listen phrase detection** — the deterministic listener-match\n   classifier recognizes \"fix X automatically\", \"no confirmation\",\n   \"just do it\", \"non-interactive\", \"go autonomous\" and routes with\n   `--autonomous`.\n\nGates bypassed in autonomous mode:\n\n- **Phase 2 brainstorm** — clarifying questions skipped. Spec is drafted\n  inline from (a) the user's request text, (b) the last ~10 turns,\n  (c) `git log --since=\"7 days ago\"` for recent change context, and\n  (d) `docs\u002Fspecs\u002F**` for similar prior work.\n- **Phase 3 pre-implementation gate** — defaults to `run`.\n- **Issue body confirmation** — `gh issue create` runs without approval.\n\nAutonomous mode honors `--autonomous` end-to-end so Phase 4–6 telemetry can\ndistinguish autonomous runs from interactive ones.\n\n### Autonomous spec drafting\n\nWhen `--autonomous` is set, do NOT ask the user. Synthesize the spec from\nconversation + repo evidence. For each unverifiable inference, mark the line\nin the spec body with a `> AUTONOMOUS ASSUMPTION:` blockquote so the spec PR\nreview can catch wrong inferences. If a critical field cannot be inferred,\npick the conservative default and note it under an **Autonomous assumptions**\nsection in the spec.\n\nIf the orchestrator cannot generate a coherent spec from available context\n(e.g. the request is too vague — \"make it better\"), autonomous mode FAILS\nLOUDLY with `code_health:autonomous_input_insufficient` rather than silently\npicking arbitrary defaults. The operator gets the specific missing fields\nand a recommended interactive command to retry.\n\n### Safety guardrails (autonomous)\n\n`autospec-autonomy-gate.sh` is called before each \"would-have-asked\"\ndecision point. The following are NEVER bypassed:\n\n1. **Destructive remote actions** — prod DB writes, force-push to protected\n   branches, mass label changes, repo deletion, `gh repo archive`,\n   `gh release delete`, `git push --force` always surface for confirmation.\n   Gate exit 1 = \"ask anyway\".\n2. **Out-of-scope file changes** — if Phase 4 implementer's planned file\n   list extends outside the auto-detected scope (Goal + Implementation\n   outline files), the gate surfaces a confirmation listing the unexpected\n   files.\n3. **Cost gate** — if estimated total tokens exceed\n   `AUTOSPEC_AUTONOMOUS_TOKEN_CAP` (default 500k), surface a\n   one-time go\u002Fno-go even in autonomous mode.\n4. **Existing rules in `feedback_autospec_autonomy_scope.md` remain in\n   force.**\n\nInvoke the gate before each gate-trigger point:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fautospec-autonomy-gate.sh\" \\\n  --check all \\\n  --tokens \"$TOKEN_ESTIMATE\" \\\n  --files \"$PLANNED_FILES\" --scope \"$SCOPE_PREFIXES\" \\\n  --intent \"$USER_REQUEST\"\n```\n\nExit 0 = autonomous OK, proceed. Exit 1 = surface confirmation. Exit 2 =\ninvocation error.\n","# autospec workflow (harness-neutral)\n\nTake the following feature request and ship it through the full pipeline:\n**bootstrap repo (if missing) → investigate → design → spec → decomposed GitHub issues → autonomous implementation with auto-merge → periodic status updates → final report.**\n\nIf the request asks to split, materialize, roadmap, decompose, or turn an\nalready-written spec into GitHub issues, use **Existing spec mode** below:\nselect a tracked `docs\u002Fspecs\u002F*.md` file, skip Phases 1-2, run Phase 3 and\nPhase 3.5 against that spec, then continue to the Phase 3 pre-impl gate.\n\nManage your own context — never exceed 60%. Delegate to subagents whenever your harness supports it; do not investigate, write code, or design directly in the main conversation when a subagent can do it.\n\n\u003C!-- autospec-block:startup-self-update SKILL_NAME=autospec -->\n\n## Self-update mode\n\nDecide this purely from the request text the harness handed you. Do NOT\nshell out (no `grep`, `sed`, `[[ =~ ]]`, command substitution, etc.) to\ntest the user's free-form request — passing it through a shell is what\nhistorically tripped harness permission engines (e.g. parse errors near\nbacktick\u002Fpipe characters in the user's prose). Read the request, normalize\nit in your reasoning (collapse whitespace, trim, lowercase), and if the result is\nexactly `update`, this skill enters self-update mode and does NOT run the\nnormal pipeline.\n\n1. **Detect harness** by checking which install path exists for this skill:\n   - Claude Code: `~\u002F.claude\u002Fskills\u002Fautospec\u002FSKILL.md`\n   - OpenCode:    `~\u002F.config\u002Fopencode\u002Fagent\u002Fautospec.md`\n   - Codex CLI:   `~\u002F.codex\u002Fprompts\u002Fautospec.md`\n2. **Re-install the full autospec suite from `main`** by piping the canonical installer:\n   ```bash\n   curl -fsSL https:\u002F\u002Fraw.githubusercontent.com\u002Fberlinguyinca\u002Fautospec\u002Fmain\u002Fbootstrap.sh | bash -s -- --skill all --harness all --update\n   ```\n   Run this one-liner once; it refreshes all autospec skills across all harnesses.\n3. **Show the diff** between the prior installed file(s) and the freshly fetched copy (e.g. `diff \u003C(cat \u003Cprior>) \u003C(curl -fsSL ...SKILL.md)` or the equivalent recorded by the installer).\n4. **Stop.** Do not enter Phase 0 \u002F Phase 1 \u002F any pipeline phase. Print the upgrade summary and return to the user.\n\nIf no install path is detected, print `Self-update: no installed copy of autospec found; run install.sh first.` and exit.\n\n## Stop mode\n\nApply the same read-and-normalize approach used for self-update mode (do\nNOT shell out the user's request). If the normalized request is exactly\n`stop`, or `stop` followed by one or more `--\u003Cword>` flags (examples:\n`stop`, `stop --graceful`, `stop --immediate`, `stop --status`,\n`stop --resume`, `stop --help`, `stop --flag`), this skill enters stop\nmode and does NOT run the normal pipeline. When dispatching, pass any\n`--\u003Cflag>` tokens the user provided as separate words to the helper.\n\n1. Dispatch to `bash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fautospec-stop.sh\" \u003Cargs>`.\n2. Print the helper's stdout to the user.\n3. Stop. Do not enter Phase 0 or any pipeline phase.\n\n## Feature request\n\n{FEATURE_DESCRIPTION}\n\n---\n\n\n## Continuous loop mode (--loop)\n\nWhen the operator invokes `\u002Fautospec --loop \"\u003Cinitial prompt>\"` (alias\n`--continuous`), this skill runs the full pipeline (Phases 1-6) once, then\nharvests the Phase 6 final report (`.autospec\u002Frun-summary.md` written by\n`autospec-write-run-summary.sh`) and re-iterates until one of six\ntermination conditions trips. The loop is driven by the shared library at\n`lib\u002Fautospec-loop.sh` — the single source of truth shared with\n`\u002Fautospec-refine --continue` and `\u002Fautospec-continue --loop`.\n\nFlags:\n- `--loop` (alias `--continuous`) — enable continuous-iteration mode.\n- `--max-iterations N` — cap the loop at N iterations (default 5, env\n  override `AUTOSPEC_LOOP_MAX_ITERATIONS`).\n- `--skip-refine` — pipe the harvested next-prompt straight into the next\n  \u002Fautospec invocation without first running `\u002Fautospec-refine` on it.\n\nTermination conditions (priority order):\n1. `evidence_based_stop` — the run-summary contains a `STOP: \u003Creason>` marker.\n2. `convergence_clean` — harvest returns empty \u002F `(none — converged)`.\n3. `oscillation_detected` — iteration N+1's harvested prompt hash equals\n   iteration N's (same work proposed twice in a row).\n4. `operator_stop` — `~\u002F.autospec\u002Fstop.flag` or\n   `~\u002F.autospec\u002Frefine-loop-stop.flag` present at iteration boundary.\n5. `budget_cap_reached` — `AUTOSPEC_LOOP_TOKEN_CAP` (default 2M tokens) or\n   `AUTOSPEC_LOOP_TIME_CAP` (default 6h \u002F 21600s) exceeded.\n6. `round_cap_reached` — `--max-iterations` hit without any of the above.\n\nPer-iteration loop:\n1. Run the full \u002Fautospec pipeline (Phase 1-6) on the current prompt.\n2. Read `$REPO_ROOT\u002F.autospec\u002Frun-summary.md` and pass it to\n   `autospec_loop_harvest_next_prompt` from the shared library.\n3. If harvest is empty → `convergence_clean`. If it returns\n   `STOP::\u003Creason>` → `evidence_based_stop`. Otherwise the harvested text\n   becomes the next iteration's prompt.\n4. Unless `--skip-refine` is set, run the harvested prompt through\n   `\u002Fautospec-refine` (4 lenses) before the next \u002Fautospec invocation.\n5. Hash the harvested prompt; oscillation trips when the hash matches\n   the previous iteration's.\n\nOutput artifacts:\n- `.autospec\u002Floop-summary.md` — markdown table with one row per iteration\n  + final status + iterations executed.\n- `\u003Cartifact-dir>\u002F\u003Cslug>-loop.json` — per-iteration JSON record validated\n  against `schemas\u002Fautospec-refinement-loop.schema.json`.\n\nSafety guardrails inherit from the existing autonomy gate\n(`autospec-autonomy-gate.sh`) — destructive remote actions still\nsurface for confirmation per iteration. The rate limit + injection guard\nfrom `autospec-continue.sh` (PR #704) also apply.\n\nDefault behavior (no `--loop`) is unchanged: a single end-to-end pipeline\nrun with no harvest\u002Fre-iteration.\n\n## Existing spec mode\n\nUse this mode when the request asks to split, materialize, roadmap, decompose,\nor turn an existing spec into GitHub issues. Examples:\n`split existing spec`, `split latest spec`, `turn this spec into GitHub issues`,\n`roadmap docs\u002Fspecs\u002F2026-05-01-example-design.md`, or\n`materialize the newest spec`.\n\nDo not run Phase 1 or Phase 2 in this mode. The design already exists; this\nmode is a shortcut into Phase 3 using the same issue decomposition and Phase 3.5\nclassification path as the normal pipeline.\n\n1. **Verify repo.** Run the Phase 0 repo probes. If the current directory is\n   not a git repo with a GitHub remote, use Phase 0 bootstrap before selecting\n   a spec.\n2. **Resolve candidate specs.**\n   - If the request contains an explicit `docs\u002Fspecs\u002F*.md` path, use that file.\n   - Otherwise list tracked and untracked local files matching `docs\u002Fspecs\u002F*.md`.\n   - Sort by ISO date in the filename (`YYYY-MM-DD-...`) descending. For files\n     without a date prefix, sort after dated files by filesystem modified time.\n   - The first item is the default \"newest\" spec.\n3. **Ask on ambiguity.**\n   - If zero specs exist, stop with: `No docs\u002Fspecs\u002F*.md files found. Create or\n     point me at a spec before running existing spec mode.`\n   - If exactly one spec exists and no explicit path was provided, use it.\n   - If more than one spec exists and no explicit path was provided, ask the user\n     to confirm the default newest spec or choose another path. Show at most the\n     five newest candidates with relative paths. Do not file issues until the\n     user answers.\n4. **Verify selected spec is filed.**\n   - The selected path must be under `docs\u002Fspecs\u002F` and end in `.md`.\n   - The selected file must be tracked on `origin\u002Fmain` before Phase 3, so child\n     issues can cite a stable GitHub URL. Verify with:\n     `git fetch origin` and `git cat-file -e origin\u002Fmain:\u003Cspec-path>`.\n   - If the selected file is missing from `origin\u002Fmain`, stop and tell the user:\n     `Selected spec is not on origin\u002Fmain yet: \u003Cspec-path>. Land the spec first,\n     or run normal \u002Fautospec so Phase 2 can create and merge the spec PR.`\n5. **Continue at Phase 3.** Capture `{selected_spec_path}` and its GitHub URL as\n   `https:\u002F\u002Fgithub.com\u002F{repo}\u002Fblob\u002Fmain\u002F{selected_spec_path}`. Run Phase 3 and\n   Phase 3.5 using that selected spec. Then proceed to the existing Phase 3\n   pre-impl gate.\n\n\u003C!-- autospec-block:harness-adapter -->\n\n### Managed Project registration after Phase 0 bootstrap\n\nWhen Phase 0 creates a GitHub repository, register it only after the required\nremote read-back succeeds. Set `REPO` to the exact `owner\u002Fname` slug and set\n`SPAWNED_FROM` to the source-spec URL when one already exists, otherwise to the\ncurrent Autospec run identity (or `bootstrap:\u003Cowner\u002Fname>` when neither exists):\n\n```bash\ngh repo view \u003Cowner>\u002F\u003Cname> --json url,defaultBranchRef\nREPO=\"\u003Cowner>\u002F\u003Cname>\"\nSPAWNED_FROM=\"${SOURCE_SPEC_URL:-${AUTOSPEC_RUN_ID:-bootstrap:$REPO}}\"\nREGISTRATION_JSON=$(\"${AUTOSPEC_BIN:-autospec}\" project onboard --repo-dir \"$PWD\" --repo \"$REPO\" --spawned-from \"$SPAWNED_FROM\") || {\n  printf '%s\\n' 'ERROR: managed Project repository registration failed before durable admission' >&2\n  exit 1\n}\ncase \"$(printf '%s' \"$REGISTRATION_JSON\" | jq -r '.outcome \u002F\u002F empty')\" in\n  reconciled) ;;\n  journaled_projection_pending)\n    printf '%s\\n' 'WARNING: managed Project repository projection is durably journaled and pending' >&2 ;;\n  *) printf '%s\\n' 'ERROR: managed Project repository registration returned no supported typed outcome' >&2; exit 1 ;;\nesac\n```\n\nNever run registration when remote verification fails. A typed pending outcome\ndoes not roll back, delete, or recreate the verified repository; the managed\nProject journal retains the pending projection for a later `project sync`.\nPropagate every hard registration failure.\n\n## Physical STL \u002F CAD design guardrails\n\nWhen the request involves STL, CAD, 3D-printable fixtures, workholding,\nvacuum, pneumatic, hydraulic, dust-collection, hose, fitting, gasket, or\nother physical models, carry these requirements into Phase 2 specs, Phase 3\nchild issues, and Phase 4 verification:\n\n- Treat physical function as acceptance criteria, not visual intent. Verify\n  mountability, tool access, fitting clearance, gasket compression, storage fit,\n  printer build volume, and expected operating orientation.\n- Do not allow blocked ports, obstructed hoses\u002Ftubes, capped passages, hidden\n  dead-end channels, or geometry that interferes with the model's purpose.\n- Around every port, fitting, connector, tap bore, hose socket, screw head, and\n  service tool path, require at least 5 mm of free working clearance in every\n  direction unless the user explicitly specifies a tighter envelope.\n- Around every gasket path, require at least 5 mm of continuous plastic margin\n  outside the gasket. Gasket grooves must not expose an edge or be crossed by\n  mounts, screws, ribs, channels, holders, or workpiece contact geometry.\n- For NPT or other tapped ports, prove the tap and installed fitting can enter\n  straight or along the specified angled axis without collisions. Ports and\n  fitting bosses must be integrated into reinforced body geometry, not left as\n  fragile stand-alone protrusions.\n- For low-flow vacuum systems, do not add relief valves, vents, restriction\n  orifices, small balancing holes, or intentional leaks unless the user\n  explicitly asks for them and the spec records why the pump can tolerate them.\n- For sealed or flowing parts, require gas\u002Ffluid\u002Fvacuum\u002Fdust-flow simulation or\n  deterministic geometry checks that prove no leaks, no disconnected internal\n  circuits, no blocked passages, and adequate inlet-to-outlet connectivity.\n- For dust collection, preserve maximum practical duct cross-section and\n  suction path continuity. No vacuum tubing, air port, dust passage, or hose\n  connection may be narrowed or blocked by ribs, mounts, bosses, decorative\n  geometry, or slicer support assumptions.\n- For functional openings such as dust hood mouths, plenum intakes, vacuum\n  channels, gasket windows, and hose throats, add deterministic projection or\n  section keepout checks. Prove that reinforcements, sockets, bosses, ribs, and\n  cutters do not intrude into the working opening from any operating angle.\n- For every generated STL, require visual QA from at least 16 angles: right,\n  left, front, back, top, bottom, top-right 45, top-left 45, top-front 45,\n  top-back 45, front-right 45, front-left 45, back-right 45, back-left 45,\n  bottom-right 45, and bottom-left 45. Renders must be nonblank, well-framed,\n  and reviewed for obvious gaps, overlaps, obstructions, unsupported fragile\n  features, and unexpected protrusions.\n- Regenerate from a clean build directory before release, then verify the build\n  directory contains every expected STL plus any PDFs, sections, renders, and\n  acceptance artifacts named by the spec.\n\n---\n\n## Harness detection (run once at skill start, before Phase 0)\n\nDetect your harness by checking available tools before any phase:\n\n1. **Claude Code** — the `Agent` tool with a `subagent_type` parameter is available.\n   - `TIER_A` = `opus` + `ultrathink`  (the alias, which resolves to the current Claude Opus generation)\n   - `TIER_B` = `sonnet`               (the alias, which resolves to the current Claude Sonnet generation)\n\n2. **OpenCode** — a `task` tool with model\u002Ftier configuration is available (no `subagent_type`).\n   - `TIER_A` = top-tier task model + high reasoning\n   - `TIER_B` = smaller-tier task model + medium reasoning\n\n3. **Codex CLI** — neither `Agent` nor a configurable `task` tool is available; `apply_patch` is the primary edit tool.\n   - `TIER_A` = current top GPT model + `reasoning_effort=high`\n   - `TIER_B` = the spark \u002F cost-optimized variant of the configured model when one exists, else the configured model + `reasoning_effort=medium`\n\n**Fallback rule:** If `TIER_B` is not available in your harness (model unknown, quota\u002Fcapacity failure, authorization failure, or tool call returns an error for that model), silently retry the same subagent dispatch with `TIER_A`. Preserve the parent context on retry; for Codex native subagents, fork\u002Finherit the current conversation context and use the latest top GPT model instead of moving the work into the main session. Never ask the user.\n\nHold `TIER_A` and `TIER_B` for the entire skill run. Every \"Tier A\" and \"Tier B\" reference below resolves to these harness-specific values.\n\n## Project configuration preflight\n\nBefore Phase 0, look for `.autospec\u002Fautospec.yml` at the repository root.\n\nIf the file is missing and the current directory is already inside a git repo,\nrun `\u002Fautospec-sweep init` behavior first:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fautospec-sweep-wizard.sh\" init\n```\n\nAccept the wizard defaults unless repo findings require a project-specific\nanswer. The generated `.autospec\u002Fautospec.yml` is tracked project source and\nmust be committed with the next autospec spec\u002Fconfig change. After it exists,\nread it before deciding which autospec phases are enabled.\n\nIf the file is missing because Phase 0 must bootstrap a brand-new repo, create\nit immediately after the initial repo scaffold and before Phase 1. Use all\nsteps enabled by default, strict isolation, `team_personality: auto`, and\ncontinuous improvement enabled for docs, tests, and code.\n\n## Phase 0-3.5 — Delegate to \u002Fautospec-define\n\nThe define half (bootstrap, investigate, design, decompose, classify) is\nowned by `\u002Fautospec-define`. Do NOT run these phases inline in this skill —\nthe full procedure lives in that skill, and re-inlining it here is exactly\nthe duplication this router removes.\n\n> **MUST** read `skills\u002Fautospec-define\u002FSKILL.md` (section \"## Phase 0 — Bootstrap repo\") and invoke `\u002Fautospec-define` (via the `skill` tool) to run Phases 0-3.5.\n\n**Gate override.** `\u002Fautospec-define` ends at its own pre-impl gate, whose\ndefault is `defer`. When the work was entered through `\u002Fautospec` (this\nskill), override that default to **`run`** — the user invoked the umbrella\nend-to-end skill expecting shipping, not plan-only. Pass the override into\n`\u002Fautospec-define` so its gate question highlights `run`.\n\nAfter `\u002Fautospec-define` completes (spec merged, issues filed, gate\nanswered), continue to the Phase 3 portfolio admission gate, then the\nPhase 3 pre-impl gate below.\n\n## Phase 3 portfolio admission gate\n\nPhase 3 decomposes into issues through the typed portfolio transaction when\nthe binary exposes it; when it does not, the documented `gh issue create`\npath applies. When the portfolio path applies, one verified primary Project\nmust exist before any issue is admitted, and the apply transaction is the\nsole provisioning\u002Fmaterialization entry point — there are no separate\npublic record or add commands, and no bare `gh issue create` fallback for\nplanned issues.\n\n**Probe the capability, do not assert it.** Binaries older than the\nportfolio commands (#3432) do not expose `portfolio`; a missing subcommand\nis a degraded capability, not a Phase 3 blocker, and the fallback must stay\nopen while the primary is unavailable:\n\n```bash\nif \"${AUTOSPEC_BIN:-autospec}\" portfolio --help >\u002Fdev\u002Fnull 2>&1; then\n  PORTFOLIO_AVAILABLE=1\nelse\n  PORTFOLIO_AVAILABLE=0\n  printf '%s\\n' 'NOTE: autospec portfolio unavailable; using gh issue create path' >&2\nfi\n```\n\nSteps 1-2 run only when `PORTFOLIO_AVAILABLE=1`. When it is 0, file the\nplanned issues through the `gh issue create` path used for draft issues\n(each starts as `needs-classify`, never `auto-implement`), and the\n`## Delivery portfolio` handoff in step 3 is omitted for that run.\n\n1. **Freeze the plan (pure validation).** Render the planned YAML manifest —\n   source spec, `project_owner`, target repositories, local parent sets,\n   planned children, audit node, and dependency edges — then run the\n   read-only validation before any remote mutation:\n\n   ```bash\n   \"${AUTOSPEC_BIN:-autospec}\" portfolio validate --manifest \"$MANIFEST\"\n   ```\n\n   Validation is pure: manifest lint, safety lint, DAG validation, and\n   per-repository read\u002Fwrite capability probes. A non-zero exit here (the\n   probe passed, so this is a validation failure, not a missing command)\n   blocks Phase 3 — fix the manifest and re-run. A repository that cannot\n   accept issues is a blocking prerequisite, never a silently omitted lane.\n2. **Apply before filing.** The apply transaction then files, in order: the\n   primary umbrella; secondary repository trackers; implementation and\n   prerequisite children; the source-repository audit. Every issue starts as\n   `needs-classify`, never `auto-implement`, and blocked prerequisites keep\n   their blocking label:\n\n   ```bash\n   APPLY_JSON=$(\"${AUTOSPEC_BIN:-autospec}\" portfolio apply --manifest \"$MANIFEST\") || {\n     printf '%s\\n' 'ERROR: primary portfolio provisioning failed; no issue is admitted' >&2\n     exit 1\n   }\n   ```\n3. **JSON handoff.** Parse `APPLY_JSON` with `jq`; hand the verified\n   portfolio ID and canonical Project URL into every child's\n   `## Delivery portfolio` section and into the pre-impl gate below. Pass\n   the plan's `project_owner` through unchanged — never derive or substitute\n   an owner at this step.\n4. **Blocked failure handling.** Any apply failure, parent-record or\n   cross-repository graph persistence failure, or unacknowledged Project\n   projection blocks admission: stop, leave the filed issues unadmitted, and\n   report the exact blocker. Resume with the frozen manifest and its\n   checkpoints; never re-decompose a partially applied plan.\n5. **Final admission ordering.** Only after every body mutation finishes\n   (Phase 3.5 model-fit labels and shared contracts) does final lint and\n   Rust safety admission transition eligible nodes from `needs-classify`\n   to `auto-implement`. The audit stays dependency-blocked until every\n   deliverable is terminal-success.\n\n## Phase 3 pre-impl gate\n\nAfter Phase 3 decomposition completes (and Phase 3.5 review-and-label has\napplied `ctx:*` \u002F `reasoning:*` labels), end Phase 3 by asking the user\nthis verbatim question (no auto-launch — always ask explicitly, per spec\n§3.3):\n\n> `\"Spec written, N issues filed. Start \u002Fautospec-run now, defer to your external daemon, or keep refining? [run \u002F defer \u002F refine]\"`\n\nSubstitute `N` with the actual issue count from Phase 3. Default highlight\nis **`run`** for `\u002Fautospec` (the umbrella end-to-end skill — the user\ninvoked `\u002Fautospec` expecting end-to-end shipping, so the gate defaults\nto `run`).\n\n- **`run`** (default for `\u002Fautospec`) — proceed to Phase 4 by delegating to\n  `\u002Fautospec-run` (the run-half pointer below).\n- **`defer`** — print\n  `\"Issues are ready. Your external monitor will pick them up. Exiting.\"`\n  and stop. For `\u002Fautospec`, this means skipping Phase 4–6 entirely; the\n  just-filed `auto-implement` queue persists on the GitHub side so an\n  external daemon (or a later `\u002Fautospec-run` invocation) can pick it up.\n- **`refine`** — re-enter Phase 2 from question 1 (Architecture).\n\nNo daemon auto-detection — always ask explicitly.\n\nOnce `run` is selected and `\u002Fautospec-run` starts, do not ask operator questions again for this run unless a true hard blocker requires explicit manual recovery.\n\n## Phase 4-6 — Delegate to \u002Fautospec-run\n\nThe run half (implement, monitor, final report) is owned by\n`\u002Fautospec-run`. Do NOT run these phases inline in this skill — the full\nmonitor pseudocode, recovery ladder, and end-of-run flow live in that\nskill, and re-inlining them here is exactly the duplication this router\nremoves.\n\n> **MUST** read `skills\u002Fautospec-run\u002FSKILL.md` (section \"## Phase 4 — Background autonomous monitor\") and invoke `\u002Fautospec-run` (via the `skill` tool) to run Phases 4-6.\n\n`\u002Fautospec-run` handles the background autonomous monitor, periodic status\nupdates, and the Phase 6 final report (including the `.autospec\u002Frun-summary.md`\nharvest contract that `--loop` mode consumes). It ends when the queue is\ndrained (`ALL_DONE`) or the operator stops the run.\n\n---\n\n## Constraints (apply throughout)\n\n- **Cadence**: sub-hour polling needs an in-session background subagent or a local cron. Cloud cron services (e.g. Anthropic remote routines) typically have a 1-hour minimum and are not appropriate.\n- **TDD non-negotiable** per AGENTS.md. Real services in tests, no DB mocks.\n- **Branch-per-issue**, conventional commits, no force-push, no hook bypass.\n- **Auto-merge** on success per AGENTS.md. Do not ask.\n- **Context budget**: stay under 60%. Delegate everything possible.\n- **Failure isolation**: a failed issue restores its `auto-implement` label so the next monitor cycle picks it up; it does not block the cascade unless dependent issues are downstream.\n- **Fresh repo**: if Phase 0 created the repo, the very first commit is the scaffold (incl. `AGENTS.md`); the spec lands as the second commit; child branches branch off that `main`.\n- **Small-LLM target**: child issues are sized and pre-staged for 32B-class local LLMs (e.g. qwen3-32B \u002F Qwen3-30B-A3B on Ollama, 48 GB-class Macs). Bias toward smaller issues, sectional spec anchors, pre-staged file pointers, checkbox AC, and one Primary smoke test.\n\n## Autonomous mode\n\n`\u002Fautospec --autonomous \"\u003Crequest>\"` skips all user-facing confirmation gates\nin this end-to-end pipeline. Spec is generated directly from conversation\ncontext + repo evidence; pre-implementation gate defaults to `run`; issue\ncreation runs without approval.\n\nTriggers (any one enables autonomous mode):\n\n1. **Explicit flag** — `\u002Fautospec --autonomous \"\u003Crequest>\"`.\n2. **Operator preference** — `~\u002F.autospec\u002Fautonomous.flag` exists; every\n   `\u002Fautospec` invocation defaults to autonomous.\n3. **autospec-listen phrase detection** — the deterministic listener-match\n   classifier recognizes \"fix X automatically\", \"no confirmation\",\n   \"just do it\", \"non-interactive\", \"go autonomous\" and routes with\n   `--autonomous`.\n\nGates bypassed in autonomous mode:\n\n- **Phase 2 brainstorm** — clarifying questions skipped. Spec is drafted\n  inline from (a) the user's request text, (b) the last ~10 turns,\n  (c) `git log --since=\"7 days ago\"` for recent change context, and\n  (d) `docs\u002Fspecs\u002F**` for similar prior work.\n- **Phase 3 pre-implementation gate** — defaults to `run`.\n- **Issue body confirmation** — `gh issue create` runs without approval.\n\nAutonomous mode honors `--autonomous` end-to-end so Phase 4–6 telemetry can\ndistinguish autonomous runs from interactive ones.\n\n### Autonomous spec drafting\n\nWhen `--autonomous` is set, do NOT ask the user. Synthesize the spec from\nconversation + repo evidence. For each unverifiable inference, mark the line\nin the spec body with a `> AUTONOMOUS ASSUMPTION:` blockquote so the spec PR\nreview can catch wrong inferences. If a critical field cannot be inferred,\npick the conservative default and note it under an **Autonomous assumptions**\nsection in the spec.\n\nIf the orchestrator cannot generate a coherent spec from available context\n(e.g. the request is too vague — \"make it better\"), autonomous mode FAILS\nLOUDLY with `code_health:autonomous_input_insufficient` rather than silently\npicking arbitrary defaults. The operator gets the specific missing fields\nand a recommended interactive command to retry.\n\n### Safety guardrails (autonomous)\n\n`autospec-autonomy-gate.sh` is called before each \"would-have-asked\"\ndecision point. The following are NEVER bypassed:\n\n1. **Destructive remote actions** — prod DB writes, force-push to protected\n   branches, mass label changes, repo deletion, `gh repo archive`,\n   `gh release delete`, `git push --force` always surface for confirmation.\n   Gate exit 1 = \"ask anyway\".\n2. **Out-of-scope file changes** — if Phase 4 implementer's planned file\n   list extends outside the auto-detected scope (Goal + Implementation\n   outline files), the gate surfaces a confirmation listing the unexpected\n   files.\n3. **Cost gate** — if estimated total tokens exceed\n   `AUTOSPEC_AUTONOMOUS_TOKEN_CAP` (default 500k), surface a\n   one-time go\u002Fno-go even in autonomous mode.\n4. **Existing rules in `feedback_autospec_autonomy_scope.md` remain in\n   force.**\n\nInvoke the gate before each gate-trigger point:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fautospec-autonomy-gate.sh\" \\\n  --check all \\\n  --tokens \"$TOKEN_ESTIMATE\" \\\n  --files \"$PLANNED_FILES\" --scope \"$SCOPE_PREFIXES\" \\\n  --intent \"$USER_REQUEST\"\n```\n\nExit 0 = autonomous OK, proceed. Exit 1 = surface confirmation. Exit 2 =\ninvocation error.\n",{"name":5,"description":7},"main","9e7f04357ff46ab731d4f56a4ac5ca5449c13bb0","skills\u002Fautospec",1,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec","https:\u002F\u002Fgithub.com\u002Fberlinguyinca","Love to lead, code, cook and contribute to open source and believe that you can learn anything you set your mind too.\r\n","2026-11-11 07:09:35",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add berlinguyinca\u002Fautospec --skill autospec",{"tool":62,"command":63},"bunx","bunx skills add berlinguyinca\u002Fautospec --skill autospec",{"tool":65,"command":66},"pnpm","pnpm dlx skills add berlinguyinca\u002Fautospec --skill autospec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002FSKILL.md",true,[70,76,80,86,90,94,98],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"agents\u002Fopenai.yaml","REFERENCE","参考文档",695,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002Fagents\u002Fopenai.yaml",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"codex\u002Fprompt.md",26498,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002Fcodex\u002Fprompt.md",{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"install.sh","SCRIPT","脚本",12538,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002Finstall.sh",{"path":87,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":88,"sourceHtmlUrl":89},"opencode\u002Fagent.md",26808,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002Fopencode\u002Fagent.md",{"path":91,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":92,"sourceHtmlUrl":93},"README.md",15633,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002FREADME.md",{"path":95,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fmonitor-recovery.md",13922,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002Freferences\u002Fmonitor-recovery.md",{"path":99,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":100,"sourceHtmlUrl":101},"uninstall.sh",3933,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002Funinstall.sh",[103,114,123,132,156,183],{"skillNo":104,"name":105,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":111,"publishedAt":43},"01M71RJHYMKPTC9AAPXWQ6F4RT","trio-pass-skill","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Flockstep-trio-pass\u002FSKILL.md",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[112,113],"trio","trio pass skill",{"skillNo":115,"name":116,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":43},"01M71RJFBQ1KAF9XM3T3Y4VMSK","duo-pass-skill","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Flockstep-duo-pass\u002FSKILL.md",[119],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[121,122],"duo pass skill","duo",{"skillNo":124,"name":125,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":43},"01M71RJDT1TB3P9TRWR6A534FB","duo-divergence-skill","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Flockstep-duo-divergence\u002FSKILL.md",[128],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[130,122,131],"duo divergence skill","divergence",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":43},"01M71RJ4F9HT8PT26CKNM9XE1M","autospec-upgrade","Use when the user wants to upgrade an Angular, Next.js, or React project to the latest official versions safely — by locking observable behavior before touching versions, upgrading one major at a time with official codemods, and gating completion on mutation score rather than coverage theater.","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-upgrade\u002FSKILL.md",[],[139,5,140,141,142,143,144,145,146,35,147,148,149,150,25,151,152,153,154,155],"autospec upgrade","upgrade","coverage","official","project","time","mutation","gating","angular","react","next","at","Next.js","one","with","behavior","latest",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":167,"publishedAt":43},"01M71RJ28FJ4PM6DXHB7T5CF8H","autospec-ui-audit","Use when a React Router application needs a deterministic whole-site route inventory before UI, UX, navigation, or evidence auditing begins.","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-ui-audit\u002FSKILL.md",[162],{"categoryNo":163,"categoryName":164,"taxonomyType":165,"taxonomyTypeDesc":166},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[168,169,170,171,5,35,172,173,174,25,175,148,176,177,178,179,180,181,182],"ui","autospec ui audit","audit","ui audit","deterministic","evidence","inventory","needs","router","route","ux","site","react router","navigation","application",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":196,"publishedAt":43},"01M71RHV8DR6K242WDMB9HZ8WW","autospec-test","Use when you want to gate every Phase 4 PR on unit + E2E test coverage against an isolated environment, auto-heal coverage gaps within a 60-minute coding budget, and block assertion-loosening rewrites before auto-merge.","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-test\u002FSKILL.md",[189,192,193],{"categoryNo":190,"categoryName":191,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":194,"categoryName":195,"taxonomyType":165,"taxonomyTypeDesc":166},"01JBSEEDCAT000000000000037","律师与法务",[197,5,198,199,35,37,200,201,141,25,202,203,204,205,206,207,208,209,33,210],"test","autospec test","you","e2e test","unit","coverage gaps","gaps","environment","pr","coding","Budget","test coverage","e2e","phase"]