[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FATTWS9W3BME3S94SA1QR":3,"skill-same:01M71FATTWS9W3BME3S94SA1QR":69},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M71FATTWS9W3BME3S94SA1QR","sweep",null,"Use when the user wants to find code that has quietly stopped being used — types \u002Fsweep, asks for a \"dead code sweep\", \"repo entropy\", \"what can we delete\", \"orphan files\", \"unused code\", or asks to review a sweep ledger. Adjudicates candidates a deterministic scanner already produced; it never deletes anything and never re-derives findings from raw source. Pairs with ponytail, which gates what gets written rather than what rots.","Wizarck\u002Fai-playbook","Wizarck","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F23051550?v=4","01M71B3AAVR67GRWFV5ZXXZP31","arturo6ramirez","01M71F5FHXDSX3G2F52R1YS77J",6,"MIT","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fsweep\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"gates","candidates","when","unused","for","can","which","re","types","orphan","review","deterministic","files","never","use","repo","entropy","code","ponytail","2026-11-10 10:12:30",false,"---\nname: sweep\ndescription: Use when the user wants to find code that has quietly stopped being used — types \u002Fsweep, asks for a \"dead code sweep\", \"repo entropy\", \"what can we delete\", \"orphan files\", \"unused code\", or asks to review a sweep ledger. Adjudicates candidates a deterministic scanner already produced; it never deletes anything and never re-derives findings from raw source. Pairs with ponytail, which gates what gets written rather than what rots.\nlicense: MIT\nmetadata:\n  author: ai-playbook\n  version: \"1.0\"\n---\n\n# sweep — adjudicate repo entropy, never delete it\n\nYou are reviewing a ledger, not searching a repository.\n\n`scripts\u002Fsweep_scan.py` has already done the deterministic half: it resolved\nimports through the project's own module-resolution config, applied the\nentry-point conventions of the declared frameworks, and produced one row per\nunreachable file with typed evidence. Your job is the half a scanner cannot do —\ndecide whether each candidate is genuinely dead, or is reached by something\nstatic analysis cannot see.\n\n## Read this before you adjudicate anything\n\n**Your failure mode is laundering.** Measured on a real repository: a naive\nresolver that ignored `tsconfig.json` path aliases reported 89 live files as\ndead, including the application's own layout and auth provider. A model\nadjudicating that output would have produced 89 fluent, confident, wrong\nrationales — converting a resolver bug into reasoned ledger rows that look like\nanalysis.\n\nSo the first question is never \"is this file dead?\" It is **\"do I believe this\nscan at all?\"**\n\n- The scanner refuses to emit a ledger unless the consumer's declared `probes` —\n  files known to be live — all read as reachable. If you are holding a ledger,\n  that gate passed.\n- **A passed gate is not a clean bill of health.** It proves the resolver works\n  for the paths the probes exercise, and nothing more. On the same repository, a\n  second run reported ten live modals in one directory as orphans: the framework\n  preset listed `page.tsx` but not `page.js`, so the routes above them were not\n  entry points. All six probes were `.tsx` files reached through `.tsx`\n  importers, so every one of them passed. If the repo is half-migrated, or spans\n  languages, ask whether the probes actually cover the mechanism a cluster\n  depends on.\n- If findings cluster suspiciously (an entire directory, every file of one\n  extension, a whole framework's worth of components), suspect the RESOLVER\n  before you suspect the repo. Say so, and stop. A missing preset or an unread\n  path alias explains a cluster; twenty independent developers abandoning one\n  directory does not.\n\nThe mechanisms that have actually produced false orphans, in order of how often\nthey bite: an unread path alias, a missing entry-point extension, an importer\nthe config never parsed, a resolution rule outside the language (a webpack\n`resolve.alias`, a `COPY` in a Dockerfile, a dynamic `import()`).\n\n## What you may and may not do\n\nThe ledger schema (`schemas\u002Fschema-sweep-manifest-v1.json`) enforces most of\nthis; the point of restating it is that you should not want to do it either.\n\n- **You may not delete, move, or edit any file.** Producing an adjudicated\n  ledger is the whole of the job. Execution is a separate, explicit human step.\n  A previous auto-delete in this playbook destroyed 623 lines of live code, from\n  a `--quiet` hook, and went unnoticed for three weeks.\n- **You may not remove a row.** There is no `delete` decision. The weakest thing\n  you can do to a finding is `dismiss`, which KEEPS the row at Tier 3 with a\n  written rationale, so the next sweep can see it was already considered.\n- **You may not edit `evidence`.** It was written once, by the detector. You\n  consume it; you do not revise it.\n- **You may not escalate to Tier 1.** Delete authority requires a human. Your\n  escalations cap at Tier 2\u002F3.\n- **Every decision other than `confirm` requires a rationale**, and the rationale\n  must name the MECHANISM, not the feeling. \"Looks unused\" is not a rationale.\n  \"Loaded by `next\u002Fdynamic` in `app\u002F(ops)\u002Fpage.tsx:26`\" is.\n\n## When a finding carries `unfinished_commitments`\n\nStop. This row does not mean what the others mean.\n\n`evidence.unfinished_commitments` is a count of undischarged obligations the\nscanner found in the file — unticked task boxes, `TODO`, \"still required\", \"MUST\nTEAR DOWN\". A stranded document that owes work is not entropy. It is **an\nobligation with no watcher**, and it is more dangerous than a dead file, because\ndeleting it destroys the only record that the work exists.\n\nMeasured on a real repository, two of these were live: a `PROGRESS.md`\nunreferenced at the repo root for four weeks, owing a teardown of seed data in a\ncustomer's production Google Workspace; and a security remediation checklist with\neight unticked P0 items including credential rotation.\n\nSo:\n\n- **Never `confirm` such a row for removal.** The executor refuses it anyway, but\n  you should not want to: your recommendation would be to delete a promise.\n- **Read the commitments and report them as the finding.** The interesting output\n  is not \"this file is unreferenced\", it is \"these N obligations are unowned, and\n  here is what they are\". Quote them.\n- **The fix is to MOVE the obligation**, not the file — into a ticket, a runbook,\n  or the deferred-items ledger, wherever this project actually watches work. Once\n  it has an owner, the marker leaves with it and the next scan clears the row\n  honestly.\n- An unticked box that is genuinely done and was never ticked is still a finding:\n  the record is wrong, and a record nobody maintains is one nobody can trust.\n\n## How to adjudicate one finding\n\nWork from the evidence, then look for the thing the scanner structurally cannot\nsee. In order:\n\n1. **Read `evidence.locations` and `evidence.search_scope`.** \"Nothing\n   references it\" is only as strong as where the scanner looked. If the subject\n   lives outside the searched scope, that is a `dismiss` with the scope named.\n2. **Search for the subject by NAME as well as by path**, and read the hits.\n   A dynamic import, a lazy `next\u002Fdynamic`, a string-built module name, a\n   registry keyed by string, or a plugin entry point all reference a file\n   without an import statement. Any of these → `dismiss` (or `downgrade` if\n   partial), naming the file and line.\n3. **Check whether it is a deliberate surface**: a public API re-export, a\n   fixture, a template rendered by path, a script an operator invokes, a\n   documented escape hatch. These are alive by contract, not by import.\n4. **Check for a twin.** A file with a same-named sibling elsewhere is often\n   half of a duplication where only one copy is wired. That is a REAL finding\n   and usually a more interesting one than a lone orphan: the two copies drift,\n   and fixes applied to the live one never reach the dead one. Link them with\n   `related_ids`.\n5. **Only then confirm.** A `confirm` means: the evidence stands, and you looked\n   for the four things above and found none.\n\nCluster related rows with `related_ids` so one root cause reads as one problem\nrather than as ten.\n\n## What you write\n\nAdd the `adjudication` block to each row, in place, leaving `evidence`\nuntouched:\n\n```json\n{\n  \"decided_by\": \"llm\",\n  \"decision\": \"dismiss\",\n  \"tier\": 3,\n  \"decided_at\": \"2026-08-02T11:04:00Z\",\n  \"model\": \"\u003Cyour model id>\",\n  \"rationale\": \"Reached by `next\u002Fdynamic(() => import('.\u002FBulkDeleteModal'))` in app\u002F(app)\u002F(modules)\u002Fgroup-management\u002Fpage.tsx:31, which the static resolver cannot follow. Not an orphan; the scan is correct that no import statement names it.\"\n}\n```\n\nThen report to the user, in this order: how many findings, how many you\nconfirmed, how many you dismissed and why in one line each, and any cluster you\nsuspect is a resolver artefact rather than real entropy.\n\nClose with the one question the ledger cannot answer: which of the confirmed\nfindings the user actually wants to act on. Do not act on it yourself.\n\n## When to fire\n\n- User types `\u002Fsweep`, or asks for a \"dead code sweep\", \"repo entropy check\",\n  \"what can we delete\", \"orphan files\", \"unused code\".\n- User asks you to review or adjudicate an existing sweep ledger.\n- A monthly cadence reminder fires. Entropy is a slow variable; scanning it more\n  often than it changes is how a detector gets disabled.\n\n## When NOT to fire\n\n- **Mid-feature.** A file added in the current branch and not yet wired is\n  work-in-progress, not entropy. Sweep against a merged tree.\n- **On a dirty worktree.** `scan.dirty_worktree` in the ledger tells you; a\n  half-written import can make a live file look orphan. Discount accordingly and\n  say so.\n- **For the decidable axes.** Unused dependencies, unwired capabilities and disk\n  residue have deterministic rules that run at zero token cost\n  (`repo-hygiene`, `capability-wiring`). Do not re-derive their findings by\n  hand — read their output.\n\n## See also\n\n- `docs\u002Fconcepts\u002Fcode-entropy.md` — the five axes and why only two need you.\n- `schemas\u002Fschema-sweep-manifest-v1.json` — the ledger contract, including every\n  constraint above expressed as schema.\n- `docs\u002Frules\u002Fcleanup-zombies.rule.md` — the tier semantics, and the executor\n  that acts on a ledger once a human authorises it.\n- `skills\u002Fponytail\u002FSKILL.md` — the preventive twin: it gates what enters a diff,\n  this adjudicates what rotted after it landed.\n","# sweep — adjudicate repo entropy, never delete it\n\nYou are reviewing a ledger, not searching a repository.\n\n`scripts\u002Fsweep_scan.py` has already done the deterministic half: it resolved\nimports through the project's own module-resolution config, applied the\nentry-point conventions of the declared frameworks, and produced one row per\nunreachable file with typed evidence. Your job is the half a scanner cannot do —\ndecide whether each candidate is genuinely dead, or is reached by something\nstatic analysis cannot see.\n\n## Read this before you adjudicate anything\n\n**Your failure mode is laundering.** Measured on a real repository: a naive\nresolver that ignored `tsconfig.json` path aliases reported 89 live files as\ndead, including the application's own layout and auth provider. A model\nadjudicating that output would have produced 89 fluent, confident, wrong\nrationales — converting a resolver bug into reasoned ledger rows that look like\nanalysis.\n\nSo the first question is never \"is this file dead?\" It is **\"do I believe this\nscan at all?\"**\n\n- The scanner refuses to emit a ledger unless the consumer's declared `probes` —\n  files known to be live — all read as reachable. If you are holding a ledger,\n  that gate passed.\n- **A passed gate is not a clean bill of health.** It proves the resolver works\n  for the paths the probes exercise, and nothing more. On the same repository, a\n  second run reported ten live modals in one directory as orphans: the framework\n  preset listed `page.tsx` but not `page.js`, so the routes above them were not\n  entry points. All six probes were `.tsx` files reached through `.tsx`\n  importers, so every one of them passed. If the repo is half-migrated, or spans\n  languages, ask whether the probes actually cover the mechanism a cluster\n  depends on.\n- If findings cluster suspiciously (an entire directory, every file of one\n  extension, a whole framework's worth of components), suspect the RESOLVER\n  before you suspect the repo. Say so, and stop. A missing preset or an unread\n  path alias explains a cluster; twenty independent developers abandoning one\n  directory does not.\n\nThe mechanisms that have actually produced false orphans, in order of how often\nthey bite: an unread path alias, a missing entry-point extension, an importer\nthe config never parsed, a resolution rule outside the language (a webpack\n`resolve.alias`, a `COPY` in a Dockerfile, a dynamic `import()`).\n\n## What you may and may not do\n\nThe ledger schema (`schemas\u002Fschema-sweep-manifest-v1.json`) enforces most of\nthis; the point of restating it is that you should not want to do it either.\n\n- **You may not delete, move, or edit any file.** Producing an adjudicated\n  ledger is the whole of the job. Execution is a separate, explicit human step.\n  A previous auto-delete in this playbook destroyed 623 lines of live code, from\n  a `--quiet` hook, and went unnoticed for three weeks.\n- **You may not remove a row.** There is no `delete` decision. The weakest thing\n  you can do to a finding is `dismiss`, which KEEPS the row at Tier 3 with a\n  written rationale, so the next sweep can see it was already considered.\n- **You may not edit `evidence`.** It was written once, by the detector. You\n  consume it; you do not revise it.\n- **You may not escalate to Tier 1.** Delete authority requires a human. Your\n  escalations cap at Tier 2\u002F3.\n- **Every decision other than `confirm` requires a rationale**, and the rationale\n  must name the MECHANISM, not the feeling. \"Looks unused\" is not a rationale.\n  \"Loaded by `next\u002Fdynamic` in `app\u002F(ops)\u002Fpage.tsx:26`\" is.\n\n## When a finding carries `unfinished_commitments`\n\nStop. This row does not mean what the others mean.\n\n`evidence.unfinished_commitments` is a count of undischarged obligations the\nscanner found in the file — unticked task boxes, `TODO`, \"still required\", \"MUST\nTEAR DOWN\". A stranded document that owes work is not entropy. It is **an\nobligation with no watcher**, and it is more dangerous than a dead file, because\ndeleting it destroys the only record that the work exists.\n\nMeasured on a real repository, two of these were live: a `PROGRESS.md`\nunreferenced at the repo root for four weeks, owing a teardown of seed data in a\ncustomer's production Google Workspace; and a security remediation checklist with\neight unticked P0 items including credential rotation.\n\nSo:\n\n- **Never `confirm` such a row for removal.** The executor refuses it anyway, but\n  you should not want to: your recommendation would be to delete a promise.\n- **Read the commitments and report them as the finding.** The interesting output\n  is not \"this file is unreferenced\", it is \"these N obligations are unowned, and\n  here is what they are\". Quote them.\n- **The fix is to MOVE the obligation**, not the file — into a ticket, a runbook,\n  or the deferred-items ledger, wherever this project actually watches work. Once\n  it has an owner, the marker leaves with it and the next scan clears the row\n  honestly.\n- An unticked box that is genuinely done and was never ticked is still a finding:\n  the record is wrong, and a record nobody maintains is one nobody can trust.\n\n## How to adjudicate one finding\n\nWork from the evidence, then look for the thing the scanner structurally cannot\nsee. In order:\n\n1. **Read `evidence.locations` and `evidence.search_scope`.** \"Nothing\n   references it\" is only as strong as where the scanner looked. If the subject\n   lives outside the searched scope, that is a `dismiss` with the scope named.\n2. **Search for the subject by NAME as well as by path**, and read the hits.\n   A dynamic import, a lazy `next\u002Fdynamic`, a string-built module name, a\n   registry keyed by string, or a plugin entry point all reference a file\n   without an import statement. Any of these → `dismiss` (or `downgrade` if\n   partial), naming the file and line.\n3. **Check whether it is a deliberate surface**: a public API re-export, a\n   fixture, a template rendered by path, a script an operator invokes, a\n   documented escape hatch. These are alive by contract, not by import.\n4. **Check for a twin.** A file with a same-named sibling elsewhere is often\n   half of a duplication where only one copy is wired. That is a REAL finding\n   and usually a more interesting one than a lone orphan: the two copies drift,\n   and fixes applied to the live one never reach the dead one. Link them with\n   `related_ids`.\n5. **Only then confirm.** A `confirm` means: the evidence stands, and you looked\n   for the four things above and found none.\n\nCluster related rows with `related_ids` so one root cause reads as one problem\nrather than as ten.\n\n## What you write\n\nAdd the `adjudication` block to each row, in place, leaving `evidence`\nuntouched:\n\n```json\n{\n  \"decided_by\": \"llm\",\n  \"decision\": \"dismiss\",\n  \"tier\": 3,\n  \"decided_at\": \"2026-08-02T11:04:00Z\",\n  \"model\": \"\u003Cyour model id>\",\n  \"rationale\": \"Reached by `next\u002Fdynamic(() => import('.\u002FBulkDeleteModal'))` in app\u002F(app)\u002F(modules)\u002Fgroup-management\u002Fpage.tsx:31, which the static resolver cannot follow. Not an orphan; the scan is correct that no import statement names it.\"\n}\n```\n\nThen report to the user, in this order: how many findings, how many you\nconfirmed, how many you dismissed and why in one line each, and any cluster you\nsuspect is a resolver artefact rather than real entropy.\n\nClose with the one question the ledger cannot answer: which of the confirmed\nfindings the user actually wants to act on. Do not act on it yourself.\n\n## When to fire\n\n- User types `\u002Fsweep`, or asks for a \"dead code sweep\", \"repo entropy check\",\n  \"what can we delete\", \"orphan files\", \"unused code\".\n- User asks you to review or adjudicate an existing sweep ledger.\n- A monthly cadence reminder fires. Entropy is a slow variable; scanning it more\n  often than it changes is how a detector gets disabled.\n\n## When NOT to fire\n\n- **Mid-feature.** A file added in the current branch and not yet wired is\n  work-in-progress, not entropy. Sweep against a merged tree.\n- **On a dirty worktree.** `scan.dirty_worktree` in the ledger tells you; a\n  half-written import can make a live file look orphan. Discount accordingly and\n  say so.\n- **For the decidable axes.** Unused dependencies, unwired capabilities and disk\n  residue have deterministic rules that run at zero token cost\n  (`repo-hygiene`, `capability-wiring`). Do not re-derive their findings by\n  hand — read their output.\n\n## See also\n\n- `docs\u002Fconcepts\u002Fcode-entropy.md` — the five axes and why only two need you.\n- `schemas\u002Fschema-sweep-manifest-v1.json` — the ledger contract, including every\n  constraint above expressed as schema.\n- `docs\u002Frules\u002Fcleanup-zombies.rule.md` — the tier semantics, and the executor\n  that acts on a ledger once a human authorises it.\n- `skills\u002Fponytail\u002FSKILL.md` — the preventive twin: it gates what enters a diff,\n  this adjudicates what rotted after it landed.\n",{"name":5,"license":15,"metadata":43,"description":7},{"author":44,"version":45},"ai-playbook","1.0","main","08fe7aa0f06bc1a3f592ec82360e46b854846968","skills\u002Fsweep",1,"https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook","https:\u002F\u002Fgithub.com\u002FWizarck","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Framirezarturo\u002F","Geek by birth, with not much to say but plenty to talk about.","2026-11-09 19:34:21",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add Wizarck\u002Fai-playbook --skill sweep",{"tool":61,"command":62},"bunx","bunx skills add Wizarck\u002Fai-playbook --skill sweep",{"tool":64,"command":65},"pnpm","pnpm dlx skills add Wizarck\u002Fai-playbook --skill sweep","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fsweep\u002FSKILL.md",true,[],[70,90,114,133,146,169],{"skillNo":71,"name":37,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":38},"01M71FAQKVDA209G7G5NMY9H1E","Use when the user wants the laziest solution that actually works — types \u002Fponytail, says \"be lazy\", \"lazy mode\", \"simplest solution\", \"minimal solution\", \"yagni\", \"do less\", or \"shortest path\", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Supports intensity levels lite, full, ultra (default). Pairs with caveman, which compresses prose, not code.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fponytail\u002FSKILL.md",[],[37,76,77,25,78,27,79,80,81,82,33,21,36,83,84,85,86,87,88,89],"notice","do","lazy","mode","default","minimal","intensity","with","yagni","about","dependencies","2026","playbook","boilerplate",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":101,"publishedAt":38},"01M71FAMS250NKNF1PET9KNBBV","ponytail-review","Use when the user wants a code review focused exclusively on over-engineering — says \"review for over-engineering\", \"what can we delete\", \"is this over-engineered\", \"simplify review\", or invokes \u002Fponytail-review. Complements correctness\u002Fsecurity review; this one only hunts complexity in the current diff. Gated by the ponytail review_ponytail component.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fponytail-review\u002FSKILL.md",[96],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[102,37,29,103,104,23,105,106,33,21,107,108,36,109,24,110,111,112,113,88],"ponytail review","complexity","diff","code review","only","simplify","correctness","one","delete","component","security review","gated",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":38},"01M71FAG53ZPCSWE272P6S9JFN","ponytail-debt","Use when the user wants to harvest every `ponytail:` comment in the codebase into a tracked debt ledger — says \"ponytail debt\", \"\u002Fponytail-debt\", \"what did ponytail defer\", \"list the shortcuts\", \"ponytail ledger\", or \"what did we mark to do later\". One-shot report, changes nothing. Gated by the ponytail debt_ponytail component.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fponytail-debt\u002FSKILL.md",[],[121,37,122,123,77,124,125,111,126,127,113,128,129,88,130,131,33,21,132,109],"ponytail debt","debt","shortcuts","mark","to do","changes","later","report","codebase","harvest","list","ledger",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":38},"01M71FACJW88WCS2JGX3MQ3KV9","ponytail-audit","Use when the user wants a whole-repo audit for over-engineering — says \"audit this codebase\", \"audit for over-engineering\", \"what can I delete from this repo\", \"find bloat\", or invokes \u002Fponytail-audit. Like ponytail-review but scans the entire tree, not a diff. One-shot report, applies no fixes. Gated by the ponytail audit_ponytail component.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fponytail-audit\u002FSKILL.md",[],[140,37,141,142,104,143,23,34,33,21,144,109,24,29,110,111,113,145,128,129],"ponytail audit","audit","tree","fixes","entire","find",{"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":152,"publishedAt":38},"01M71FA9THHXDX79PQTJ9CZX9E","openspec-propose","Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fopenspec-propose\u002FSKILL.md",[],[153,154,83,155,156,157,158,159,160,23,161,162,163,164,165,166,33,21,167,168],"openspec","openspec propose","ready","proposal","change","cli","get","build","complete","design","new","implementation","generated","describe","artifacts","tasks",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":38},"01M71FA80MEBSWG2G43YT4C825","openspec-explore","Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.","https:\u002F\u002Fgithub.com\u002FWizarck\u002Fai-playbook\u002Fblob\u002Fmain\u002Fskills\u002Fopenspec-explore\u002FSKILL.md",[],[153,176,177,178,179,180,23,79,33,21,181,157,158,182,183,184],"explore","openspec explore","thinking","ideas","thinking partner","requirements","partner","think","user"]