[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71P4E9AZM56JBY227P2G1SC":3,"skill-same:01M71P4E9AZM56JBY227P2G1SC":83},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M71P4E9AZM56JBY227P2G1SC","writing-good-tickets",null,"Write, file, or update an issue or ticket that an agent or a developer can take to one PR. Use when filing a bug or feature, updating an issue, or breaking a plan into tickets.","drsh4dow\u002Fpi-setup","drsh4dow","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F45247070?v=4","01M71P068NASGHSWS11VWW416N","Daniel Moretti","01M71P0698BH81N65NP04X9NVN",10,"MIT","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-tickets\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"writing","tickets","writing good tickets","good","issue","take","bug","write","update","plan","can","one","file","when","false","use","ticket","filing","feature","pr","2026-11-10 10:56:23",false,"---\nname: writing-good-tickets\ndescription: Write, file, or update an issue or ticket that an agent or a developer can take to one PR. Use when filing a bug or feature, updating an issue, or breaking a plan into tickets.\ndisable-model-invocation: false\nuser-invokable: false\n---\n\n# Writing good tickets\n\nA ticket hands one problem to someone who was not in the conversation, a developer or an agent, who takes it to one PR. It answers, in order: what goes wrong today and for whom, what shows it, how anyone will know it is fixed, and what to read before starting. The closing PR proves each `## Done when` item with a witness, per the **writing-good-prs** skill.\n\nEdit the prose with the **unslop** skill. Follow the repository's tracker and template conventions, starting from its issue tracker record, `docs\u002Fagents\u002Fissue-tracker.md`, when it has one. When the repository has an issue template, fill its sections and apply the rules below to the section that plays each role.\n\nEverything the ticket points at is reachable by any developer with access to the repository: issues, PRs, CI runs, hosted media, and public URLs. Paths on your machine, such as your home directory, `\u002Ftmp`, a worktree, or an agent state folder, are reachable only by you. Paste what they hold instead. Say \"on main\" or name the released version where you saw it, rather than a commit hash.\n\n## Title\n\nWrite `area: symptom`, with no trailing period: the trigger and what the reader sees, for one failure. A cause or a remedy stays out of the title, because the symptom stays true when the guessed cause turns out wrong.\n\n- Good: `subagents: an autonomous run sends one unit through five fix rounds until the operator stops it`\n- Bad: `subagents: an autonomous run has no round count per unit, so nothing stops a third fix round`, which names the missing mechanism instead of what the reader saw.\n\n## Body\n\n```markdown\n## Problem\n\n## Done when\n\n- [ ] \n\n## Suggested approach\n\n## Context\n```\n\n`## Problem` and `## Done when` are required. Drop any other section with nothing to say.\n\n### Problem\n\n1. **Open with one story, in the present tense.** Who hits it, the trigger, what happens, what should happen, and what it costs. For a feature, the story is the person and the moment the current behavior fails them, quoted in their words when you have them. This story is the baseline: the closing PR is judged by whether the same story now ends differently.\n2. **Show the witness.** Paste the decisive lines: output, a log excerpt, a screenshot, or a quoted report, with where you saw it and how often, such as `3 of 3 runs`.\n3. **Give the recipe.** The exact steps, run from a fresh clone of the repository after its normal setup. Say whether you reproduced it yourself, and write `reported, not reproduced` when you did not.\n\nPreserve the nuances from the conversation that an implementer would otherwise lose.\n\n### Done when\n\nEach item is one behavior, written so a developer reads what must be true and an agent reads how to check it:\n\n```markdown\n- [ ] **\u003Cthe behavior, in plain words>.** Check: \u003Cthe setup, the action, and the exact result to observe>.\n```\n\n- The check names a surface that anyone can run: a command and the output it must print, a test case and what it asserts, or a walk through the running app with the repository's `verify-*` skill.\n- The first item replays the Problem's story with the new ending.\n- When the fix could overshoot, give the boundary its own item: what must keep working as before, such as \"real `pi --print` launches are still refused\".\n- A behavior the conversation settled, such as \"a missing Java still fails the check\", is an item here.\n- An unknown that running something can settle is an item too, such as \"**The faster layout is kept.** Check: prototype both and keep the one that renders in under 16 ms.\"\n- Repository gates such as `vp run verify` go last, and never stand alone.\n\nA ticket that still waits on a product call only a person can make is not ready. Ask that person before you file.\n\n### Suggested approach\n\nOptional, and never binding: the implementer owns the how. Give it when you hold something that would save them time:\n\n- The cause you suspect, marked `Hypothesis` with what you saw that points to it.\n- A possible approach and the alternative you would rule out, with the reason.\n- A visual from the **writing-good-prs** Shape menu when it shows the idea faster than prose.\n\nName behavior and symbols, not file paths. Finding where a symbol lives is one search.\n\n### Context\n\nList the material the implementer reads before starting that neither a code search nor the tracker gives them, each with one line on why it matters:\n\n- Docs, specs, and external URLs the fix must follow.\n- Attachments: logs, screenshots, recordings, and data, hosted where everyone can open them.\n\nRelate other issues and PRs through the tracker itself, as a parent, a blocker, or a sub-issue, per the issue tracker record, so the link lives in one place. When another issue settled something this ticket depends on, state what it settled in Problem or Done when.\n\n## Example\n\nThe same ticket, condensed from a real one and written well:\n\n````markdown\ndelegate-guard: a delegate's read-only grep for launch strings is refused as a launch\n\n## Problem\n\nWhen a reviewer subagent greps the code for launch strings, the guard refuses the read-only search with \"Delegates spawn nothing\", so the reviewer cannot read the guard it is reviewing. None of these commands starts Pi. Reproduced on main, 3 of 3 runs, by saving this as `repro.ts` in a clone and running `bun repro.ts`:\n\n```ts\nimport { spawnGuard } from \".\u002Fagent\u002Fextensions\u002Fdelegate-guard.ts\";\nconst guard = spawnGuard([\"node\", \"pi\", \"--print\"])!;\nfor (const cmd of [\n  \"grep -nE 'pi-subagent|pi --print' delegate-guard.ts\",\n  'rg \"foo; pi -p\" .',\n]) console.log(cmd, guard(cmd) === undefined ? \"allowed\" : \"BLOCKED\");\n```\n\n```text\ngrep -nE 'pi-subagent|pi --print' delegate-guard.ts BLOCKED\nrg \"foo; pi -p\" . BLOCKED\n```\n\n## Done when\n\n- [ ] **A delegate can search for launch strings.** Check: `delegate-guard.test.ts` runs both commands above as a delegate, and the guard allows each.\n- [ ] **Real launches are still refused.** Check: the existing launch cases, including heredoc and `bg_start` launches, are still blocked.\n- [ ] **The repository gate passes.** Check: `vp run verify` exits 0.\n\n## Suggested approach\n\nHypothesis: the guard splits commands on `;` and `|` inside quotes, so the quoted words read as a `pi --print` command. Teaching the splitter shell quoting would fix it. Allowing every command that starts with `grep` or `rg` would not, because `rg x; pi -p` would then start Pi.\n\n## Context\n\n- The subagents skill's Kinds section defines delegates and owners and why a delegate starts nothing. The fix must keep that rule.\n````\n\nThe same ticket, written badly:\n\n```markdown\ndelegate-guard: improve command parsing\n\n## Problem\n\nThe regex in delegate-guard is broken and blocks valid commands. See \u002Ftmp\u002Freflect-result.md.\n\n## Done when\n\n- [ ] Use a proper parser\n- [ ] Add tests\n```\n\nIts title names a remedy instead of a symptom. Its Problem states a guessed cause as fact, names nobody who is hurt, and points at a file only its writer can open. Its Done when prescribes code instead of a behavior, gives no check anyone could run, and leaves out the boundary: nothing says real launches must still be refused.\n\n## Size\n\nSize each ticket as a vertical slice. It cuts a narrow path through every layer it needs, is verifiable on its own, and fits in one agent session. Split a wide refactor into an expand ticket, migrate tickets in batches, and a contract ticket, each blocked by the one before.\n\n## Before you file\n\n- Search the tracker for the same symptom, error text, and area. For a confident duplicate, add the new evidence to the existing issue instead of filing. For a possible match, file the new ticket, then comment on the match with a link to it and say why it is not a duplicate.\n- For complex agent-facing workflow instructions inside a ticket, use the **writing-for-agents** skill.\n\n## Check the body\n\nWrite the body to a file and run both gates.\n\n1. **Structure.** Run `..\u002Fwriting-good-prs\u002Fscripts\u002Fcheck-body.ts ticket \u003Cbody-file> --title \"\u003Ctitle>\"`, with `--template \u003Cpath>` when the repository has an issue template. Fix each printed problem and rerun until it exits 0. Exit 0 means the headings and title parse. It says nothing about the case the body makes.\n2. **Implementer read.** Give one subagent in the `cross-family reviewer` role, per the **subagents** skill, only the title and the body file. Ask it to:\n   1. Retell the problem as one story, with who it costs, and name the witness that shows it, or write `none visible`.\n   2. For each Done-when item, say exactly what it would run and what result counts as done, or write `unclear`.\n   3. As the implementer, list what it would still need to start, or write `nothing`.\n\n   Run the read once. Fix every gap its answers show, then move on without a second read.\n\n   A delegate launches no subagent, so it writes the body file and names this read in its report for its parent to run.\n\nPublish the same file through the tracker, then read the ticket back and compare what the tracker stored with the title and the body file. On GitHub, publish with `gh issue create --body-file` or `gh issue edit --body-file`, read back with `gh issue view \u003Cn> --json title,body`, and diff the body with `gh issue view \u003Cn> --json body --jq .body | diff \u003Cbody-file> -`. Fix each difference at its cause, such as a shell expansion or a template the tracker applied, republish, and read it back once more. Report any difference that remains.\n","# Writing good tickets\n\nA ticket hands one problem to someone who was not in the conversation, a developer or an agent, who takes it to one PR. It answers, in order: what goes wrong today and for whom, what shows it, how anyone will know it is fixed, and what to read before starting. The closing PR proves each `## Done when` item with a witness, per the **writing-good-prs** skill.\n\nEdit the prose with the **unslop** skill. Follow the repository's tracker and template conventions, starting from its issue tracker record, `docs\u002Fagents\u002Fissue-tracker.md`, when it has one. When the repository has an issue template, fill its sections and apply the rules below to the section that plays each role.\n\nEverything the ticket points at is reachable by any developer with access to the repository: issues, PRs, CI runs, hosted media, and public URLs. Paths on your machine, such as your home directory, `\u002Ftmp`, a worktree, or an agent state folder, are reachable only by you. Paste what they hold instead. Say \"on main\" or name the released version where you saw it, rather than a commit hash.\n\n## Title\n\nWrite `area: symptom`, with no trailing period: the trigger and what the reader sees, for one failure. A cause or a remedy stays out of the title, because the symptom stays true when the guessed cause turns out wrong.\n\n- Good: `subagents: an autonomous run sends one unit through five fix rounds until the operator stops it`\n- Bad: `subagents: an autonomous run has no round count per unit, so nothing stops a third fix round`, which names the missing mechanism instead of what the reader saw.\n\n## Body\n\n```markdown\n## Problem\n\n## Done when\n\n- [ ] \n\n## Suggested approach\n\n## Context\n```\n\n`## Problem` and `## Done when` are required. Drop any other section with nothing to say.\n\n### Problem\n\n1. **Open with one story, in the present tense.** Who hits it, the trigger, what happens, what should happen, and what it costs. For a feature, the story is the person and the moment the current behavior fails them, quoted in their words when you have them. This story is the baseline: the closing PR is judged by whether the same story now ends differently.\n2. **Show the witness.** Paste the decisive lines: output, a log excerpt, a screenshot, or a quoted report, with where you saw it and how often, such as `3 of 3 runs`.\n3. **Give the recipe.** The exact steps, run from a fresh clone of the repository after its normal setup. Say whether you reproduced it yourself, and write `reported, not reproduced` when you did not.\n\nPreserve the nuances from the conversation that an implementer would otherwise lose.\n\n### Done when\n\nEach item is one behavior, written so a developer reads what must be true and an agent reads how to check it:\n\n```markdown\n- [ ] **\u003Cthe behavior, in plain words>.** Check: \u003Cthe setup, the action, and the exact result to observe>.\n```\n\n- The check names a surface that anyone can run: a command and the output it must print, a test case and what it asserts, or a walk through the running app with the repository's `verify-*` skill.\n- The first item replays the Problem's story with the new ending.\n- When the fix could overshoot, give the boundary its own item: what must keep working as before, such as \"real `pi --print` launches are still refused\".\n- A behavior the conversation settled, such as \"a missing Java still fails the check\", is an item here.\n- An unknown that running something can settle is an item too, such as \"**The faster layout is kept.** Check: prototype both and keep the one that renders in under 16 ms.\"\n- Repository gates such as `vp run verify` go last, and never stand alone.\n\nA ticket that still waits on a product call only a person can make is not ready. Ask that person before you file.\n\n### Suggested approach\n\nOptional, and never binding: the implementer owns the how. Give it when you hold something that would save them time:\n\n- The cause you suspect, marked `Hypothesis` with what you saw that points to it.\n- A possible approach and the alternative you would rule out, with the reason.\n- A visual from the **writing-good-prs** Shape menu when it shows the idea faster than prose.\n\nName behavior and symbols, not file paths. Finding where a symbol lives is one search.\n\n### Context\n\nList the material the implementer reads before starting that neither a code search nor the tracker gives them, each with one line on why it matters:\n\n- Docs, specs, and external URLs the fix must follow.\n- Attachments: logs, screenshots, recordings, and data, hosted where everyone can open them.\n\nRelate other issues and PRs through the tracker itself, as a parent, a blocker, or a sub-issue, per the issue tracker record, so the link lives in one place. When another issue settled something this ticket depends on, state what it settled in Problem or Done when.\n\n## Example\n\nThe same ticket, condensed from a real one and written well:\n\n````markdown\ndelegate-guard: a delegate's read-only grep for launch strings is refused as a launch\n\n## Problem\n\nWhen a reviewer subagent greps the code for launch strings, the guard refuses the read-only search with \"Delegates spawn nothing\", so the reviewer cannot read the guard it is reviewing. None of these commands starts Pi. Reproduced on main, 3 of 3 runs, by saving this as `repro.ts` in a clone and running `bun repro.ts`:\n\n```ts\nimport { spawnGuard } from \".\u002Fagent\u002Fextensions\u002Fdelegate-guard.ts\";\nconst guard = spawnGuard([\"node\", \"pi\", \"--print\"])!;\nfor (const cmd of [\n  \"grep -nE 'pi-subagent|pi --print' delegate-guard.ts\",\n  'rg \"foo; pi -p\" .',\n]) console.log(cmd, guard(cmd) === undefined ? \"allowed\" : \"BLOCKED\");\n```\n\n```text\ngrep -nE 'pi-subagent|pi --print' delegate-guard.ts BLOCKED\nrg \"foo; pi -p\" . BLOCKED\n```\n\n## Done when\n\n- [ ] **A delegate can search for launch strings.** Check: `delegate-guard.test.ts` runs both commands above as a delegate, and the guard allows each.\n- [ ] **Real launches are still refused.** Check: the existing launch cases, including heredoc and `bg_start` launches, are still blocked.\n- [ ] **The repository gate passes.** Check: `vp run verify` exits 0.\n\n## Suggested approach\n\nHypothesis: the guard splits commands on `;` and `|` inside quotes, so the quoted words read as a `pi --print` command. Teaching the splitter shell quoting would fix it. Allowing every command that starts with `grep` or `rg` would not, because `rg x; pi -p` would then start Pi.\n\n## Context\n\n- The subagents skill's Kinds section defines delegates and owners and why a delegate starts nothing. The fix must keep that rule.\n````\n\nThe same ticket, written badly:\n\n```markdown\ndelegate-guard: improve command parsing\n\n## Problem\n\nThe regex in delegate-guard is broken and blocks valid commands. See \u002Ftmp\u002Freflect-result.md.\n\n## Done when\n\n- [ ] Use a proper parser\n- [ ] Add tests\n```\n\nIts title names a remedy instead of a symptom. Its Problem states a guessed cause as fact, names nobody who is hurt, and points at a file only its writer can open. Its Done when prescribes code instead of a behavior, gives no check anyone could run, and leaves out the boundary: nothing says real launches must still be refused.\n\n## Size\n\nSize each ticket as a vertical slice. It cuts a narrow path through every layer it needs, is verifiable on its own, and fits in one agent session. Split a wide refactor into an expand ticket, migrate tickets in batches, and a contract ticket, each blocked by the one before.\n\n## Before you file\n\n- Search the tracker for the same symptom, error text, and area. For a confident duplicate, add the new evidence to the existing issue instead of filing. For a possible match, file the new ticket, then comment on the match with a link to it and say why it is not a duplicate.\n- For complex agent-facing workflow instructions inside a ticket, use the **writing-for-agents** skill.\n\n## Check the body\n\nWrite the body to a file and run both gates.\n\n1. **Structure.** Run `..\u002Fwriting-good-prs\u002Fscripts\u002Fcheck-body.ts ticket \u003Cbody-file> --title \"\u003Ctitle>\"`, with `--template \u003Cpath>` when the repository has an issue template. Fix each printed problem and rerun until it exits 0. Exit 0 means the headings and title parse. It says nothing about the case the body makes.\n2. **Implementer read.** Give one subagent in the `cross-family reviewer` role, per the **subagents** skill, only the title and the body file. Ask it to:\n   1. Retell the problem as one story, with who it costs, and name the witness that shows it, or write `none visible`.\n   2. For each Done-when item, say exactly what it would run and what result counts as done, or write `unclear`.\n   3. As the implementer, list what it would still need to start, or write `nothing`.\n\n   Run the read once. Fix every gap its answers show, then move on without a second read.\n\n   A delegate launches no subagent, so it writes the body file and names this read in its report for its parent to run.\n\nPublish the same file through the tracker, then read the ticket back and compare what the tracker stored with the title and the body file. On GitHub, publish with `gh issue create --body-file` or `gh issue edit --body-file`, read back with `gh issue view \u003Cn> --json title,body`, and diff the body with `gh issue view \u003Cn> --json body --jq .body | diff \u003Cbody-file> -`. Fix each difference at its cause, such as a shell expansion or a template the tracker applied, republish, and read it back once more. Report any difference that remains.\n",{"name":5,"description":7,"user-invokable":50,"disable-model-invocation":50},"main","f7936596c1ba2e1472dadccc3f111b9d517fa96c","agent\u002Fskills\u002Fwriting-good-tickets",2,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup","https:\u002F\u002Fgithub.com\u002Fdrsh4dow","https:\u002F\u002Fdanielmoretti.com\u002F","Toss A Coin To Your Witcher :pirate_flag: ","2026-11-03 22:13:53",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add drsh4dow\u002Fpi-setup --skill writing-good-tickets",{"tool":69,"command":70},"bunx","bunx skills add drsh4dow\u002Fpi-setup --skill writing-good-tickets",{"tool":72,"command":73},"pnpm","pnpm dlx skills add drsh4dow\u002Fpi-setup --skill writing-good-tickets","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-tickets\u002FSKILL.md",true,[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"agents\u002Fopenai.yaml","REFERENCE","参考文档",42,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-tickets\u002Fagents\u002Fopenai.yaml",[84,102,119,140,151,171],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":49},"01M71P4GPJMBK21BTZBKY9T8EE","changelog","Write the changelog entry for a pull request. Use when a PR changes behavior that users, operators, or integrators can notice.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fevals\u002Fharness-lessons\u002Ffixtures\u002Fchangelog-skill\u002FSKILL.md",[],[86,91,92,39,42,44,36,93,94,95,96,97,48,98,99,100,101],"changes","changelog entry","entry","behavior","request","for","pull request","operators","notice","pull","users",{"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":110,"publishedAt":49},"01M71P4C0B0DXTRRSG9RA6Y687","writing-good-prs","Write or update a pull request title and body that a reviewer can trust and own. Use when opening a PR or editing its description.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-prs\u002FSKILL.md",[108,109],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[111,29,112,32,42,113,44,43,114,48,115,100,39,116,117,36,37,95,97,118],"writing good prs","prs","editing","reviewer","trust","body","opening a pr","title",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":127,"publishedAt":49},"01M71P49D1AG2MR6AYNPMMT34Z","writing-good-commits","Write or reword a git commit message and size the commit it describes. Use when committing, or when reshaping commits during a rebase.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-commits\u002FSKILL.md",[125,126],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[128,129,32,29,130,131,132,42,133,134,43,44,135,136,36,137,138,139],"writing good commits","commits","it","commit","committing","commit message","git commit message","git commit","git","size","message","rebase",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":148,"publishedAt":49},"01M71P480BDE55JMPVVEBCFS7P","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[146,147],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[29,96,149,44,42,150,43,113],"writing for agents","documents",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":49},"01M71P45SNCD7DDSA6FRVCPA17","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwizard\u002FSKILL.md",[],[153,43,158,44,159,160,161,162,96,163,164,42,165,166,167,168,39,169,40,170],"invoke","only","provisioning infrastructure","ci","up","setting","running","human","generate","dashboard","credentials","interactive","Bash",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":49},"01M71P43DNNPQ67NY6G4XQQM50","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwhy\u002FSKILL.md",[],[173,178,179,94,180,181,43,44,182,183,96,184],"rationale","data","how","work","design","runtime","thresholds"]