[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71RGMTD8A9D8ZBXP17Y48GE":3,"skill-same:01M71RGMTD8A9D8ZBXP17Y48GE":113},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M71RGMTD8A9D8ZBXP17Y48GE","autospec-release",null,"Use when a repo needs an end-to-end release readiness sweep across specs, docs, implementation, tests, QA proof artifacts, legacy cleanup, and merge readiness using existing autospec skills.","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-release\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"autospec","release","autospec release","implementation","merge","release readiness","readiness","sweep","across","needs","artifacts","when","Legacy","Existing","use","cleanup","qa","tests","end","repo","2026-11-10 13:02:02",false,"---\nname: autospec-release\ndescription: Use when a repo needs an end-to-end release readiness sweep across specs, docs, implementation, tests, QA proof artifacts, legacy cleanup, and merge readiness using existing autospec skills.\n---\n\n# autospec-release workflow\n\nRun the repo-level release readiness loop. This is the \"I want to ship the\ncurrent repo\" wrapper over the existing autospec surfaces: sweep, review, run,\ntest, QA, proof validation, documentation drift checks, and legacy-code cleanup.\n\nUse this when the operator wants one explicit release gate instead of invoking\neach lower-level skill by hand.\n\n\u003C!-- autospec-block:startup-self-update SKILL_NAME=autospec-release -->\n\n## Self-update mode\n\nIf the feature-request argument matches `update` after trimming and lowercasing,\nre-install the full autospec suite from `main`, show the before\u002Fafter diff if the\nharness exposes it, then stop. Do not run the release gate.\n\n## Required capabilities & harness adapter\n\n| Capability | Claude Code | OpenCode | Codex CLI | Fallback if missing |\n| --- | --- | --- | --- | --- |\n| Subagent model tier | Tier A: `opus` + ultrathink | Tier A: top-tier `task` + max reasoning | Tier A: current top GPT + `reasoning_effort=high` | Run inline, but keep the same PASS\u002FPARTIAL\u002FFAIL contract |\n\u003C!-- autospec-block:harness-adapter-core -->\n| Existing autospec skills | Slash skills | agent prompts | skills\u002Fprompts | Run the matching workflow instructions inline |\n| GitHub operations | `gh` through shell | shell | shell | Mark merge\u002Fissue steps BLOCKED with exact command |\n| Test and QA execution | Browser\u002FE2E or shell | browser\u002Ftask or shell | shell\u002Fbrowser when available | Mark app-only checks NOT TESTED with blocker |\n\n**Model tier:** TIER_A for release synthesis and final readiness verdicts\nbecause a false PASS can ship broken behavior.\n\n## Harness detection\n\nDetect the harness once at skill start:\n\n1. Claude Code: `Agent` with `subagent_type` is available.\n   - `TIER_A` = `opus` + ultrathink.\n   - `TIER_B` = `sonnet`.\n2. OpenCode: `task` tool is available.\n   - `TIER_A` = top-tier task model + high reasoning.\n   - `TIER_B` = smaller-tier task model + medium reasoning.\n3. Codex CLI: `apply_patch` is the primary edit tool.\n   - `TIER_A` = current top GPT + `reasoning_effort=high`.\n   - `TIER_B` = current cost-optimized Codex model + `reasoning_effort=medium`.\n\nPrefer a Tier A reviewer\u002Fverifier subagent for the final release verdict when\nthe harness supports it. If `TIER_A` is unavailable, silently fall back to the\nnext available top-tier model. If delegation is unavailable, run the verdict\ninline.\n\n## Area dispatch (parallel subagents)\n\n`\u002Fautospec-release` parallelizes Stages 3-8 across 6 area subagents instead\nof walking them sequentially in the orchestrator (issue #731). The\ncanonical orchestrator script is `release-area-dispatch.sh`, which:\n\n1. Reads area definitions from `skills\u002Fautospec-release\u002Fareas\u002F\u003Cname>.md`.\n2. Dispatches all 6 area subagents in parallel via the harness-aware\n   dispatcher (`lib\u002Fautospec-harness-detect.sh`, PR #725).\n3. Aggregates per-area findings into `.autospec\u002Frelease-verdict.json`\n   honoring the schema consumed by `compute-release-verdict.sh`\n   (PR #636).\n4. Optionally re-probes stale findings via the qa-finding-filter\n   (`qa-finding-filter.sh`, PR #650) when\n   `AUTOSPEC_RELEASE_VERIFY_FIRST=1`.\n\nThe 6 areas:\n\n| Area | Stage | Description |\n| --- | --- | --- |\n| `spec-completeness` | 3 | Specs match live code; no stale\u002Fsuperseded blockers. |\n| `docs-freshness` | 3 | README\u002FAGENTS\u002FUSER_MANUAL describe current behavior. |\n| `implementation-completeness` | 5 | Every acceptance criterion has live code. |\n| `test-coverage` | 6 | Release-gate suites green; mutation + density floors met. |\n| `qa-artifact-integrity` | 7 | proof-matrix + control-ledger + mutation-proof + canary-results fresh + schema-valid. |\n| `legacy-cleanup` | 8 | No dead routes\u002Fcaches\u002Fconfigs masquerading as current. |\n\nEach area subagent receives a tight prompt bounded to 50-120k context and\n25 tool calls. Findings carry `verified_at: \u003Chead_sha>` since each\nsubagent is its own verifier; the orchestrator merges them and surfaces\n`live_app_proof` from `qa-artifact-integrity` so\n`compute-release-verdict.sh` continues to consume the merged verdict\nunchanged.\n\n**Model tier:** Tier A (spec work) for `spec-completeness`,\n`implementation-completeness`, and `legacy-cleanup`; Tier B\n(implementation work) for `docs-freshness`, `test-coverage`, and\n`qa-artifact-integrity`.\n\nInvoke the orchestrator directly:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Frelease-area-dispatch.sh\"\n```\n\nOr, when iterating on a single area:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Frelease-area-dispatch.sh\" --area spec-completeness\n```\n\n## When to use\n\n- The repo has existing specs, issues, code, and docs, and the operator asks\n  \"can we release this?\"\n- A project needs QA, review, testing, documentation drift checks, and legacy\n  cleanup in one coordinated pass.\n- Lower-level autospec skills have been run piecemeal and the operator wants a\n  single release-readiness answer.\n- The team wants a repeatable gate before tagging, deployment, or handoff.\n\n## When not to use\n\n- Do not use this as the first step for a brand-new feature idea. Use\n  `\u002Fautospec` or `\u002Fautospec-define`.\n- Do not use it as a replacement for `\u002Fautospec-stop` while a monitor is active.\n- Do not mark release PASS with mocked tests only when a no-mock smoke path is\n  required by the repo contract.\n- Do not paper over legacy code by leaving stale spec\u002Fdocs references behind.\n\n## Release pipeline\n\nRun these stages in order. If a lower-level skill is installed and invocable,\ncall that skill. If not, follow its documented workflow inline and report that\nthe explicit skill invocation was unavailable.\n\n1. Preflight\n   - Record branch, dirty files, remotes, GitHub repo, open PRs, open\n     `auto-implement` and `needs-classify` issues, and installed autospec skill\n     versions if visible.\n   - Do not revert user work. If dirty files exist, treat them as current repo\n     reality and avoid overwriting them.\n\n2. Sweep\n   - Run `\u002Fautospec-sweep` or the equivalent sweep workflow.\n   - Ensure `.autospec\u002Fautospec.yml` and the latest sweep report exist when the\n     repo is configured for sweeps.\n   - Turn recurring drift into concrete spec, issue, test, or docs work.\n\n3. Spec, docs, and story sync\n   - Compare `docs\u002Fspecs\u002F**`, README docs, user-facing docs, config docs, and\n     implementation reality.\n   - Remove stale claims for legacy code, legacy storage, deprecated APIs,\n     removed flags, dead routes, and old workflows.\n   - If behavior still exists only for compatibility, document that explicitly\n     as compatibility, not as the preferred path.\n\n4. Review\n   - Run `\u002Fautospec-review`.\n   - File or surface high-priority regression issues for spec-vs-code gaps.\n   - Do not proceed to PASS while untriaged release-blocking review findings\n     remain.\n\n5. Implementation queue\n   - Run `\u002Fautospec-classify` if `needs-classify` issues exist.\n   - Run `\u002Fautospec-run` until there are no ready release-blocking\n     `auto-implement` issues, or until a blocker is documented with the exact\n     issue number and command to resume.\n\n6. Test gate\n   - Run `\u002Fautospec-test` where available.\n   - Require lint, typecheck, unit, integration, smoke, E2E, and static checks\n     that the target repo defines as release gates.\n   - Failed tests are work, not report decoration: fix them or create a\n     release-blocking issue with exact reproduction.\n\n7. QA proof (MANDATORY — required for PASS)\n   - Run `\u002Fautospec-qa` against a live booted app. Either:\n     (a) boot the app locally (dev or prod build) and exercise it, or\n     (b) point QA at an already-deployed environment whose commit SHA matches\n         HEAD (or is explicitly recorded as the SHA under test).\n   - Mocked unit\u002Fintegration tests do NOT satisfy this gate. Stage 7 must\n     produce browser- or app-level interaction artifacts (screenshots, DOM\n     snapshots, network traces, or recorded sessions) covering the user-\n     facing surfaces in the release range.\n   - Require control-level proof for text boxes, selects, dropdowns, buttons,\n     validation, API effects, failure banners, fallback behavior, accessibility,\n     and no-mock smoke paths where the repo contract requires them.\n   - Validate QA artifacts with\n     `skills\u002Fautospec-shared\u002Fscripts\u002Fvalidate-qa-artifacts.sh` when available.\n   - Do not skip silently. If the app cannot be booted or reached, record the\n     reason, mark Stage 7 as `NOT EXECUTED`, and apply the Stage 9 verdict cap.\n   - After `\u002Fautospec-qa` completes, confirm `.autospec\u002Fqa-verdict.json`\n     exists with `head_sha` matching current HEAD and `live_app_proof: true`.\n     If absent, stale, or `live_app_proof: false`, the QA gate has not been\n     satisfied for this commit — treat as `NOT EXECUTED` for Stage 9.\n\n8. Legacy cleanup gate\n   - Search code, specs, docs, tests, fixtures, config, infra, and examples for\n     removed or deprecated behavior.\n   - Delete dead code when tests prove it is unreachable.\n   - Remove stale spec\u002Fdocs references in the same change that removes the code.\n   - If a legacy path cannot be removed yet, create a deprecation issue that\n     names the owner, replacement path, and removal trigger.\n\n8a. Repo quality audit\n   - Run the shared read-only audit before computing the release verdict:\n     ```bash\n     bash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Frepo-quality-audit.sh\" \\\n       --repo . \\\n       --json \".autospec\u002Frepo-quality-audit.json\" \\\n       --markdown \".autospec\u002Frepo-quality-audit.md\" \\\n       ${AUTOSPEC_QUALITY_AUDIT_FILE_ISSUES:+--file-issues}\n     ```\n   - Include audit status, filed issue links, suppressed findings, and unfiled\n     residual risks in the release report.\n   - Release PASS is blocked by unresolved `current-branch-regression` security\n     or verification findings unless they are explicitly classified as inherited\n     accepted debt in `.autospec\u002Fquality-audit-accepted.json`.\n\n9. Verdict computation and release iteration loop\n\n   The deterministic computation is implemented by\n   `compute-release-verdict.sh` and is the canonical source of truth.\n   Invoke it with the current verdict path; stdout is one of `PASS` \u002F\n   `PARTIAL` \u002F `FAIL` and the exit code mirrors that (0\u002F1\u002F2; 3 for\n   infrastructure errors). The prose rules below describe what that script\n   does — if they diverge from the script's actual behavior, fix the script\n   and the bats tests in `tests\u002Fcompute-release-verdict.bats`, not the\n   prose. Never re-derive the verdict by hand when the script is available.\n\n   Compute the verdict deterministically from `.autospec\u002Fqa-verdict.json`:\n\n   - If the file is missing → verdict is `FAIL` with a synthetic finding\n     \"qa-verdict.json not produced by Stage 7\".\n   - If `head_sha` does not match `git rev-parse HEAD` → treat as missing.\n     Synthesize a FAIL finding \"QA verdict stale relative to HEAD\" and\n     require Stage 7 to re-run in the same iteration before recomputing\n     the verdict.\n   - If `live_app_proof: false` → cap at `PARTIAL` regardless of findings.\n   - For each finding with `release_blocking: true`:\n     - `status: FAIL` → verdict is at least `FAIL` for that finding.\n     - `status: PARTIAL` or `NOT_TESTED` → cap at `PARTIAL`.\n   - Otherwise → verdict is `PASS`.\n\n   Hard caps that override the file contents:\n   - \"No merged PR in this range requires it\" is NOT a valid reason to skip\n     live-app QA or any release-blocking finding. This gate evaluates the\n     cumulative shippable state of the repo, not the diff of the most\n     recent PRs.\n\n   Iteration loop:\n   - If verdict is `PASS`, emit the release report and stop.\n   - Otherwise, do NOT emit a final report yet. Pick the smallest\n     remediation that converts the highest-priority `release_blocking`\n     finding into evidence:\n     - `benchmark_overfit` \u002F `mutation_proof_missing` \u002F\n       `automated_test_gap` → re-enter `\u002Fautospec-qa`'s regeneration loop\n       to rewrite the offending tests.\n     - `no_mock_smoke` \u002F `live_backend_blocker` → boot the app or unblock\n       the live backend, then re-run Stage 7.\n     - `spec_contradiction` \u002F `legacy_residue` → fix docs\u002Fspecs\u002Fcode in one\n       commit, then re-run Stages 3-4.\n     - `outsourced_implementation` → replace the third-party API\u002FSDK call\n       with an in-repo implementation of the spec's described algorithm;\n       the external service MUST be either removed or gated behind an\n       off-by-default flag scoped to evaluation-only use, with cached\n       payloads carrying explicit redistribution permission. Then re-run\n       Stages 4-7. If the same offending client\u002FURL recurs in the next\n       iteration's findings, escalate to human review rather than\n       re-iterating on the same remediation.\n     - Untriaged `auto-implement` issue or queued blocker → run\n       `\u002Fautospec-run` on it, then re-run Stages 4-7.\n     - Any other `release_blocking` finding (e.g. `accessibility`,\n       `cross_browser`, `duplicate_code`, `new_code_intent`,\n       `presentational_misclassified`, `other`) → file a tracked GitHub\n       issue with reproduction steps, link it from the release report,\n       then re-run Stage 7.\n     After the remediation lands and is committed, re-enter at Stage 2\n     (sweep) and recompute. Each iteration MUST re-run Stage 7 before\n     recomputing the verdict — a verdict file whose `head_sha` does not\n     match the iteration's current HEAD is treated as missing.\n\n   Termination conditions (any one ends the loop):\n   - Verdict reached `PASS`.\n   - Iteration cap hit. Default: 5 iterations. Override:\n     `AUTOSPEC_RELEASE_MAX_ITERATIONS=\u003Cn>`. On cap, emit `PARTIAL` with the\n     unresolved findings and the exact next remediation command.\n   - `~\u002F.autospec\u002Fstop.flag` is present (operator halt). Emit `PARTIAL`\n     with the current state.\n   - No-progress detector: two consecutive iterations produced an identical\n     set of `release_blocking` findings (by category + summary). Emit\n     `FAIL` with the stuck findings and an escalation note.\n\n   Verdict values:\n   - `PASS`: all gates green; verdict file confirms live-app proof; no\n     blocking findings remain.\n   - `PARTIAL`: useful progress landed but the iteration cap or operator\n     halt ended the loop with at least one non-FAIL blocking finding\n     still open.\n   - `FAIL`: at least one `release_blocking` finding has `status: FAIL`\n     after the loop terminated, or the no-progress detector tripped, or\n     the loop aborted on infrastructure failure.\n\n## Spec supersession (recency)\n\nWhen `docs\u002Fspecs\u002F` contains two specs that overlap on a behavior, the spec\nwhose last-modifying commit on the current branch is most recent wins\n(issue #635: implicit-by-recency supersession; untracked specs fall back\nto filesystem mtime). Operators do NOT write `Supersedes:` frontmatter —\nrecency alone decides.\n\nRelease verdict computation MUST consult the resolver before treating any\nfinding as `release_blocking`. A finding whose `source_spec` is older than\nanother spec covering the same behavior is downgraded from\n`release_blocking` to `informational` — the newer spec has already replaced\nthe requirement.\n\nUse the shared helper for every finding under review:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fresolve-spec-supersession.sh\" \"\u003Cbehavior-key>\"\n```\n\nIf the resolver returns a spec path different from the finding's\n`source_spec`, the finding is referencing a superseded behavior. Downgrade\nthe severity and annotate the finding with the winning spec path so the\noperator can confirm the supersession intent. Do NOT block the release on a\nsuperseded finding.\n\nThis rule applies to release report rows, QA proof-matrix carryover, and\nlegacy-cleanup blockers alike.\n\n## Legacy cleanup prompt\n\nUse this prompt whenever code, config, docs, tests, specs, infra, or examples\nmention a deprecated path:\n\n```text\nBefore accepting this release:\n\n1. Is this path still reachable in the product, CLI, API, deployment, tests, or\n   docs?\n2. Is it the preferred path, a compatibility shim, or dead code?\n3. Does the spec still describe it as current behavior?\n4. Does any test fixture, README, runbook, env var, script, or infra module keep\n   it alive accidentally?\n5. What is the replacement path and where is that replacement proven?\n6. Can I delete it now? If not, what exact issue tracks removal and what event\n   will make removal safe?\n\nRequired outcome:\n- Preferred path: keep it and prove it.\n- Compatibility path: label and document it as compatibility only.\n- Dead path: delete it and remove matching spec\u002Fdocs\u002Ftests references.\n- Unknown path: mark release PARTIAL and create the smallest investigation or\n  cleanup issue needed to settle it.\n```\n\n## Worktree guard (commit gate)\n\n\u003C!-- worktree-assert:begin -->\nBefore committing any remediation fix (stage 9 iteration) or any other\nchange produced by this skill, run `worktree-guard.sh assert` and require\nexit 0. A non-zero exit (in_primary_checkout \u002F dirty \u002F stale_base) is NEVER\nworked around — stop the release flow and surface the emitted\n`code_health:*` identifier to the operator.\n\n```bash\n# MANDATORY assert gate: MUST exit 0 before any commit in the release flow.\nif ! bash \"${AUTOSPEC_SCRIPTS_DIR:-scripts}\u002Fworktree-guard.sh\" assert; then\n  echo \"worktree-guard assert failed (see code_health identifier above); aborting release commit\" >&2\n  exit 1\nfi\n```\n\nCleanup after a release-flow commit lands: `git worktree remove` the linked\nworktree and `git worktree prune`. Never work in the primary checkout.\n\u003C!-- worktree-assert:end -->\n\n## Release report contract\n\nReturn a concise report with:\n\n- Verdict: `PASS`, `PARTIAL`, or `FAIL`.\n- Branch and commit range reviewed.\n- Skills\u002Fstages run, with command evidence.\n- Changed files and simplifications made, if edits were performed.\n- Test, QA, docs, review, and legacy-cleanup evidence.\n- Remaining blockers with exact issue numbers or next commands.\n- Known `NOT TESTED` areas, separated from tested evidence.\n\nNever say the repo is release-ready unless the evidence above is complete.\n","# autospec-release workflow\n\nRun the repo-level release readiness loop. This is the \"I want to ship the\ncurrent repo\" wrapper over the existing autospec surfaces: sweep, review, run,\ntest, QA, proof validation, documentation drift checks, and legacy-code cleanup.\n\nUse this when the operator wants one explicit release gate instead of invoking\neach lower-level skill by hand.\n\n\u003C!-- autospec-block:startup-self-update SKILL_NAME=autospec-release -->\n\n## Self-update mode\n\nIf the feature-request argument matches `update` after trimming and lowercasing,\nre-install the full autospec suite from `main`, show the before\u002Fafter diff if the\nharness exposes it, then stop. Do not run the release gate.\n\n## Required capabilities & harness adapter\n\n| Capability | Claude Code | OpenCode | Codex CLI | Fallback if missing |\n| --- | --- | --- | --- | --- |\n| Subagent model tier | Tier A: `opus` + ultrathink | Tier A: top-tier `task` + max reasoning | Tier A: current top GPT + `reasoning_effort=high` | Run inline, but keep the same PASS\u002FPARTIAL\u002FFAIL contract |\n\u003C!-- autospec-block:harness-adapter-core -->\n| Existing autospec skills | Slash skills | agent prompts | skills\u002Fprompts | Run the matching workflow instructions inline |\n| GitHub operations | `gh` through shell | shell | shell | Mark merge\u002Fissue steps BLOCKED with exact command |\n| Test and QA execution | Browser\u002FE2E or shell | browser\u002Ftask or shell | shell\u002Fbrowser when available | Mark app-only checks NOT TESTED with blocker |\n\n**Model tier:** TIER_A for release synthesis and final readiness verdicts\nbecause a false PASS can ship broken behavior.\n\n## Harness detection\n\nDetect the harness once at skill start:\n\n1. Claude Code: `Agent` with `subagent_type` is available.\n   - `TIER_A` = `opus` + ultrathink.\n   - `TIER_B` = `sonnet`.\n2. OpenCode: `task` tool is available.\n   - `TIER_A` = top-tier task model + high reasoning.\n   - `TIER_B` = smaller-tier task model + medium reasoning.\n3. Codex CLI: `apply_patch` is the primary edit tool.\n   - `TIER_A` = current top GPT + `reasoning_effort=high`.\n   - `TIER_B` = current cost-optimized Codex model + `reasoning_effort=medium`.\n\nPrefer a Tier A reviewer\u002Fverifier subagent for the final release verdict when\nthe harness supports it. If `TIER_A` is unavailable, silently fall back to the\nnext available top-tier model. If delegation is unavailable, run the verdict\ninline.\n\n## Area dispatch (parallel subagents)\n\n`\u002Fautospec-release` parallelizes Stages 3-8 across 6 area subagents instead\nof walking them sequentially in the orchestrator (issue #731). The\ncanonical orchestrator script is `release-area-dispatch.sh`, which:\n\n1. Reads area definitions from `skills\u002Fautospec-release\u002Fareas\u002F\u003Cname>.md`.\n2. Dispatches all 6 area subagents in parallel via the harness-aware\n   dispatcher (`lib\u002Fautospec-harness-detect.sh`, PR #725).\n3. Aggregates per-area findings into `.autospec\u002Frelease-verdict.json`\n   honoring the schema consumed by `compute-release-verdict.sh`\n   (PR #636).\n4. Optionally re-probes stale findings via the qa-finding-filter\n   (`qa-finding-filter.sh`, PR #650) when\n   `AUTOSPEC_RELEASE_VERIFY_FIRST=1`.\n\nThe 6 areas:\n\n| Area | Stage | Description |\n| --- | --- | --- |\n| `spec-completeness` | 3 | Specs match live code; no stale\u002Fsuperseded blockers. |\n| `docs-freshness` | 3 | README\u002FAGENTS\u002FUSER_MANUAL describe current behavior. |\n| `implementation-completeness` | 5 | Every acceptance criterion has live code. |\n| `test-coverage` | 6 | Release-gate suites green; mutation + density floors met. |\n| `qa-artifact-integrity` | 7 | proof-matrix + control-ledger + mutation-proof + canary-results fresh + schema-valid. |\n| `legacy-cleanup` | 8 | No dead routes\u002Fcaches\u002Fconfigs masquerading as current. |\n\nEach area subagent receives a tight prompt bounded to 50-120k context and\n25 tool calls. Findings carry `verified_at: \u003Chead_sha>` since each\nsubagent is its own verifier; the orchestrator merges them and surfaces\n`live_app_proof` from `qa-artifact-integrity` so\n`compute-release-verdict.sh` continues to consume the merged verdict\nunchanged.\n\n**Model tier:** Tier A (spec work) for `spec-completeness`,\n`implementation-completeness`, and `legacy-cleanup`; Tier B\n(implementation work) for `docs-freshness`, `test-coverage`, and\n`qa-artifact-integrity`.\n\nInvoke the orchestrator directly:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Frelease-area-dispatch.sh\"\n```\n\nOr, when iterating on a single area:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Frelease-area-dispatch.sh\" --area spec-completeness\n```\n\n## When to use\n\n- The repo has existing specs, issues, code, and docs, and the operator asks\n  \"can we release this?\"\n- A project needs QA, review, testing, documentation drift checks, and legacy\n  cleanup in one coordinated pass.\n- Lower-level autospec skills have been run piecemeal and the operator wants a\n  single release-readiness answer.\n- The team wants a repeatable gate before tagging, deployment, or handoff.\n\n## When not to use\n\n- Do not use this as the first step for a brand-new feature idea. Use\n  `\u002Fautospec` or `\u002Fautospec-define`.\n- Do not use it as a replacement for `\u002Fautospec-stop` while a monitor is active.\n- Do not mark release PASS with mocked tests only when a no-mock smoke path is\n  required by the repo contract.\n- Do not paper over legacy code by leaving stale spec\u002Fdocs references behind.\n\n## Release pipeline\n\nRun these stages in order. If a lower-level skill is installed and invocable,\ncall that skill. If not, follow its documented workflow inline and report that\nthe explicit skill invocation was unavailable.\n\n1. Preflight\n   - Record branch, dirty files, remotes, GitHub repo, open PRs, open\n     `auto-implement` and `needs-classify` issues, and installed autospec skill\n     versions if visible.\n   - Do not revert user work. If dirty files exist, treat them as current repo\n     reality and avoid overwriting them.\n\n2. Sweep\n   - Run `\u002Fautospec-sweep` or the equivalent sweep workflow.\n   - Ensure `.autospec\u002Fautospec.yml` and the latest sweep report exist when the\n     repo is configured for sweeps.\n   - Turn recurring drift into concrete spec, issue, test, or docs work.\n\n3. Spec, docs, and story sync\n   - Compare `docs\u002Fspecs\u002F**`, README docs, user-facing docs, config docs, and\n     implementation reality.\n   - Remove stale claims for legacy code, legacy storage, deprecated APIs,\n     removed flags, dead routes, and old workflows.\n   - If behavior still exists only for compatibility, document that explicitly\n     as compatibility, not as the preferred path.\n\n4. Review\n   - Run `\u002Fautospec-review`.\n   - File or surface high-priority regression issues for spec-vs-code gaps.\n   - Do not proceed to PASS while untriaged release-blocking review findings\n     remain.\n\n5. Implementation queue\n   - Run `\u002Fautospec-classify` if `needs-classify` issues exist.\n   - Run `\u002Fautospec-run` until there are no ready release-blocking\n     `auto-implement` issues, or until a blocker is documented with the exact\n     issue number and command to resume.\n\n6. Test gate\n   - Run `\u002Fautospec-test` where available.\n   - Require lint, typecheck, unit, integration, smoke, E2E, and static checks\n     that the target repo defines as release gates.\n   - Failed tests are work, not report decoration: fix them or create a\n     release-blocking issue with exact reproduction.\n\n7. QA proof (MANDATORY — required for PASS)\n   - Run `\u002Fautospec-qa` against a live booted app. Either:\n     (a) boot the app locally (dev or prod build) and exercise it, or\n     (b) point QA at an already-deployed environment whose commit SHA matches\n         HEAD (or is explicitly recorded as the SHA under test).\n   - Mocked unit\u002Fintegration tests do NOT satisfy this gate. Stage 7 must\n     produce browser- or app-level interaction artifacts (screenshots, DOM\n     snapshots, network traces, or recorded sessions) covering the user-\n     facing surfaces in the release range.\n   - Require control-level proof for text boxes, selects, dropdowns, buttons,\n     validation, API effects, failure banners, fallback behavior, accessibility,\n     and no-mock smoke paths where the repo contract requires them.\n   - Validate QA artifacts with\n     `skills\u002Fautospec-shared\u002Fscripts\u002Fvalidate-qa-artifacts.sh` when available.\n   - Do not skip silently. If the app cannot be booted or reached, record the\n     reason, mark Stage 7 as `NOT EXECUTED`, and apply the Stage 9 verdict cap.\n   - After `\u002Fautospec-qa` completes, confirm `.autospec\u002Fqa-verdict.json`\n     exists with `head_sha` matching current HEAD and `live_app_proof: true`.\n     If absent, stale, or `live_app_proof: false`, the QA gate has not been\n     satisfied for this commit — treat as `NOT EXECUTED` for Stage 9.\n\n8. Legacy cleanup gate\n   - Search code, specs, docs, tests, fixtures, config, infra, and examples for\n     removed or deprecated behavior.\n   - Delete dead code when tests prove it is unreachable.\n   - Remove stale spec\u002Fdocs references in the same change that removes the code.\n   - If a legacy path cannot be removed yet, create a deprecation issue that\n     names the owner, replacement path, and removal trigger.\n\n8a. Repo quality audit\n   - Run the shared read-only audit before computing the release verdict:\n     ```bash\n     bash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Frepo-quality-audit.sh\" \\\n       --repo . \\\n       --json \".autospec\u002Frepo-quality-audit.json\" \\\n       --markdown \".autospec\u002Frepo-quality-audit.md\" \\\n       ${AUTOSPEC_QUALITY_AUDIT_FILE_ISSUES:+--file-issues}\n     ```\n   - Include audit status, filed issue links, suppressed findings, and unfiled\n     residual risks in the release report.\n   - Release PASS is blocked by unresolved `current-branch-regression` security\n     or verification findings unless they are explicitly classified as inherited\n     accepted debt in `.autospec\u002Fquality-audit-accepted.json`.\n\n9. Verdict computation and release iteration loop\n\n   The deterministic computation is implemented by\n   `compute-release-verdict.sh` and is the canonical source of truth.\n   Invoke it with the current verdict path; stdout is one of `PASS` \u002F\n   `PARTIAL` \u002F `FAIL` and the exit code mirrors that (0\u002F1\u002F2; 3 for\n   infrastructure errors). The prose rules below describe what that script\n   does — if they diverge from the script's actual behavior, fix the script\n   and the bats tests in `tests\u002Fcompute-release-verdict.bats`, not the\n   prose. Never re-derive the verdict by hand when the script is available.\n\n   Compute the verdict deterministically from `.autospec\u002Fqa-verdict.json`:\n\n   - If the file is missing → verdict is `FAIL` with a synthetic finding\n     \"qa-verdict.json not produced by Stage 7\".\n   - If `head_sha` does not match `git rev-parse HEAD` → treat as missing.\n     Synthesize a FAIL finding \"QA verdict stale relative to HEAD\" and\n     require Stage 7 to re-run in the same iteration before recomputing\n     the verdict.\n   - If `live_app_proof: false` → cap at `PARTIAL` regardless of findings.\n   - For each finding with `release_blocking: true`:\n     - `status: FAIL` → verdict is at least `FAIL` for that finding.\n     - `status: PARTIAL` or `NOT_TESTED` → cap at `PARTIAL`.\n   - Otherwise → verdict is `PASS`.\n\n   Hard caps that override the file contents:\n   - \"No merged PR in this range requires it\" is NOT a valid reason to skip\n     live-app QA or any release-blocking finding. This gate evaluates the\n     cumulative shippable state of the repo, not the diff of the most\n     recent PRs.\n\n   Iteration loop:\n   - If verdict is `PASS`, emit the release report and stop.\n   - Otherwise, do NOT emit a final report yet. Pick the smallest\n     remediation that converts the highest-priority `release_blocking`\n     finding into evidence:\n     - `benchmark_overfit` \u002F `mutation_proof_missing` \u002F\n       `automated_test_gap` → re-enter `\u002Fautospec-qa`'s regeneration loop\n       to rewrite the offending tests.\n     - `no_mock_smoke` \u002F `live_backend_blocker` → boot the app or unblock\n       the live backend, then re-run Stage 7.\n     - `spec_contradiction` \u002F `legacy_residue` → fix docs\u002Fspecs\u002Fcode in one\n       commit, then re-run Stages 3-4.\n     - `outsourced_implementation` → replace the third-party API\u002FSDK call\n       with an in-repo implementation of the spec's described algorithm;\n       the external service MUST be either removed or gated behind an\n       off-by-default flag scoped to evaluation-only use, with cached\n       payloads carrying explicit redistribution permission. Then re-run\n       Stages 4-7. If the same offending client\u002FURL recurs in the next\n       iteration's findings, escalate to human review rather than\n       re-iterating on the same remediation.\n     - Untriaged `auto-implement` issue or queued blocker → run\n       `\u002Fautospec-run` on it, then re-run Stages 4-7.\n     - Any other `release_blocking` finding (e.g. `accessibility`,\n       `cross_browser`, `duplicate_code`, `new_code_intent`,\n       `presentational_misclassified`, `other`) → file a tracked GitHub\n       issue with reproduction steps, link it from the release report,\n       then re-run Stage 7.\n     After the remediation lands and is committed, re-enter at Stage 2\n     (sweep) and recompute. Each iteration MUST re-run Stage 7 before\n     recomputing the verdict — a verdict file whose `head_sha` does not\n     match the iteration's current HEAD is treated as missing.\n\n   Termination conditions (any one ends the loop):\n   - Verdict reached `PASS`.\n   - Iteration cap hit. Default: 5 iterations. Override:\n     `AUTOSPEC_RELEASE_MAX_ITERATIONS=\u003Cn>`. On cap, emit `PARTIAL` with the\n     unresolved findings and the exact next remediation command.\n   - `~\u002F.autospec\u002Fstop.flag` is present (operator halt). Emit `PARTIAL`\n     with the current state.\n   - No-progress detector: two consecutive iterations produced an identical\n     set of `release_blocking` findings (by category + summary). Emit\n     `FAIL` with the stuck findings and an escalation note.\n\n   Verdict values:\n   - `PASS`: all gates green; verdict file confirms live-app proof; no\n     blocking findings remain.\n   - `PARTIAL`: useful progress landed but the iteration cap or operator\n     halt ended the loop with at least one non-FAIL blocking finding\n     still open.\n   - `FAIL`: at least one `release_blocking` finding has `status: FAIL`\n     after the loop terminated, or the no-progress detector tripped, or\n     the loop aborted on infrastructure failure.\n\n## Spec supersession (recency)\n\nWhen `docs\u002Fspecs\u002F` contains two specs that overlap on a behavior, the spec\nwhose last-modifying commit on the current branch is most recent wins\n(issue #635: implicit-by-recency supersession; untracked specs fall back\nto filesystem mtime). Operators do NOT write `Supersedes:` frontmatter —\nrecency alone decides.\n\nRelease verdict computation MUST consult the resolver before treating any\nfinding as `release_blocking`. A finding whose `source_spec` is older than\nanother spec covering the same behavior is downgraded from\n`release_blocking` to `informational` — the newer spec has already replaced\nthe requirement.\n\nUse the shared helper for every finding under review:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fresolve-spec-supersession.sh\" \"\u003Cbehavior-key>\"\n```\n\nIf the resolver returns a spec path different from the finding's\n`source_spec`, the finding is referencing a superseded behavior. Downgrade\nthe severity and annotate the finding with the winning spec path so the\noperator can confirm the supersession intent. Do NOT block the release on a\nsuperseded finding.\n\nThis rule applies to release report rows, QA proof-matrix carryover, and\nlegacy-cleanup blockers alike.\n\n## Legacy cleanup prompt\n\nUse this prompt whenever code, config, docs, tests, specs, infra, or examples\nmention a deprecated path:\n\n```text\nBefore accepting this release:\n\n1. Is this path still reachable in the product, CLI, API, deployment, tests, or\n   docs?\n2. Is it the preferred path, a compatibility shim, or dead code?\n3. Does the spec still describe it as current behavior?\n4. Does any test fixture, README, runbook, env var, script, or infra module keep\n   it alive accidentally?\n5. What is the replacement path and where is that replacement proven?\n6. Can I delete it now? If not, what exact issue tracks removal and what event\n   will make removal safe?\n\nRequired outcome:\n- Preferred path: keep it and prove it.\n- Compatibility path: label and document it as compatibility only.\n- Dead path: delete it and remove matching spec\u002Fdocs\u002Ftests references.\n- Unknown path: mark release PARTIAL and create the smallest investigation or\n  cleanup issue needed to settle it.\n```\n\n## Worktree guard (commit gate)\n\n\u003C!-- worktree-assert:begin -->\nBefore committing any remediation fix (stage 9 iteration) or any other\nchange produced by this skill, run `worktree-guard.sh assert` and require\nexit 0. A non-zero exit (in_primary_checkout \u002F dirty \u002F stale_base) is NEVER\nworked around — stop the release flow and surface the emitted\n`code_health:*` identifier to the operator.\n\n```bash\n# MANDATORY assert gate: MUST exit 0 before any commit in the release flow.\nif ! bash \"${AUTOSPEC_SCRIPTS_DIR:-scripts}\u002Fworktree-guard.sh\" assert; then\n  echo \"worktree-guard assert failed (see code_health identifier above); aborting release commit\" >&2\n  exit 1\nfi\n```\n\nCleanup after a release-flow commit lands: `git worktree remove` the linked\nworktree and `git worktree prune`. Never work in the primary checkout.\n\u003C!-- worktree-assert:end -->\n\n## Release report contract\n\nReturn a concise report with:\n\n- Verdict: `PASS`, `PARTIAL`, or `FAIL`.\n- Branch and commit range reviewed.\n- Skills\u002Fstages run, with command evidence.\n- Changed files and simplifications made, if edits were performed.\n- Test, QA, docs, review, and legacy-cleanup evidence.\n- Remaining blockers with exact issue numbers or next commands.\n- Known `NOT TESTED` areas, separated from tested evidence.\n\nNever say the repo is release-ready unless the evidence above is complete.\n",{"name":5,"description":7},"main","9e7f04357ff46ab731d4f56a4ac5ca5449c13bb0","skills\u002Fautospec-release",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":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add berlinguyinca\u002Fautospec --skill autospec-release",{"tool":58,"command":59},"bunx","bunx skills add berlinguyinca\u002Fautospec --skill autospec-release",{"tool":61,"command":62},"pnpm","pnpm dlx skills add berlinguyinca\u002Fautospec --skill autospec-release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002FSKILL.md",true,[66,72,75,79,83,87,91,95,101,105,109],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"areas\u002Fdocs-freshness.md","REFERENCE","参考文档",1258,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Fareas\u002Fdocs-freshness.md",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":74},"areas\u002Fimplementation-completeness.md","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Fareas\u002Fimplementation-completeness.md",{"path":76,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":77,"sourceHtmlUrl":78},"areas\u002Flegacy-cleanup.md",1129,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Fareas\u002Flegacy-cleanup.md",{"path":80,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":81,"sourceHtmlUrl":82},"areas\u002Fqa-artifact-integrity.md",1236,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Fareas\u002Fqa-artifact-integrity.md",{"path":84,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":85,"sourceHtmlUrl":86},"areas\u002Fspec-completeness.md",1342,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Fareas\u002Fspec-completeness.md",{"path":88,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":89,"sourceHtmlUrl":90},"areas\u002Ftest-coverage.md",1102,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Fareas\u002Ftest-coverage.md",{"path":92,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":93,"sourceHtmlUrl":94},"codex\u002Fprompt.md",18067,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Fcodex\u002Fprompt.md",{"path":96,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"install.sh","SCRIPT","脚本",6383,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Finstall.sh",{"path":102,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":103,"sourceHtmlUrl":104},"opencode\u002Fagent.md",18316,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Fopencode\u002Fagent.md",{"path":106,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":107,"sourceHtmlUrl":108},"README.md",1509,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002FREADME.md",{"path":110,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":111,"sourceHtmlUrl":112},"uninstall.sh",2089,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-release\u002Funinstall.sh",[114,127,136,145,167,191],{"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":124,"publishedAt":39},"01M71RJHYMKPTC9AAPXWQ6F4RT","trio-pass-skill","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Flockstep-trio-pass\u002FSKILL.md",[119],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[125,126],"trio","trio pass skill",{"skillNo":128,"name":129,"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":130,"categories":131,"keywords":133,"publishedAt":39},"01M71RJFBQ1KAF9XM3T3Y4VMSK","duo-pass-skill","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Flockstep-duo-pass\u002FSKILL.md",[132],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[134,135],"duo pass skill","duo",{"skillNo":137,"name":138,"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":139,"categories":140,"keywords":142,"publishedAt":39},"01M71RJDT1TB3P9TRWR6A534FB","duo-divergence-skill","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Flockstep-duo-divergence\u002FSKILL.md",[141],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[143,135,144],"duo divergence skill","divergence",{"skillNo":146,"name":19,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":153,"publishedAt":39},"01M71RJAC4NNEQSYBDSY3NZS73","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.","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002FSKILL.md",[150],{"categoryNo":151,"categoryName":152,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000015","视觉设计",[19,154,37,155,156,157,158,159,30,27,160,23,161,162,163,164,165,38,166,33],"ship a feature","issues","design","autonomous","auto","loop","design spec","ship","implementation loop","github issues","feature","commits","missing",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":39},"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",[],[174,19,175,176,177,178,179,180,181,30,182,183,184,185,33,186,187,188,189,190],"autospec upgrade","upgrade","mutation","coverage","official","project","time","gating","angular","react","next","at","Next.js","one","with","behavior","latest",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":202,"publishedAt":39},"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",[197],{"categoryNo":198,"categoryName":199,"taxonomyType":200,"taxonomyTypeDesc":201},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[203,19,204,205,206,33,207,208,209,210,211,212,213,214,215,183,28,30,216],"ui audit","audit","autospec ui audit","ui","inventory","evidence","deterministic","route","ux","site","react router","navigation","application","router"]