[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71RSAS02SAC1C7S5FSQMNWB":3,"skill-same:01M71RSAS02SAC1C7S5FSQMNWB":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":68},"01M71RSAS02SAC1C7S5FSQMNWB","pstack-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 \u002Fskill:pstack-create-verification-skill, \"make a control skill for this repo\", or when a project has no scripted way to prove UI\u002FCLI\u002Fservice behavior.","dmae97\u002Fomk","dmae97","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F146327957?v=4","01M71RJRBWDNKEJ1A2DZVES8X1","01M71RJRCYHNT7E83M0Q42V6SJ",152,"MIT","https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Fresources\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"create","verification","create verification skill","pstack","pstack create verification skill","use","prove","true","repo","for","platform","framework","make","ui","generate","cli","when","local","project","app","2026-11-10 13:02:02",false,"---\nname: pstack-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 \u002Fskill:pstack-create-verification-skill, \\\"make a control skill for this repo\\\", or when a project has no scripted way to prove UI\u002FCLI\u002Fservice behavior.\"\ndisable-model-invocation: true\n---\n\n# Create a verification 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 (`\u003Cskills>\u002Fverify-\u003Capp>\u002F`) tailored to the repo. `\u003Cskills>` is your harness's project skill folder: `.omk\u002Fskills\u002F`. If the repo already keeps skills in one of these, use that one. 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 `\u003Cskills>\u002Fverify-\u003Capp>\u002FSKILL.md` with YAML frontmatter (`name: verify-\u003Capp>` and a `description` that names the app, the surface, and when to reach for it — without frontmatter the skill never registers) 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 `\u003Cskills>\u002Fverify-\u003Capp>\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 `\u002Fskill:pstack-maintain-verification-skill` for keeping the map honest as the app changes. Suggest a cadence only if they ask.\n","# Create a verification 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 (`\u003Cskills>\u002Fverify-\u003Capp>\u002F`) tailored to the repo. `\u003Cskills>` is your harness's project skill folder: `.omk\u002Fskills\u002F`. If the repo already keeps skills in one of these, use that one. 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 `\u003Cskills>\u002Fverify-\u003Capp>\u002FSKILL.md` with YAML frontmatter (`name: verify-\u003Capp>` and a `description` that names the app, the surface, and when to reach for it — without frontmatter the skill never registers) 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 `\u003Cskills>\u002Fverify-\u003Capp>\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 `\u002Fskill:pstack-maintain-verification-skill` for keeping the map honest as the app changes. Suggest a cadence only if they ask.\n",{"name":5,"description":7,"disable-model-invocation":48},true,"main","ea03fcf76b438f12f0cebcd6b255d24d4cb52741","packages\u002Fcoding-agent\u002Fresources\u002Fpstack\u002Fskills\u002Fcreate-verification-skill",29,"https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk","https:\u002F\u002Fgithub.com\u002Fdmae97","2026-11-11 10:48:59",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":48},[58,61,64],{"tool":59,"command":60},"npx","npx skills add dmae97\u002Fomk --skill pstack-create-verification-skill",{"tool":62,"command":63},"bunx","bunx skills add dmae97\u002Fomk --skill pstack-create-verification-skill",{"tool":65,"command":66},"pnpm","pnpm dlx skills add dmae97\u002Fomk --skill pstack-create-verification-skill","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Fresources\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[69,75,79],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Ffeature-map-example\u002Fcreate-note.md","REFERENCE","参考文档",2926,"https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Fresources\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Ffeature-map-example\u002Fcreate-note.md",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Ffeature-map-example\u002FREADME.md",2601,"https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Fresources\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Ffeature-map-example\u002FREADME.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Ffeature-map-example\u002Fsearch.md",3478,"https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Fresources\u002Fpstack\u002Fskills\u002Fcreate-verification-skill\u002Freferences\u002Ffeature-map-example\u002Fsearch.md",[84,95,109,122,133,141],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":91,"publishedAt":43},"01M71RZKQCQ4G7MP08TE3QQ0PD","valid-skill","A valid skill for testing purposes.","https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Fvalid-skill\u002FSKILL.md",[90],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[92,93,94,32],"valid skill","valid","testing",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":102,"publishedAt":43},"01M71RZJ8YHH8GKADPTSZBCJ1T","unknown-field","A skill with an unknown frontmatter field.","https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Funknown-field\u002FSKILL.md",[101],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[103,104,105,106,107,108],"unknown","unknown field","a skill","frontmatter","with","unknown frontmatter field",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"publishedAt":43},"01M71RZH4FVEENABTV8WTQ5HTS","nested-child","Nested skill should be ignored.","https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Froot-skill-preferred\u002Fnested-child\u002FSKILL.md",[115],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[117,118,119,120,121],"nested child","child","nested","ignored","nested skill",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":43},"01M71RZFZYSXRRVY5M8HP05NJV","root-skill-preferred","Root skill should win.","https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Froot-skill-preferred\u002FSKILL.md",[128],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[130,131,132],"root","root skill preferred","root skill",{"skillNo":134,"name":135,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":139,"publishedAt":43},"01M71RZEQDH7RZ1PH36G7GPN9N","no-frontmatter","https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Fno-frontmatter\u002FSKILL.md",[138],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[106,140],"no frontmatter",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":43},"01M71RZDC0QR3ZJQ549N3H94Y4","child-skill","A nested skill in a subdirectory.","https:\u002F\u002Fgithub.com\u002Fdmae97\u002Fomk\u002Fblob\u002Fmain\u002Fpackages\u002Fcoding-agent\u002Ftest\u002Ffixtures\u002Fskills\u002Fnested\u002Fchild-skill\u002FSKILL.md",[147],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[149,118,121,119],"child skill"]