[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M750AMV15JYTMKMBERCD201C":3,"skill-same:01M750AMV15JYTMKMBERCD201C":61},{"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},"01M750AMV15JYTMKMBERCD201C","create-verification-skill",null,"Generate a project-local verification skill that drives your app the way a user does — any language, framework, or platform. Use for \u002Fcreate-verification-skill, \"make a control skill for this repo\", \"make a driver skill for this repo\", or when a project has no scripted way to prove UI\u002FCLI\u002Fservice behavior.","michael-denyer\u002Fpstack-claude","michael-denyer","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F97485362?v=4","01M7509NWA6PC2Z183SZ6D78FT","Michael Denyer","01M7509NX1YE4AYWW6Y30TCCRV",4309,"MIT","https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: create-verification-skill\ndescription: \"Generate a project-local verification skill that drives your app the way a user does — any language, framework, or platform. Use for \u002Fcreate-verification-skill, \\\"make a control skill for this repo\\\", \\\"make a driver skill for this repo\\\", or when a project has no scripted way to prove UI\u002FCLI\u002Fservice behavior.\"\n---\n\n# Create a verification skill\n\nOn Codex, read the [platform mapping](..\u002Fpoteto-mode\u002Freferences\u002Fcodex-tools.md), including its per-skill notes, before following this skill.\n\nOn GitHub Copilot, read the [platform mapping](..\u002Fpoteto-mode\u002Freferences\u002Fcopilot-tools.md), including its per-skill notes, before following this skill.\n\nOn Muse, read the [platform mapping](..\u002Fpoteto-mode\u002Freferences\u002Fmuse-tools.md), including its per-skill notes, before following this skill.\n\nOn Antigravity, read the [platform mapping](..\u002Fpoteto-mode\u002Freferences\u002Fagy-tools.md), including its per-skill notes, before following this skill.\n\nEvery serious project needs a scripted way to drive the real app and prove behavior: launch it, exercise a feature the way a user would, and capture evidence. This skill generates that as a project-local skill (`.claude\u002Fskills\u002Fverify\u002F`) tailored to the repo. Name it `verify`. At the repo root a project skill by that name replaces Claude Code's bundled `\u002Fverify`, which only the user can invoke, so every playbook that names the driver skill can call the project one ([Claude Code 2.1.200 or later](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fskills#run-and-verify-your-app)). In a monorepo, write it in the touched package directory instead. You write the generator's output for the next agent, not for a human: it will be read cold, mid-task, by an agent that has never seen the app.\n\n## 1. Interview the repo, not the user\n\nAnswer these from the codebase and only ask the user what you cannot observe:\n\n- **Surface:** what does a user actually touch? A web UI, a CLI\u002FTUI, a desktop app, an API, a mobile app, a library? A repo can have several; pick the primary one and note the rest.\n- **Run:** how does the app start locally? Prefer the repo's own documented dev command (package scripts, Makefile, README quickstart). Note ports, env vars, seed data, auth.\n- **Drive:** how can an agent interact with it programmatically? Existing harnesses first — Playwright\u002FCypress specs, expect scripts, PTY helpers, curl-able endpoints, a debug port. Only then pick a generic recipe: browser\u002FCDP for web and Electron, a tmux\u002FPTY harness for CLI\u002FTUI, plain HTTP for services.\n- **Observe:** what evidence can be captured? Screenshots, terminal transcripts, response bodies, logs, exit codes, DB state.\n- **Isolate:** can two instances run side by side (ports, data dirs, profiles)? If not, say so in the generated skill: refusing to double-drive a shared instance beats corrupting the user's session.\n\nIf the checkout doesn't build or start as-is, fix that first (or report it precisely) before generating; a skill written against a broken base teaches wrong steps. When an irrelevant missing asset blocks startup (a static dir the API never serves, a sample config), the generated skill may create it, clearly marked as verification scaffolding, and remove it in cleanup.\n\n## 2. Generate the skill\n\nWrite `.claude\u002Fskills\u002Fverify\u002FSKILL.md` with YAML frontmatter (`name: verify` and a `description` that names the app, the surface, and when to reach for it — without frontmatter the skill never registers, and with `disable-model-invocation` the model cannot call it) and these sections, each grounded in what the interview actually found (no placeholders left):\n\n- **Launch:** the exact command that starts the app for verification, and how to tell it's ready (a log line, a prompt). Launch must reach a usable state from an empty data dir, including any migrations and seed data. Ready means usable, not just that a process answers. A database health check can pass while its init scripts are still running. Include teardown. For a short-lived CLI or TUI there is no server to keep alive: launch means build the binary (or install deps) once, then start each drive in its own isolated PTY or tmux session.\n- **Doctor:** one read-only check that answers \"is this instance worth driving?\" — process up, right version\u002Fbuild, port owned by us, auth valid. An agent runs this first whenever anything looks off.\n- **Drive:** the harness recipe with real selectors\u002Fcommands from this repo, not examples. Prefer stable handles (ARIA labels, data attributes, prompt strings, route paths) over coordinates and tab order.\n- **Evidence:** what to capture for a proof and where it goes. State the proof standards: exercise the real user path, not internal setters or test-only endpoints; capture the action and the resulting state, not just the final screen; verify side effects (files written, rows inserted, messages sent) alongside what's visible; mocks only where a production boundary already isolates the external system. When the safe path is a dry-run or test mode, verify what it actually skips by observing (files, network, git refs) rather than trusting its name: some dry-runs still touch the network or open a browser.\n- **Cleanup:** how to tear down instances the run created. Never kill by process name; kill what you started. Cleanup removes instances and scratch state, never the evidence: proof artifacts survive the teardown, in a location the skill names.\n- **Helpers:** any script the skill ships is executable and its invocation is shown in the skill body. A helper the reader has to reverse-engineer is not a helper.\n\n## 3. Seed the feature map\n\nCreate `.claude\u002Fskills\u002Fverify\u002Ffeatures\u002FREADME.md` plus one file per user-facing feature you can identify (aim for the top 3-5 to start, from routes, commands, menus, or docs). Follow the shape in [`references\u002Ffeature-map-example\u002F`](references\u002Ffeature-map-example\u002F), with a README index and one file per feature. Each file answers, from the user's point of view: what the feature is, how to reach it, how to drive it with the harness, and what observable end state proves it works. The four H2s are `Sub-features`, `How to get to it (user POV)`, `Driving it with \u003Charness>`, and `Gotchas`. If the seed data lacks a precondition that a journey needs, the journey reports a failure and the reason goes in that feature's `Gotchas`. Never weaken the journey to make it pass. The map is the repo's maintained verification source; a proof that drives one convenient entry point is incomplete when the map lists others.\n\n## 4. Prove the generated skill before handing it over\n\nRun its own instructions end to end once: launch, doctor, drive ONE mapped feature (one is enough; the map exists so later runs can cover the rest), capture evidence, clean up. After cleanup, confirm the evidence still exists at the named location — a cleanup that eats the proof fails this step. Fix what fails, and run the generated cleanup after every failed iteration too, so broken attempts don't strand processes and ports. A generated skill that was never executed is a draft, not a deliverable. If you proved it in a stand-in for the real target (a container in place of a fresh VM, a local stack in place of a remote one), list every setup step the stand-in did that the target will not. Those steps stay unverified until a run on the real target covers them.\n\n## 5. Offer the maintenance loop\n\nPoint the user at `\u002Fmaintain-verification-skill` for keeping the map honest as the app changes. Suggest a cadence only if they ask.\n","# Create a verification skill\n\nOn Codex, read the [platform mapping](..\u002Fpoteto-mode\u002Freferences\u002Fcodex-tools.md), including its per-skill notes, before following this skill.\n\nOn GitHub Copilot, read the [platform mapping](..\u002Fpoteto-mode\u002Freferences\u002Fcopilot-tools.md), including its per-skill notes, before following this skill.\n\nOn Muse, read the [platform mapping](..\u002Fpoteto-mode\u002Freferences\u002Fmuse-tools.md), including its per-skill notes, before following this skill.\n\nOn Antigravity, read the [platform mapping](..\u002Fpoteto-mode\u002Freferences\u002Fagy-tools.md), including its per-skill notes, before following this skill.\n\nEvery serious project needs a scripted way to drive the real app and prove behavior: launch it, exercise a feature the way a user would, and capture evidence. This skill generates that as a project-local skill (`.claude\u002Fskills\u002Fverify\u002F`) tailored to the repo. Name it `verify`. At the repo root a project skill by that name replaces Claude Code's bundled `\u002Fverify`, which only the user can invoke, so every playbook that names the driver skill can call the project one ([Claude Code 2.1.200 or later](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fskills#run-and-verify-your-app)). In a monorepo, write it in the touched package directory instead. You write the generator's output for the next agent, not for a human: it will be read cold, mid-task, by an agent that has never seen the app.\n\n## 1. Interview the repo, not the user\n\nAnswer these from the codebase and only ask the user what you cannot observe:\n\n- **Surface:** what does a user actually touch? A web UI, a CLI\u002FTUI, a desktop app, an API, a mobile app, a library? A repo can have several; pick the primary one and note the rest.\n- **Run:** how does the app start locally? Prefer the repo's own documented dev command (package scripts, Makefile, README quickstart). Note ports, env vars, seed data, auth.\n- **Drive:** how can an agent interact with it programmatically? Existing harnesses first — Playwright\u002FCypress specs, expect scripts, PTY helpers, curl-able endpoints, a debug port. Only then pick a generic recipe: browser\u002FCDP for web and Electron, a tmux\u002FPTY harness for CLI\u002FTUI, plain HTTP for services.\n- **Observe:** what evidence can be captured? Screenshots, terminal transcripts, response bodies, logs, exit codes, DB state.\n- **Isolate:** can two instances run side by side (ports, data dirs, profiles)? If not, say so in the generated skill: refusing to double-drive a shared instance beats corrupting the user's session.\n\nIf the checkout doesn't build or start as-is, fix that first (or report it precisely) before generating; a skill written against a broken base teaches wrong steps. When an irrelevant missing asset blocks startup (a static dir the API never serves, a sample config), the generated skill may create it, clearly marked as verification scaffolding, and remove it in cleanup.\n\n## 2. Generate the skill\n\nWrite `.claude\u002Fskills\u002Fverify\u002FSKILL.md` with YAML frontmatter (`name: verify` and a `description` that names the app, the surface, and when to reach for it — without frontmatter the skill never registers, and with `disable-model-invocation` the model cannot call it) and these sections, each grounded in what the interview actually found (no placeholders left):\n\n- **Launch:** the exact command that starts the app for verification, and how to tell it's ready (a log line, a prompt). Launch must reach a usable state from an empty data dir, including any migrations and seed data. Ready means usable, not just that a process answers. A database health check can pass while its init scripts are still running. Include teardown. For a short-lived CLI or TUI there is no server to keep alive: launch means build the binary (or install deps) once, then start each drive in its own isolated PTY or tmux session.\n- **Doctor:** one read-only check that answers \"is this instance worth driving?\" — process up, right version\u002Fbuild, port owned by us, auth valid. An agent runs this first whenever anything looks off.\n- **Drive:** the harness recipe with real selectors\u002Fcommands from this repo, not examples. Prefer stable handles (ARIA labels, data attributes, prompt strings, route paths) over coordinates and tab order.\n- **Evidence:** what to capture for a proof and where it goes. State the proof standards: exercise the real user path, not internal setters or test-only endpoints; capture the action and the resulting state, not just the final screen; verify side effects (files written, rows inserted, messages sent) alongside what's visible; mocks only where a production boundary already isolates the external system. When the safe path is a dry-run or test mode, verify what it actually skips by observing (files, network, git refs) rather than trusting its name: some dry-runs still touch the network or open a browser.\n- **Cleanup:** how to tear down instances the run created. Never kill by process name; kill what you started. Cleanup removes instances and scratch state, never the evidence: proof artifacts survive the teardown, in a location the skill names.\n- **Helpers:** any script the skill ships is executable and its invocation is shown in the skill body. A helper the reader has to reverse-engineer is not a helper.\n\n## 3. Seed the feature map\n\nCreate `.claude\u002Fskills\u002Fverify\u002Ffeatures\u002FREADME.md` plus one file per user-facing feature you can identify (aim for the top 3-5 to start, from routes, commands, menus, or docs). Follow the shape in [`references\u002Ffeature-map-example\u002F`](references\u002Ffeature-map-example\u002F), with a README index and one file per feature. Each file answers, from the user's point of view: what the feature is, how to reach it, how to drive it with the harness, and what observable end state proves it works. The four H2s are `Sub-features`, `How to get to it (user POV)`, `Driving it with \u003Charness>`, and `Gotchas`. If the seed data lacks a precondition that a journey needs, the journey reports a failure and the reason goes in that feature's `Gotchas`. Never weaken the journey to make it pass. The map is the repo's maintained verification source; a proof that drives one convenient entry point is incomplete when the map lists others.\n\n## 4. Prove the generated skill before handing it over\n\nRun its own instructions end to end once: launch, doctor, drive ONE mapped feature (one is enough; the map exists so later runs can cover the rest), capture evidence, clean up. After cleanup, confirm the evidence still exists at the named location — a cleanup that eats the proof fails this step. Fix what fails, and run the generated cleanup after every failed iteration too, so broken attempts don't strand processes and ports. A generated skill that was never executed is a draft, not a deliverable. If you proved it in a stand-in for the real target (a container in place of a fresh VM, a local stack in place of a remote one), list every setup step the stand-in did that the target will not. Those steps stay unverified until a run on the real target covers them.\n\n## 5. Offer the maintenance loop\n\nPoint the user at `\u002Fmaintain-verification-skill` for keeping the map honest as the app changes. Suggest a cadence only if they ask.\n",{"name":5,"description":7},"main","bc09365fe61c725c486ba95157fc4048bf8a0b99","plugins\u002Fpstack\u002Fskills\u002Fcreate-verification-skill",397,"https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude","https:\u002F\u002Fgithub.com\u002Fmichael-denyer","https:\u002F\u002Fwww.wisdompanel.com\u002F","Software Engineer and Bioinformatician","2026-11-13 23:53:05",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add michael-denyer\u002Fpstack-claude --skill create-verification-skill",{"tool":39,"command":40},"bunx","bunx skills add michael-denyer\u002Fpstack-claude --skill create-verification-skill",{"tool":42,"command":43},"pnpm","pnpm dlx skills add michael-denyer\u002Fpstack-claude --skill create-verification-skill","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",true,[47,53,57],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"references\u002Ffeature-map-example\u002Fcreate-note.md","REFERENCE","参考文档",2926,"https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Ffeature-map-example\u002Fcreate-note.md",{"path":54,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":55,"sourceHtmlUrl":56},"references\u002Ffeature-map-example\u002FREADME.md",2601,"https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Ffeature-map-example\u002FREADME.md",{"path":58,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":59,"sourceHtmlUrl":60},"references\u002Ffeature-map-example\u002Fsearch.md",3478,"https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Ffeature-map-example\u002Fsearch.md",[62,69,76,83,90,97],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M750F31RNVHGK1JVWBJHDGTX","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Fwhy\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"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":19},"01M750F17NKT7YCP8ND5675XHN","what-did-i-get-done","Summarize authored commits over a user-specified time period into a concise update","https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Fwhat-did-i-get-done\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M750EYD7DP60DDPQY6GK3TTR","unslop","Cut AI tells from any writing.","https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Funslop\u002FSKILL.md",[],[],{"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":89,"publishedAt":19},"01M750EWQG73FRRSA065D2NMRZ","typescript-best-practices","TypeScript best practices. Use when reading or editing any .ts or .tsx file.","https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Ftypescript-best-practices\u002FSKILL.md",[],[],{"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":96,"publishedAt":19},"01M750ETTMA3MB36DJQJ1H4QGB","thermos","Launch both thermo-nuclear review subagents in parallel, then synthesize their findings. Use for thermos, double thermo review, or combined bug\u002Fsecurity and code-quality branch audits.","https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Fthermos\u002FSKILL.md",[],[],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":19},"01M750EQVQMQSW08KYGM7TG8K0","thermo-nuclear-review","Comprehensive security and correctness audit of a branch's changes. Use for thermo nuclear, thermonuclear, or deep review requests, or branch\u002FPR diff audits focused on bugs, breaking changes, security issues, devex regressions, and feature-gate leaks.","https:\u002F\u002Fgithub.com\u002Fmichael-denyer\u002Fpstack-claude\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fskills\u002Fthermo-nuclear-review\u002FSKILL.md",[],[]]