[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CDYHDFRAZP8T121PGMZ46R":3,"skill-same:01M7CDYHDFRAZP8T121PGMZ46R":45},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":29,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M7CDYHDFRAZP8T121PGMZ46R","verify",null,"Use after an implementation pass, or to verify a landed slice before close. Whole verification of landed work: ticket, RFC, governing docs, and the project's verification set.","dveyarangi\u002Fgoodwolf-harness","dveyarangi","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F693404?v=4","01M77KAGWZ8X0CNA092ZDNEF6T","Fima Rotter","01M7CDVSGB58A879MVTYC1SVD0",0,"MIT","https:\u002F\u002Fgithub.com\u002Fdveyarangi\u002Fgoodwolf-harness\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: verify\ndescription: >-\n  Use after an implementation pass, or to verify a landed slice before close.\n  Whole verification of landed work: ticket, RFC, governing docs, and the\n  project's verification set.\n---\n\n\u003Cstraw-dog question=\"q-54kvny\">Mechanism: not yet\u003C\u002Fstraw-dog>\n\nCompare the work to its ticket, RFC if any, governing docs, and every check\nin the project's [verification set](#the-verification-set).\nFind out:\n\n- How well the work matches and represents the documentation\n- Where the work went wrong or weird because of underspecification or\n  contradiction in the docs\n- Whether the verification set's checks hold\n\nLook for architectural or responsibility leakage.\n\n## Installed from other mechanisms\n\n\u003Cinstalled by=\"edge\">\n**E4** When the landed work changes an edge — a promise in its Contract or Invariants, an invariant's\nvalidator, or a check of its Extending — the same commit writes its record under `docs\u002Fedge\u002F`. A\npromise the landing makes true loses its `⚠ pending` mark, and the record leaves\n`Normative (tentative)` when no mark is left; a landing that breaks a promise no decision changed\nis a finding, never written into the record. The Roadmap entry of the ticket that landed is\nremoved. An extension observed live in this work has what was seen written in its sidecar, dated,\nnot only in the ticket or the session record.\n\u003C\u002Finstalled>\n\n## The verification set\n\nThe project's verification set is its typechecker, its tests and every other command required\nof landed work, named in the project's local rules file and installed here as the local block. A\nfailed check is unfinished work.\nDiscovery reporting success with zero tests is not verification; the run must show a positive\ncount. A clean run means nothing was caught, never that the tree obeys. `\u002Fimplement` may run\nnamed checks during the work; that run is not this pass.\n\n\u003Cinstalled by=\"mechanism-shape\">\n**R7** A project's own answers and overrides are authored in one file beside the entry file,\n`local.rules.md`, in the rules-file format, and reach a file only as the local block — the\ninstalled block whose owner is `local` — which the installer writes after every mechanism's block\nthere, so the project's answer is what a reader meets after core's rule. An override names the rule it\noverrides. A local change to a rule is written in the local file, never into a skill or the entry\nfile, and re-installed. The local block is the project's,\nnot core's, and a redeploy preserves it.\n\u003C\u002Finstalled>\n\n\u003Cinstalled by=\"local\">\n**L3** The verification set: the checks always; the tests too when the work changed a file that is not\nmarkdown, the question store's own writes aside.\n\n```\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fmechanisms.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Finject_rules.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Ftickets.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fedges.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fmaintain.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fquestions.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fsessions.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fproduct.py --check\n```\n\n```\nuv run --offline --no-project python -m unittest discover -s .agents\u002Fscripts\u002Fgw\u002Ftest -p \"test_*.py\"\n```\n\u003C\u002Finstalled>\n\n\n## Check and repair\n\n- Cross-check documents against each other and against code, in both directions.\n  Ask whether the implementation contract could be reconstructed from the architecture\n  alone; a load-bearing decision visible only in code is a documentation finding.\n- Code that contradicts an accepted decision is a code finding. Do not settle a\n  contradiction by weakening the rule.\n- Check named validators still exist and still assert the promise they were named for.\n  A missing or drifted validator is a finding, as is an unguarded normative promise.\n  A promise about something that already exists — a recipient's tree, a stored record — is\n  asserted only by a fixture built the way that thing came to be: one the code under test\n  made cannot hold a shape that code now refuses, or lack a file that code now ships.\n- Sweep the question store, `docs\u002Fquestions\u002F`, for entries in scope: a question the\n  implementation has since answered closes with a pointer to its owning record, and a dead\n  trigger retires.\n- A discrepancy is mended or taken to [\u002Falign](..\u002Falign\u002FSKILL.md), as *Discrepancies* says. A\n  missing, ambiguous or contradictory rule, a new foundational decision, or work beyond the\n  authorization goes to `\u002Falign` too. Pause that change; independently authorized work continues.\n\n\u003Cstraw-dog question=\"q-ktwi2e\">\n- Read the landed work against the open questions. What one's answer will change is a straw\n  dog: wrap it and bind it to that question, per the entry file, and leave what no open question\n  would change alone. Run `straw_dogs.py --guess` over the files the slice touched and judge its\n  candidates.\n\u003C\u002Fstraw-dog>\n\nDiscrepancies:\n\n- Below the dial of what it mends, make the repair, verify it, and report in the owning work\n  item. Cite the violated rule, what changed, the verification result and any remaining\n  uncertainty.\n- Otherwise `\u002Falign`: present the discrepancy, affected constraints,\n  recommended resolution and the decision needed. Do not amend until that\n  returns.\n- Do not rewrite a governing rule, weaken a validator or relax acceptance\n  criteria to make a violation disappear.\n\nA missing RFC is not a defect of this skill when the ticket has none.\n\n- Docstrings say what their own unit does. Apply\n  [\u002Fimprove-comments](..\u002Fimprove-comments\u002FSKILL.md) to comments in scope and check\n  that TODO tags still describe something pending.\n\u003Cstraw-dog question=\"q-jbv3d6\">\n- Read the pointers in the slice's code: each names, word for word, a heading or a bold lead that\n  the record it points into holds. One that does not is a finding.\n\u003C\u002Fstraw-dog>\n\n\nApply `\u002Fplan` rules that help this review. Do not start a whole-tree\nmaintenance pass; `\u002Fmaintain` owns that.\n","\u003Cstraw-dog question=\"q-54kvny\">Mechanism: not yet\u003C\u002Fstraw-dog>\n\nCompare the work to its ticket, RFC if any, governing docs, and every check\nin the project's [verification set](#the-verification-set).\nFind out:\n\n- How well the work matches and represents the documentation\n- Where the work went wrong or weird because of underspecification or\n  contradiction in the docs\n- Whether the verification set's checks hold\n\nLook for architectural or responsibility leakage.\n\n## Installed from other mechanisms\n\n\u003Cinstalled by=\"edge\">\n**E4** When the landed work changes an edge — a promise in its Contract or Invariants, an invariant's\nvalidator, or a check of its Extending — the same commit writes its record under `docs\u002Fedge\u002F`. A\npromise the landing makes true loses its `⚠ pending` mark, and the record leaves\n`Normative (tentative)` when no mark is left; a landing that breaks a promise no decision changed\nis a finding, never written into the record. The Roadmap entry of the ticket that landed is\nremoved. An extension observed live in this work has what was seen written in its sidecar, dated,\nnot only in the ticket or the session record.\n\u003C\u002Finstalled>\n\n## The verification set\n\nThe project's verification set is its typechecker, its tests and every other command required\nof landed work, named in the project's local rules file and installed here as the local block. A\nfailed check is unfinished work.\nDiscovery reporting success with zero tests is not verification; the run must show a positive\ncount. A clean run means nothing was caught, never that the tree obeys. `\u002Fimplement` may run\nnamed checks during the work; that run is not this pass.\n\n\u003Cinstalled by=\"mechanism-shape\">\n**R7** A project's own answers and overrides are authored in one file beside the entry file,\n`local.rules.md`, in the rules-file format, and reach a file only as the local block — the\ninstalled block whose owner is `local` — which the installer writes after every mechanism's block\nthere, so the project's answer is what a reader meets after core's rule. An override names the rule it\noverrides. A local change to a rule is written in the local file, never into a skill or the entry\nfile, and re-installed. The local block is the project's,\nnot core's, and a redeploy preserves it.\n\u003C\u002Finstalled>\n\n\u003Cinstalled by=\"local\">\n**L3** The verification set: the checks always; the tests too when the work changed a file that is not\nmarkdown, the question store's own writes aside.\n\n```\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fmechanisms.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Finject_rules.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Ftickets.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fedges.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fmaintain.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fquestions.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fsessions.py --check\nuv run --offline --no-project python .agents\u002Fscripts\u002Fgw\u002Fproduct.py --check\n```\n\n```\nuv run --offline --no-project python -m unittest discover -s .agents\u002Fscripts\u002Fgw\u002Ftest -p \"test_*.py\"\n```\n\u003C\u002Finstalled>\n\n\n## Check and repair\n\n- Cross-check documents against each other and against code, in both directions.\n  Ask whether the implementation contract could be reconstructed from the architecture\n  alone; a load-bearing decision visible only in code is a documentation finding.\n- Code that contradicts an accepted decision is a code finding. Do not settle a\n  contradiction by weakening the rule.\n- Check named validators still exist and still assert the promise they were named for.\n  A missing or drifted validator is a finding, as is an unguarded normative promise.\n  A promise about something that already exists — a recipient's tree, a stored record — is\n  asserted only by a fixture built the way that thing came to be: one the code under test\n  made cannot hold a shape that code now refuses, or lack a file that code now ships.\n- Sweep the question store, `docs\u002Fquestions\u002F`, for entries in scope: a question the\n  implementation has since answered closes with a pointer to its owning record, and a dead\n  trigger retires.\n- A discrepancy is mended or taken to [\u002Falign](..\u002Falign\u002FSKILL.md), as *Discrepancies* says. A\n  missing, ambiguous or contradictory rule, a new foundational decision, or work beyond the\n  authorization goes to `\u002Falign` too. Pause that change; independently authorized work continues.\n\n\u003Cstraw-dog question=\"q-ktwi2e\">\n- Read the landed work against the open questions. What one's answer will change is a straw\n  dog: wrap it and bind it to that question, per the entry file, and leave what no open question\n  would change alone. Run `straw_dogs.py --guess` over the files the slice touched and judge its\n  candidates.\n\u003C\u002Fstraw-dog>\n\nDiscrepancies:\n\n- Below the dial of what it mends, make the repair, verify it, and report in the owning work\n  item. Cite the violated rule, what changed, the verification result and any remaining\n  uncertainty.\n- Otherwise `\u002Falign`: present the discrepancy, affected constraints,\n  recommended resolution and the decision needed. Do not amend until that\n  returns.\n- Do not rewrite a governing rule, weaken a validator or relax acceptance\n  criteria to make a violation disappear.\n\nA missing RFC is not a defect of this skill when the ticket has none.\n\n- Docstrings say what their own unit does. Apply\n  [\u002Fimprove-comments](..\u002Fimprove-comments\u002FSKILL.md) to comments in scope and check\n  that TODO tags still describe something pending.\n\u003Cstraw-dog question=\"q-jbv3d6\">\n- Read the pointers in the slice's code: each names, word for word, a heading or a bold lead that\n  the record it points into holds. One that does not is a finding.\n\u003C\u002Fstraw-dog>\n\n\nApply `\u002Fplan` rules that help this review. Do not start a whole-tree\nmaintenance pass; `\u002Fmaintain` owns that.\n",{"name":5,"description":7},"main","a43633f7ef0eeeb220f42872be487150daec8575",".agents\u002Fskills\u002Fverify","https:\u002F\u002Fgithub.com\u002Fdveyarangi\u002Fgoodwolf-harness","https:\u002F\u002Fgithub.com\u002Fdveyarangi","http:\u002F\u002Fdveyarangi.blogspot.com\u002F","2026-11-14 12:09:52",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add dveyarangi\u002Fgoodwolf-harness --skill verify",{"tool":37,"command":38},"bunx","bunx skills add dveyarangi\u002Fgoodwolf-harness --skill verify",{"tool":40,"command":41},"pnpm","pnpm dlx skills add dveyarangi\u002Fgoodwolf-harness --skill verify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdveyarangi\u002Fgoodwolf-harness\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fverify\u002FSKILL.md",true,[],[46,53,60,67,74,81],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M7CDYES9QW4N2JZ8GX1Q9DMV","ticket","Use to decompose a parent work into independently-workable child tickets. Use to mint ticket(s), possibly a single one, when planning implementation without one.","https:\u002F\u002Fgithub.com\u002Fdveyarangi\u002Fgoodwolf-harness\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fticket\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M7CDYB6CFM7PD0APTBBS17HH","tdd","Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions \"red-green-refactor\", wants integration tests, or asks for test-first development.","https:\u002F\u002Fgithub.com\u002Fdveyarangi\u002Fgoodwolf-harness\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftdd\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7CDY7V9VR5DDC0TPXQRB6K1","skill-up","Aid agent skill creation or modification. Use when creating a new skill or changing an existing one. Use whenever writing any agent instructions, whether to a file or directly in a reply.","https:\u002F\u002Fgithub.com\u002Fdveyarangi\u002Fgoodwolf-harness\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fskill-up\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":19},"01M7CDY4B01RZP7Y90JGTCHNY5","setup-devops","Set up the project's engineering scaffolding, from toolchain to CICD and observability. Use when initializing a repo or filling a setup gap.","https:\u002F\u002Fgithub.com\u002Fdveyarangi\u002Fgoodwolf-harness\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsetup-devops\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M7CDY1P8T9VT2W2ZXEH1H4PR","review-architecture","Explore the codebase for module-deepening opportunities — architectural improvements that raise testability and navigability. Use when asked to improve or refactor the architecture.","https:\u002F\u002Fgithub.com\u002Fdveyarangi\u002Fgoodwolf-harness\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freview-architecture\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M7CDXYZWWB6QVZPF7Q4PXSMY","recall","Determine where the project stands and what to work on next, with the decisions already taken surfaced alongside the questions genuinely still open. Use when asked what is next, where things stand, or to continue or pick up work.","https:\u002F\u002Fgithub.com\u002Fdveyarangi\u002Fgoodwolf-harness\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frecall\u002FSKILL.md",[],[]]