[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71M64KG1YA3G5M7FYYGZ1VM":3,"skill-same:01M71M64KG1YA3G5M7FYYGZ1VM":62},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":44,"ownerHtmlUrl":45,"ownerBlogUrl":46,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M71M64KG1YA3G5M7FYYGZ1VM","verification-quality",null,"Truth scoring and code quality verification with automatic rollback below a 0.95 confidence threshold, for checking agent output.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverification-quality\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33],"verification quality","verification","quality","code","scoring","automatic","code quality","for","output","with","rollback","2026-11-10 10:56:23",false,"---\nname: verification-quality\ndescription: \"Truth scoring and code quality verification with automatic rollback below a 0.95 confidence threshold, for checking agent output.\"\n---\n\n# verification-quality — Evidence Before Claims\n\n## Overview\n\nClaims without evidence are noise. \"It works\", \"tests pass\", \"I fixed it\" — none of\nthese mean anything until verified against the codebase, the test suite, and the build.\n\nThis skill wires four concepts to monomind's real command surface: **truth scoring**\n(a 0.0–1.0 confidence score from citable evidence), an **evidence-before-claims\nprotocol** (require `file:line`, test names, or build output before marking done),\n**auto-rollback** (regression detection via `analyze diff`, revert via git), and a\n**multi-angle quality workflow** (correctness, tests, security, performance, docs).\n\n**Core principle:** NO CLAIM IS TRUE UNTIL VERIFIED AGAINST EVIDENCE.\n\n**Iron Law:**\n```\nNO \"DONE\" WITHOUT A TRUTH SCORE ≥ 0.95 BACKED BY CITABLE EVIDENCE\n```\n\nIf you cannot point to a `file:line`, a passing test name, or a green build, you\nhave not finished. You have started.\n\n## When to Use\n\nUse for ANY task that ends in a claim of completion: \"I implemented X\", \"the bug is\nfixed\", \"tests pass\", \"ready to ship\", or any agent-returned work.\n\n**Use this ESPECIALLY when:** the agent (or you) is in a hurry — that's when false\nclaims slip in; the change touches security, money, auth, or data integrity; a\nprevious attempt already failed; you're about to commit, push, open a PR, or merge.\n\n**Don't skip when:** \"it's a tiny change\" (tiny changes break tests too) or \"I'm sure\"\n(confidence without evidence is the failure mode this skill prevents).\n\n## The Real Command Surface\n\nThese are the ONLY commands this skill wires to. Anything else is invented.\n\n| Command | What it does | Phase |\n|---|---|---|\n| `monomind analyze diff` | Git diff risk + change classification | Evidence, regression |\n| `monomind analyze code` | Static code analysis | Verification |\n| `monomind analyze deps --security` | Dependency CVEs | Verification |\n| `monomind analyze complexity` | Cyclomatic complexity | Verification |\n| `monomind analyze symbols` | Extract functions\u002Fclasses\u002Ftypes | Evidence |\n| `monomind analyze imports` | Import graph | Verification |\n| `monomind security scan` | Vulnerability + secret scan | Verification |\n| `monomind security secrets` | Dedicated secret detection | Verification |\n| `monomind security audit` | Security audit log | Verification |\n| `monomind performance benchmark` | Run benchmarks (wasm\u002Fmemory\u002Fsearch) | Evidence |\n| `monomind performance metrics` | View\u002Fexport metrics | Monitoring |\n| `monomind performance bottleneck` | Identify bottlenecks | Verification |\n| `monomind doctor` \u002F `doctor --fix` | 28 health-check categories | Baseline, monitoring |\n| `monomind hooks metrics` | Learning-hook metrics | Monitoring |\n| `monomind hooks intelligence` | Neural\u002FMoE\u002FHNSW status | Monitoring |\n| `monomind monograph search` | Knowledge graph search (BM25\u002Fsemantic\u002Fhybrid) | Evidence |\n| `monomind monograph build` | Build\u002Frebuild the knowledge graph | Baseline |\n| `monomind tokens dashboard` | Token spend | Monitoring |\n\n> Use `npx monomind@latest ...` from outside the repo; inside the repo\n> `node packages\u002F@monomind\u002Fcli\u002Fbin\u002Fcli.js ...` works too. **Never use `monomind@alpha`** —\n> it does not exist.\n\n### MCP tools (called by Claude Code, not the CLI)\n\n| Tool | Use |\n|---|---|\n| `mcp__monomind__hooks_pre-task` | Capture task intent + acceptance criteria before work |\n| `mcp__monomind__hooks_post-task` | Record outcome + evidence after work |\n| `mcp__monomind__monograph_query` | Find `file:line` for a symbol before citing it |\n| `mcp__monomind__monograph_impact` | Blast radius before risky edits |\n| `mcp__monomind__monograph_context` | 360° callers\u002Fcallees for the change site |\n| `mcp__monomind__system_health` | Snapshot system health before declaring done |\n| `mcp__monomind__system_metrics` | Objective metrics for the verification record |\n\n---\n\n## Core Concept: The Truth Score\n\nA truth score is a 0.0–1.0 confidence value derived from **evidence you can cite**,\nnot a feeling. The default ship threshold is **0.95**. The score is computed in\nPhase 3 from real command output; the action mapping lives in Phase 4. You do not\ninvent it.\n\n---\n\n## The Four Phases\n\nComplete each phase before moving on. Skipping a phase produces unverified claims.\n\n### Phase 1: Evidence Collection\n\nBEFORE claiming work is done, gather evidence it actually works.\n\n**1a. State the claim precisely:**\n> \"I claim X is done. Acceptance criteria: [list]. Evidence required: [list].\"\n\n**1b. Capture task intent (MCP) and cite the change site via the knowledge graph:**\n```\nmcp__monomind__hooks_pre-task({ task: \"...\", acceptance: [\"...\", \"...\"] })\nmcp__monomind__monograph_query(symbol: \"refreshToken\")     # cite before editing\nmcp__monomind__monograph_impact(file: \"src\u002Fauth\u002Frefresh.ts\")\n```\nEvery cited location must be `file:line`. \"Somewhere in auth\" is not a citation.\n\n**1c. Capture the diff as evidence:**\n```bash\nnpx monomind@latest analyze diff --risk --classify -v > evidence-diff.json\nnpx monomind@latest analyze imports src\u002Fauth --external    # import-graph blast radius\n```\n\n**Success criteria:** acceptance criteria written, diff classified on disk, every\nchanged symbol cited as `file:line`.\n\n---\n\n### Phase 2: Multi-Angle Verification\n\nRun each angle that applies. **All applicable angles must pass** or the truth score\ndrops. Skip an angle only when it genuinely does not apply (and say so).\n\n**Angle 1 — Correctness (always applies):**\n```bash\nnpx monomind@latest analyze code src\u002Fauth\u002F    # static analysis on touched paths\nnpm run build && npm run typecheck            # use the project's real commands\n```\n\n**Angle 2 — Tests (always applies when tests exist):**\n```bash\nnpm test -- --reporter=spec\n```\nThe evidence is **test names + counts**, not \"tests passed\".\n\n**Angle 3 — Security (applies to auth, crypto, input boundaries, deps):**\n```bash\nnpx monomind@latest security scan\nnpx monomind@latest security secrets\nnpx monomind@latest analyze deps --security\n```\n\n**Angle 4 — Performance (applies to hot paths, queries, bundles):**\n```bash\nnpx monomind@latest performance benchmark -s all -i 100 -o json > bench.json\nnpx monomind@latest performance bottleneck\nnpx monomind@latest analyze complexity src\u002Fauth\u002F -t 10\n```\n\n**Angle 5 — Documentation (applies to public APIs, behavior changes):**\n```bash\nnpx monomind@latest analyze symbols src\u002Fauth\u002Frefresh.ts   # did docs track changes?\n```\nIf exported symbols changed and docs didn't, this angle fails.\n\n**Angle 6 — System health:**\n```bash\nnpx monomind@latest doctor\n```\nA red doctor category blocks the claim, even if the code looks fine.\n\n---\n\n### Phase 3: Truth Score Computation\n\nScore each applicable angle — judgment against a checklist, not a vibe:\n\n| Angle | 1.0 (full) | 0.5 (partial) | 0.0 (fail\u002Fno evidence) |\n|---|---|---|---|\n| Correctness | Build + typecheck + analyze code clean | Typecheck clean, build warnings | Build or typecheck fails |\n| Tests | All relevant tests pass, names captured | New tests pass, one pre-existing flake | Any relevant test fails |\n| Security | `security scan`, `secrets`, `deps --security` clean | One informational finding, no exploit path | Any HIGH\u002FCRITICAL or leaked secret |\n| Performance | Benchmark within baseline, no new hotspot | Within ±5% of baseline | Regression vs. baseline |\n| Documentation | All changed symbols documented | Minor export undocumented | Public API change with no doc update |\n| System health | `doctor` green | Yellows acknowledged | Any red category |\n\n**Composite score formula:**\n```\ntruth_score = (sum of angle scores) \u002F (number of applicable angles)\n```\n\nA failing angle zeroes its row. **Any 0.0 angle caps the composite at 0.85** —\ncritical findings always block shipping regardless of the average.\n\nWrite the score and per-angle evidence to the task record:\n```\nmcp__monomind__hooks_post-task({\n  task: \"Fix auth refresh race\", outcome: \"complete\", truth_score: 0.96,\n  evidence: {\n    diff: \"evidence-diff.json\",\n    tests: \"auth.test.ts: 42 passed, 0 failed\",\n    security: \"scan clean; deps --security 0 HIGH\",\n    performance: \"benchmark within 1.2% of baseline\",\n    health: \"doctor green\",\n    citations: [\"src\u002Fauth\u002Frefresh.ts:87\", \"src\u002Fauth\u002Frefresh.ts:134\"]\n  }\n})\n```\n\n---\n\n### Phase 4: Decision — Ship, Fix, or Rollback\n\nUse the composite score from Phase 3:\n\n| Score | Decision | Required action |\n|---|---|---|\n| `≥ 0.95` | **Ship** | Record evidence via `hooks_post-task`; proceed to commit\u002FPR |\n| `0.85–0.94` | **Ship with caveats** | Record the gaps explicitly in the PR description |\n| `0.75–0.84` | **Fix** | Return to Phase 1 with the failing angle as the new task |\n| `\u003C 0.75` | **Rollback** | See Auto-Rollback below; do not leave broken code on the branch |\n\n**3 or more fix loops without reaching 0.95 → architectural problem.** Stop, discuss\nwith the user. Do not attempt a 4th loop. (Same rule as `mastermind-debug` Phase 4.5.)\n\n---\n\n## Methodology: Auto-Rollback\n\nWhen a change scores below 0.75, or a regression is detected after merge, revert.\nmonomind does not have a magic `verify rollback` subcommand — rollback is **git +\nevidence from `analyze diff`**.\n\n**1. Confirm the regression is real:**\n```bash\nnpx monomind@latest analyze diff --risk -v              # was it high-risk at review?\nnpx monomind@latest analyze complexity src\u002F -t 15 -f json\nnpx monomind@latest performance benchmark -s all -i 100 -o json > now.json\n# diff now.json against the saved baseline\n```\n\n**2. Roll back to the last known-good state:**\n```bash\ngit log --oneline -10\ngit revert \u003Cbad-commit> --no-edit          # preserves the diagnosis in history\n# or, if nothing downstream depends on it:\ngit reset --hard \u003Clast-good-commit>\n```\n\n**3. Prevent recurrence:**\n```bash\n# Add a regression test for the failure mode BEFORE re-attempting (see mastermind-debug Phase 4)\nnpx monomind@latest doctor                  # re-verify the rolled-back state\nnpx monomind@latest security scan\n```\n\n**Rules:**\n- Never rollback silently — record what failed and why in the postmortem.\n- Selective rollback (revert one file, keep another) is fine **if** `analyze diff`\n  shows the changes are independent. Otherwise revert as a unit.\n- Always re-verify the rolled-back state passes the failing angle.\n\n---\n\n## Methodology: CI\u002FCD Integration\n\nWire the same four phases into CI so unverified work cannot merge.\n\n**GitHub Action — quality gate on PRs:**\n```yaml\nname: Quality Verification\non: [pull_request]\njobs:\n  verify:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n        with: { fetch-depth: 0 }   # analyze diff needs history\n      - run: npm ci\n      - name: Build + typecheck + tests   # Angle 1 + 2\n        run: |\n          npm run build\n          npm run typecheck\n          npm test\n      - name: Diff risk + security        # Angle 3\n        run: |\n          npx monomind@latest analyze diff main..HEAD --risk --classify --format json > diff-risk.json\n          npx monomind@latest security scan\n          npx monomind@latest analyze deps --security\n      - name: Health + benchmark          # Angle 4 + 6\n        run: |\n          npx monomind@latest doctor\n          npx monomind@latest performance benchmark -s all -i 50 -o json > bench.json\n      - uses: actions\u002Fupload-artifact@v4\n        with: { name: verification-evidence, path: \"diff-risk.json\\nbench.json\" }\n```\n\n> Prefer **risk classification** (qualitative, stable) over **hard latency thresholds**\n> (fragile, flaky) for the gate. Use metrics for trend analysis offline.\n\n---\n\n## Methodology: Continuous Monitoring\n\nVerification is not just a PR gate. Keep watching after merge:\n\n```bash\nnpx monomind@latest doctor                                          # daily health\nnpx monomind@latest performance metrics -t 7d -f json > \"metrics-$(date +%Y%m%d).json\"\nnpx monomind@latest hooks metrics                                   # what hooks learned\nnpx monomind@latest hooks intelligence                              # neural\u002FHNSW status (usually not-loaded)\nnpx monomind@latest tokens dashboard -p week --no-interactive       # spend surprises → quality problems\n```\n\nFor long-term storage, pipe `performance metrics -f prometheus` into Prometheus and\nalert on trend, not on single values.\n\n---\n\n## Red Flags — STOP and Return to Phase 1\n\n| Thought \u002F Action | What it means |\n|---|---|\n| \"It works\" with no test names or file:line | No evidence. Phase 1. |\n| \"Tests pass\" with no output captured | Untested claim. Re-run and capture. |\n| \"It's a tiny change, skip verification\" | Tiny changes break tests too. Phase 2. |\n| \"Security probably isn't affected\" | Probably ≠ verified. If auth\u002Fcrypto\u002Finput touched, run `security scan`. |\n| \"Performance feels fine\" | Feeling is not measurement. Run `performance benchmark`. |\n| Skipping an angle without saying why | Silent skips are how bugs ship. State \"N\u002FA because…\". |\n| \"Doctor has a red but it's unrelated\" | Verify the unrelated-ness, don't assume. |\n| 3+ fix loops, still \u003C 0.95 | Architectural problem. Stop, discuss design. |\n| Merging with score 0.85 \"to unblock\" | Below threshold is below threshold. Fix the gap. |\n| \"The agent said it's done\" \u002F \"it compiled\" | Agent claims and clean compiles are inputs to verify, not conclusions. |\n\n---\n\n## Related Skills\n\n- [`mastermind-debug`](..\u002Fmastermind-debug\u002FSKILL.md) — root-cause methodology when verification finds a failure; Phase 4 covers failing-test-first evidence collection\n- [`performance-analysis`](..\u002Fperformance-analysis\u002FSKILL.md) — Phase 2 Angle 4 deep-dive (pack extras — `monomind packs add extras`)\n- [`mastermind-receive-review`](..\u002Fmastermind-receive-review\u002FSKILL.md) — same rigor applied to incoming review feedback\n- [`swarm-orchestration`](..\u002Fswarm-orchestration\u002FSKILL.md) — every agent output runs through Phase 1–4 before merge\n\n## Quick Reference\n\n| Phase | Key commands | Success criteria |\n|---|---|---|\n| **1. Evidence** | `analyze diff --risk`, `monograph query\u002Fimpact`, `hooks_pre-task` | Acceptance criteria + cited `file:line` on disk |\n| **2. Verification** | `analyze code`, `security scan`, `performance benchmark`, `analyze complexity`, `doctor` | Every applicable angle scored |\n| **3. Truth score** | Composite formula above | Numeric score + per-angle evidence recorded via `hooks_post-task` |\n| **4. Decision** | `git` (rollback when `\u003C 0.75`) | Ship ≥ 0.95, fix 0.75–0.94, rollback `\u003C 0.75` |\n\n---\n\n**Version**: 2.0.0 · **Last Updated**: 2026-08-12\n","# verification-quality — Evidence Before Claims\n\n## Overview\n\nClaims without evidence are noise. \"It works\", \"tests pass\", \"I fixed it\" — none of\nthese mean anything until verified against the codebase, the test suite, and the build.\n\nThis skill wires four concepts to monomind's real command surface: **truth scoring**\n(a 0.0–1.0 confidence score from citable evidence), an **evidence-before-claims\nprotocol** (require `file:line`, test names, or build output before marking done),\n**auto-rollback** (regression detection via `analyze diff`, revert via git), and a\n**multi-angle quality workflow** (correctness, tests, security, performance, docs).\n\n**Core principle:** NO CLAIM IS TRUE UNTIL VERIFIED AGAINST EVIDENCE.\n\n**Iron Law:**\n```\nNO \"DONE\" WITHOUT A TRUTH SCORE ≥ 0.95 BACKED BY CITABLE EVIDENCE\n```\n\nIf you cannot point to a `file:line`, a passing test name, or a green build, you\nhave not finished. You have started.\n\n## When to Use\n\nUse for ANY task that ends in a claim of completion: \"I implemented X\", \"the bug is\nfixed\", \"tests pass\", \"ready to ship\", or any agent-returned work.\n\n**Use this ESPECIALLY when:** the agent (or you) is in a hurry — that's when false\nclaims slip in; the change touches security, money, auth, or data integrity; a\nprevious attempt already failed; you're about to commit, push, open a PR, or merge.\n\n**Don't skip when:** \"it's a tiny change\" (tiny changes break tests too) or \"I'm sure\"\n(confidence without evidence is the failure mode this skill prevents).\n\n## The Real Command Surface\n\nThese are the ONLY commands this skill wires to. Anything else is invented.\n\n| Command | What it does | Phase |\n|---|---|---|\n| `monomind analyze diff` | Git diff risk + change classification | Evidence, regression |\n| `monomind analyze code` | Static code analysis | Verification |\n| `monomind analyze deps --security` | Dependency CVEs | Verification |\n| `monomind analyze complexity` | Cyclomatic complexity | Verification |\n| `monomind analyze symbols` | Extract functions\u002Fclasses\u002Ftypes | Evidence |\n| `monomind analyze imports` | Import graph | Verification |\n| `monomind security scan` | Vulnerability + secret scan | Verification |\n| `monomind security secrets` | Dedicated secret detection | Verification |\n| `monomind security audit` | Security audit log | Verification |\n| `monomind performance benchmark` | Run benchmarks (wasm\u002Fmemory\u002Fsearch) | Evidence |\n| `monomind performance metrics` | View\u002Fexport metrics | Monitoring |\n| `monomind performance bottleneck` | Identify bottlenecks | Verification |\n| `monomind doctor` \u002F `doctor --fix` | 28 health-check categories | Baseline, monitoring |\n| `monomind hooks metrics` | Learning-hook metrics | Monitoring |\n| `monomind hooks intelligence` | Neural\u002FMoE\u002FHNSW status | Monitoring |\n| `monomind monograph search` | Knowledge graph search (BM25\u002Fsemantic\u002Fhybrid) | Evidence |\n| `monomind monograph build` | Build\u002Frebuild the knowledge graph | Baseline |\n| `monomind tokens dashboard` | Token spend | Monitoring |\n\n> Use `npx monomind@latest ...` from outside the repo; inside the repo\n> `node packages\u002F@monomind\u002Fcli\u002Fbin\u002Fcli.js ...` works too. **Never use `monomind@alpha`** —\n> it does not exist.\n\n### MCP tools (called by Claude Code, not the CLI)\n\n| Tool | Use |\n|---|---|\n| `mcp__monomind__hooks_pre-task` | Capture task intent + acceptance criteria before work |\n| `mcp__monomind__hooks_post-task` | Record outcome + evidence after work |\n| `mcp__monomind__monograph_query` | Find `file:line` for a symbol before citing it |\n| `mcp__monomind__monograph_impact` | Blast radius before risky edits |\n| `mcp__monomind__monograph_context` | 360° callers\u002Fcallees for the change site |\n| `mcp__monomind__system_health` | Snapshot system health before declaring done |\n| `mcp__monomind__system_metrics` | Objective metrics for the verification record |\n\n---\n\n## Core Concept: The Truth Score\n\nA truth score is a 0.0–1.0 confidence value derived from **evidence you can cite**,\nnot a feeling. The default ship threshold is **0.95**. The score is computed in\nPhase 3 from real command output; the action mapping lives in Phase 4. You do not\ninvent it.\n\n---\n\n## The Four Phases\n\nComplete each phase before moving on. Skipping a phase produces unverified claims.\n\n### Phase 1: Evidence Collection\n\nBEFORE claiming work is done, gather evidence it actually works.\n\n**1a. State the claim precisely:**\n> \"I claim X is done. Acceptance criteria: [list]. Evidence required: [list].\"\n\n**1b. Capture task intent (MCP) and cite the change site via the knowledge graph:**\n```\nmcp__monomind__hooks_pre-task({ task: \"...\", acceptance: [\"...\", \"...\"] })\nmcp__monomind__monograph_query(symbol: \"refreshToken\")     # cite before editing\nmcp__monomind__monograph_impact(file: \"src\u002Fauth\u002Frefresh.ts\")\n```\nEvery cited location must be `file:line`. \"Somewhere in auth\" is not a citation.\n\n**1c. Capture the diff as evidence:**\n```bash\nnpx monomind@latest analyze diff --risk --classify -v > evidence-diff.json\nnpx monomind@latest analyze imports src\u002Fauth --external    # import-graph blast radius\n```\n\n**Success criteria:** acceptance criteria written, diff classified on disk, every\nchanged symbol cited as `file:line`.\n\n---\n\n### Phase 2: Multi-Angle Verification\n\nRun each angle that applies. **All applicable angles must pass** or the truth score\ndrops. Skip an angle only when it genuinely does not apply (and say so).\n\n**Angle 1 — Correctness (always applies):**\n```bash\nnpx monomind@latest analyze code src\u002Fauth\u002F    # static analysis on touched paths\nnpm run build && npm run typecheck            # use the project's real commands\n```\n\n**Angle 2 — Tests (always applies when tests exist):**\n```bash\nnpm test -- --reporter=spec\n```\nThe evidence is **test names + counts**, not \"tests passed\".\n\n**Angle 3 — Security (applies to auth, crypto, input boundaries, deps):**\n```bash\nnpx monomind@latest security scan\nnpx monomind@latest security secrets\nnpx monomind@latest analyze deps --security\n```\n\n**Angle 4 — Performance (applies to hot paths, queries, bundles):**\n```bash\nnpx monomind@latest performance benchmark -s all -i 100 -o json > bench.json\nnpx monomind@latest performance bottleneck\nnpx monomind@latest analyze complexity src\u002Fauth\u002F -t 10\n```\n\n**Angle 5 — Documentation (applies to public APIs, behavior changes):**\n```bash\nnpx monomind@latest analyze symbols src\u002Fauth\u002Frefresh.ts   # did docs track changes?\n```\nIf exported symbols changed and docs didn't, this angle fails.\n\n**Angle 6 — System health:**\n```bash\nnpx monomind@latest doctor\n```\nA red doctor category blocks the claim, even if the code looks fine.\n\n---\n\n### Phase 3: Truth Score Computation\n\nScore each applicable angle — judgment against a checklist, not a vibe:\n\n| Angle | 1.0 (full) | 0.5 (partial) | 0.0 (fail\u002Fno evidence) |\n|---|---|---|---|\n| Correctness | Build + typecheck + analyze code clean | Typecheck clean, build warnings | Build or typecheck fails |\n| Tests | All relevant tests pass, names captured | New tests pass, one pre-existing flake | Any relevant test fails |\n| Security | `security scan`, `secrets`, `deps --security` clean | One informational finding, no exploit path | Any HIGH\u002FCRITICAL or leaked secret |\n| Performance | Benchmark within baseline, no new hotspot | Within ±5% of baseline | Regression vs. baseline |\n| Documentation | All changed symbols documented | Minor export undocumented | Public API change with no doc update |\n| System health | `doctor` green | Yellows acknowledged | Any red category |\n\n**Composite score formula:**\n```\ntruth_score = (sum of angle scores) \u002F (number of applicable angles)\n```\n\nA failing angle zeroes its row. **Any 0.0 angle caps the composite at 0.85** —\ncritical findings always block shipping regardless of the average.\n\nWrite the score and per-angle evidence to the task record:\n```\nmcp__monomind__hooks_post-task({\n  task: \"Fix auth refresh race\", outcome: \"complete\", truth_score: 0.96,\n  evidence: {\n    diff: \"evidence-diff.json\",\n    tests: \"auth.test.ts: 42 passed, 0 failed\",\n    security: \"scan clean; deps --security 0 HIGH\",\n    performance: \"benchmark within 1.2% of baseline\",\n    health: \"doctor green\",\n    citations: [\"src\u002Fauth\u002Frefresh.ts:87\", \"src\u002Fauth\u002Frefresh.ts:134\"]\n  }\n})\n```\n\n---\n\n### Phase 4: Decision — Ship, Fix, or Rollback\n\nUse the composite score from Phase 3:\n\n| Score | Decision | Required action |\n|---|---|---|\n| `≥ 0.95` | **Ship** | Record evidence via `hooks_post-task`; proceed to commit\u002FPR |\n| `0.85–0.94` | **Ship with caveats** | Record the gaps explicitly in the PR description |\n| `0.75–0.84` | **Fix** | Return to Phase 1 with the failing angle as the new task |\n| `\u003C 0.75` | **Rollback** | See Auto-Rollback below; do not leave broken code on the branch |\n\n**3 or more fix loops without reaching 0.95 → architectural problem.** Stop, discuss\nwith the user. Do not attempt a 4th loop. (Same rule as `mastermind-debug` Phase 4.5.)\n\n---\n\n## Methodology: Auto-Rollback\n\nWhen a change scores below 0.75, or a regression is detected after merge, revert.\nmonomind does not have a magic `verify rollback` subcommand — rollback is **git +\nevidence from `analyze diff`**.\n\n**1. Confirm the regression is real:**\n```bash\nnpx monomind@latest analyze diff --risk -v              # was it high-risk at review?\nnpx monomind@latest analyze complexity src\u002F -t 15 -f json\nnpx monomind@latest performance benchmark -s all -i 100 -o json > now.json\n# diff now.json against the saved baseline\n```\n\n**2. Roll back to the last known-good state:**\n```bash\ngit log --oneline -10\ngit revert \u003Cbad-commit> --no-edit          # preserves the diagnosis in history\n# or, if nothing downstream depends on it:\ngit reset --hard \u003Clast-good-commit>\n```\n\n**3. Prevent recurrence:**\n```bash\n# Add a regression test for the failure mode BEFORE re-attempting (see mastermind-debug Phase 4)\nnpx monomind@latest doctor                  # re-verify the rolled-back state\nnpx monomind@latest security scan\n```\n\n**Rules:**\n- Never rollback silently — record what failed and why in the postmortem.\n- Selective rollback (revert one file, keep another) is fine **if** `analyze diff`\n  shows the changes are independent. Otherwise revert as a unit.\n- Always re-verify the rolled-back state passes the failing angle.\n\n---\n\n## Methodology: CI\u002FCD Integration\n\nWire the same four phases into CI so unverified work cannot merge.\n\n**GitHub Action — quality gate on PRs:**\n```yaml\nname: Quality Verification\non: [pull_request]\njobs:\n  verify:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n        with: { fetch-depth: 0 }   # analyze diff needs history\n      - run: npm ci\n      - name: Build + typecheck + tests   # Angle 1 + 2\n        run: |\n          npm run build\n          npm run typecheck\n          npm test\n      - name: Diff risk + security        # Angle 3\n        run: |\n          npx monomind@latest analyze diff main..HEAD --risk --classify --format json > diff-risk.json\n          npx monomind@latest security scan\n          npx monomind@latest analyze deps --security\n      - name: Health + benchmark          # Angle 4 + 6\n        run: |\n          npx monomind@latest doctor\n          npx monomind@latest performance benchmark -s all -i 50 -o json > bench.json\n      - uses: actions\u002Fupload-artifact@v4\n        with: { name: verification-evidence, path: \"diff-risk.json\\nbench.json\" }\n```\n\n> Prefer **risk classification** (qualitative, stable) over **hard latency thresholds**\n> (fragile, flaky) for the gate. Use metrics for trend analysis offline.\n\n---\n\n## Methodology: Continuous Monitoring\n\nVerification is not just a PR gate. Keep watching after merge:\n\n```bash\nnpx monomind@latest doctor                                          # daily health\nnpx monomind@latest performance metrics -t 7d -f json > \"metrics-$(date +%Y%m%d).json\"\nnpx monomind@latest hooks metrics                                   # what hooks learned\nnpx monomind@latest hooks intelligence                              # neural\u002FHNSW status (usually not-loaded)\nnpx monomind@latest tokens dashboard -p week --no-interactive       # spend surprises → quality problems\n```\n\nFor long-term storage, pipe `performance metrics -f prometheus` into Prometheus and\nalert on trend, not on single values.\n\n---\n\n## Red Flags — STOP and Return to Phase 1\n\n| Thought \u002F Action | What it means |\n|---|---|\n| \"It works\" with no test names or file:line | No evidence. Phase 1. |\n| \"Tests pass\" with no output captured | Untested claim. Re-run and capture. |\n| \"It's a tiny change, skip verification\" | Tiny changes break tests too. Phase 2. |\n| \"Security probably isn't affected\" | Probably ≠ verified. If auth\u002Fcrypto\u002Finput touched, run `security scan`. |\n| \"Performance feels fine\" | Feeling is not measurement. Run `performance benchmark`. |\n| Skipping an angle without saying why | Silent skips are how bugs ship. State \"N\u002FA because…\". |\n| \"Doctor has a red but it's unrelated\" | Verify the unrelated-ness, don't assume. |\n| 3+ fix loops, still \u003C 0.95 | Architectural problem. Stop, discuss design. |\n| Merging with score 0.85 \"to unblock\" | Below threshold is below threshold. Fix the gap. |\n| \"The agent said it's done\" \u002F \"it compiled\" | Agent claims and clean compiles are inputs to verify, not conclusions. |\n\n---\n\n## Related Skills\n\n- [`mastermind-debug`](..\u002Fmastermind-debug\u002FSKILL.md) — root-cause methodology when verification finds a failure; Phase 4 covers failing-test-first evidence collection\n- [`performance-analysis`](..\u002Fperformance-analysis\u002FSKILL.md) — Phase 2 Angle 4 deep-dive (pack extras — `monomind packs add extras`)\n- [`mastermind-receive-review`](..\u002Fmastermind-receive-review\u002FSKILL.md) — same rigor applied to incoming review feedback\n- [`swarm-orchestration`](..\u002Fswarm-orchestration\u002FSKILL.md) — every agent output runs through Phase 1–4 before merge\n\n## Quick Reference\n\n| Phase | Key commands | Success criteria |\n|---|---|---|\n| **1. Evidence** | `analyze diff --risk`, `monograph query\u002Fimpact`, `hooks_pre-task` | Acceptance criteria + cited `file:line` on disk |\n| **2. Verification** | `analyze code`, `security scan`, `performance benchmark`, `analyze complexity`, `doctor` | Every applicable angle scored |\n| **3. Truth score** | Composite formula above | Numeric score + per-angle evidence recorded via `hooks_post-task` |\n| **4. Decision** | `git` (rollback when `\u003C 0.75`) | Ship ≥ 0.95, fix 0.75–0.94, rollback `\u003C 0.75` |\n\n---\n\n**Version**: 2.0.0 · **Last Updated**: 2026-08-12\n",{"name":5,"description":7},"main","f7cd4595d0f8959822163e14f9787117765c931a",".claude\u002Fskills\u002Fverification-quality",2,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-10 01:53:48",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add monoes\u002Fmonomind --skill verification-quality",{"tool":54,"command":55},"bunx","bunx skills add monoes\u002Fmonomind --skill verification-quality",{"tool":57,"command":58},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill verification-quality","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverification-quality\u002FSKILL.md",true,[],[63,91,125,152,175,200],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":90},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward","Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","knowledge","impact","query","snark","review","monomind","security review","stark","zettelkasten","cryptography","security","org","blockchain","2026-11-10 13:02:02",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":95,"licenseFileUrl":96,"sourceHtmlUrl":97,"categories":98,"keywords":107,"publishedAt":90},"01M71PB18SDG28WBKPKJNB814K","writing-plans","Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.","MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FSKILL.md",[99,102],{"categoryNo":100,"categoryName":101,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[108,109,110,74,111,112,113,114,79,26,115,116,117,118,119,120,121,122,123,124],"writing","writing plans","plans","superpowers","implementation plan","when","you","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":129,"sourceHtmlUrl":130,"categories":131,"keywords":135,"publishedAt":90},"01M71PAXFM488X9ARXK0T04TF5","write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",[132],{"categoryNo":133,"categoryName":134,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000031","产品经理",[118,136,137,138,139,77,140,113,141,142,143,117,144,145,146,147,148,149,150,151],"write spec","spec","user request","problem","acceptance","ask","vague","work","request","scoping","idea","metrics","feature","problem statement","use","document",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":156,"sourceHtmlUrl":157,"categories":158,"keywords":162,"publishedAt":90},"01M71PASSZY800C0RPEARBS918","write-query","Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000033","数据分析师",[79,118,163,164,30,165,77,150,113,166,167,32,168,143,169,170,171,172,173,174],"write query","postgres","snowflake","best practices","natural-language","multi","github","sql","https","syntax","plugins","data",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":185,"publishedAt":90},"01M71PAPTX0T3PF6ETFVR96SJJ","workflow-automation","Org role guidance for workflow automation: build and maintain CI\u002FCD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-automation\u002FSKILL.md",[181,184],{"categoryNo":182,"categoryName":183,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[186,187,188,189,30,190,191,192,193,78,194,195,196,79,82,169,197,198,199,171],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":207,"publishedAt":90},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[206],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[188,208,209,210,211,212,213,30,214,215,26,216,217,218,82,169,219,220,171,221],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems"]