[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BVAWG7CTR7ERZC6YZHEMNJ":3,"skill-same:01M6BVAWG7CTR7ERZC6YZHEMNJ":72},{"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":23,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":14,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":71},"01M6BVAWG7CTR7ERZC6YZHEMNJ","create-formal-verification-skill",null,"Generate a project-local skill that formally verifies the code where a bug costs the most and tests reach the least, in any language, with whichever verification tool fits. Use for \u002Fcreate-formal-verification-skill, \"model-check this race\", \"prove this invariant\", or when concurrency, retries, state machines, parsers, or unsafe code need more than tests.","bnferguson\u002Fdotfiles","bnferguson","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47749?v=4","01M6BV4H2TJKK8P14W86V1ZCPP","Brandon Ferguson","01M6BV4H7GJWTZJ1BVHQ1TX11Y",0,"MIT","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002Fpstack\u002Fupstream\u002Fskills\u002Fcreate-formal-verification-skill\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"verification","create formal verification skill","create","formal verification","use","when","prove","unsafe","for","true","more","retries","tests","project","local","check","parsers","model","tool","concurrency","state","code","generate","2026-11-10 10:12:30",false,"---\nname: create-formal-verification-skill\ndescription: \"Generate a project-local skill that formally verifies the code where a bug costs the most and tests reach the least, in any language, with whichever verification tool fits. Use for \u002Fcreate-formal-verification-skill, \\\"model-check this race\\\", \\\"prove this invariant\\\", or when concurrency, retries, state machines, parsers, or unsafe code need more than tests.\"\ndisable-model-invocation: true\n---\n\n# Create a formal verification skill\n\nA test checks the cases that someone thought to write. Formal verification checks every case in a stated scope: every order of steps in a model, every input up to a bound, or every input. This skill finds the part of the repo where that matters most, verifies one property of it, and leaves a project-local skill that lets the next agent check a change against that property. Write that skill for an agent who reads it cold, mid-change, and has never seen your work. The user must be able to trust the result and act on it without learning the verification language.\n\n## Choose the target from the code\n\nAnswer from the codebase, and ask the user only what you cannot observe. If the user named an area or a bug, start there.\n\nA good target is a promise the code makes, where a break harms users and tests rarely reach the case that breaks it. Choose the strongest such target in the repo, not the one that is easiest to verify.\n\n## Let the question choose the tool\n\nPick the tool that answers the question at the lowest cost: a model checker, a proof assistant, an SMT-backed verifier, or another tool. Whether events can happen in a bad order usually suits a model checker over a small model of the design, and TLA+ is the default for that in any language. Whether the code itself behaves for every input, as with memory safety, overflow, or a data-structure invariant, usually suits a verifier that runs on the code. If no verifier runs on this language, say so, and test the real code with generated inputs, not a hand model of the function. A property that must hold at every size, where a bound is not enough, can need a proof. Prefer a tool that the repo's developers can install and run, and tell the user why you chose it.\n\n## What makes it good\n\n- **True to the code.** Every part of the model or proof points to code that a reviewer can open. What the verification treats as one indivisible step is one indivisible step in the code. Names come from this repo.\n- **Able to fail.** A check that you have never seen fail proves nothing. Show each property failing on a broken variant of the code it guards, such as a removed check or a reordered step.\n- **Findings stay findings.** When the current code breaks the property, report it with the counterexample in the code's terms. Do not weaken the property or the model until it passes, and do not change product code unless the user asks.\n- **Honest about scope.** Say what is verified, under which bounds and assumptions, and what is left out. A pass covers the model or the bound, not the whole system.\n- **Readable without the tool.** State the property and the harm in one plain sentence each. Tell a counterexample as a short sequence of steps in the code's words.\n- **Cheap to rerun.** One command, a reproducible tool version, and a run short enough that the next agent will use it on every relevant change.\n- **Kept in step with the code.** Record which files and functions each check covers, and the commit at which you last confirmed that the verification describes them. When the covered code changes after that commit, the next agent can see that the verification needs another look.\n\n## Generate the verify skill\n\nWrite a project-local skill with frontmatter that names the area and says when to use it. Without frontmatter, the skill never registers. From the skill alone, the next agent must be able to tell whether a change touches the verified code, run the check, tell a real bug from a modeling error, and update the verification when a change is intended. Put the coverage record and the sync commit in the skill, and tell the next agent to move the sync commit forward only after it confirms that the verification describes the code at the new commit. Use this repo's real commands, paths, and nouns, and leave no placeholders.\n\nIf the check is a TLA+ model, tell the next agent to read every result with the pstack [`\u002Fstatechart`](..\u002Fstatechart\u002FSKILL.md) skill. It shows each invariant violation the checker finds as its shortest path in plain words. When the check passes, `\u002Fstatechart` draws a chart of how the system moves between states. Refer to `\u002Fstatechart` by name. Its commands, options, and file paths change between releases and machines, so copy none of them into the generated skill or its scripts.\n\n## Prove it before you hand off\n\nFollow the generated skill once, as the next agent would, on a scratch change that breaks the property in the real code. It must catch the break. Then drop the scratch change and confirm that the check is back where it started: passing, or failing only on the findings you will report. A verify skill that was never run is a draft. If the skill misses the break or a step does not run, fix the skill or the verification, not the scratch change.\n\n## Hand off\n\nTell the user what you verified, which tool you used and why, the bounds, what the check found in plain words, how to run it, and what it does not cover. Suggest a second target only if you found a close one. Point the user at `\u002Fmaintain-formal-verification-skill` for bringing the verification back in line after changes that did not recheck it.\n","# Create a formal verification skill\n\nA test checks the cases that someone thought to write. Formal verification checks every case in a stated scope: every order of steps in a model, every input up to a bound, or every input. This skill finds the part of the repo where that matters most, verifies one property of it, and leaves a project-local skill that lets the next agent check a change against that property. Write that skill for an agent who reads it cold, mid-change, and has never seen your work. The user must be able to trust the result and act on it without learning the verification language.\n\n## Choose the target from the code\n\nAnswer from the codebase, and ask the user only what you cannot observe. If the user named an area or a bug, start there.\n\nA good target is a promise the code makes, where a break harms users and tests rarely reach the case that breaks it. Choose the strongest such target in the repo, not the one that is easiest to verify.\n\n## Let the question choose the tool\n\nPick the tool that answers the question at the lowest cost: a model checker, a proof assistant, an SMT-backed verifier, or another tool. Whether events can happen in a bad order usually suits a model checker over a small model of the design, and TLA+ is the default for that in any language. Whether the code itself behaves for every input, as with memory safety, overflow, or a data-structure invariant, usually suits a verifier that runs on the code. If no verifier runs on this language, say so, and test the real code with generated inputs, not a hand model of the function. A property that must hold at every size, where a bound is not enough, can need a proof. Prefer a tool that the repo's developers can install and run, and tell the user why you chose it.\n\n## What makes it good\n\n- **True to the code.** Every part of the model or proof points to code that a reviewer can open. What the verification treats as one indivisible step is one indivisible step in the code. Names come from this repo.\n- **Able to fail.** A check that you have never seen fail proves nothing. Show each property failing on a broken variant of the code it guards, such as a removed check or a reordered step.\n- **Findings stay findings.** When the current code breaks the property, report it with the counterexample in the code's terms. Do not weaken the property or the model until it passes, and do not change product code unless the user asks.\n- **Honest about scope.** Say what is verified, under which bounds and assumptions, and what is left out. A pass covers the model or the bound, not the whole system.\n- **Readable without the tool.** State the property and the harm in one plain sentence each. Tell a counterexample as a short sequence of steps in the code's words.\n- **Cheap to rerun.** One command, a reproducible tool version, and a run short enough that the next agent will use it on every relevant change.\n- **Kept in step with the code.** Record which files and functions each check covers, and the commit at which you last confirmed that the verification describes them. When the covered code changes after that commit, the next agent can see that the verification needs another look.\n\n## Generate the verify skill\n\nWrite a project-local skill with frontmatter that names the area and says when to use it. Without frontmatter, the skill never registers. From the skill alone, the next agent must be able to tell whether a change touches the verified code, run the check, tell a real bug from a modeling error, and update the verification when a change is intended. Put the coverage record and the sync commit in the skill, and tell the next agent to move the sync commit forward only after it confirms that the verification describes the code at the new commit. Use this repo's real commands, paths, and nouns, and leave no placeholders.\n\nIf the check is a TLA+ model, tell the next agent to read every result with the pstack [`\u002Fstatechart`](..\u002Fstatechart\u002FSKILL.md) skill. It shows each invariant violation the checker finds as its shortest path in plain words. When the check passes, `\u002Fstatechart` draws a chart of how the system moves between states. Refer to `\u002Fstatechart` by name. Its commands, options, and file paths change between releases and machines, so copy none of them into the generated skill or its scripts.\n\n## Prove it before you hand off\n\nFollow the generated skill once, as the next agent would, on a scratch change that breaks the property in the real code. It must catch the break. Then drop the scratch change and confirm that the check is back where it started: passing, or failing only on the findings you will report. A verify skill that was never run is a draft. If the skill misses the break or a step does not run, fix the skill or the verification, not the scratch change.\n\n## Hand off\n\nTell the user what you verified, which tool you used and why, the bounds, what the check found in plain words, how to run it, and what it does not cover. Suggest a second target only if you found a close one. Point the user at `\u002Fmaintain-formal-verification-skill` for bringing the verification back in line after changes that did not recheck it.\n",{"name":5,"description":7,"disable-model-invocation":52},true,"main","e63965e4644984470d4cc8b3014a8b001f0c2666","pstack\u002Fupstream\u002Fskills\u002Fcreate-formal-verification-skill","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Fbnferguson","2026-11-11 03:04:59",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":52},[61,64,67],{"tool":62,"command":63},"npx","npx skills add bnferguson\u002Fdotfiles --skill create-formal-verification-skill",{"tool":65,"command":66},"bunx","bunx skills add bnferguson\u002Fdotfiles --skill create-formal-verification-skill",{"tool":68,"command":69},"pnpm","pnpm dlx skills add bnferguson\u002Fdotfiles --skill create-formal-verification-skill","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002Fpstack\u002Fupstream\u002Fskills\u002Fcreate-formal-verification-skill\u002FSKILL.md",[],[73,98,115,144,153,165],{"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":77,"licenseFileUrl":78,"sourceHtmlUrl":79,"categories":80,"keywords":82,"publishedAt":47},"01M6BVA3RS3M016FANZ6792F9H","skill-creator","Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002Fclaude\u002Fconfig\u002Fskills\u002Fskill-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002Fclaude\u002Fconfig\u002Fskills\u002Fskill-creator\u002FSKILL.md",[81],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[83,84,85,86,26,87,88,89,42,90,91,92,93,94,95,32,96,29,97],"creator","skill creator","specialized","workflows","update","capabilities","knowledge","integrations","guide","new skill","existing skill","users","with","Existing","new",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":112,"publishedAt":47},"01M6BV94WN2RPYM8N6PN8TBNT8","writing-shape","Writing, exploit: shape raw material into an article, paragraph by paragraph.","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwriting-shape\u002FSKILL.md",[104,107],{"categoryNo":105,"categoryName":106,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[113,114],"writing shape","writing",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":119,"sourceHtmlUrl":120,"categories":121,"keywords":128,"publishedAt":47},"01M6BV8QDFJ6PXBVK5NFBZT5M7","webapp-testing","Test local web applications using Playwright. Use when verifying frontend functionality, debugging UI behavior, capturing browser screenshots, or viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[122,125],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[129,130,131,132,133,134,135,136,137,138,139,140,141,142,28,38,143,29],"webapp","webapp testing","testing","browser","frontend","screenshots","playwright","test","web","debugging","ui","logs","applications","behavior","test local",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":47},"01M6BV8MDXKXNVHKS3QF3YDFTF","wait-what","Stop. That last message did not land: re-pitch it.","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwait-what\u002FSKILL.md",[],[151,152],"wait what","land",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":162,"publishedAt":47},"01M6BV756DJHT5BDA1HVRVHJJ7","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\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fprototype\u002FSKILL.md",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000032","设计师",[155,163,164,139,44],"design","explore",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":172,"publishedAt":47},"01M6BV6SBW166685KVBPWM2K4N","improve-codebase-architecture","Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.","https:\u002F\u002Fgithub.com\u002Fbnferguson\u002Fdotfiles\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",[171],{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},[173,174,175,176],"architecture","improve","improve codebase architecture","report"]