[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71J41J2Y4GPHTWADA68TXN3":3,"skill-same:01M71J41J2Y4GPHTWADA68TXN3":77},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":6,"updatedAt":63,"install":64,"resources":76},"01M71J41J2Y4GPHTWADA68TXN3","request-review",null,"Dispatch a fresh reviewer agent with a clean context to critique the code after audit-code passes. The reviewer has no shared state with the coding agent and gives a genuine second opinion. Use after audit-code passes, before committing, or when user wants an independent code review.","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",289,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.gemini\u002Fextensions\u002Fbigpowers\u002Fskills\u002Frequest-review\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"request","request review","review","coding agent","true","second","opus","context","coding","opinion","audit","critique","clean context","fresh","reviewer","code","when","clean","code review","shared","2026-11-10 10:12:30",false,"---\nname: request-review\nmodel: opus\ndescription: \"Dispatch a fresh reviewer agent with a clean context to critique the code after audit-code passes. The reviewer has no shared state with the coding agent and gives a genuine second opinion. Use after audit-code passes, before committing, or when user wants an independent code review.\"\ndisable-model-invocation: true\n---\n\n\u003C!-- story: e45s28 -->\n\n# Request Review\n\nDispatch fresh reviewer agents with clean contexts. Reviewers have no shared state — they find what the coding agent missed.\n\n## Target (argument)\n\nIf an argument was passed after `\u002Frequest-review` (e.g. `\u002Frequest-review abc1234` or `\u002Frequest-review HEAD~3..HEAD`), use it as the diff target when building the reviewer brief:\n\n```bash\ngit diff \u003Carg>        # range: abc..def, HEAD~3..HEAD\ngit show \u003Carg>        # single commit: abc1234\n```\n\nIf no argument was given, review uncommitted working-tree changes.\n\n**Distinct from `audit-code`:** `audit-code` is self-review (internal). This skill dispatches external agents.\n\n**Solo developer note:** Reviewer agents replace the human reviewer.\n\n**Run `audit-code` first.** Don't waste reviewer attention on hygiene issues you could have caught yourself.\n\n## Santa Method — Dual-Blind AND Gate (e45s07)\n\nUse **two independent reviewers** (Reviewer A and Reviewer B) with **no shared context** between them or the coding agent.\n\n| Parameter | Value |\n|-----------|-------|\n| Reviewers | 2 (mandatory) |\n| `MAX_REVIEW_ITERATIONS` | **5** (hard cap — e45s28; iteration 6 forbidden) |\n| Pass rule | **AND-gate** — both reviewers must pass independently |\n| Blindness | Neither reviewer sees the other's report until both complete |\n\n**Iteration loop (max `MAX_REVIEW_ITERATIONS`):**\n\n1. Dispatch Reviewer A and Reviewer B in parallel with identical briefs but separate contexts.\n2. Collect both reports. Each categorizes findings: must-fix \u002F should-fix \u002F consider.\n3. **AND-gate:** If **either** reviewer has must-fix findings → FAIL round. Run `respond-review`, fix, re-dispatch both reviewers.\n4. If both pass (zero must-fix, score ≥ 94% each) → review complete.\n5. After **5** iterations without dual pass → **stop**; report \"Review cap exhausted (5\u002F5). Human decision required.\" Do not merge.\n\n> **HARD GATE** — Single-reviewer pass is insufficient. Partial agreement does not satisfy the AND-gate.\n\n## Process\n\n### 1. Prepare the review brief\n\nWrite a self-contained brief for each reviewer. Include:\n\n- What was built (feature description, not implementation)\n- Which files changed (the diff context)\n- What `specs\u002F` artifacts are relevant (active `epics\u002FeNN-*.yaml`, `requirements\u002FSCOPE_LATEST.yaml`, `bugs\u002FBUG-*.md`)\n- What CONVENTIONS.md requires\n- What the verify command is\n- What you're most uncertain about (where you want fresh eyes)\n- **Security focus** — If the epic has a `specs\u002Fsecurity\u002Fepics\u002F\u003Cid>\u002FTHREAT_MODEL.md`, include the relevant vulnerability categories as reviewer focal points. Also include the false-positive exclusion rules so the reviewer avoids known-safe patterns. Tag the review as `security-sensitive: true` if THREAT_MODEL risk is HIGH+.\n\n### 2. Fan-out parallel reviewers (e45s17)\n\nBeyond the mandatory dual-blind pair (e45s07), optionally dispatch **N dimension-specific subagents in one message** — one check per agent for broader coverage (OpenAI Codex `code-review-*` pattern):\n\n| Agent | Focus |\n|-------|-------|\n| R-correctness | Logic, edge cases, verify command result |\n| R-conventions | CONVENTIONS.md, test quality (F.I.R.S.T) |\n| R-security | Injection, auth, secrets (when `security-sensitive`) |\n| R-design | Simpler alternatives, API shape |\n\nSanta Method still applies: each agent is blind; AND-gate uses Reviewer A + B scores. Fan-out agents feed findings into `respond-review` but do not replace the dual-blind pair.\n\n### 2b. Dispatch both reviewer agents (parallel)\n\nUse the Agent tool twice with completely fresh contexts. Each prompt must be self-contained — no references to \"our conversation\" or \"what we discussed.\"\n\n```\nYou are code reviewer [A|B]. Review the following code changes independently.\n\nContext: [feature description]\nCONVENTIONS.md rules: [paste relevant sections]\nActive epic shard: [paste or summarize from specs\u002Fepics\u002F]\n\nDiff: [paste git diff or describe changed files]\n\nVerify command: [runnable command]\n\nReview for:\n1. Correctness — does the code do what was intended?\n2. CONVENTIONS.md compliance — are all rules followed?\n3. Test quality — do tests verify behavior (not implementation)?\n4. Design — are there simpler or more robust approaches?\n5. Edge cases — what inputs or states could cause failures?\n6. Security — any injection, auth, or data exposure risks?\n7. Refactoring smells — explicitly name any detected Fowler smells: Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Message Chains, Middle Man\n\nFor each finding, categorize as: must-fix \u002F should-fix \u002F consider.\nRun the verify command and report the result.\n```\n\n### 3. Collect both reports\n\nWhen reviewers return:\n- Read every finding from **both** reports before acting on any\n- Note each verify command result\n- Compute quality score per reviewer: `100 × (total_items − must_fix − should_fix) \u002F total_items`\n- **AND-gate check:** both scores ≥ 94% and zero must-fix from **both**?\n\n> **HARD GATE** — If either score \u003C 94% or either has must-fix → FAIL round. Run `respond-review` first. The 94% threshold also applies to `npm run compliance` (scripts\u002Faudit-compliance.sh).\n\n### 4. Hand off to respond-review\n\nPass combined findings to `respond-review` to categorize and apply fixes. Increment iteration counter. Re-dispatch both reviewers until AND-gate passes or iteration 3 exhausted.\n\nReport to user: \"Review round [N\u002F3]. Reviewer A: [score], Reviewer B: [score]. AND-gate: [PASS|FAIL].\"\n\n## Verify\n\n→ verify: `test -f scripts\u002Flib\u002Fparallel-review-worktrees.sh && test -f skills\u002Frequest-review\u002FSKILL.md`\n","\u003C!-- story: e45s28 -->\n\n# Request Review\n\nDispatch fresh reviewer agents with clean contexts. Reviewers have no shared state — they find what the coding agent missed.\n\n## Target (argument)\n\nIf an argument was passed after `\u002Frequest-review` (e.g. `\u002Frequest-review abc1234` or `\u002Frequest-review HEAD~3..HEAD`), use it as the diff target when building the reviewer brief:\n\n```bash\ngit diff \u003Carg>        # range: abc..def, HEAD~3..HEAD\ngit show \u003Carg>        # single commit: abc1234\n```\n\nIf no argument was given, review uncommitted working-tree changes.\n\n**Distinct from `audit-code`:** `audit-code` is self-review (internal). This skill dispatches external agents.\n\n**Solo developer note:** Reviewer agents replace the human reviewer.\n\n**Run `audit-code` first.** Don't waste reviewer attention on hygiene issues you could have caught yourself.\n\n## Santa Method — Dual-Blind AND Gate (e45s07)\n\nUse **two independent reviewers** (Reviewer A and Reviewer B) with **no shared context** between them or the coding agent.\n\n| Parameter | Value |\n|-----------|-------|\n| Reviewers | 2 (mandatory) |\n| `MAX_REVIEW_ITERATIONS` | **5** (hard cap — e45s28; iteration 6 forbidden) |\n| Pass rule | **AND-gate** — both reviewers must pass independently |\n| Blindness | Neither reviewer sees the other's report until both complete |\n\n**Iteration loop (max `MAX_REVIEW_ITERATIONS`):**\n\n1. Dispatch Reviewer A and Reviewer B in parallel with identical briefs but separate contexts.\n2. Collect both reports. Each categorizes findings: must-fix \u002F should-fix \u002F consider.\n3. **AND-gate:** If **either** reviewer has must-fix findings → FAIL round. Run `respond-review`, fix, re-dispatch both reviewers.\n4. If both pass (zero must-fix, score ≥ 94% each) → review complete.\n5. After **5** iterations without dual pass → **stop**; report \"Review cap exhausted (5\u002F5). Human decision required.\" Do not merge.\n\n> **HARD GATE** — Single-reviewer pass is insufficient. Partial agreement does not satisfy the AND-gate.\n\n## Process\n\n### 1. Prepare the review brief\n\nWrite a self-contained brief for each reviewer. Include:\n\n- What was built (feature description, not implementation)\n- Which files changed (the diff context)\n- What `specs\u002F` artifacts are relevant (active `epics\u002FeNN-*.yaml`, `requirements\u002FSCOPE_LATEST.yaml`, `bugs\u002FBUG-*.md`)\n- What CONVENTIONS.md requires\n- What the verify command is\n- What you're most uncertain about (where you want fresh eyes)\n- **Security focus** — If the epic has a `specs\u002Fsecurity\u002Fepics\u002F\u003Cid>\u002FTHREAT_MODEL.md`, include the relevant vulnerability categories as reviewer focal points. Also include the false-positive exclusion rules so the reviewer avoids known-safe patterns. Tag the review as `security-sensitive: true` if THREAT_MODEL risk is HIGH+.\n\n### 2. Fan-out parallel reviewers (e45s17)\n\nBeyond the mandatory dual-blind pair (e45s07), optionally dispatch **N dimension-specific subagents in one message** — one check per agent for broader coverage (OpenAI Codex `code-review-*` pattern):\n\n| Agent | Focus |\n|-------|-------|\n| R-correctness | Logic, edge cases, verify command result |\n| R-conventions | CONVENTIONS.md, test quality (F.I.R.S.T) |\n| R-security | Injection, auth, secrets (when `security-sensitive`) |\n| R-design | Simpler alternatives, API shape |\n\nSanta Method still applies: each agent is blind; AND-gate uses Reviewer A + B scores. Fan-out agents feed findings into `respond-review` but do not replace the dual-blind pair.\n\n### 2b. Dispatch both reviewer agents (parallel)\n\nUse the Agent tool twice with completely fresh contexts. Each prompt must be self-contained — no references to \"our conversation\" or \"what we discussed.\"\n\n```\nYou are code reviewer [A|B]. Review the following code changes independently.\n\nContext: [feature description]\nCONVENTIONS.md rules: [paste relevant sections]\nActive epic shard: [paste or summarize from specs\u002Fepics\u002F]\n\nDiff: [paste git diff or describe changed files]\n\nVerify command: [runnable command]\n\nReview for:\n1. Correctness — does the code do what was intended?\n2. CONVENTIONS.md compliance — are all rules followed?\n3. Test quality — do tests verify behavior (not implementation)?\n4. Design — are there simpler or more robust approaches?\n5. Edge cases — what inputs or states could cause failures?\n6. Security — any injection, auth, or data exposure risks?\n7. Refactoring smells — explicitly name any detected Fowler smells: Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Message Chains, Middle Man\n\nFor each finding, categorize as: must-fix \u002F should-fix \u002F consider.\nRun the verify command and report the result.\n```\n\n### 3. Collect both reports\n\nWhen reviewers return:\n- Read every finding from **both** reports before acting on any\n- Note each verify command result\n- Compute quality score per reviewer: `100 × (total_items − must_fix − should_fix) \u002F total_items`\n- **AND-gate check:** both scores ≥ 94% and zero must-fix from **both**?\n\n> **HARD GATE** — If either score \u003C 94% or either has must-fix → FAIL round. Run `respond-review` first. The 94% threshold also applies to `npm run compliance` (scripts\u002Faudit-compliance.sh).\n\n### 4. Hand off to respond-review\n\nPass combined findings to `respond-review` to categorize and apply fixes. Increment iteration counter. Re-dispatch both reviewers until AND-gate passes or iteration 3 exhausted.\n\nReport to user: \"Review round [N\u002F3]. Reviewer A: [score], Reviewer B: [score]. AND-gate: [PASS|FAIL].\"\n\n## Verify\n\n→ verify: `test -f scripts\u002Flib\u002Fparallel-review-worktrees.sh && test -f skills\u002Frequest-review\u002FSKILL.md`\n",{"name":5,"model":35,"description":7,"disable-model-invocation":54},true,"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".gemini\u002Fextensions\u002Fbigpowers\u002Fskills\u002Frequest-review",24,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":54},[66,69,72],{"tool":67,"command":68},"npx","npx skills add danielvm-git\u002Fbigpowers --skill request-review",{"tool":70,"command":71},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill request-review",{"tool":73,"command":74},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill request-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.gemini\u002Fextensions\u002Fbigpowers\u002Fskills\u002Frequest-review\u002FSKILL.md",[],[78,97,104,133,156,177],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":87,"publishedAt":49},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[88,89,90,91,92,93,94,95,96],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"skillNo":98,"name":99,"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":100,"categories":101,"keywords":102,"publishedAt":49},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[103,93],"negative path",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":113,"publishedAt":49},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[110],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",[114,115,116,117,118,119,120,121,122,123,124,45,125,126,127,128,129,130,131,132],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","use","minimal","bold","sonnet","integrity","organize","sync","directory","guides",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":49},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[140,141,142,123,143,124,144,145,146,147,127,148,149,150,151,152,153,45,154,155],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"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":162,"publishedAt":49},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[163,164,165,166,167,168,169,170,171,172,173,123,174,95,140,127,175,176],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":190,"publishedAt":49},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[183,186,187],{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":188,"categoryName":189,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000033","数据分析师",[191,192,193,194,195,196,197,198,199,127,200,201,202,203,204,205,206,154,207,208],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","plan","browser","api","architecture","project status","http api"]