[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J3Z71KR82KTVP2PKG23NJG":3,"skill-same:01M6J3Z71KR82KTVP2PKG23NJG":82},{"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":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":14,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6J3Z71KR82KTVP2PKG23NJG","investigate",null,"Settle a factual claim about this repo with a measurement, not a\nrecollection. Use when a number, a date, or a current state is asserted and\nneeds checking: verify a figure in a doc or plan, establish when a change\nactually landed, reproduce a past measurement, or confirm whether something\nis really enabled\u002Fdisabled\u002Fenforced. Forces a cross-check by a second\nINDEPENDENT method and a positive control, because a zero result and a\nbroken instrument look identical.\nPick by INPUT: a CLAIM to test comes here (\"the cache cut cost 40%\", \"that\nlanded in July\"); a TOPIC to survey goes to \u002Fexplain --history (\"have we\ntouched rate limiting?\"). \"Why is it this way\" is \u002Fexplain.\nTriggers on: \"verify that\", \"is that number right\", \"is this still true\",\n\"when did we actually\", \"did that change land\", \"reproduce the measurement\",\n\"check whether X is really\", \"confirm the claim\", \"\u002Finvestigate\".\nFull command syntax: see the Usage section in this skill.","Lbstrydom\u002Fclaude-engineering-skills","Lbstrydom","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F77991486?v=4","01M6J3X4N2T0FTZT1RKFXDVS0K","Louis Strydom","01M6J3X4SXV0BXWDMXPW90D8BK",0,"MIT","https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finvestigate\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"full","when","result","rate","positive control","past","number","usage","measurement","goes","input","cut","change","claim","survey","command","broken","syntax","pick","plan","why","doc","land","2026-11-10 10:12:30",false,"---\nname: investigate\ndescription: |\n  Settle a factual claim about this repo with a measurement, not a\n  recollection. Use when a number, a date, or a current state is asserted and\n  needs checking: verify a figure in a doc or plan, establish when a change\n  actually landed, reproduce a past measurement, or confirm whether something\n  is really enabled\u002Fdisabled\u002Fenforced. Forces a cross-check by a second\n  INDEPENDENT method and a positive control, because a zero result and a\n  broken instrument look identical.\n  Pick by INPUT: a CLAIM to test comes here (\"the cache cut cost 40%\", \"that\n  landed in July\"); a TOPIC to survey goes to \u002Fexplain --history (\"have we\n  touched rate limiting?\"). \"Why is it this way\" is \u002Fexplain.\n  Triggers on: \"verify that\", \"is that number right\", \"is this still true\",\n  \"when did we actually\", \"did that change land\", \"reproduce the measurement\",\n  \"check whether X is really\", \"confirm the claim\", \"\u002Finvestigate\".\n  Full command syntax: see the Usage section in this skill.\n---\n\n# Investigate\n\n> **Worktree preflight** — in a linked git worktree the synced tooling tree\n> `scripts\u002F.claude-skills\u002F` is absent — it is gitignored, so `git worktree add`\n> does not populate it, and every command below that uses it dies on a bare\n> `MODULE_NOT_FOUND`. Run `npm run skills:hydrate` first. If this repo defines\n> no such script, `references\u002Fworktree-preflight.md` holds the entry to add — ask\n> the user first, since it edits their `package.json`.\n\n## Usage\n\n```\nUsage:\n  \u002Finvestigate \"\u003Cclaim or question>\"    — verify one claim\n  \u002Finvestigate \"\u003Cclaim>\" --brief        — emit a brief for a sub-agent\u002Fsession\n```\n\nFor claims with a truth value an instrument can settle. Two investigations on\n2026-08-03 returned correct answers *despite* the method prescribed for them\nbeing wrong — the answers were right by luck. This skill exists so the next one\nis right on purpose.\n\n**Scope firewall**: include a step only if it changes what you *measure*. \"Why\nis this code shaped this way\" is `\u002Fexplain` — recorded rationale, not\nmeasurement. \"Is the plan implemented\" is `\u002Fux-lock verify`. \"Is the code\ncorrect\" is `\u002Faudit-code`.\n\n---\n\n## The failure this skill prevents\n\nBoth 2026-08-03 briefs named a specific command. In both cases the named\ncommand fails **silently** on the exact question being asked — it returns a\nconfident, well-formed, wrong answer rather than an error.\n\n| Prescribed | Why it fails silently |\n|---|---|\n| `docker image inspect --format '{{.Size}}'` | Under the containerd snapshotter this returns *content* size, not the *disk usage* figure the claim cited. They differ by 3.6x. Following the brief would have produced a rigorously-derived false contradiction. |\n| `git log -S 'python3 make g++'` | The commit removed the string from a `RUN` line and re-added it verbatim in a comment. Net occurrence count unchanged, so `-S` reports nothing. A reader reproducing the stated method would conclude the change never happened. |\n\nBoth over-specified *how* and under-specified *what quantity is in question*.\n\n> The pickaxe case is **live in this repo**. `scripts\u002Fexplain-history.mjs` ran\n> `git log --all -S \u003Ctopic>` as its content search. Measured on 2026-08-04:\n> `-S 'runJsonLinesAsyncStrict'` → 18 commits; `-G` on the same symbol → 35.\n> Seventeen commits that touched lines containing the symbol were invisible to\n> the tool this repo ships for answering \"have we touched this before?\" Pass C\n> (`-G`, `source: git-touched`) was added the same day.\n\n---\n\n## Step 1 — State the quantity, before naming a tool\n\nWrite down what is actually in question — the measurement, event or object —\nand *how you know that is the one the source meant*. Do not assume the obvious\nreading. `.Size` and disk usage are both \"the image size\"; only one is the\nclaim's figure.\n\nIf the brief you were handed names a command, treat that as a hint about intent,\nnot an instruction. Say which quantity you concluded it meant, and why.\n\nAlso settle **which question**: verifying a historical claim and assessing\ncurrent state are different. \"Does the July figure reproduce at that commit\"\nand \"does the number still hold for what is deployed today\" have different\nanswers. Say which one you are answering, and if you think the other is the one\nthat matters, say so.\n\n## Step 2 — Choose the instrument, then break it on purpose\n\nState the method you chose and why. Then:\n\nFor \"when did this change\" questions, `\u002Fexplain --history \"\u003Ctopic>\"` is the\nrepo's cross-source instrument (git subject-grep + `-S` + `-G`, arch-memory,\nplans, brainstorm ledger) — use it rather than a hand-rolled `git log`, and\ntreat its four sources as candidate cross-checks. For \"is this stated gate\nactually enforced\" questions, `npm run gates:check` reads the `gate-contract.json`\nbinding directly. Neither removes the obligations below.\n\n- **Cross-check with a second, independent method.** Independent means it does\n  not share an input with the first. Two readings derived from one capture are\n  one observation, not two — that is how a fabricated finding survives four\n  review passes (see `docs\u002Frunbooks\u002Fpre-ship-empirical-verify.md`).\n- **Reconcile any disagreement, and report it even if you resolve it.** A\n  reconciled disagreement is the most informative thing in the report; deleting\n  it because you settled it discards the evidence that the first number was\n  ambiguous.\n- **Require a positive control.** A wall of zero matches, empty results or\n  denials is indistinguishable from a broken harness, a dead endpoint, a\n  revoked credential or a typo'd path. State what result would prove the\n  instrument was working, run that too, and report it alongside. This is the\n  same rule as \"can this gate return green without having checked anything?\" —\n  applied to your own measurement instead of to a code path.\n\n**Capture, don't summarise.** A transcript showing only the successful commands\nis a reconstruction. Include failures and retries, in the order issued. Name any\nevidence file using the actual capture date, determined at run time — not a date\ncopied from the brief.\n\n## Step 2.5 — Verify the attribution, not just the figure\n\nReproducing a number does not test the sentence it sits in. A recorded \"22.5%\nimage-size reduction\" **reproduced perfectly** while its stated cause was false:\nthe parent commit already had the property being credited, and the real mechanism\naccounted for **92%** of the delta. A pass that checks figures and not\nattributions clears both.\n\nSo whenever the claim names a *cause* — \"X made it faster \u002F smaller \u002F safer\":\n\n- **Ask whether the parent already had the property being credited.** Inspect the\n  parent for it directly. This is the whole check, and it is usually one command.\n- **Ask the build system where one can answer.** In the source case a resolver\n  settled it independently of reading any file: one target resolved at the parent,\n  the other did not.\n- **Decompose the delta.** 92\u002F8 is a different story from 50\u002F50, and only\n  measurement distinguishes them.\n\n**Report two verdicts, never one**: `figure: reproduced | refuted` and\n`attribution: confirmed | refuted | untested`. Fusing them is the artefact that\nmisleads — and `untested` is a legitimate result to report.\n\nThe chronological trap is the sibling, in both directions: do not infer causation\nfrom proximity (Step 3), and check the order actually holds — in the same\nengagement a campaign credited with enabling a migration began *ninety minutes\nafter* that migration merged.\n\n→ `references\u002Fverification-discipline.md` §4.\n\n## Step 3 — Report without softening\n\n- **Label every figure `measured` \u002F `derived` \u002F `expected`, and carry the fields\n  its kind requires** — for `measured`, the exact command, the working context,\n  the immutable revision, the observation time; for `derived`, its sources and\n  formula; for `expected`, its basis and an explicit note that it is not a\n  measurement. A label with no evidence behind it is the same shape as a green\n  with no check. A documented test count once sat stale by 2.3x on count and\n  6.7x on wall clock, and nothing in the row said when it had last been true.\n- **Name the metric.** \"Size\" and \"faster\" name nothing: one container image\n  reported three sizes varying by **3.6x** depending on tool and storage driver.\n- **Pin any `file:line` you cite to the commit you read it at** — `path:120\n  (a4ec98da)`. Cite append-newest-first files (`status.md`, changelogs) by\n  section header, never by line. A path is durable; a path plus a line is a\n  snapshot. Five of nine bad claims in one verified document were correct when\n  written and decayed afterwards. → `references\u002Fverification-discipline.md` §1-2.\n- Where the evidence does not settle a question, say it does not settle it.\n  **Absence of a recorded rationale is a finding, not a gap to fill with a\n  plausible one.** Confabulating a plausible rationale is the default\n  behaviour, and it is indistinguishable from a real one in the output.\n- Do not infer causation from chronological proximity. Two commits one day\n  apart were driven by unrelated goals in the case that prompted this rule.\n- If history was rewritten, squashed, or the record is otherwise unavailable,\n  say so explicitly rather than working around it.\n\n## Step 4 — Recommend, open-endedly\n\nRecommend a position and justify it. Any options you list are illustrative, not\nexhaustive. If the honest answer is a split — drop one half of the claim, keep\nthe other — say so. In one of the two source investigations the true answer was\nexactly that split, and a closed menu did not contain it.\n\n---\n\n## Two different failure modes — do not merge them\n\nThe 2026-08-03 briefs got one half right and one half wrong, and the halves are\nindependent. Both belong in any brief you write:\n\n**Incentive design — this worked, keep doing it.** Removing the reward for a\npleasing answer, by pre-authorising the unpleasing one and naming the specific\ncheat paths:\n\n> A failed reproduction is a legitimate and reportable result.\n> I would rather narrow the claim than defend an inflated one.\n> Do not adjust the figures to match a fresh build.\n> Do not substitute a different commit or patch the old file to make it build.\n\nGeneric instructions to \"be rigorous\" do nothing; naming *this task's* specific\ncorruption does.\n\n**Method prescription — this failed, and it is the harder one to see.** The\nincentive failures are visible: you can read a brief and notice it is leading\nthe witness. A wrong instrument is invisible from the brief — it looks like\nrigour. It only surfaces when someone knows the tool's semantics, and the whole\npoint of delegating was that they might not.\n\n## Four things not to put in a brief\n\n1. **Do not prescribe the command.** Ask for the quantity plus a justified\n   method and a cross-check.\n2. **Do not offer a forced-choice menu with a pre-endorsed option.** A closed\n   menu plus a stated preference produces a worse answer than an open question.\n3. **Do not hardcode unverified values.** An evidence filename was dated a day\n   ahead of the actual capture — in a brief about appearance versus reality.\n4. **Do not issue unscoped destructive cleanup.** \"Prune afterwards\" on a host\n   with 25 images, 166 volumes and other projects' builds would have destroyed\n   unrelated work. Clean up only what this task created, by name or tag.\n\n---\n\n## Reference files\n\nThis skill's canonical flow is above. The files below cover specialised\nsituations — read them only when the trigger applies.\n\n| File | Summary | Read when |\n|---|---|---|\n| `references\u002Fbrief-skeleton.md` | Copy-paste brief template for delegating an investigation to a sub-agent or fresh session. | Invoked with `--brief`, OR the user is writing instructions for another agent\u002Fsession to run the investigation. |\n| `references\u002Fverification-discipline.md` | Verification discipline — pinned citations, figure provenance, two-direction proof, attribution, consumer-side checks. | Step 2.5 — the claim names a cause and the attribution needs testing, OR Step 3 — writing figures or `file:line` citations into a durable document. |\n| `references\u002Fworktree-preflight.md` | Worktree preflight remedy — the skills:hydrate npm script to add when a linked worktree lacks the tooling tree. | A command dies with `MODULE_NOT_FOUND` in a linked worktree AND this repo has no `skills:hydrate` script. |\n","# Investigate\n\n> **Worktree preflight** — in a linked git worktree the synced tooling tree\n> `scripts\u002F.claude-skills\u002F` is absent — it is gitignored, so `git worktree add`\n> does not populate it, and every command below that uses it dies on a bare\n> `MODULE_NOT_FOUND`. Run `npm run skills:hydrate` first. If this repo defines\n> no such script, `references\u002Fworktree-preflight.md` holds the entry to add — ask\n> the user first, since it edits their `package.json`.\n\n## Usage\n\n```\nUsage:\n  \u002Finvestigate \"\u003Cclaim or question>\"    — verify one claim\n  \u002Finvestigate \"\u003Cclaim>\" --brief        — emit a brief for a sub-agent\u002Fsession\n```\n\nFor claims with a truth value an instrument can settle. Two investigations on\n2026-08-03 returned correct answers *despite* the method prescribed for them\nbeing wrong — the answers were right by luck. This skill exists so the next one\nis right on purpose.\n\n**Scope firewall**: include a step only if it changes what you *measure*. \"Why\nis this code shaped this way\" is `\u002Fexplain` — recorded rationale, not\nmeasurement. \"Is the plan implemented\" is `\u002Fux-lock verify`. \"Is the code\ncorrect\" is `\u002Faudit-code`.\n\n---\n\n## The failure this skill prevents\n\nBoth 2026-08-03 briefs named a specific command. In both cases the named\ncommand fails **silently** on the exact question being asked — it returns a\nconfident, well-formed, wrong answer rather than an error.\n\n| Prescribed | Why it fails silently |\n|---|---|\n| `docker image inspect --format '{{.Size}}'` | Under the containerd snapshotter this returns *content* size, not the *disk usage* figure the claim cited. They differ by 3.6x. Following the brief would have produced a rigorously-derived false contradiction. |\n| `git log -S 'python3 make g++'` | The commit removed the string from a `RUN` line and re-added it verbatim in a comment. Net occurrence count unchanged, so `-S` reports nothing. A reader reproducing the stated method would conclude the change never happened. |\n\nBoth over-specified *how* and under-specified *what quantity is in question*.\n\n> The pickaxe case is **live in this repo**. `scripts\u002Fexplain-history.mjs` ran\n> `git log --all -S \u003Ctopic>` as its content search. Measured on 2026-08-04:\n> `-S 'runJsonLinesAsyncStrict'` → 18 commits; `-G` on the same symbol → 35.\n> Seventeen commits that touched lines containing the symbol were invisible to\n> the tool this repo ships for answering \"have we touched this before?\" Pass C\n> (`-G`, `source: git-touched`) was added the same day.\n\n---\n\n## Step 1 — State the quantity, before naming a tool\n\nWrite down what is actually in question — the measurement, event or object —\nand *how you know that is the one the source meant*. Do not assume the obvious\nreading. `.Size` and disk usage are both \"the image size\"; only one is the\nclaim's figure.\n\nIf the brief you were handed names a command, treat that as a hint about intent,\nnot an instruction. Say which quantity you concluded it meant, and why.\n\nAlso settle **which question**: verifying a historical claim and assessing\ncurrent state are different. \"Does the July figure reproduce at that commit\"\nand \"does the number still hold for what is deployed today\" have different\nanswers. Say which one you are answering, and if you think the other is the one\nthat matters, say so.\n\n## Step 2 — Choose the instrument, then break it on purpose\n\nState the method you chose and why. Then:\n\nFor \"when did this change\" questions, `\u002Fexplain --history \"\u003Ctopic>\"` is the\nrepo's cross-source instrument (git subject-grep + `-S` + `-G`, arch-memory,\nplans, brainstorm ledger) — use it rather than a hand-rolled `git log`, and\ntreat its four sources as candidate cross-checks. For \"is this stated gate\nactually enforced\" questions, `npm run gates:check` reads the `gate-contract.json`\nbinding directly. Neither removes the obligations below.\n\n- **Cross-check with a second, independent method.** Independent means it does\n  not share an input with the first. Two readings derived from one capture are\n  one observation, not two — that is how a fabricated finding survives four\n  review passes (see `docs\u002Frunbooks\u002Fpre-ship-empirical-verify.md`).\n- **Reconcile any disagreement, and report it even if you resolve it.** A\n  reconciled disagreement is the most informative thing in the report; deleting\n  it because you settled it discards the evidence that the first number was\n  ambiguous.\n- **Require a positive control.** A wall of zero matches, empty results or\n  denials is indistinguishable from a broken harness, a dead endpoint, a\n  revoked credential or a typo'd path. State what result would prove the\n  instrument was working, run that too, and report it alongside. This is the\n  same rule as \"can this gate return green without having checked anything?\" —\n  applied to your own measurement instead of to a code path.\n\n**Capture, don't summarise.** A transcript showing only the successful commands\nis a reconstruction. Include failures and retries, in the order issued. Name any\nevidence file using the actual capture date, determined at run time — not a date\ncopied from the brief.\n\n## Step 2.5 — Verify the attribution, not just the figure\n\nReproducing a number does not test the sentence it sits in. A recorded \"22.5%\nimage-size reduction\" **reproduced perfectly** while its stated cause was false:\nthe parent commit already had the property being credited, and the real mechanism\naccounted for **92%** of the delta. A pass that checks figures and not\nattributions clears both.\n\nSo whenever the claim names a *cause* — \"X made it faster \u002F smaller \u002F safer\":\n\n- **Ask whether the parent already had the property being credited.** Inspect the\n  parent for it directly. This is the whole check, and it is usually one command.\n- **Ask the build system where one can answer.** In the source case a resolver\n  settled it independently of reading any file: one target resolved at the parent,\n  the other did not.\n- **Decompose the delta.** 92\u002F8 is a different story from 50\u002F50, and only\n  measurement distinguishes them.\n\n**Report two verdicts, never one**: `figure: reproduced | refuted` and\n`attribution: confirmed | refuted | untested`. Fusing them is the artefact that\nmisleads — and `untested` is a legitimate result to report.\n\nThe chronological trap is the sibling, in both directions: do not infer causation\nfrom proximity (Step 3), and check the order actually holds — in the same\nengagement a campaign credited with enabling a migration began *ninety minutes\nafter* that migration merged.\n\n→ `references\u002Fverification-discipline.md` §4.\n\n## Step 3 — Report without softening\n\n- **Label every figure `measured` \u002F `derived` \u002F `expected`, and carry the fields\n  its kind requires** — for `measured`, the exact command, the working context,\n  the immutable revision, the observation time; for `derived`, its sources and\n  formula; for `expected`, its basis and an explicit note that it is not a\n  measurement. A label with no evidence behind it is the same shape as a green\n  with no check. A documented test count once sat stale by 2.3x on count and\n  6.7x on wall clock, and nothing in the row said when it had last been true.\n- **Name the metric.** \"Size\" and \"faster\" name nothing: one container image\n  reported three sizes varying by **3.6x** depending on tool and storage driver.\n- **Pin any `file:line` you cite to the commit you read it at** — `path:120\n  (a4ec98da)`. Cite append-newest-first files (`status.md`, changelogs) by\n  section header, never by line. A path is durable; a path plus a line is a\n  snapshot. Five of nine bad claims in one verified document were correct when\n  written and decayed afterwards. → `references\u002Fverification-discipline.md` §1-2.\n- Where the evidence does not settle a question, say it does not settle it.\n  **Absence of a recorded rationale is a finding, not a gap to fill with a\n  plausible one.** Confabulating a plausible rationale is the default\n  behaviour, and it is indistinguishable from a real one in the output.\n- Do not infer causation from chronological proximity. Two commits one day\n  apart were driven by unrelated goals in the case that prompted this rule.\n- If history was rewritten, squashed, or the record is otherwise unavailable,\n  say so explicitly rather than working around it.\n\n## Step 4 — Recommend, open-endedly\n\nRecommend a position and justify it. Any options you list are illustrative, not\nexhaustive. If the honest answer is a split — drop one half of the claim, keep\nthe other — say so. In one of the two source investigations the true answer was\nexactly that split, and a closed menu did not contain it.\n\n---\n\n## Two different failure modes — do not merge them\n\nThe 2026-08-03 briefs got one half right and one half wrong, and the halves are\nindependent. Both belong in any brief you write:\n\n**Incentive design — this worked, keep doing it.** Removing the reward for a\npleasing answer, by pre-authorising the unpleasing one and naming the specific\ncheat paths:\n\n> A failed reproduction is a legitimate and reportable result.\n> I would rather narrow the claim than defend an inflated one.\n> Do not adjust the figures to match a fresh build.\n> Do not substitute a different commit or patch the old file to make it build.\n\nGeneric instructions to \"be rigorous\" do nothing; naming *this task's* specific\ncorruption does.\n\n**Method prescription — this failed, and it is the harder one to see.** The\nincentive failures are visible: you can read a brief and notice it is leading\nthe witness. A wrong instrument is invisible from the brief — it looks like\nrigour. It only surfaces when someone knows the tool's semantics, and the whole\npoint of delegating was that they might not.\n\n## Four things not to put in a brief\n\n1. **Do not prescribe the command.** Ask for the quantity plus a justified\n   method and a cross-check.\n2. **Do not offer a forced-choice menu with a pre-endorsed option.** A closed\n   menu plus a stated preference produces a worse answer than an open question.\n3. **Do not hardcode unverified values.** An evidence filename was dated a day\n   ahead of the actual capture — in a brief about appearance versus reality.\n4. **Do not issue unscoped destructive cleanup.** \"Prune afterwards\" on a host\n   with 25 images, 166 volumes and other projects' builds would have destroyed\n   unrelated work. Clean up only what this task created, by name or tag.\n\n---\n\n## Reference files\n\nThis skill's canonical flow is above. The files below cover specialised\nsituations — read them only when the trigger applies.\n\n| File | Summary | Read when |\n|---|---|---|\n| `references\u002Fbrief-skeleton.md` | Copy-paste brief template for delegating an investigation to a sub-agent or fresh session. | Invoked with `--brief`, OR the user is writing instructions for another agent\u002Fsession to run the investigation. |\n| `references\u002Fverification-discipline.md` | Verification discipline — pinned citations, figure provenance, two-direction proof, attribution, consumer-side checks. | Step 2.5 — the claim names a cause and the attribution needs testing, OR Step 3 — writing figures or `file:line` citations into a durable document. |\n| `references\u002Fworktree-preflight.md` | Worktree preflight remedy — the skills:hydrate npm script to add when a linked worktree lacks the tooling tree. | A command dies with `MODULE_NOT_FOUND` in a linked worktree AND this repo has no `skills:hydrate` script. |\n",{"name":5,"description":7},"main","938efbef34b7c76f0d112f336d1ac4018224d186",".claude\u002Fskills\u002Finvestigate","https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills","https:\u002F\u002Fgithub.com\u002FLbstrydom","Studying M.Sc Computer Science at Heriot Watt","2026-11-14 03:15:23",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add Lbstrydom\u002Fclaude-engineering-skills --skill investigate",{"tool":60,"command":61},"bunx","bunx skills add Lbstrydom\u002Fclaude-engineering-skills --skill investigate",{"tool":63,"command":64},"pnpm","pnpm dlx skills add Lbstrydom\u002Fclaude-engineering-skills --skill investigate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finvestigate\u002FSKILL.md",true,[68,74,78],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fbrief-skeleton.md","REFERENCE","参考文档",4185,"https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finvestigate\u002Freferences\u002Fbrief-skeleton.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fverification-discipline.md",28340,"https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finvestigate\u002Freferences\u002Fverification-discipline.md",{"path":79,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fworktree-preflight.md",3413,"https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finvestigate\u002Freferences\u002Fworktree-preflight.md",[83,101,112,132,146,181],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":94,"publishedAt":42},"01M6J45X4FDB2AD5BGS4R4QY8X","stated-absent","Negative fixture — the contract's stated string never appears in this file.","https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fgate-honesty\u002Fnegative\u002Fstated-absent\u002Fskills\u002Fstated-absent\u002FSKILL.md",[89],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[95,96,97,98,99,100],"stated absent","STRING","fixture","contract","never","file",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":42},"01M6J45TAX2PPHETZ5TJZG20QQ","nonexistent-implementation","Negative fixture — contract references an implementation file that does not exist.","https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fgate-honesty\u002Fnegative\u002Fnonexistent-implementation\u002Fskills\u002Fnonexistent-implementation\u002FSKILL.md",[107],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[109,110,97,111,98,100],"implementation","nonexistent implementation","references",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":123,"publishedAt":42},"01M6J45P5GN52YFMZ81T7NN1VF","document-only-with-params","Negative fixture — a document-only gate illegally carries params (schema must refuse this fake-check pattern).","https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fgate-honesty\u002Fnegative\u002Fdocument-only-with-params\u002Fskills\u002Fdocument-only-with-params\u002FSKILL.md",[118],{"categoryNo":119,"categoryName":120,"taxonomyType":121,"taxonomyTypeDesc":122},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[124,125,126,127,128,97,129,130,131],"only","document","document only with params","with","pattern","gate","schema","check",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":141,"publishedAt":42},"01M6J45J1CCZ7AXDGQKBA9VC8M","lying-skill","Fixture skill for the gate-honesty self-check — every gate here is deliberately dishonest.","https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fgate-honesty\u002Flying-skill\u002Fskills\u002Flying-skill\u002FSKILL.md",[138],{"categoryNo":139,"categoryName":140,"taxonomyType":121,"taxonomyTypeDesc":122},"01JBSEEDCAT000000000000023","Skill与智能体开发",[142,97,143,129,144,145,131],"lying skill","self","for","fixture skill",{"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":161,"publishedAt":42},"01M6J45CW0DNN7K2W39E3PQHEY","visual-audit","Math-first, deterministic visual\u002Fpaint inspection — the 4th UX lens, complementing\npersona-test (journey), click-test (page), and nav-audit (system). Drives Playwright +\ncomputed styles + bounding boxes + CDP forced-pseudo-state to audit declared-token\nconformance, light\u002Fdark theme parity, layout physics, and affordance signifiers. A VLM\nis advisory-only and never gates. CI gate is drift-only on the changed contracted surface.\nTriggers on: \"visual audit\", \"check styling consistency\", \"theme parity\", \"dark mode parity\",\n\"design token drift\", \"paint audit\", \"button\u002Fcard consistency\", \"focus ring audit\",\n\"\u002Fvisual-audit\".","https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-audit\u002FSKILL.md",[152,155,158],{"categoryNo":153,"categoryName":154,"taxonomyType":121,"taxonomyTypeDesc":122},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":156,"categoryName":157,"taxonomyType":121,"taxonomyTypeDesc":122},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":159,"categoryName":160,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000032","设计师",[162,163,164,165,166,167,168,169,170,171,172,99,173,174,175,176,177,178,124,179,180],"visual audit","visual","audit","inspection","layout","math","focus","design token","cdp","lens","click","physics","card","mode","ci","design","journey","persona","drift",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":193,"publishedAt":42},"01M6J4569S40ZASFWW698CHBKP","ux-lock","Generate Playwright e2e specs. Two modes:\n  1. LOCK mode — pin a fix's DOM contract so it doesn't regress (default).\n  2. VERIFY mode — check that a \u002Fplan plan was actually implemented\n     by parsing its Acceptance Criteria section and driving the live URL.\nVERIFY mode grades a plan against a RUNNING app. To judge the plan document\nitself, before anything is built, that is \u002Faudit-plan.\nTriggers on: \"ux lock\", \"lock ux\", \"lock in the fix\", \"write regression spec\",\n\"generate e2e test for\", \"regression test for commit\", \"lock this fix\",\n\"verify the plan\", \"verify plan implementation\", \"check the plan was built\",\n\"audit frontend implementation\", \"did we ship the plan\".\nFull command syntax: see the Usage section in this skill.","https:\u002F\u002Fgithub.com\u002FLbstrydom\u002Fclaude-engineering-skills\u002Fblob\u002Fmain\u002Fskills\u002Fux-lock\u002FSKILL.md",[187,188,191,192],{"categoryNo":153,"categoryName":154,"taxonomyType":121,"taxonomyTypeDesc":122},{"categoryNo":189,"categoryName":190,"taxonomyType":121,"taxonomyTypeDesc":122},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":159,"categoryName":160,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[194,195,196,36,197,198,199,175,200,201,202,203,204,205,38,34,206,164,207,208,209],"ux","lock","ux lock","app","regression","e2e test","default","fix","frontend","acceptance","URL","commit","generate","write","judge","verify plan"]