[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71P3Y82T1W17GQ0YZDH08AC":3,"skill-same:01M71P3Y82T1W17GQ0YZDH08AC":58},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":43,"updatedAt":44,"install":45,"resources":57},"01M71P3Y82T1W17GQ0YZDH08AC","triage",null,"Turn a batch of tickets someone else wrote into agent-ready work, with duplicates closed, stale tickets dropped, decisions grilled, and a parent spec over sub-tickets with blocking edges.","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\u002Ftriage\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29],"with","ready","work","duplicates","tickets","spec","true","stale","parent","decisions","batch","2026-11-10 10:56:23",false,"---\nname: triage\ndescription: Turn a batch of tickets someone else wrote into agent-ready work, with duplicates closed, stale tickets dropped, decisions grilled, and a parent spec over sub-tickets with blocking edges.\ndisable-model-invocation: true\nuser-invokable: true\n---\n\n# Triage\n\nThe user passes a **batch** of ticket ids, such as `\u002Fskill:triage ENG-101, ENG-104, ENG-107`, usually written by other people and short of the bar in [writing-good-tickets](..\u002Fwriting-good-tickets\u002FSKILL.md). Triage reasons across the whole batch, not one ticket at a time. It ends with each ticket ready for an agent, closed with a reason, or waiting on a named person, and with the batch grouped by outcome, each group a parent spec over sub-tickets where the work calls for it. Tickets from [to-tickets](..\u002Fto-tickets\u002FSKILL.md) are already agent-ready, so they don't need triage.\n\nRead the project's issue tracker record, `docs\u002Fagents\u002Fissue-tracker.md`, and its domain record, `docs\u002Fagents\u002Fdomain.md`. If the tracker record is missing, stop and tell the user to run [setup-sh4dow-skills](..\u002Fsetup-sh4dow-skills\u002FSKILL.md).\n\n- **Reads** start from the record's **Fetch** and **Search**. Where they omit something the steps below need, such as children, linked PRs, or a linked document, use any read-only tool that reaches it, and list each gap in the report so setup can add it to the record.\n- **Writes** go through the record's operations only. When the record names no **Edit**, use the tracker tool that updates an existing ticket by id, after its schema or `--help` confirms it does, and tell the user to rerun setup to record it.\n\nTriage writes nothing to the tracker before step 6, and nothing there without the user's approval. When the user wrote a ticket, the decisions in it are the user's.\n\n## The ledger\n\nKeep the batch's state in `\u003Cstate folder>\u002Ftriage\u002F\u003Cbatch-slug>\u002F`, with the state folder the system prompt defines:\n\n- `raw\u002F\u003Cid>.md`: each ticket as fetched, with its last-updated time.\n- `grounding\u002F\u003Cid>.md`: each grounding report from step 2.\n- `drafts\u002F\u003Cid or new-slug>.md`: each body from step 5.\n- `plan.md`: the approved writes from step 6, each `pending`, `applied` with the id the tracker returned, or `verified`.\n- `ledger.md`: one section per ticket, with its title, author, verdict, evidence, the decisions that settle it, and its open questions.\n\nWhen `ledger.md` already exists for these ids, this is a resume. Fetch each ticket again. A ticket whose body changed or that has a new comment since its `raw\u002F` file loses its grounding, its draft, and its approval: show the change, then redo those for it. Its settled decisions stand unless the change contradicts one, which you ask about again. Don't re-ask resolved questions.\n\nEach ticket carries one **verdict**, kept in the ledger. A ticket that bundles separate pieces of work gets a verdict per piece, and the structure in step 3 splits it.\n\n| Verdict | Means |\n| --- | --- |\n| `duplicate` | Another ticket covers the same work. Names the canonical ticket. |\n| `implemented` | The behavior already exists on the branch production deploys from. Names where. |\n| `obsolete` | The need behind it is gone. Names the evidence. |\n| `needs-decision` | A decision the user can make is still open, or grounding could not settle the claim. |\n| `needs-author` | A question only someone else can answer is open. Names that person. |\n| `parent` | The spec over a group's sub-tickets, in the template of [to-spec](..\u002Fto-spec\u002FSKILL.md). |\n| `ready-for-agent` | Specified to the writing-good-tickets bar, and an agent can take it. |\n| `ready-for-human` | Specified to the same bar, but it needs judgment, access, or manual testing that an agent can't supply. Says which. |\n\n## 1. Snapshot\n\nFetch each ticket in full: body, every comment, relations (parent, children, blockers, duplicates), project, attachments, linked PRs, and the PRs its body references. Fetch its parent and the documents its project links too, because a parent often carries the reason for the work. Save each one to `raw\u002F\u003Cid>.md`.\n\nJudge every ticket from its snapshot, never from a search listing, because a listing omits the comments, and a comment may already say the work is done.\n\nDone when every ticket in the batch has a `raw\u002F` file that holds its comments, relations, and linked PRs.\n\n## 2. Ground\n\nFor each ticket, launch one delegate subagent per [subagents](..\u002Fsubagents\u002FSKILL.md), at most four at a time, from the project directory so the tracker tools reach them. Redirect each one's stdout to `grounding\u002F\u003Cid>.md`. Pin it to one commit of each repository it reads, the tip of the branch production deploys from unless the ticket's work lives on an open PR, and have it name that commit. It writes nothing to the tracker and changes nothing in a shared checkout. A reproduction that writes files, such as a build or a test run, runs in its own worktree or scratch directory, and a claim it could not reproduce says it rests on reading the code.\n\nGive it the ticket's `raw\u002F` file, the glossary and ADRs for its area, and this task:\n\n- **Redundancy.** Search for an existing implementation of the requested behavior by domain concept (not just the request's wording), and report where you looked. Search the PRs of the repositories the ticket targets for its id, and say which merged and what they changed.\n- **Claim.** For a bug, find the code path and say whether it still behaves as the ticket describes, reproducing it when that takes a few minutes. For a feature, say what the code does today. Report confirmed, failed, or insufficient detail.\n- **Language.** List each term the ticket uses that conflicts with the glossary, or that names a concept the glossary lacks.\n- **Open decisions.** List each product or design choice an implementer would have to guess, and who could make it: the user, or a person the ticket names.\n- **Verdict.** Propose one verdict from the ledger's table, or one per piece of a bundled ticket.\n\nThe report opens with a summary of at most ten lines: the verdict, the decisive evidence, the open decisions, and the overlaps it noticed. Every claim in the report cites a code symbol, a commit, a PR, or a comment, or says `not checked`. Read the summaries, and open the full report for the evidence behind each closure. Rerun a report whose verdict cites nothing once. When it still cites nothing, the verdict is `needs-decision`, and the gap becomes a question in step 4.\n\nDone when every ticket has a grounding report and a cited verdict.\n\n## 3. Map the set\n\nCompare the tickets with each other. Matching is by concept similarity, not keyword. Then **Search** the tracker for each concept the batch covers, with several phrasings, because the tracker matches words. List the open tickets outside the batch that overlap it as **neighbors**. Fetch a neighbor in full before the structure relies on it.\n\nPropose a structure:\n\n- **Groups.** One group per outcome the batch serves. A ticket that shares no outcome stays on its own.\n- **Parent spec.** For a group that needs one, promote the existing ticket that covers its outcome, in the batch or a neighbor. Create a new parent only when none does.\n- **Sub-tickets.** Slice each group's work by the vertical-slice rules in to-tickets, each slice with its blocking edges. A ticket that covers two slices splits. Tickets that cover the same slice merge into the one with the most history (comments, links, PRs), and the rest become its duplicates.\n- **Closures.** Each `duplicate`, `implemented`, and `obsolete` ticket or piece, with its evidence.\n- **Changes to existing tickets.** For each ticket the structure touches, neighbors included: which slice keeps its id, and what happens to its existing parent, children, and blockers.\n\nPresent a table with one row per ticket (id, title, proposed verdict, overlaps, evidence), then the structure, then the neighbors. Every neighbor the structure does not touch stays unchanged. Wait for the user to approve or change the structure.\n\nDone when the user approves a structure.\n\n## 4. Grill\n\nRun [grilling](..\u002Fgrilling\u002FSKILL.md) and [domain-modeling](..\u002Fdomain-modeling\u002FSKILL.md) together over one design tree for the whole batch. Seed the tree with every open decision, term conflict, and unsettled claim from the grounding reports. Ask a decision that several tickets share once, before the decisions that hang off it, and record in the ledger which tickets it settles. Update the glossary and ADRs as decisions land, per the domain record.\n\nA question only someone else can answer, such as a product call the ticket's author owns, is **parked**: draft it as a comment for that person, mark its ticket `needs-author`, and take the branches that depend on it off the tree. Questions must be specific and actionable, not \"please provide more info\".\n\nDone when the frontier holds only parked questions and the user confirms you have reached a shared understanding.\n\n## 5. Draft\n\nWrite each parent spec in the to-spec template, and each sub-ticket per writing-good-tickets. Each decision from step 4 lands in one place: an observable behavior in the ticket's `## Done when`, a design choice in its `## Suggested approach` or the parent's Implementation Decisions, and a term in the glossary.\n\nAn existing ticket keeps its author's text, quoted line by line under a `### Original description` heading at the end of its last section, with the author and date. When the fetched body already has that heading, from an earlier triage, keep that block as it is and quote nothing else.\n\nPass each sub-ticket through the two gates in the \"Check the body\" section of writing-good-tickets: the structure check, then one implementer read. A sub-ticket that passes both, with no parked question, takes `ready-for-agent` or `ready-for-human`. A sub-ticket with a parked question keeps `needs-author`, and so does each ticket it blocks.\n\nDone when every draft is in `drafts\u002F` and every sub-ticket without a parked question passed both gates.\n\n## 6. Write back\n\nShow the user, for each ticket: the diff from its `raw\u002F` body to its draft, the relation and state changes, and the comment you will post. Write the writes the user approves to `plan.md` as `pending`, in dependency order: parents, then sub-tickets with each blocker before what it blocks, then relations, then closures, then comments, including each parked question.\n\nApply the plan one write at a time, and mark each `applied`, with the id the tracker returned, before the next:\n\n- Fetch each ticket just before its first write. When it changed since its `raw\u002F` file, stop, show the change, and ask again. Its later writes need no fresh check, because the plan's own writes change it.\n- Publish or edit each body by the publish steps in writing-good-tickets. Use the record's **Nest under a parent** and **Block** for relations, **Close** for closures, in its duplicate form for a duplicate, and **Comment** for each ticket's comment, which says what triage changed and the decisions behind it.\n- When the tracker already has a ready-for-agent label, apply it to each ready ticket. Create no labels.\n- Leave the fields triage did not decide, such as assignee, priority, and estimate, as they are.\n- After a failed or lost response, **Search** or **Fetch** for the write before retrying it, so a retry never creates a second ticket or comment.\n\nFetch every ticket the plan touched and compare it with the plan: body, title, parent, blockers, duplicate target, state, label, and each planned comment. A body includes any `Part of` or `Blocked by` line the record's relation fallback adds. Mark each match `verified`. Fix each difference at its cause once, and report the differences that remain.\n\n## 7. Report\n\nList each ticket with its verdict, its link, and what changed, the parked questions and whom they wait on, the neighbors left unchanged, the record gaps found in steps 1 and 6, and the ledger's path.\n","# Triage\n\nThe user passes a **batch** of ticket ids, such as `\u002Fskill:triage ENG-101, ENG-104, ENG-107`, usually written by other people and short of the bar in [writing-good-tickets](..\u002Fwriting-good-tickets\u002FSKILL.md). Triage reasons across the whole batch, not one ticket at a time. It ends with each ticket ready for an agent, closed with a reason, or waiting on a named person, and with the batch grouped by outcome, each group a parent spec over sub-tickets where the work calls for it. Tickets from [to-tickets](..\u002Fto-tickets\u002FSKILL.md) are already agent-ready, so they don't need triage.\n\nRead the project's issue tracker record, `docs\u002Fagents\u002Fissue-tracker.md`, and its domain record, `docs\u002Fagents\u002Fdomain.md`. If the tracker record is missing, stop and tell the user to run [setup-sh4dow-skills](..\u002Fsetup-sh4dow-skills\u002FSKILL.md).\n\n- **Reads** start from the record's **Fetch** and **Search**. Where they omit something the steps below need, such as children, linked PRs, or a linked document, use any read-only tool that reaches it, and list each gap in the report so setup can add it to the record.\n- **Writes** go through the record's operations only. When the record names no **Edit**, use the tracker tool that updates an existing ticket by id, after its schema or `--help` confirms it does, and tell the user to rerun setup to record it.\n\nTriage writes nothing to the tracker before step 6, and nothing there without the user's approval. When the user wrote a ticket, the decisions in it are the user's.\n\n## The ledger\n\nKeep the batch's state in `\u003Cstate folder>\u002Ftriage\u002F\u003Cbatch-slug>\u002F`, with the state folder the system prompt defines:\n\n- `raw\u002F\u003Cid>.md`: each ticket as fetched, with its last-updated time.\n- `grounding\u002F\u003Cid>.md`: each grounding report from step 2.\n- `drafts\u002F\u003Cid or new-slug>.md`: each body from step 5.\n- `plan.md`: the approved writes from step 6, each `pending`, `applied` with the id the tracker returned, or `verified`.\n- `ledger.md`: one section per ticket, with its title, author, verdict, evidence, the decisions that settle it, and its open questions.\n\nWhen `ledger.md` already exists for these ids, this is a resume. Fetch each ticket again. A ticket whose body changed or that has a new comment since its `raw\u002F` file loses its grounding, its draft, and its approval: show the change, then redo those for it. Its settled decisions stand unless the change contradicts one, which you ask about again. Don't re-ask resolved questions.\n\nEach ticket carries one **verdict**, kept in the ledger. A ticket that bundles separate pieces of work gets a verdict per piece, and the structure in step 3 splits it.\n\n| Verdict | Means |\n| --- | --- |\n| `duplicate` | Another ticket covers the same work. Names the canonical ticket. |\n| `implemented` | The behavior already exists on the branch production deploys from. Names where. |\n| `obsolete` | The need behind it is gone. Names the evidence. |\n| `needs-decision` | A decision the user can make is still open, or grounding could not settle the claim. |\n| `needs-author` | A question only someone else can answer is open. Names that person. |\n| `parent` | The spec over a group's sub-tickets, in the template of [to-spec](..\u002Fto-spec\u002FSKILL.md). |\n| `ready-for-agent` | Specified to the writing-good-tickets bar, and an agent can take it. |\n| `ready-for-human` | Specified to the same bar, but it needs judgment, access, or manual testing that an agent can't supply. Says which. |\n\n## 1. Snapshot\n\nFetch each ticket in full: body, every comment, relations (parent, children, blockers, duplicates), project, attachments, linked PRs, and the PRs its body references. Fetch its parent and the documents its project links too, because a parent often carries the reason for the work. Save each one to `raw\u002F\u003Cid>.md`.\n\nJudge every ticket from its snapshot, never from a search listing, because a listing omits the comments, and a comment may already say the work is done.\n\nDone when every ticket in the batch has a `raw\u002F` file that holds its comments, relations, and linked PRs.\n\n## 2. Ground\n\nFor each ticket, launch one delegate subagent per [subagents](..\u002Fsubagents\u002FSKILL.md), at most four at a time, from the project directory so the tracker tools reach them. Redirect each one's stdout to `grounding\u002F\u003Cid>.md`. Pin it to one commit of each repository it reads, the tip of the branch production deploys from unless the ticket's work lives on an open PR, and have it name that commit. It writes nothing to the tracker and changes nothing in a shared checkout. A reproduction that writes files, such as a build or a test run, runs in its own worktree or scratch directory, and a claim it could not reproduce says it rests on reading the code.\n\nGive it the ticket's `raw\u002F` file, the glossary and ADRs for its area, and this task:\n\n- **Redundancy.** Search for an existing implementation of the requested behavior by domain concept (not just the request's wording), and report where you looked. Search the PRs of the repositories the ticket targets for its id, and say which merged and what they changed.\n- **Claim.** For a bug, find the code path and say whether it still behaves as the ticket describes, reproducing it when that takes a few minutes. For a feature, say what the code does today. Report confirmed, failed, or insufficient detail.\n- **Language.** List each term the ticket uses that conflicts with the glossary, or that names a concept the glossary lacks.\n- **Open decisions.** List each product or design choice an implementer would have to guess, and who could make it: the user, or a person the ticket names.\n- **Verdict.** Propose one verdict from the ledger's table, or one per piece of a bundled ticket.\n\nThe report opens with a summary of at most ten lines: the verdict, the decisive evidence, the open decisions, and the overlaps it noticed. Every claim in the report cites a code symbol, a commit, a PR, or a comment, or says `not checked`. Read the summaries, and open the full report for the evidence behind each closure. Rerun a report whose verdict cites nothing once. When it still cites nothing, the verdict is `needs-decision`, and the gap becomes a question in step 4.\n\nDone when every ticket has a grounding report and a cited verdict.\n\n## 3. Map the set\n\nCompare the tickets with each other. Matching is by concept similarity, not keyword. Then **Search** the tracker for each concept the batch covers, with several phrasings, because the tracker matches words. List the open tickets outside the batch that overlap it as **neighbors**. Fetch a neighbor in full before the structure relies on it.\n\nPropose a structure:\n\n- **Groups.** One group per outcome the batch serves. A ticket that shares no outcome stays on its own.\n- **Parent spec.** For a group that needs one, promote the existing ticket that covers its outcome, in the batch or a neighbor. Create a new parent only when none does.\n- **Sub-tickets.** Slice each group's work by the vertical-slice rules in to-tickets, each slice with its blocking edges. A ticket that covers two slices splits. Tickets that cover the same slice merge into the one with the most history (comments, links, PRs), and the rest become its duplicates.\n- **Closures.** Each `duplicate`, `implemented`, and `obsolete` ticket or piece, with its evidence.\n- **Changes to existing tickets.** For each ticket the structure touches, neighbors included: which slice keeps its id, and what happens to its existing parent, children, and blockers.\n\nPresent a table with one row per ticket (id, title, proposed verdict, overlaps, evidence), then the structure, then the neighbors. Every neighbor the structure does not touch stays unchanged. Wait for the user to approve or change the structure.\n\nDone when the user approves a structure.\n\n## 4. Grill\n\nRun [grilling](..\u002Fgrilling\u002FSKILL.md) and [domain-modeling](..\u002Fdomain-modeling\u002FSKILL.md) together over one design tree for the whole batch. Seed the tree with every open decision, term conflict, and unsettled claim from the grounding reports. Ask a decision that several tickets share once, before the decisions that hang off it, and record in the ledger which tickets it settles. Update the glossary and ADRs as decisions land, per the domain record.\n\nA question only someone else can answer, such as a product call the ticket's author owns, is **parked**: draft it as a comment for that person, mark its ticket `needs-author`, and take the branches that depend on it off the tree. Questions must be specific and actionable, not \"please provide more info\".\n\nDone when the frontier holds only parked questions and the user confirms you have reached a shared understanding.\n\n## 5. Draft\n\nWrite each parent spec in the to-spec template, and each sub-ticket per writing-good-tickets. Each decision from step 4 lands in one place: an observable behavior in the ticket's `## Done when`, a design choice in its `## Suggested approach` or the parent's Implementation Decisions, and a term in the glossary.\n\nAn existing ticket keeps its author's text, quoted line by line under a `### Original description` heading at the end of its last section, with the author and date. When the fetched body already has that heading, from an earlier triage, keep that block as it is and quote nothing else.\n\nPass each sub-ticket through the two gates in the \"Check the body\" section of writing-good-tickets: the structure check, then one implementer read. A sub-ticket that passes both, with no parked question, takes `ready-for-agent` or `ready-for-human`. A sub-ticket with a parked question keeps `needs-author`, and so does each ticket it blocks.\n\nDone when every draft is in `drafts\u002F` and every sub-ticket without a parked question passed both gates.\n\n## 6. Write back\n\nShow the user, for each ticket: the diff from its `raw\u002F` body to its draft, the relation and state changes, and the comment you will post. Write the writes the user approves to `plan.md` as `pending`, in dependency order: parents, then sub-tickets with each blocker before what it blocks, then relations, then closures, then comments, including each parked question.\n\nApply the plan one write at a time, and mark each `applied`, with the id the tracker returned, before the next:\n\n- Fetch each ticket just before its first write. When it changed since its `raw\u002F` file, stop, show the change, and ask again. Its later writes need no fresh check, because the plan's own writes change it.\n- Publish or edit each body by the publish steps in writing-good-tickets. Use the record's **Nest under a parent** and **Block** for relations, **Close** for closures, in its duplicate form for a duplicate, and **Comment** for each ticket's comment, which says what triage changed and the decisions behind it.\n- When the tracker already has a ready-for-agent label, apply it to each ready ticket. Create no labels.\n- Leave the fields triage did not decide, such as assignee, priority, and estimate, as they are.\n- After a failed or lost response, **Search** or **Fetch** for the write before retrying it, so a retry never creates a second ticket or comment.\n\nFetch every ticket the plan touched and compare it with the plan: body, title, parent, blockers, duplicate target, state, label, and each planned comment. A body includes any `Part of` or `Blocked by` line the record's relation fallback adds. Mark each match `verified`. Fix each difference at its cause once, and report the differences that remain.\n\n## 7. Report\n\nList each ticket with its verdict, its link, and what changed, the parked questions and whom they wait on, the neighbors left unchanged, the record gaps found in steps 1 and 6, and the ledger's path.\n",{"name":5,"description":7,"user-invokable":35,"disable-model-invocation":35},true,"main","f7936596c1ba2e1472dadccc3f111b9d517fa96c","agent\u002Fskills\u002Ftriage",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":46,"prompt":56,"zipAvailable":35},[47,50,53],{"tool":48,"command":49},"npx","npx skills add drsh4dow\u002Fpi-setup --skill triage",{"tool":51,"command":52},"bunx","bunx skills add drsh4dow\u002Fpi-setup --skill triage",{"tool":54,"command":55},"pnpm","pnpm dlx skills add drsh4dow\u002Fpi-setup --skill triage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Ftriage\u002FSKILL.md",[],[59,82,113,130,151,162],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":30},"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",[],[61,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81],"users","pull","notice","changes","operators","pr","pull request","for","request","behavior","entry","write","use","when","can","changelog entry",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":98,"publishedAt":30},"01M71P4E9AZM56JBY227P2G1SC","writing-good-tickets","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.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-tickets\u002FSKILL.md",[88,93],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[99,100,23,101,71,102,103,104,78,105,79,106,107,80,108,109,77,110,111,112],"good","writing","writing good tickets","feature","filing","ticket","false","file","one","plan","update","bug","take","issue",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":121,"publishedAt":30},"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",[119,120],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},[99,122,100,123,67,124,71,125,78,105,79,80,126,127,72,74,109,77,128,129],"prs","writing good prs","trust","editing","reviewer","title","opening a pr","body",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":138,"publishedAt":30},"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",[136,137],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},[139,99,100,140,141,142,77,143,144,145,78,105,146,147,79,148,149,150],"commits","writing good commits","message","size","git commit message","git","git commit","rebase","commit message","committing","commit","it",{"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":159,"publishedAt":30},"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",[157,158],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},[160,73,100,125,78,105,161,79],"writing for agents","documents",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":30},"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",[],[164,169,170,73,171,172,173,174,78,175,105,79,176,107,177,80,178,179,180,181],"running","setting","up","ci","provisioning infrastructure","only","invoke","Bash","interactive","credentials","dashboard","generate","human"]