[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72WE0F58KDB68QPBGQEA91F":3,"skill-same:01M72WE0F58KDB68QPBGQEA91F":57},{"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":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":30,"ownerDescription":31,"updatedAt":32,"install":33,"resources":46},"01M72WE0F58KDB68QPBGQEA91F","tiger-style",null,"Check the column budget of the lines a change adds, and read that change against the TIGER_STYLE shape rules a script cannot judge. Use when the user asks about line length or column limits, to check code shape, what the column check flagged, or why a commit was blocked on a column budget.","raisedadead\u002Fclaude-code-plugins","raisedadead","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1884376?v=4","01M72WC4WYRJGZ2CXMCSF7B6VG","Mrugesh Mohapatra","01M72WC4XJTNHQ0D89QPG2H0W4",3,"ISC","https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fwhetstone\u002Fskills\u002Ftiger-style\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: tiger-style\ndescription: Check the column budget of the lines a change adds, and read that change against the TIGER_STYLE shape rules a script cannot judge. Use when the user asks about line length or column limits, to check code shape, what the column check flagged, or why a commit was blocked on a column budget.\n---\n\n# tiger-style — one shape rule computed, the rest read by hand\n\nOne TIGER_STYLE rule is cheap to compute from a diff; the rest need a reader. This skill keeps the two halves apart and labelled — a checklist presented as a gate is worse than no gate.\n\n## When to use\n\n- Before committing a change that adds source lines.\n- When a build reports `TIGER: BLOCK` or `TIGER: NAG` and you need to know which limit applied.\n- When reviewing someone else's diff for shape rather than correctness.\n\n## Run the check\n\n```bash\n\"${CLAUDE_PLUGIN_ROOT}\"\u002Fbin\u002Ftiger-check [repo-path]\n```\n\nReads the **staged** diff (`git diff --cached`), never `HEAD`. `--cached` compares HEAD against the index, which is exactly what the commit will contain. `HEAD` would compare against the working tree instead: it would flag unstaged edits the commit does not carry, and it fails outright in a repository with no commits yet — a failure the checker would read as \"nothing was added\".\n\nOnly lines the change **adds** are measured. Existing long lines are somebody else's commit.\n\n| exit | signal                                    | meaning                                                                                                   |\n| ---- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------- |\n| 0    | `TIGER: CLEAN \u003Cn> file(s)[, \u003Cm> skipped]` | no added line is over its limit, across the `\u003Cn>` files examined; `\u003Cm>` more were staged but not measured |\n| 1    | `TIGER: BLOCK \u003Cn>`                        | `\u003Cn>` added lines exceed a limit **the repo declared**                                                    |\n| 2    | `TIGER: NAG \u003Cn>`                          | `\u003Cn>` added lines exceed the built-in 100-column fallback                                                 |\n| 64   | —                                         | the path is not a git work tree                                                                           |\n\nEach offence prints as `path:line: \u003Cwidth> cols (limit \u003Cn>)` before the verdict line.\n\n`CLEAN 0 files` and `CLEAN 3 files` are both exit 0, and the difference matters: the first means nothing was measured. A caller that reads only the exit code cannot tell \"checked, fine\" from \"checked nothing\" — which is how a mis-typed `git add` reads as a pass.\n\n`CLEAN 0 files, 2 skipped` is a commit whose every file was prose, data, or declared `off` — a docs-only commit, or a bump of a lockfile the skip lists below name, reaches it correctly, and it is not a mistake. A bare `CLEAN 0 files` means no added, copied, modified, renamed or type-changed path was staged at all, which has two causes: an empty index, or a commit that stages only deletions. Deletions have no added lines to measure, so they reach neither counter. Check your `git add` over the bare form when the commit was meant to change a file.\n\nOne run can turn up both kinds at once — a declared-limit offence in one file and a fallback offence in another. Every offence is printed either way, but `\u003Cn>` in the verdict counts only the kind the verdict names. A fallback offence is never counted into a `BLOCK` and never blocks a commit, whatever else the run found.\n\n### Which limit applies\n\nResolved per file, first match wins:\n\n1. `WHETSTONE_TIGER_COLS` — a **positive** integer. Declared, so it **blocks**. `0`, a negative, or a non-number is not a limit: the value is dropped, resolution continues at the next source, and the reason is named on stderr. An operator who set `WHETSTONE_TIGER_COLS=0` in a repo with an `.editorconfig` limit therefore gets that repo's limit — still a `BLOCK`, at a number they did not choose. The stderr line is what makes that visible.\n1. `.editorconfig` `max_line_length` for the nearest section matching the file. Declared, so it **blocks**. A value of `off` is spec-legal and skips the file entirely.\n\n\"Nearest\" is directory distance: the walk starts beside the file and stops at a `root = true`. It is not specificity. Where two sections in the **same** file both match, EditorConfig's own rule applies and the later one wins — `[*.py]` followed by `[*]` loses to the `[*]`, which is the opposite of what CSS-shaped intuition predicts.\n\nA later section only wins if its value parses. `max_line_length = 0` in the more specific section leaves the broader section's limit standing, which is the same silent-ignore trap as the env var and gets the same treatment: the value is named on stderr rather than dropped.\n\n1. Nothing declared → 100 columns, and exceeding it only **nags**.\n\nThe distinction is the point: a repo that has stated its limit gets it enforced, and a repo that has not gets told, never stopped. The env var carries whetstone's own prefix rather than a `DOSSIER_` one — this is whetstone's behaviour, and it must be configurable by someone who has never installed the dossier plugin.\n\nProse and data formats are skipped outright by suffix — `.md`, `.markdown`, `.rst`, `.txt`, `.json`, `.jsonl`, `.csv`, `.tsv`, `.svg`, `.lock`, `.snap` — and by exact name: `go.sum`, `yarn.lock`, `pnpm-lock.yaml`, `poetry.lock`, `Cargo.lock`. A column limit describes a statement, not a record.\n\nThe name list carries only the lockfiles the suffix list misses. `pnpm-lock.yaml` is generated and `.github\u002Fworkflows\u002Fci.yaml` is written by hand, so skipping every `.yaml` to reach the first is not on offer. Both lists are literal, not a guess at what looks generated: a lockfile named anything else — `gradle.lockfile`, say — is measured like source, and one of its added lines over a declared limit exits 1.\n\n## The manual pass — what the script cannot judge\n\nThese are the TIGER_STYLE rules that need a reader. **Nothing enforces them.** They produce no exit code, and no tool will stop a commit that violates them. Read the diff against them yourself:\n\n- **Function length.** A function that does not fit on a screen is doing more than one thing. Split at the seam, not at the line count.\n- **Assert adequacy.** A non-trivial function asserts its preconditions. Assert the negative space too — the states that must never occur, not only the ones you expect.\n- **Loop bounds.** Every loop states an upper bound. An unbounded loop is a hang waiting for the input that triggers it.\n- **Limits as numbers.** Every limit is a named constant with a stated unit, never an inline literal. A magic number is a decision nobody can find later.\n\nTreat this list the way `skill-smith` treats its reference checklists: the exit code is the gate, the checklist is the judgement, and the two are never described as the same thing.\n\nInside a dossier build run with `--review`, the `dossier-reviewer` agent reads the diff against this same list. That does not make it a gate: its findings on these four rules are capped at `Warn:`, which cannot block a commit, and `--review` is opt-in — it auto-fires only for destructive-class tasks, a category that has nothing to do with code shape. A second reader is worth having. It is not enforcement.\n\n## What is deliberately not here\n\nFour TIGER_STYLE rules are absent on purpose, so their absence does not read as an oversight:\n\n- **Assert the negative space, as a testing rule** — already carried by the repo's testing standard: `run-slice` fails a slice whose test passed on its first run, and every gate is required to ship a positive and a negative test. That is the same rule enforced one level up, at the test rather than at the function.\n- **Zero technical debt** — a caught bug becomes a recorded, testable invariant through the dossier plugin's backprop verb. `ds:status --drift` runs those checks when asked, and only a high-recurrence class is promoted to a write-time guard; nothing runs them on every commit by itself. Denying `TODO` \u002F `FIXME` markers at write time is a personal coding standard and belongs in an operator's own harness, not shipped to everyone who installs a plugin.\n- **Say why in comments** — same reason. Comment policy is one person's taste; a plugin that ships it imposes it.\n- **Static allocation, no recursion** — TIGER_STYLE was written for a database in Zig. These rules do not translate to Python, bash and markdown, and pretending otherwise would be cargo cult.\n\n## Not built yet\n\nNamed so nobody assumes they work:\n\n- **Formatter configs as a limit source.** Prettier's `printWidth`, black's `line-length` and rustfmt's `max_width` are not read. Only `WHETSTONE_TIGER_COLS` and `.editorconfig` are.\n- **Full `.editorconfig` glob syntax.** Brace expansion, `*`, `**`, `?`, `[seq]` and `[!seq]` work. Escapes and numeric ranges (`{1..9}`) do not, and `[^seq]` is a literal `^` — the spec's negation form is `[!seq]`. Brace expansion is capped at 256 alternatives; past the cap the pattern is left unexpanded and matches nothing, so the file falls back to the advisory limit instead of stalling the commit.\n- **Configurable tab width.** A tab advances to the next multiple of 8. `.editorconfig`'s `tab_width` and `indent_size` are not read.\n- **Per-language parsing.** Width is display columns — a tab advances to its stop, a CJK or otherwise wide character counts two, a combining mark counts zero. What is missing is an AST, so nothing here can measure a function's length or find a magic number, which is exactly why those rules sit in the manual pass above rather than in the table.\n\n## Verification\n\nDone = `tiger-check` exits 0 or 2 **and** you have read the diff against the manual pass. Exit 1 is not done: a declared limit was exceeded.\n\n## Dossier breadcrumb\n\nIn a repo with a live dossier ledger, record a non-clean verdict as one `§S` line through the dossier plugin's append tooling — `tiger=block@\u003Cn>` or `tiger=nag@\u003Cn>`. A clean run writes nothing; a log that records every uneventful pass buries the events that matter. No dossier → skip, no-op: this skill ships no hooks and needs no dossier to run.\n","# tiger-style — one shape rule computed, the rest read by hand\n\nOne TIGER_STYLE rule is cheap to compute from a diff; the rest need a reader. This skill keeps the two halves apart and labelled — a checklist presented as a gate is worse than no gate.\n\n## When to use\n\n- Before committing a change that adds source lines.\n- When a build reports `TIGER: BLOCK` or `TIGER: NAG` and you need to know which limit applied.\n- When reviewing someone else's diff for shape rather than correctness.\n\n## Run the check\n\n```bash\n\"${CLAUDE_PLUGIN_ROOT}\"\u002Fbin\u002Ftiger-check [repo-path]\n```\n\nReads the **staged** diff (`git diff --cached`), never `HEAD`. `--cached` compares HEAD against the index, which is exactly what the commit will contain. `HEAD` would compare against the working tree instead: it would flag unstaged edits the commit does not carry, and it fails outright in a repository with no commits yet — a failure the checker would read as \"nothing was added\".\n\nOnly lines the change **adds** are measured. Existing long lines are somebody else's commit.\n\n| exit | signal                                    | meaning                                                                                                   |\n| ---- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------- |\n| 0    | `TIGER: CLEAN \u003Cn> file(s)[, \u003Cm> skipped]` | no added line is over its limit, across the `\u003Cn>` files examined; `\u003Cm>` more were staged but not measured |\n| 1    | `TIGER: BLOCK \u003Cn>`                        | `\u003Cn>` added lines exceed a limit **the repo declared**                                                    |\n| 2    | `TIGER: NAG \u003Cn>`                          | `\u003Cn>` added lines exceed the built-in 100-column fallback                                                 |\n| 64   | —                                         | the path is not a git work tree                                                                           |\n\nEach offence prints as `path:line: \u003Cwidth> cols (limit \u003Cn>)` before the verdict line.\n\n`CLEAN 0 files` and `CLEAN 3 files` are both exit 0, and the difference matters: the first means nothing was measured. A caller that reads only the exit code cannot tell \"checked, fine\" from \"checked nothing\" — which is how a mis-typed `git add` reads as a pass.\n\n`CLEAN 0 files, 2 skipped` is a commit whose every file was prose, data, or declared `off` — a docs-only commit, or a bump of a lockfile the skip lists below name, reaches it correctly, and it is not a mistake. A bare `CLEAN 0 files` means no added, copied, modified, renamed or type-changed path was staged at all, which has two causes: an empty index, or a commit that stages only deletions. Deletions have no added lines to measure, so they reach neither counter. Check your `git add` over the bare form when the commit was meant to change a file.\n\nOne run can turn up both kinds at once — a declared-limit offence in one file and a fallback offence in another. Every offence is printed either way, but `\u003Cn>` in the verdict counts only the kind the verdict names. A fallback offence is never counted into a `BLOCK` and never blocks a commit, whatever else the run found.\n\n### Which limit applies\n\nResolved per file, first match wins:\n\n1. `WHETSTONE_TIGER_COLS` — a **positive** integer. Declared, so it **blocks**. `0`, a negative, or a non-number is not a limit: the value is dropped, resolution continues at the next source, and the reason is named on stderr. An operator who set `WHETSTONE_TIGER_COLS=0` in a repo with an `.editorconfig` limit therefore gets that repo's limit — still a `BLOCK`, at a number they did not choose. The stderr line is what makes that visible.\n1. `.editorconfig` `max_line_length` for the nearest section matching the file. Declared, so it **blocks**. A value of `off` is spec-legal and skips the file entirely.\n\n\"Nearest\" is directory distance: the walk starts beside the file and stops at a `root = true`. It is not specificity. Where two sections in the **same** file both match, EditorConfig's own rule applies and the later one wins — `[*.py]` followed by `[*]` loses to the `[*]`, which is the opposite of what CSS-shaped intuition predicts.\n\nA later section only wins if its value parses. `max_line_length = 0` in the more specific section leaves the broader section's limit standing, which is the same silent-ignore trap as the env var and gets the same treatment: the value is named on stderr rather than dropped.\n\n1. Nothing declared → 100 columns, and exceeding it only **nags**.\n\nThe distinction is the point: a repo that has stated its limit gets it enforced, and a repo that has not gets told, never stopped. The env var carries whetstone's own prefix rather than a `DOSSIER_` one — this is whetstone's behaviour, and it must be configurable by someone who has never installed the dossier plugin.\n\nProse and data formats are skipped outright by suffix — `.md`, `.markdown`, `.rst`, `.txt`, `.json`, `.jsonl`, `.csv`, `.tsv`, `.svg`, `.lock`, `.snap` — and by exact name: `go.sum`, `yarn.lock`, `pnpm-lock.yaml`, `poetry.lock`, `Cargo.lock`. A column limit describes a statement, not a record.\n\nThe name list carries only the lockfiles the suffix list misses. `pnpm-lock.yaml` is generated and `.github\u002Fworkflows\u002Fci.yaml` is written by hand, so skipping every `.yaml` to reach the first is not on offer. Both lists are literal, not a guess at what looks generated: a lockfile named anything else — `gradle.lockfile`, say — is measured like source, and one of its added lines over a declared limit exits 1.\n\n## The manual pass — what the script cannot judge\n\nThese are the TIGER_STYLE rules that need a reader. **Nothing enforces them.** They produce no exit code, and no tool will stop a commit that violates them. Read the diff against them yourself:\n\n- **Function length.** A function that does not fit on a screen is doing more than one thing. Split at the seam, not at the line count.\n- **Assert adequacy.** A non-trivial function asserts its preconditions. Assert the negative space too — the states that must never occur, not only the ones you expect.\n- **Loop bounds.** Every loop states an upper bound. An unbounded loop is a hang waiting for the input that triggers it.\n- **Limits as numbers.** Every limit is a named constant with a stated unit, never an inline literal. A magic number is a decision nobody can find later.\n\nTreat this list the way `skill-smith` treats its reference checklists: the exit code is the gate, the checklist is the judgement, and the two are never described as the same thing.\n\nInside a dossier build run with `--review`, the `dossier-reviewer` agent reads the diff against this same list. That does not make it a gate: its findings on these four rules are capped at `Warn:`, which cannot block a commit, and `--review` is opt-in — it auto-fires only for destructive-class tasks, a category that has nothing to do with code shape. A second reader is worth having. It is not enforcement.\n\n## What is deliberately not here\n\nFour TIGER_STYLE rules are absent on purpose, so their absence does not read as an oversight:\n\n- **Assert the negative space, as a testing rule** — already carried by the repo's testing standard: `run-slice` fails a slice whose test passed on its first run, and every gate is required to ship a positive and a negative test. That is the same rule enforced one level up, at the test rather than at the function.\n- **Zero technical debt** — a caught bug becomes a recorded, testable invariant through the dossier plugin's backprop verb. `ds:status --drift` runs those checks when asked, and only a high-recurrence class is promoted to a write-time guard; nothing runs them on every commit by itself. Denying `TODO` \u002F `FIXME` markers at write time is a personal coding standard and belongs in an operator's own harness, not shipped to everyone who installs a plugin.\n- **Say why in comments** — same reason. Comment policy is one person's taste; a plugin that ships it imposes it.\n- **Static allocation, no recursion** — TIGER_STYLE was written for a database in Zig. These rules do not translate to Python, bash and markdown, and pretending otherwise would be cargo cult.\n\n## Not built yet\n\nNamed so nobody assumes they work:\n\n- **Formatter configs as a limit source.** Prettier's `printWidth`, black's `line-length` and rustfmt's `max_width` are not read. Only `WHETSTONE_TIGER_COLS` and `.editorconfig` are.\n- **Full `.editorconfig` glob syntax.** Brace expansion, `*`, `**`, `?`, `[seq]` and `[!seq]` work. Escapes and numeric ranges (`{1..9}`) do not, and `[^seq]` is a literal `^` — the spec's negation form is `[!seq]`. Brace expansion is capped at 256 alternatives; past the cap the pattern is left unexpanded and matches nothing, so the file falls back to the advisory limit instead of stalling the commit.\n- **Configurable tab width.** A tab advances to the next multiple of 8. `.editorconfig`'s `tab_width` and `indent_size` are not read.\n- **Per-language parsing.** Width is display columns — a tab advances to its stop, a CJK or otherwise wide character counts two, a combining mark counts zero. What is missing is an AST, so nothing here can measure a function's length or find a magic number, which is exactly why those rules sit in the manual pass above rather than in the table.\n\n## Verification\n\nDone = `tiger-check` exits 0 or 2 **and** you have read the diff against the manual pass. Exit 1 is not done: a declared limit was exceeded.\n\n## Dossier breadcrumb\n\nIn a repo with a live dossier ledger, record a non-clean verdict as one `§S` line through the dossier plugin's append tooling — `tiger=block@\u003Cn>` or `tiger=nag@\u003Cn>`. A clean run writes nothing; a log that records every uneventful pass buries the events that matter. No dossier → skip, no-op: this skill ships no hooks and needs no dossier to run.\n",{"name":5,"description":7},"main","718ea193fb0c08761758130b858c138b908ef193","plugins\u002Fwhetstone\u002Fskills\u002Ftiger-style",0,"https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins","https:\u002F\u002Fgithub.com\u002Fraisedadead","https:\u002F\u002Fmrugesh.dev","dad • dev\u002F\u002Fops • open-source","2026-11-13 12:58:58",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add raisedadead\u002Fclaude-code-plugins --skill tiger-style",{"tool":39,"command":40},"bunx","bunx skills add raisedadead\u002Fclaude-code-plugins --skill tiger-style",{"tool":42,"command":43},"pnpm","pnpm dlx skills add raisedadead\u002Fclaude-code-plugins --skill tiger-style","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fwhetstone\u002Fskills\u002Ftiger-style\u002FSKILL.md",true,[47,53],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"scripts\u002Ftiger-check-cli.ts","SCRIPT","脚本",12156,"https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fwhetstone\u002Fskills\u002Ftiger-style\u002Fscripts\u002Ftiger-check-cli.ts",{"path":54,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":55,"sourceHtmlUrl":56},"scripts\u002Funicode-width.ts",6728,"https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fwhetstone\u002Fskills\u002Ftiger-style\u002Fscripts\u002Funicode-width.ts",[58,66,73,80,87,94],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":65},"01M76ACYEV4AABQFW2E5F0JGDK","suite-review","Run the monthly evidence review of this repo's plugin skills. Count each skill's opportunities and uses with the census, read what happened where a skill was not used, put each skill in one bucket, act, and write the actions as predictions with a check date. Use when the operator says \"suite review\" or \"monthly review\", or when the suite-review line on LATER.md is due.","https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsuite-review\u002FSKILL.md",[],[],"2026-11-12 13:55:43",{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":19},"01M72WDX5A781BKCTSDN0GF3M8","tdd-cycle","Drive one vertical slice of behaviour red-green-refactor, seam agreed before the first test. Use when the user asks to add a feature, fix a bug, write code test-first, says \"TDD this\", \"red green refactor\", or \"write a failing test first\". Inside a live dossier:build covenant, invoke dossier:build instead — it composes this skill's run-slice command as its RED\u002FGREEN proof.","https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fwhetstone\u002Fskills\u002Ftdd-cycle\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":19},"01M72WDPE6ESWEK5GVRRRV5EC1","prototype","Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.","https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fwhetstone\u002Fskills\u002Fprototype\u002FSKILL.md",[],[],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":19},"01M72WD6W8XSQT2RHRE3VV9ED6","doubt-pass","Adversarial doubt cycle on a plan or design before any code exists — distinct from post-hoc code review. Use when the user asks to doubt this, stress-test a design before building it, poke holes in a plan, find the flaw in an approach, or before committing to a non-trivial architecture or design decision.","https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fwhetstone\u002Fskills\u002Fdoubt-pass\u002FSKILL.md",[],[],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":19},"01M72WD2MWAENN8RKFD9AXHQ3B","diagnose","Diagnose a hard bug or a performance regression with a feedback loop first, then ranked hypotheses, instrumentation and a regression test. Use when the user says diagnose or debug this, or reports something broken, throwing, failing or slow.","https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fwhetstone\u002Fskills\u002Fdiagnose\u002FSKILL.md",[],[],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":19},"01M72WCWGQNB8NCAER3CRXSCHH","verify","Empirical fact-check for freshness-sensitive claims — versions, EOLs, package latest, GitHub Action SHAs, k8s apiVersions, AI model deprecations, image tags, or anything the model's training cutoff may have staled. Primary sources only. Auto-fires as a PreToolUse hook on Edit\u002FWrite, but only in a repo with a `.scratchpad\u002Fdossier\u002F` directory; `\u002Fdossier:verify` on demand works anywhere. Invoke when user says \"verify\", \"fact-check\", \"is this current\", \"\u002Fdossier:verify\", \"double check\", or when reviewing freshness claims.","https:\u002F\u002Fgithub.com\u002Fraisedadead\u002Fclaude-code-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fdossier\u002Fskills\u002Fverify\u002FSKILL.md",[],[]]