[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GXB76JD5GARMD930YHMVDP":3,"skill-same:01M6GXB76JD5GARMD930YHMVDP":58},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":43,"install":44,"resources":57},"01M6GXB76JD5GARMD930YHMVDP","spec-review",null,"Multi-provider SPEC review gate skill","autopus-ai\u002Fautopus-adk","autopus-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F327805805?v=4","01M6GX6DDW0BA7MCYD3799BYEF","01M6GX6DJ6FKVZVDKSPQTNNPME",109,"MIT","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fspec-review\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31],"review","spec","spec review","gate","provider","multi-provider","omp","multi","review gate","2026-11-10 10:12:30",false,"---\nname: spec-review\ndescription: Multi-provider SPEC review gate skill\ncompatibility: omp\n---\n\n# SPEC Review Gate Skill\n\nA review gate that validates SPEC document quality using multiple providers.\nBefore Step 1, treat `.omp\u002Frules\u002Fautopus-spec-quality.md` as the pre-review self-check that spec-writer should already have applied to `spec.md`, `plan.md`, `acceptance.md`, and `research.md`.\n\nThe CLI writes the authoritative promotion receipt to\n`{SPEC_DIR}\u002Freview-receipt.json` with\n`schema=spec_review_promotion_receipt.v1`. Consumers bind it to the current\ninvocation with `run_id` and `finished_at`, then preserve `analysis_verdict`,\n`gate_status`, `critical_veto`, `status_changed`, `degraded_reasons`, and\n`override_applied` without recomputing promotion.\n`--allow-degraded` is the only operator path that may promote a degraded PASS,\nand its audit reason remains present after promotion. An unresolved Critical\nsecurity\u002Fcorrectness finding sets `critical_veto=true`, keeps\n`gate_status=blocked`, and leaves the prior status unchanged.\n\n## Review Process\n\n### Step 0: spec-writer self-verify\n\nConfirm that the draft went through a first-pass self-check using `.omp\u002Frules\u002Fautopus-spec-quality.md`.\nLook for observable traces such as `research.md`'s `## Self-Verify Summary` or `spec.md`'s `## Open Issues`.\nAlso prefer the draft's `## Outcome Lock`, `## Completion Debt`, `## Evolution Ideas`, `## Reviewer Brief`, `## Traceability Matrix`, and `## Reference Discipline` as scope-control evidence: review listed blockers and invariants first, treat Completion Debt as blocking, and treat Evolution Ideas or unrelated deeper-layer suggestions as advisory unless they expose critical\u002Fsecurity\u002Fdata integrity risk.\nDo not create or request follow-up\u002Fsibling SPECs from Evolution Ideas. A sibling SPEC request is valid only when the draft includes a `## Sibling SPEC Decision` with an allowed reason and bounded ownership.\nIf the checklist was skipped or obviously not reflected in the draft, call that out as a completeness or style finding before continuing.\n\n### Step 1: Load SPEC\n\nLoad `.autopus\u002Fspecs\u002FSPEC-{ID}\u002Fspec.md` and extract requirements.\n\n### Step 2: Collect Code Context\n\nIf `spec.review_gate.auto_collect_context: true`:\n- Scan project source files\n- Collect relevant code within `context_max_lines` limit\n- Include collected code in the review prompt\n\n### Step 3: Multi-Provider Review\n\nRun the review via the Orchestra engine with configured providers (claude, gemini, etc.):\n- Each provider reviews the SPEC independently\n- Auxiliary documents (`plan.md`, `research.md`, `acceptance.md`) are injected in full by default under an adaptive total context budget. Structure-preserving compression is a fallback that triggers only when the combined budget is exceeded, and it keeps tail-critical sections (Self-Verify Summary, Traceability Matrix, Reviewer Brief, Completion Debt, Evolution Ideas, Open Issues) instead of dropping the document tail.\n- Provider quorum: the gate counts how many providers returned a usable review and compares it to the configured minimum (`spec.review_gate.min_providers`, default majority of configured providers).\n- Results are merged according to the strategy (debate, consensus, etc.)\n- Provider integrity retains requested, configured, resolved, attempted,\n  usable, and failed sets; configured-but-unavailable providers do not vanish\n  from the declared quorum denominator.\n- Structured findings are clustered by stable identity, preserve minority\n  evidence, and apply Critical veto before promotion.\n\n### Step 4: Verdict\n\nParse results and determine the final verdict:\n- **PASS**: SPEC approved; promote status to \"approved\" only when observation is complete and the provider quorum is met\n- **REVISE**: Revision required, return with list of findings\n- **REJECT**: Fundamental redesign required\n\nA PASS produced under partial observation is a degraded PASS and does not auto-promote status. The verdict is annotated with a degraded reason:\n- `partial_doc_context`: a required auxiliary document was injected below 100 percent coverage because the document set exceeded the total context budget\n- `provider_quorum`: fewer providers returned a usable review than the configured minimum\n\nWhen any degraded reason is present, leave the prior SPEC status unchanged unless the operator passes `--allow-degraded`.\nReport `run_id`, `finished_at`, `analysis_verdict`, `gate_status`,\n`critical_veto`, `status_changed`, `degraded_reasons`, and `override_applied`\nin `{SPEC_DIR}\u002Freview-receipt.json` and the terminal handoff. Consumers must\nalso verify `current_status`; they never edit SPEC status themselves. A clean\nre-review of an already-approved SPEC may report `status_changed=false` while\nremaining `gate_status=passed` and `current_status=approved`.\n\n### Step 5: Save Results\n\nSave `review.md` to the SPEC directory:\n- Final verdict, with any degraded reason on the verdict line\n- An `## Observation Coverage` section listing each auxiliary document with injected lines, source total lines, coverage percent, and a complete flag\n- Findings from each provider\n- Original responses\n- When `--allow-degraded` promoted a degraded PASS, an audit line recording the override reason\n\nThe same per-document coverage is persisted in the `review-findings.json` sidecar as an additive, optional `DocCoverages` field, so older sidecars written without it still load.\n\n## CLI Usage\n\n```bash\nauto spec review SPEC-PIPE-001\nauto spec review SPEC-AUTH-001 --strategy debate --timeout 180\nauto spec review SPEC-AUTH-001 --strategy debate --providers claude,codex\nauto spec review SPEC-AUTH-001 --allow-degraded  # promote a degraded PASS; recorded as an audit line\n```\n\n`--providers` is an explicit comma-separated provider override. Forward the\nuser-supplied list unchanged; omit the flag only when the user supplied no\noverride.\n\nDo not wrap these commands with GNU `timeout` (for example,\n`timeout 540 auto spec review ...`). macOS does not include GNU `timeout` by\ndefault. Use the agent tool's native timeout\u002Fbackground control for wall-clock\nlimits, and use `--timeout \u003Cseconds>` for Autopus provider execution limits.\n\n## Configuration (autopus.yaml)\n\n```yaml\nspec:\n  review_gate:\n    enabled: true\n    strategy: debate\n    providers: [claude, gemini]\n    judge: claude\n    max_revisions: 2\n    min_providers: 0      # 0 = default minimum quorum (majority: len\u002F2+1 of configured providers)\n    auto_collect_context: true\n    context_max_lines: 0  # unset; adaptive limits are 500\u002F1500\u002F3000 by cited file count\n```\n\n## Provider Fallback\n\nIf a configured provider binary is not installed:\n- Skip that provider and output a warning\n- Continue review with available providers only\n- Return an error if no providers are available\n","# SPEC Review Gate Skill\n\nA review gate that validates SPEC document quality using multiple providers.\nBefore Step 1, treat `.omp\u002Frules\u002Fautopus-spec-quality.md` as the pre-review self-check that spec-writer should already have applied to `spec.md`, `plan.md`, `acceptance.md`, and `research.md`.\n\nThe CLI writes the authoritative promotion receipt to\n`{SPEC_DIR}\u002Freview-receipt.json` with\n`schema=spec_review_promotion_receipt.v1`. Consumers bind it to the current\ninvocation with `run_id` and `finished_at`, then preserve `analysis_verdict`,\n`gate_status`, `critical_veto`, `status_changed`, `degraded_reasons`, and\n`override_applied` without recomputing promotion.\n`--allow-degraded` is the only operator path that may promote a degraded PASS,\nand its audit reason remains present after promotion. An unresolved Critical\nsecurity\u002Fcorrectness finding sets `critical_veto=true`, keeps\n`gate_status=blocked`, and leaves the prior status unchanged.\n\n## Review Process\n\n### Step 0: spec-writer self-verify\n\nConfirm that the draft went through a first-pass self-check using `.omp\u002Frules\u002Fautopus-spec-quality.md`.\nLook for observable traces such as `research.md`'s `## Self-Verify Summary` or `spec.md`'s `## Open Issues`.\nAlso prefer the draft's `## Outcome Lock`, `## Completion Debt`, `## Evolution Ideas`, `## Reviewer Brief`, `## Traceability Matrix`, and `## Reference Discipline` as scope-control evidence: review listed blockers and invariants first, treat Completion Debt as blocking, and treat Evolution Ideas or unrelated deeper-layer suggestions as advisory unless they expose critical\u002Fsecurity\u002Fdata integrity risk.\nDo not create or request follow-up\u002Fsibling SPECs from Evolution Ideas. A sibling SPEC request is valid only when the draft includes a `## Sibling SPEC Decision` with an allowed reason and bounded ownership.\nIf the checklist was skipped or obviously not reflected in the draft, call that out as a completeness or style finding before continuing.\n\n### Step 1: Load SPEC\n\nLoad `.autopus\u002Fspecs\u002FSPEC-{ID}\u002Fspec.md` and extract requirements.\n\n### Step 2: Collect Code Context\n\nIf `spec.review_gate.auto_collect_context: true`:\n- Scan project source files\n- Collect relevant code within `context_max_lines` limit\n- Include collected code in the review prompt\n\n### Step 3: Multi-Provider Review\n\nRun the review via the Orchestra engine with configured providers (claude, gemini, etc.):\n- Each provider reviews the SPEC independently\n- Auxiliary documents (`plan.md`, `research.md`, `acceptance.md`) are injected in full by default under an adaptive total context budget. Structure-preserving compression is a fallback that triggers only when the combined budget is exceeded, and it keeps tail-critical sections (Self-Verify Summary, Traceability Matrix, Reviewer Brief, Completion Debt, Evolution Ideas, Open Issues) instead of dropping the document tail.\n- Provider quorum: the gate counts how many providers returned a usable review and compares it to the configured minimum (`spec.review_gate.min_providers`, default majority of configured providers).\n- Results are merged according to the strategy (debate, consensus, etc.)\n- Provider integrity retains requested, configured, resolved, attempted,\n  usable, and failed sets; configured-but-unavailable providers do not vanish\n  from the declared quorum denominator.\n- Structured findings are clustered by stable identity, preserve minority\n  evidence, and apply Critical veto before promotion.\n\n### Step 4: Verdict\n\nParse results and determine the final verdict:\n- **PASS**: SPEC approved; promote status to \"approved\" only when observation is complete and the provider quorum is met\n- **REVISE**: Revision required, return with list of findings\n- **REJECT**: Fundamental redesign required\n\nA PASS produced under partial observation is a degraded PASS and does not auto-promote status. The verdict is annotated with a degraded reason:\n- `partial_doc_context`: a required auxiliary document was injected below 100 percent coverage because the document set exceeded the total context budget\n- `provider_quorum`: fewer providers returned a usable review than the configured minimum\n\nWhen any degraded reason is present, leave the prior SPEC status unchanged unless the operator passes `--allow-degraded`.\nReport `run_id`, `finished_at`, `analysis_verdict`, `gate_status`,\n`critical_veto`, `status_changed`, `degraded_reasons`, and `override_applied`\nin `{SPEC_DIR}\u002Freview-receipt.json` and the terminal handoff. Consumers must\nalso verify `current_status`; they never edit SPEC status themselves. A clean\nre-review of an already-approved SPEC may report `status_changed=false` while\nremaining `gate_status=passed` and `current_status=approved`.\n\n### Step 5: Save Results\n\nSave `review.md` to the SPEC directory:\n- Final verdict, with any degraded reason on the verdict line\n- An `## Observation Coverage` section listing each auxiliary document with injected lines, source total lines, coverage percent, and a complete flag\n- Findings from each provider\n- Original responses\n- When `--allow-degraded` promoted a degraded PASS, an audit line recording the override reason\n\nThe same per-document coverage is persisted in the `review-findings.json` sidecar as an additive, optional `DocCoverages` field, so older sidecars written without it still load.\n\n## CLI Usage\n\n```bash\nauto spec review SPEC-PIPE-001\nauto spec review SPEC-AUTH-001 --strategy debate --timeout 180\nauto spec review SPEC-AUTH-001 --strategy debate --providers claude,codex\nauto spec review SPEC-AUTH-001 --allow-degraded  # promote a degraded PASS; recorded as an audit line\n```\n\n`--providers` is an explicit comma-separated provider override. Forward the\nuser-supplied list unchanged; omit the flag only when the user supplied no\noverride.\n\nDo not wrap these commands with GNU `timeout` (for example,\n`timeout 540 auto spec review ...`). macOS does not include GNU `timeout` by\ndefault. Use the agent tool's native timeout\u002Fbackground control for wall-clock\nlimits, and use `--timeout \u003Cseconds>` for Autopus provider execution limits.\n\n## Configuration (autopus.yaml)\n\n```yaml\nspec:\n  review_gate:\n    enabled: true\n    strategy: debate\n    providers: [claude, gemini]\n    judge: claude\n    max_revisions: 2\n    min_providers: 0      # 0 = default minimum quorum (majority: len\u002F2+1 of configured providers)\n    auto_collect_context: true\n    context_max_lines: 0  # unset; adaptive limits are 500\u002F1500\u002F3000 by cited file count\n```\n\n## Provider Fallback\n\nIf a configured provider binary is not installed:\n- Skip that provider and output a warning\n- Continue review with available providers only\n- Return an error if no providers are available\n",{"name":5,"description":7,"compatibility":29},"main","4f21f3091a165c082859130de920aaeb017efad8",".omp\u002Fskills\u002Fspec-review",74,"https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk","https:\u002F\u002Fgithub.com\u002Fautopus-ai","2026-11-11 21:01:34",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add autopus-ai\u002Fautopus-adk --skill spec-review",{"tool":50,"command":51},"bunx","bunx skills add autopus-ai\u002Fautopus-adk --skill spec-review",{"tool":53,"command":54},"pnpm","pnpm dlx skills add autopus-ai\u002Fautopus-adk --skill spec-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fspec-review\u002FSKILL.md",true,[],[59,65,80,87,96,110],{"skillNo":60,"name":61,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":32},"01M6GXC22ZCVSKYJXPE5ZE51ZV","auto","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002Ftestdata\u002Fupgrade\u002Fv0.50.108\u002F.agents\u002Fskills\u002Fauto\u002FSKILL.md",[],[61],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":72,"publishedAt":32},"01M6GXBY8KS4F365HYZFCP8MDG","worktree-isolation","Worktree isolation for parallel agent execution in the pipeline","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fworktree-isolation\u002FSKILL.md",[71],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[73,74,75,76,29,77,78,79],"worktree isolation","isolation","worktree","for","parallel","execution","pipeline",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":32},"01M6GXBR2JFP9AG6XW059P9508","verification","구현 결과 검증 및 품질 게이트 통과 스킬","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fverification\u002FSKILL.md",[],[82,29],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":32},"01M6GXBJWVA7CA2Y0QFMC9WMYF","using-autopus","Autopus-ADK 설치 및 활용 가이드 스킬","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Fusing-autopus\u002FSKILL.md",[],[94,29,95],"using autopus","adk",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":105,"publishedAt":32},"01M6GXBFA7F84VAZHW7XA612X5","testing-strategy","통합\u002FE2E\u002F계약 테스트 전략 및 테스트 피라미드","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Ftesting-strategy\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",[106,107,108,29,109],"testing","strategy","testing strategy","e2e",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":32},"01M6GXBB988G8Q86YH7S0K4FWT","tdd","Test-Driven Development 방법론 스킬","https:\u002F\u002Fgithub.com\u002Fautopus-ai\u002Fautopus-adk\u002Fblob\u002Fmain\u002F.omp\u002Fskills\u002Ftdd\u002FSKILL.md",[],[112,117,118,29,119,120],"test-driven","driven","development","test"]