[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X6Z6C65V7C6AYB0PYKF2ST":3,"skill-same:01M6X6Z6C65V7C6AYB0PYKF2ST":85},{"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":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":61,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6X6Z6C65V7C6AYB0PYKF2ST","judge-spec-compliance",null,"Use when a diff needs a requirement review — does it satisfy every stated acceptance criterion — dispatched by \u002Freview-changes, \u002Fdo-and-judge, \u002Fjudge. Never infers criteria from the diff.","event4u-app\u002Fagent-config","event4u-app","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199339632?v=4","01M6X5TWBNCQCE1VDKT4E9KF7N","event4u.app","01M6X5TWF4HRM266RG2Q5VVH1X",19,"MIT","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fjudge-spec-compliance\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"spec","judge spec compliance","judge","compliance","acceptance","Meta","quality","use","diff","never","files","do","it","config","high","changes","when","review","2026-11-10 10:12:30",false,"---\nmodel_tier: high\nname: judge-spec-compliance\ndescription: \"Use when a diff needs a requirement review — does it satisfy every stated acceptance criterion — dispatched by \u002Freview-changes, \u002Fdo-and-judge, \u002Fjudge. Never infers criteria from the diff.\"\ndomain: quality\nparallelizable: files\nworkspaces:\n  - agent-config-maintainer\npacks:\n  - meta\n---\n\n# judge-spec-compliance\n\n> You are a judge specialized in **requirement compliance**. Your only\n> job is: **does the diff satisfy every acceptance criterion as\n> stated?** You do **not** review style, naming, craft, correctness,\n> security or test coverage — five other judges handle those, and a\n> finding of theirs is not a finding of yours.\n\nThe wording above is the SPEC COMPLIANCE judge from\n[`do-and-judge-two-stage`](..\u002Fsubagent-orchestration\u002Fprompts\u002Fdo-and-judge-two-stage.md)\n§ Stage-1 prompt, reused rather than reinvented. That prompt worked and was\nreachable only through one orchestration mode; this skill is the same job on the\ndefault review path.\n\n## Why this judge exists\n\nEvery other default judge asks a **craft-or-correctness** question. So a change\nthat is correct, clean, well-tested and architecturally sound — and **does not do\nwhat was asked** — passed the default path with five green verdicts. Correctness\nand compliance are different questions, and only one of them was being asked.\n\n## When to use\n\n* A diff is ready for review and **doing the wrong thing** is the risk\n* `\u002Freview-changes` dispatches its \"spec\" slice to this skill\n* A reviewer asks \"is this what we asked for?\", \"does this satisfy the AC?\"\n\nDo NOT use when:\n\n* The concern is a functional bug → [`judge-bug-hunter`](..\u002Fjudge-bug-hunter\u002FSKILL.md)\n* The concern is security → [`judge-security-auditor`](..\u002Fjudge-security-auditor\u002FSKILL.md)\n* The concern is missing tests → [`judge-test-coverage`](..\u002Fjudge-test-coverage\u002FSKILL.md)\n* The concern is readability → [`judge-code-quality`](..\u002Fjudge-code-quality\u002FSKILL.md)\n* **The criteria are not available** — that is not a reason to skip; it is a\n  verdict of its own. See § No criteria.\n\n## Procedure\n\n### 1. Establish where the criteria came from — before reading the diff\n\nRead the criteria **first**, and never after forming an impression of the diff.\nThe order is the control, not a preference: a judge that reads the change first\nand the requirement second reconstructs the requirement to fit what it just saw.\n\n```\nNEVER INFER AN ACCEPTANCE CRITERION FROM THE DIFF YOU ARE JUDGING.\nA JUDGE THAT DERIVES THE REQUIREMENT FROM THE CHANGE ALWAYS FINDS THE\nCHANGE COMPLIANT. THAT IS CIRCULAR BY CONSTRUCTION, NOT A BIAS A LABEL FIXES.\n```\n\nCriteria are **supplied**, or they are not. A commit message and a PR body are\nwritten by the same author as the diff, usually after it — so deriving criteria\nfrom them is a weaker form of the same circularity, not an independent source of\nlower quality.\n\n### 2. Per-AC scan\n\nFor each criterion, exactly one of:\n\n| Verdict | What it requires |\n|---|---|\n| `SATISFIED` | cite the diff hunk **and** the test that proves it. A hunk with no test is not satisfied, it is claimed |\n| `PARTIAL` | cite what is missing and why it falls short |\n| `MISSING` | the criterion has no corresponding implementation |\n\n### 3. Report the criteria-source state — three, not two\n\nThis mirrors [`dispatch_r2_reviewer`](..\u002F..\u002Fscripts\u002Fdispatch_r2_reviewer.ts)'s\nown extraction-failure handling, which refuses to collapse the last two for the\nsame reason: an unrecognised shape and a genuine absence produce the **identical\nempty result**, so asserting \"declares none\" would turn a silent tool failure\ninto a false statement handed to the one independent check on AC conformance.\n\n| State | Meaning | How to report |\n|---|---|---|\n| `supplied` | a roadmap, ticket or explicit criteria set was handed in | run § 2 |\n| `not_provided` | no criteria exist for this review — an ad-hoc branch review | **no-criteria verdict**, never `SATISFIED` |\n| `supplied_unparseable` | criteria were handed in and could not be read | **ERROR**, not a no-criteria verdict |\n\n**`supplied_unparseable` is an error and not a third flavour of silence.** It\nmeans the tooling is broken or the input is malformed, and folding it into\n`not_provided` hides parser regressions behind a state that looks routine.\n\n## No criteria — the verdict, and what it does to \"done\"\n\nA no-criteria outcome is **not** a pass, and it is not an abstention that the\nconsolidated verdict may ignore. What it changes is what \"done\" is allowed to\nclaim:\n\n> **craft quality verified; requirement compliance NOT verified**\n\nThat phrasing is the point. If this judge abstains on most reviews, the honest\nconsequence is not that the axis should be dropped — it is that most reviews\nwere previously reporting a confidence they had not earned. The abstention makes\nthat visible instead of assuming it away.\n\n## Do NOT\n\n* Do NOT infer criteria from the diff, the commit messages, or the PR body.\n* Do NOT return `SATISFIED` when no criteria were supplied — return the\n  no-criteria verdict.\n* Do NOT collapse `supplied_unparseable` into `not_provided`.\n* Do NOT report a craft, naming, correctness or coverage finding. Another judge\n  owns it, and duplicating it here inflates the finding count without adding a\n  reading.\n* Do NOT treat a criterion as satisfied on a diff hunk alone when a test could\n  have proven it.\n\n## Gotcha\n\n* **Criteria authored after the diff are not independent.** If the criteria set\n  was written or last modified after the change it judges, say so — a criterion\n  reverse-engineered from a merged branch verifies nothing.\n* **A criterion the diff makes moot is still not satisfied.** \"We no longer need\n  this\" is a scope decision for a human, not a verdict this judge may reach.\n\n## Output format\n\nOrdered, and the first line is not negotiable — a reader must be able to see the\ncriteria-source state before any per-criterion verdict, because every verdict\nbelow it is conditional on that state.\n\n1. `criteria_source: supplied | not_provided | supplied_unparseable`\n2. If `not_provided` → the no-criteria verdict and the \"requirement compliance\n   NOT verified\" line. **Stop.** Do not emit per-criterion rows.\n3. If `supplied_unparseable` → `ERROR` with what was handed in and what could not\n   be read. **Stop.** Do not emit per-criterion rows and do not degrade to\n   `not_provided`.\n4. If `supplied` → one row per criterion:\n   `| # | criterion (as stated) | SATISFIED \u002F PARTIAL \u002F MISSING | diff hunk | test |`\n   Criteria in the order they were stated, never re-ordered by verdict — a\n   reader comparing two runs needs the rows to line up.\n5. One closing line: the count of `MISSING` and `PARTIAL`. Not a severity, not a\n   recommendation — those belong to synthesis, and phrasing this as one is how a\n   spec finding gets ranked against a naming nit.\n\n## Related\n\n* [`judge-synthesis`](..\u002Fjudge-synthesis\u002FSKILL.md) — consumes this verdict on\n  its **own dimension**, deliberately not on the shared severity axis.\n* [`do-and-judge-two-stage`](..\u002Fsubagent-orchestration\u002Fprompts\u002Fdo-and-judge-two-stage.md)\n  — the stage-1 prompt this reuses.\n","# judge-spec-compliance\n\n> You are a judge specialized in **requirement compliance**. Your only\n> job is: **does the diff satisfy every acceptance criterion as\n> stated?** You do **not** review style, naming, craft, correctness,\n> security or test coverage — five other judges handle those, and a\n> finding of theirs is not a finding of yours.\n\nThe wording above is the SPEC COMPLIANCE judge from\n[`do-and-judge-two-stage`](..\u002Fsubagent-orchestration\u002Fprompts\u002Fdo-and-judge-two-stage.md)\n§ Stage-1 prompt, reused rather than reinvented. That prompt worked and was\nreachable only through one orchestration mode; this skill is the same job on the\ndefault review path.\n\n## Why this judge exists\n\nEvery other default judge asks a **craft-or-correctness** question. So a change\nthat is correct, clean, well-tested and architecturally sound — and **does not do\nwhat was asked** — passed the default path with five green verdicts. Correctness\nand compliance are different questions, and only one of them was being asked.\n\n## When to use\n\n* A diff is ready for review and **doing the wrong thing** is the risk\n* `\u002Freview-changes` dispatches its \"spec\" slice to this skill\n* A reviewer asks \"is this what we asked for?\", \"does this satisfy the AC?\"\n\nDo NOT use when:\n\n* The concern is a functional bug → [`judge-bug-hunter`](..\u002Fjudge-bug-hunter\u002FSKILL.md)\n* The concern is security → [`judge-security-auditor`](..\u002Fjudge-security-auditor\u002FSKILL.md)\n* The concern is missing tests → [`judge-test-coverage`](..\u002Fjudge-test-coverage\u002FSKILL.md)\n* The concern is readability → [`judge-code-quality`](..\u002Fjudge-code-quality\u002FSKILL.md)\n* **The criteria are not available** — that is not a reason to skip; it is a\n  verdict of its own. See § No criteria.\n\n## Procedure\n\n### 1. Establish where the criteria came from — before reading the diff\n\nRead the criteria **first**, and never after forming an impression of the diff.\nThe order is the control, not a preference: a judge that reads the change first\nand the requirement second reconstructs the requirement to fit what it just saw.\n\n```\nNEVER INFER AN ACCEPTANCE CRITERION FROM THE DIFF YOU ARE JUDGING.\nA JUDGE THAT DERIVES THE REQUIREMENT FROM THE CHANGE ALWAYS FINDS THE\nCHANGE COMPLIANT. THAT IS CIRCULAR BY CONSTRUCTION, NOT A BIAS A LABEL FIXES.\n```\n\nCriteria are **supplied**, or they are not. A commit message and a PR body are\nwritten by the same author as the diff, usually after it — so deriving criteria\nfrom them is a weaker form of the same circularity, not an independent source of\nlower quality.\n\n### 2. Per-AC scan\n\nFor each criterion, exactly one of:\n\n| Verdict | What it requires |\n|---|---|\n| `SATISFIED` | cite the diff hunk **and** the test that proves it. A hunk with no test is not satisfied, it is claimed |\n| `PARTIAL` | cite what is missing and why it falls short |\n| `MISSING` | the criterion has no corresponding implementation |\n\n### 3. Report the criteria-source state — three, not two\n\nThis mirrors [`dispatch_r2_reviewer`](..\u002F..\u002Fscripts\u002Fdispatch_r2_reviewer.ts)'s\nown extraction-failure handling, which refuses to collapse the last two for the\nsame reason: an unrecognised shape and a genuine absence produce the **identical\nempty result**, so asserting \"declares none\" would turn a silent tool failure\ninto a false statement handed to the one independent check on AC conformance.\n\n| State | Meaning | How to report |\n|---|---|---|\n| `supplied` | a roadmap, ticket or explicit criteria set was handed in | run § 2 |\n| `not_provided` | no criteria exist for this review — an ad-hoc branch review | **no-criteria verdict**, never `SATISFIED` |\n| `supplied_unparseable` | criteria were handed in and could not be read | **ERROR**, not a no-criteria verdict |\n\n**`supplied_unparseable` is an error and not a third flavour of silence.** It\nmeans the tooling is broken or the input is malformed, and folding it into\n`not_provided` hides parser regressions behind a state that looks routine.\n\n## No criteria — the verdict, and what it does to \"done\"\n\nA no-criteria outcome is **not** a pass, and it is not an abstention that the\nconsolidated verdict may ignore. What it changes is what \"done\" is allowed to\nclaim:\n\n> **craft quality verified; requirement compliance NOT verified**\n\nThat phrasing is the point. If this judge abstains on most reviews, the honest\nconsequence is not that the axis should be dropped — it is that most reviews\nwere previously reporting a confidence they had not earned. The abstention makes\nthat visible instead of assuming it away.\n\n## Do NOT\n\n* Do NOT infer criteria from the diff, the commit messages, or the PR body.\n* Do NOT return `SATISFIED` when no criteria were supplied — return the\n  no-criteria verdict.\n* Do NOT collapse `supplied_unparseable` into `not_provided`.\n* Do NOT report a craft, naming, correctness or coverage finding. Another judge\n  owns it, and duplicating it here inflates the finding count without adding a\n  reading.\n* Do NOT treat a criterion as satisfied on a diff hunk alone when a test could\n  have proven it.\n\n## Gotcha\n\n* **Criteria authored after the diff are not independent.** If the criteria set\n  was written or last modified after the change it judges, say so — a criterion\n  reverse-engineered from a merged branch verifies nothing.\n* **A criterion the diff makes moot is still not satisfied.** \"We no longer need\n  this\" is a scope decision for a human, not a verdict this judge may reach.\n\n## Output format\n\nOrdered, and the first line is not negotiable — a reader must be able to see the\ncriteria-source state before any per-criterion verdict, because every verdict\nbelow it is conditional on that state.\n\n1. `criteria_source: supplied | not_provided | supplied_unparseable`\n2. If `not_provided` → the no-criteria verdict and the \"requirement compliance\n   NOT verified\" line. **Stop.** Do not emit per-criterion rows.\n3. If `supplied_unparseable` → `ERROR` with what was handed in and what could not\n   be read. **Stop.** Do not emit per-criterion rows and do not degrade to\n   `not_provided`.\n4. If `supplied` → one row per criterion:\n   `| # | criterion (as stated) | SATISFIED \u002F PARTIAL \u002F MISSING | diff hunk | test |`\n   Criteria in the order they were stated, never re-ordered by verdict — a\n   reader comparing two runs needs the rows to line up.\n5. One closing line: the count of `MISSING` and `PARTIAL`. Not a severity, not a\n   recommendation — those belong to synthesis, and phrasing this as one is how a\n   spec finding gets ranked against a naming nit.\n\n## Related\n\n* [`judge-synthesis`](..\u002Fjudge-synthesis\u002FSKILL.md) — consumes this verdict on\n  its **own dimension**, deliberately not on the shared severity axis.\n* [`do-and-judge-two-stage`](..\u002Fsubagent-orchestration\u002Fprompts\u002Fdo-and-judge-two-stage.md)\n  — the stage-1 prompt this reuses.\n",{"name":5,"packs":52,"domain":35,"model_tier":43,"workspaces":54,"description":7,"parallelizable":39},[53],"meta",[55],"agent-config-maintainer","main","12bd765ce1d800501d45dfb8232102793af01290","src\u002Fskills\u002Fjudge-spec-compliance",1,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config","https:\u002F\u002Fevent4u.app","https:\u002F\u002Fgithub.com\u002Fevent4u-app","Your events in your hand","2026-11-14 02:29:41",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add event4u-app\u002Fagent-config --skill judge-spec-compliance",{"tool":71,"command":72},"bunx","bunx skills add event4u-app\u002Fagent-config --skill judge-spec-compliance",{"tool":74,"command":75},"pnpm","pnpm dlx skills add event4u-app\u002Fagent-config --skill judge-spec-compliance","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fjudge-spec-compliance\u002FSKILL.md",true,[79],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"evals\u002Ftriggers.json","REFERENCE","参考文档",1191,"https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fjudge-spec-compliance\u002Fevals\u002Ftriggers.json",[86,100,113,124,136,146],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":93,"publishedAt":47},"01M6X84PK96XBPENXH66JCTSD1","unknown-key-fixture","Declares a key the schema does not know.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Funknown-key\u002FSKILL.md",[92],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[94,95,96,97,98,99],"unknown key fixture","Unknown key","fixture","unknown","schema","package",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"publishedAt":47},"01M6X84HW7NAHZ7GZMQ9RXK1XJ","portable-fixture","Declares only semantics the MCP-lite carrier transports whole.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fportable\u002FSKILL.md",[106],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[96,108,109,110,111,99,112],"portable","portable fixture","engineer","only","MCP",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":47},"01M6X84F29FE0RGGZ1ZTFGZTX2","non-portable-fixture","Declares a runtime semantic the carrier drops.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Fscripts\u002Ffixtures\u002Fbody-portable\u002Fnon-portable\u002FSKILL.md",[119],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[109,121,108,96,122,43,123,99],"non portable fixture","semantic","runtime",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":131,"publishedAt":47},"01M6X848F706PT9MDCX75JKJ6B","candidate-zero-width","A candidate whose prose carries an invisible joiner.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fzero-width-injection\u002FSKILL.md",[130],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[132,133,134,135],"candidate zero width","candidate","ZeRO","prose",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":143,"publishedAt":47},"01M6X841SSC2T31VDF41SA6DG1","candidate-disclosure-suppression","A candidate whose prose tells the agent to withhold from the user.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdisclosure-suppression\u002FSKILL.md",[142],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[144,133,135,145],"candidate disclosure suppression","user",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":153,"publishedAt":47},"01M6X83TFS5AGPBPVTQNWP0BB3","candidate-dangerous-frontmatter","A candidate claiming an unscoped tool grant and a permission bypass.","https:\u002F\u002Fgithub.com\u002Fevent4u-app\u002Fagent-config\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskill-scout-candidates\u002Fdangerous-frontmatter\u002FSKILL.md",[152],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[154,133,155,156,157,158],"candidate dangerous frontmatter","frontmatter","shell","permission","tool"]