[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H83CDKW62VG9HTR5Z13N3C":3,"skill-same:01M6H83CDKW62VG9HTR5Z13N3C":86},{"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":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":14,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6H83CDKW62VG9HTR5Z13N3C","testing-policy-creator",null,"Writes, or brings up to date, a repo's own testing-policy skill at .claude\u002Fskills\u002Ftesting-policy\u002FSKILL.md: which code gets which kind of test, with which doubles, asserting what, and why. Surveys the codebase for its layers and boundaries, proposes a draft map, grills the user on it row by row, then lists the tests and boundaries that break the policy. Use when the user says \"create a testing policy\", \"write our testing-policy skill\", \"decide what we test in this repo\", \"which tests should we keep\", \"our tests are a mess, set some rules\", \"purge tests that don't conform\", or asks to update an existing testing policy. Not for writing a test (use the language's testing skill and tdd) or reviewing a diff.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftesting-policy-creator\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"policy","testing policy creator","creator","testing","up","when","Existing","for","layers","which","keep","tests","map","diff","use","repo","decide","testing skill","Rules","SET","writing","2026-11-10 10:12:30",false,"---\nname: testing-policy-creator\ndescription: >\n  Writes, or brings up to date, a repo's own testing-policy skill at\n  .claude\u002Fskills\u002Ftesting-policy\u002FSKILL.md: which code gets which kind of test, with which doubles,\n  asserting what, and why. Surveys the codebase for its layers and boundaries, proposes a draft\n  map, grills the user on it row by row, then lists the tests and boundaries that break the\n  policy. Use when the user says \"create a testing policy\", \"write our testing-policy skill\",\n  \"decide what we test in this repo\", \"which tests should we keep\", \"our tests are a mess, set\n  some rules\", \"purge tests that don't conform\", or asks to update an existing testing policy.\n  Not for writing a test (use the language's testing skill and tdd) or reviewing a diff.\n---\n\n# Testing policy creator\n\nProduces one file in the target repo: `.claude\u002Fskills\u002Ftesting-policy\u002FSKILL.md`. That skill\ndecides **what** is tested and why. How a test is written (assertions, tables, helpers) belongs\nto the language's testing skill (`go-testing` for Go); the policy names it and never restates it.\n\nA good policy does two jobs at once. It stops regressions, and it makes the codebase legible: a\nreader who knows the map knows what each layer is for, because each row says what behaviour the\nlayer promises and which test proves it. Code that fits no row is a design finding, not a gap in\nthe map.\n\nRead [references\u002Fprinciples.md](references\u002Fprinciples.md) before drafting. It holds the rules for\nchoosing what earns a test, picking its size and doubles, and reading untestability as coupling.\n[references\u002Fpolicy-template.md](references\u002Fpolicy-template.md) is the output shape, and\n[references\u002Fexample-go-policy.md](references\u002Fexample-go-policy.md) is a finished policy from a Go\nservice to calibrate against.\n\n## 1. Check for an existing policy\n\nIf `.claude\u002Fskills\u002Ftesting-policy\u002FSKILL.md` exists, this is an update. Treat it as the draft:\nexplore as below, then grill only on what changed (new layers, rows the code no longer matches,\nrules the tests ignore). Never overwrite it wholesale.\n\n## 2. Survey the codebase\n\nDispatch `Explore` sub-agents in parallel, one per question, and keep only their conclusions:\n\n- **Stack.** Languages, test runner, test file convention (`foo_test.go`, `foo.test.ts`,\n  `test_foo.py`), fixture and snapshot locations, and which testing skill applies.\n- **Layers.** The architectural layers or modules and the exported surface each offers callers\n  (services, stores, handlers, adapters, consumers, UI components). Name each by what it does.\n- **Boundaries.** Every out-of-process dependency, split into managed (only this app touches it,\n  e.g. its own database) and unmanaged (others observe it: third-party APIs, queues, email,\n  LLMs). This decides doubles.\n- **Existing tests.** For each test file: the source file it pairs with, the layer it exercises,\n  its size, its doubles, and what it asserts. Flag files pairing with no source file, fixtures no\n  test reads, tests of unexported code, and assertions on calls between the repo's own packages.\n- **Boundary gaps.** Code that cannot be tested through an exported surface without reaching\n  into internals, standing up the whole app, or mocking the repo's own packages. Note the seam\n  each would need.\n\n## 3. Draft the map\n\nFrom the survey and the principles, draft one row per layer: code, test file, size, doubles,\nwhat it asserts, and a short \"guards\" note naming the regression or promise the row protects.\nAdd the never-tested list and the boundary gaps. Start from the core rule in the template.\n\nWhere an existing test already shows a row's shape well, lift a trimmed version of it as that\nrow's example. Examples illustrate a rule; they are chosen because they are good, not because\nthey exist.\n\n## 4. Grill\n\nCall the Skill tool with \"grilling\" and give it this agenda, one branch per item:\n\n1. The core rule, and whether this repo's file convention overrides it.\n2. Each map row: does the layer exist as described, is this the right size and doubles, does the\n   assertion target behaviour a caller observes.\n3. The never-tested list.\n4. Doubles: fidelity order, where fakes live, whether a fake needs a contract suite.\n5. When interaction assertions are allowed.\n6. Each boundary gap: keep it in the policy as a named gap, or drop it.\n\n## 5. Write the policy\n\nWrite `.claude\u002Fskills\u002Ftesting-policy\u002FSKILL.md` from the template. It states rules that hold\nwhenever it is read, so it never describes the repo as it was on the day it was written: no\ninventory of current tests, no \"X is the pilot\", no \"bring code onto the policy when touched\",\nno counts or dates. Its description uses the standards-skill shape (`TRIGGER — load BEFORE\nwriting, editing or reviewing a test … SKIP …`) so it loads on plain \"add a test\" requests.\n\nWrite the reasoning behind each row (the evidence from the survey, the principle applied, the\ngrilling answer) to a rationale file outside the repo, in the session scratchpad or the system\ntemp directory. It is a review aid only; tell the user it is safe to delete once they have read it.\n\n## 6. Report and hand off\n\n1. Add one line to the repo's `AGENTS.md` (create it if missing) pointing at the policy:\n   `Before writing or reviewing a test, load the testing-policy skill.`\n2. Print the tests that break the policy, grouped by the rule they break, then the boundary gaps\n   with the seam each needs. Recommend delete, rewrite or move for each test; change nothing.\n3. Ask once whether to file both lists as one purge issue. On yes, call the Skill tool with\n   \"file-issue\".\n4. Give the path to the rationale file.\n","# Testing policy creator\n\nProduces one file in the target repo: `.claude\u002Fskills\u002Ftesting-policy\u002FSKILL.md`. That skill\ndecides **what** is tested and why. How a test is written (assertions, tables, helpers) belongs\nto the language's testing skill (`go-testing` for Go); the policy names it and never restates it.\n\nA good policy does two jobs at once. It stops regressions, and it makes the codebase legible: a\nreader who knows the map knows what each layer is for, because each row says what behaviour the\nlayer promises and which test proves it. Code that fits no row is a design finding, not a gap in\nthe map.\n\nRead [references\u002Fprinciples.md](references\u002Fprinciples.md) before drafting. It holds the rules for\nchoosing what earns a test, picking its size and doubles, and reading untestability as coupling.\n[references\u002Fpolicy-template.md](references\u002Fpolicy-template.md) is the output shape, and\n[references\u002Fexample-go-policy.md](references\u002Fexample-go-policy.md) is a finished policy from a Go\nservice to calibrate against.\n\n## 1. Check for an existing policy\n\nIf `.claude\u002Fskills\u002Ftesting-policy\u002FSKILL.md` exists, this is an update. Treat it as the draft:\nexplore as below, then grill only on what changed (new layers, rows the code no longer matches,\nrules the tests ignore). Never overwrite it wholesale.\n\n## 2. Survey the codebase\n\nDispatch `Explore` sub-agents in parallel, one per question, and keep only their conclusions:\n\n- **Stack.** Languages, test runner, test file convention (`foo_test.go`, `foo.test.ts`,\n  `test_foo.py`), fixture and snapshot locations, and which testing skill applies.\n- **Layers.** The architectural layers or modules and the exported surface each offers callers\n  (services, stores, handlers, adapters, consumers, UI components). Name each by what it does.\n- **Boundaries.** Every out-of-process dependency, split into managed (only this app touches it,\n  e.g. its own database) and unmanaged (others observe it: third-party APIs, queues, email,\n  LLMs). This decides doubles.\n- **Existing tests.** For each test file: the source file it pairs with, the layer it exercises,\n  its size, its doubles, and what it asserts. Flag files pairing with no source file, fixtures no\n  test reads, tests of unexported code, and assertions on calls between the repo's own packages.\n- **Boundary gaps.** Code that cannot be tested through an exported surface without reaching\n  into internals, standing up the whole app, or mocking the repo's own packages. Note the seam\n  each would need.\n\n## 3. Draft the map\n\nFrom the survey and the principles, draft one row per layer: code, test file, size, doubles,\nwhat it asserts, and a short \"guards\" note naming the regression or promise the row protects.\nAdd the never-tested list and the boundary gaps. Start from the core rule in the template.\n\nWhere an existing test already shows a row's shape well, lift a trimmed version of it as that\nrow's example. Examples illustrate a rule; they are chosen because they are good, not because\nthey exist.\n\n## 4. Grill\n\nCall the Skill tool with \"grilling\" and give it this agenda, one branch per item:\n\n1. The core rule, and whether this repo's file convention overrides it.\n2. Each map row: does the layer exist as described, is this the right size and doubles, does the\n   assertion target behaviour a caller observes.\n3. The never-tested list.\n4. Doubles: fidelity order, where fakes live, whether a fake needs a contract suite.\n5. When interaction assertions are allowed.\n6. Each boundary gap: keep it in the policy as a named gap, or drop it.\n\n## 5. Write the policy\n\nWrite `.claude\u002Fskills\u002Ftesting-policy\u002FSKILL.md` from the template. It states rules that hold\nwhenever it is read, so it never describes the repo as it was on the day it was written: no\ninventory of current tests, no \"X is the pilot\", no \"bring code onto the policy when touched\",\nno counts or dates. Its description uses the standards-skill shape (`TRIGGER — load BEFORE\nwriting, editing or reviewing a test … SKIP …`) so it loads on plain \"add a test\" requests.\n\nWrite the reasoning behind each row (the evidence from the survey, the principle applied, the\ngrilling answer) to a rationale file outside the repo, in the session scratchpad or the system\ntemp directory. It is a review aid only; tell the user it is safe to delete once they have read it.\n\n## 6. Report and hand off\n\n1. Add one line to the repo's `AGENTS.md` (create it if missing) pointing at the policy:\n   `Before writing or reviewing a test, load the testing-policy skill.`\n2. Print the tests that break the policy, grouped by the rule they break, then the boundary gaps\n   with the seam each needs. Recommend delete, rewrite or move for each test; change nothing.\n3. Ask once whether to file both lists as one purge issue. On yes, call the Skill tool with\n   \"file-issue\".\n4. Give the path to the rationale file.\n",{"name":5,"description":7},"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fcode\u002Ftesting-policy-creator","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997","https:\u002F\u002Fpersonal-portfolio-v2-phi.vercel.app","Go & TypeScript developer building tooling for AI-assisted development: git worktree workflows, Claude Code skills and agent orchestration.","2026-11-11 22:26:34",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill testing-policy-creator",{"tool":64,"command":65},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill testing-policy-creator",{"tool":67,"command":68},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill testing-policy-creator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftesting-policy-creator\u002FSKILL.md",true,[72,78,82],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fexample-go-policy.md","REFERENCE","参考文档",5295,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftesting-policy-creator\u002Freferences\u002Fexample-go-policy.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fpolicy-template.md",3226,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftesting-policy-creator\u002Freferences\u002Fpolicy-template.md",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fprinciples.md",7351,"https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fcode\u002Ftesting-policy-creator\u002Freferences\u002Fprinciples.md",[87,95,102,128,153,180],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":94},"01M745F5J4Z2W32G4QXESCN5PM","vault-recall","Answer the user's conceptual or technical question using their Obsidian vault as well as general knowledge. Use when the user asks a question (not a task) whose topic appears in the vault MOC digest from session start. Not for task instructions, not mid-task, and not for writing to the vault (that is to-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fvault-recall\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":94},"01M745EW5W0A7K9016Z54A4KG2","ingest","Ingest one external source (an article, course lesson, doc, PDF or URL) into the user's Obsidian vault: save the original to raw\u002F, then build wiki\u002F pages per the vault's § Ingest. Use when the user types \u002Fingest, or says \"ingest this\", \"add this source to my wiki\", \"put this article\u002Flesson in the vault as a wiki page\". Works from any repo. Routing rule: someone else's words go to wiki\u002F (this skill); the user's own learnings and decisions go to notes\u002F (\u002Fto-vault).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fproductivity\u002Fingest\u002FSKILL.md",[],[],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":45},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[109,110,111,112,113,114,115,116,117,118,119,120,121,122,39,31,123,124,125,126,127],"tickets","to tickets","new","signatures","github","plan","batch","task","code","manifest","plans","true","ticket","command","feature","run","worktrees","as","cut",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":137,"publishedAt":45},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[138,139,111,140,141,142,143,144,145,38,44,29,146,120,147,148,149,39,31,150,151,152,126,122],"to seams","schema","neither","it","but","file","prompt","either","interface","repos","block","records","build","can","record",{"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":164,"publishedAt":45},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[165,166,167,126,123,168,169,29,170,171,172,109,173,174,114,175,176,120,121,177,178,179],"to roadmap","roadmap","never","via","features","doc","board","about","next","later","self","now","card","re","ideas",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":187,"publishedAt":45},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[186],{"categoryNo":160,"categoryName":161,"taxonomyType":162,"taxonomyTypeDesc":163},[188,189,190,191,192,193,194,195,109,196,114,197,198,199,120,178,123,200,33,126],"prd","to prd","say","interviews","codebase","report","line","delivery","spine","state","multi","ask","problem"]