[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M74AAAPNY933TSRZHM4PSKZ3":3,"skill-same:01M74AAAPNY933TSRZHM4PSKZ3":51},{"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":26,"commitSha":27,"skillDirectory":28,"forksCount":14,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":31,"install":32,"resources":44},"01M74AAAPNY933TSRZHM4PSKZ3","shape",null,"Review a working change for its shape (cause, ownership, states, names, size, reuse, cost), then apply what you accept.","lithammer\u002Fai","lithammer","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F177685?v=4","01M72XZ1CBM905458R0T7AGP87","Peter Lithammer","01M72XZ1CYWE22YVYQ43NJQZQB",0,"MIT","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fshape\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: shape\ndescription: Review a working change for its shape (cause, ownership, states, names, size, reuse, cost), then apply what you accept.\ndisable-model-invocation: true\nargument-hint: \"[target]\"\n---\n\n# Shape\n\n## Run\n\n1. Diff the review target: the current branch against its merge-base\n   with the default branch, plus uncommitted changes, unless the\n   invocation names another target.\n2. Spawn one reviewer for both Where axes and wait for it.\n3. If it reports findings, present each with its counter-draft, its\n   cost, and your recommendation with its reason, and wait for the\n   person to accept or decline it. Apply the accepted ones.\n4. Spawn one reviewer per How axis, in parallel, on the code as it now\n   stands, and give each the declined Where findings.\n5. Apply each How finding whose counter-draft stays inside the diff,\n   keeps to the ticket, preserves behavior, and leaves every test in\n   place.\n6. End with the findings by axis and which you applied, one combined\n   counter-draft for the rest, and the decisions they leave the person,\n   each with your recommendation.\n\nGive every reviewer the Scope, Evidence, and Report sections and its own\naxis sections, copied verbatim, plus the review target and the ticket.\nAdd nothing of your own reading.\n\n## Scope\n\nReview the axes your task names. Other reviewers cover the other axes,\nand a correctness review runs on the result. When your task carries\ndeclined Where findings, a person has ruled on them; leave them out.\n\n## Evidence\n\nFor each candidate, write the counter-draft: the smallest correct change\nthat solves the same problem. A finding is the gap between the diff and\nthat draft, and the draft is its evidence. Show that the draft preserves\nbehavior against callers and tests, and name the concrete cost of the\ngap: what a maintainer must hold in mind, keep in sync, or work around.\nLine count alone is not a cost.\n\n## Where\n\n### Root cause\n\nDoes the change fix the mechanism that produces the problem, or apply a\nband-aid downstream of it? A special case layered on shared code is the\nusual sign. Trace the problem to its cause and name the change there. A\ncause-level fix may overturn an approach the spec prescribed; report it\nall the same, for a person to decide.\n\n### Ownership\n\nDoes each responsibility the change adds or moves live in the module\nthat owns its data and rules? Find information leakage: knowledge of one\nmodule's rules or internals spread into its callers. Verify the owner\nagainst interfaces and callers, and keep the search tied to the changed\nresponsibility.\n\n## How\n\n### States\n\nDoes the code admit states the problem does not have? Find data shaped\nto hold combinations the problem never produces or to store what could\nbe derived, and checks that guard states callers and types already rule\nout. Make illegal states unrepresentable, and parse, don't validate:\ninput is checked once where it crosses a trust boundary, into a type the\nrest of the code can trust. Show the reshaped data, or the proof from\ncallers and types, and the code it deletes.\n\n### Precision\n\nDo names, types, and comments say less than the code knows? Name the\nprecise replacement, in the ubiquitous language. When a comment explains\nwhat a name could say, the name is the finding. When the code relies on\na constraint no name or type can show, the missing comment is the\nfinding.\n\n### Proportion\n\nDoes the change carry accidental complexity: concepts its problem does\nnot need? A concept is anything a reader must hold in mind. Code the\nchange repeats or leaves dead counts; so does compatibility with\nanything the base never shipped, and a comment that restates the code or\nrecounts how the change came about. Name each concept the counter-draft\nremoves.\n\n### Reuse\n\nDoes something already do this, in the repository or in what it already\ndepends on? Name the existing symbol, check that its behavior and\ndependency boundaries fit this caller, and weigh the reuse against the\ncost of changing the caller.\n\n### Efficiency\n\nDoes the change add work the result does not need, or put work where it\ncosts more: on a hot path, at startup, in sequence where it could run\nconcurrently, or in memory held longer than its use? Name the cheaper\nalternative. Calibrate to where the code runs; work off the hot path\ncosts little.\n\n## Report\n\nReturn each finding with its file and line, its axis, the counter-draft,\nthe cost, and whether the draft reaches outside the diff or departs from\nthe ticket.\n","# Shape\n\n## Run\n\n1. Diff the review target: the current branch against its merge-base\n   with the default branch, plus uncommitted changes, unless the\n   invocation names another target.\n2. Spawn one reviewer for both Where axes and wait for it.\n3. If it reports findings, present each with its counter-draft, its\n   cost, and your recommendation with its reason, and wait for the\n   person to accept or decline it. Apply the accepted ones.\n4. Spawn one reviewer per How axis, in parallel, on the code as it now\n   stands, and give each the declined Where findings.\n5. Apply each How finding whose counter-draft stays inside the diff,\n   keeps to the ticket, preserves behavior, and leaves every test in\n   place.\n6. End with the findings by axis and which you applied, one combined\n   counter-draft for the rest, and the decisions they leave the person,\n   each with your recommendation.\n\nGive every reviewer the Scope, Evidence, and Report sections and its own\naxis sections, copied verbatim, plus the review target and the ticket.\nAdd nothing of your own reading.\n\n## Scope\n\nReview the axes your task names. Other reviewers cover the other axes,\nand a correctness review runs on the result. When your task carries\ndeclined Where findings, a person has ruled on them; leave them out.\n\n## Evidence\n\nFor each candidate, write the counter-draft: the smallest correct change\nthat solves the same problem. A finding is the gap between the diff and\nthat draft, and the draft is its evidence. Show that the draft preserves\nbehavior against callers and tests, and name the concrete cost of the\ngap: what a maintainer must hold in mind, keep in sync, or work around.\nLine count alone is not a cost.\n\n## Where\n\n### Root cause\n\nDoes the change fix the mechanism that produces the problem, or apply a\nband-aid downstream of it? A special case layered on shared code is the\nusual sign. Trace the problem to its cause and name the change there. A\ncause-level fix may overturn an approach the spec prescribed; report it\nall the same, for a person to decide.\n\n### Ownership\n\nDoes each responsibility the change adds or moves live in the module\nthat owns its data and rules? Find information leakage: knowledge of one\nmodule's rules or internals spread into its callers. Verify the owner\nagainst interfaces and callers, and keep the search tied to the changed\nresponsibility.\n\n## How\n\n### States\n\nDoes the code admit states the problem does not have? Find data shaped\nto hold combinations the problem never produces or to store what could\nbe derived, and checks that guard states callers and types already rule\nout. Make illegal states unrepresentable, and parse, don't validate:\ninput is checked once where it crosses a trust boundary, into a type the\nrest of the code can trust. Show the reshaped data, or the proof from\ncallers and types, and the code it deletes.\n\n### Precision\n\nDo names, types, and comments say less than the code knows? Name the\nprecise replacement, in the ubiquitous language. When a comment explains\nwhat a name could say, the name is the finding. When the code relies on\na constraint no name or type can show, the missing comment is the\nfinding.\n\n### Proportion\n\nDoes the change carry accidental complexity: concepts its problem does\nnot need? A concept is anything a reader must hold in mind. Code the\nchange repeats or leaves dead counts; so does compatibility with\nanything the base never shipped, and a comment that restates the code or\nrecounts how the change came about. Name each concept the counter-draft\nremoves.\n\n### Reuse\n\nDoes something already do this, in the repository or in what it already\ndepends on? Name the existing symbol, check that its behavior and\ndependency boundaries fit this caller, and weigh the reuse against the\ncost of changing the caller.\n\n### Efficiency\n\nDoes the change add work the result does not need, or put work where it\ncosts more: on a hot path, at startup, in sequence where it could run\nconcurrently, or in memory held longer than its use? Name the cheaper\nalternative. Calibrate to where the code runs; work off the hot path\ncosts little.\n\n## Report\n\nReturn each finding with its file and line, its axis, the counter-draft,\nthe cost, and whether the draft reaches outside the diff or departs from\nthe ticket.\n",{"name":5,"description":7,"argument-hint":24,"disable-model-invocation":25},"[target]",true,"main","6c43d36bf64f0af6cc48a23a75649b8be0ba247c","skills\u002Fshape","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai","https:\u002F\u002Fgithub.com\u002Flithammer","2026-11-11 22:45:02",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":25},[34,37,40],{"tool":35,"command":36},"npx","npx skills add lithammer\u002Fai --skill shape",{"tool":38,"command":39},"bunx","bunx skills add lithammer\u002Fai --skill shape",{"tool":41,"command":42},"pnpm","pnpm dlx skills add lithammer\u002Fai --skill shape","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fshape\u002FSKILL.md",[45],{"path":46,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":49,"sourceHtmlUrl":50},"agents\u002Fopenai.yaml","REFERENCE","参考文档",167,"https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fshape\u002Fagents\u002Fopenai.yaml",[52,59],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":19},"01M74AA65VBXVA11AA8JPBNYW6","correctness","Review a working change for defects (logic, state, lifecycle, concurrency, regression) and for drift from its ticket, docs, and rules, then apply what you accept.","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fcorrectness\u002FSKILL.md",[],[],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":66},"01M72XZK86KJE3FVJVJ2KRSSZN","develop","Implement an agreed feature or fix and prove each requirement with real runs. Use when carrying a defined change through implementation.","https:\u002F\u002Fgithub.com\u002Flithammer\u002Fai\u002Fblob\u002Fmain\u002Fskills\u002Fdevelop\u002FSKILL.md",[],[],"2026-11-10 22:39:42"]