[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6R97V91NPJWV2H5YVCHN1R4":3,"skill-same:01M6R97V91NPJWV2H5YVCHN1R4":82},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6R97V91NPJWV2H5YVCHN1R4","github-triage",null,"Triage GitHub issues through a label-based state machine with interactive grilling sessions. Use when user wants to triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.","Nairon-AI\u002Fagentic-starter-pack","Nairon-AI","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F260662138?v=4","01M6R8PZ1Y8CSQGFN61VACZGTH","Nairon AI","01M6R8PZ6184VR3BA88YZFBC3N",4,"MIT","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fgithub-triage\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],"github","triage","github triage","when","review","state machine","bugs","for","machine","feature","issue workflow","manage","issue","use","issues","github issues","sessions","triage issues","workflow","triage github issues","2026-11-10 10:12:30",false,"---\nname: github-triage\ndescription: Triage GitHub issues through a label-based state machine with interactive grilling sessions. Use when user wants to triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.\n---\n\n# GitHub Issue Triage\n\nTriage issues in the current repo using a label-based state machine. Infer the repo from `git remote`. Use `gh` for all GitHub operations.\n\n## Prerequisites\n\n- The repo must have a GitHub remote.\n- Install GitHub CLI if needed: `brew install gh`, `pnpm dlx @githubnext\u002Fgithub-cli`, or see https:\u002F\u002Fcli.github.com\u002F.\n- Authenticate before use: `gh auth login`\n\n## Reference docs\n\n- [AGENT-BRIEF.md](AGENT-BRIEF.md) — how to write durable agent briefs\n- [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — how the `.out-of-scope\u002F` knowledge base works\n\n## Labels\n\n| Label             | Type     | Description                              |\n| ----------------- | -------- | ---------------------------------------- |\n| `bug`             | Category | Something is broken                      |\n| `enhancement`     | Category | New feature or improvement               |\n| `needs-triage`    | State    | Maintainer needs to evaluate this issue  |\n| `needs-info`      | State    | Waiting on reporter for more information |\n| `ready-for-agent` | State    | Fully specified, ready for AFK agent     |\n| `ready-for-human` | State    | Requires human implementation            |\n| `wontfix`         | State    | Will not be actioned                     |\n\nEvery issue should have exactly **one** state label and **one** category label. If an issue has conflicting state labels (e.g. both `needs-triage` and `ready-for-agent`), flag the conflict and ask the maintainer which state is correct before doing anything else. Provide a recommendation.\n\n## State Machine\n\n| Current State  | Can transition to | Who triggers it        | What happens                                                                                                         |\n| -------------- | ----------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------- |\n| `unlabeled`    | `needs-triage`    | Skill (on first look)  | Issue needs maintainer evaluation. Skill applies label after presenting recommendation.                              |\n| `unlabeled`    | `ready-for-agent` | Maintainer (via skill) | Issue is already well-specified and agent-suitable. Skill writes agent brief comment, applies label.                 |\n| `unlabeled`    | `ready-for-human` | Maintainer (via skill) | Issue requires human implementation. Skill writes a brief comment summarizing the task, applies label.               |\n| `unlabeled`    | `wontfix`         | Maintainer (via skill) | Issue is spam, duplicate, or out of scope. Skill closes with comment (and writes `.out-of-scope\u002F` for enhancements). |\n| `needs-triage` | `needs-info`      | Maintainer (via skill) | Issue is underspecified. Skill posts triage notes capturing progress so far + questions for reporter.                |\n| `needs-triage` | `ready-for-agent` | Maintainer (via skill) | Grilling session complete, agent-suitable. Skill writes agent brief comment, applies label.                          |\n| `needs-triage` | `ready-for-human` | Maintainer (via skill) | Grilling session complete, needs human. Skill writes a brief comment summarizing the task, applies label.            |\n| `needs-triage` | `wontfix`         | Maintainer (via skill) | Maintainer decides not to action. Skill closes with comment (and writes `.out-of-scope\u002F` for enhancements).          |\n| `needs-info`   | `needs-triage`    | Skill (detects reply)  | Reporter has replied. Skill surfaces to maintainer for re-evaluation.                                                |\n\nAn issue can only move along these transitions. The maintainer can override any state directly (see Quick State Override below), but the skill should flag if the transition is unusual.\n\n## Invocation\n\nThe maintainer invokes `\u002Fgithub-triage` then describes what they want in natural language. The skill interprets the request and takes the appropriate action.\n\nExample requests:\n\n- \"Show me anything that needs my attention\"\n- \"Let's look at #42\"\n- \"Move #42 to ready-for-agent\"\n- \"What's ready for agents to pick up?\"\n- \"Are there any unlabeled issues?\"\n\n## Workflow: Show What Needs Attention\n\nWhen the maintainer asks for an overview, query GitHub and present a summary grouped into three buckets:\n\n1. **Unlabeled issues** — new, no labels at all. These have never been triaged.\n2. **`needs-triage` issues** — maintainer needs to evaluate or continue evaluating.\n3. **`needs-info` issues with new activity** — the reporter has commented since the last triage notes comment. Check comment timestamps to determine this.\n\nDisplay counts per group. Within each group, show issues oldest first (longest-waiting gets attention first). For each issue, show: number, title, age, and a one-line summary of the issue body.\n\nLet the maintainer pick which issue to dive into.\n\n## Workflow: Triage a Specific Issue\n\n### Step 1: Gather context\n\nBefore presenting anything to the maintainer:\n\n- Read the full issue: body, all comments, all labels, who reported it, when\n- If there are prior triage notes comments (from previous sessions), parse them to understand what has already been established\n- Explore the codebase to build context — understand the domain, relevant interfaces, and existing behavior related to the issue\n- Read `.out-of-scope\u002F*.md` files and check if this issue matches or is similar to a previously rejected concept\n\n### Step 2: Present a recommendation\n\nTell the maintainer:\n\n- **Category recommendation:** bug or enhancement, with reasoning\n- **State recommendation:** where this issue should go, with reasoning\n- If it matches a prior out-of-scope rejection, surface that: \"This is similar to `.out-of-scope\u002Fconcept-name.md` — we rejected this before because X. Do you still feel the same way?\"\n- A brief summary of what you found in the codebase that's relevant\n\nThen wait for the maintainer's direction. They may:\n\n- Agree and ask you to apply labels → do it\n- Want to flesh it out → start a grilling session\n- Override with a different state → apply their choice\n- Want to discuss → have a conversation\n\n### Step 3: Bug reproduction (bugs only)\n\nIf the issue is categorized as a bug, attempt to reproduce it before starting a grilling session. This will vary by codebase, but do your best:\n\n- Read the reporter's reproduction steps (if provided)\n- Explore the codebase to understand the relevant code paths\n- Try to reproduce the bug: run tests, execute commands, or trace the logic to confirm the reported behavior\n- If reproduction succeeds, report what you found to the maintainer — include the specific behavior you observed and where in the code it originates\n- If reproduction fails, report that too — the bug may be environment-specific, already fixed, or the report may be inaccurate\n- If the report lacks enough detail to attempt reproduction, note that — this is a strong signal the issue should move to `needs-info`\n\nThe reproduction attempt informs the grilling session and the agent brief. A confirmed reproduction with a known code path makes for a much stronger brief.\n\n### Step 4: Grilling session (if needed)\n\nIf the issue needs to be fleshed out before it's ready for an agent, interview the maintainer to build a complete specification. Follow the \u002Fgrill-me pattern:\n\n- Ask questions one at a time\n- Provide a recommended answer for each question\n- If a question can be answered by exploring the codebase, explore the codebase instead\n- If there are prior triage notes on this issue, resume from where you left off — never re-ask questions that were already resolved\n- For bugs: use the reproduction findings to ask targeted questions (\"I confirmed this happens because X — should the fix be Y or Z?\")\n\nThe goal is to reach a point where you can write a complete agent brief. Keep going until you have:\n\n- A clear summary of the desired behavior\n- Concrete acceptance criteria\n- Key interfaces that may need to change\n- A clear boundary of what's out of scope\n\n### Step 5: Apply the outcome\n\nBefore posting any comment or applying any label, show the maintainer a **preview** of exactly what will be posted and which labels will be applied\u002Fremoved. Only proceed on confirmation.\n\nDepending on the outcome:\n\n- **ready-for-agent** — post an agent brief comment (see [AGENT-BRIEF.md](AGENT-BRIEF.md))\n- **ready-for-human** — post a comment summarizing the task, what was established during triage, and why it needs human implementation. Use the same structure as an agent brief but note the reason it can't be delegated to an agent (e.g. requires judgment calls, external system access, design decisions, or manual testing).\n- **needs-info** — post triage notes with progress so far and questions for the reporter (see Needs Info Output below)\n- **wontfix (bug)** — post a polite comment explaining why, then close the issue\n- **wontfix (enhancement)** — write to `.out-of-scope\u002F`, post a comment linking to it, then close the issue (see [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md))\n- **needs-triage** — apply the label. Optionally leave a comment if there's partial progress to capture.\n\n## Workflow: Quick State Override\n\nWhen the maintainer explicitly tells you to move an issue to a specific state (e.g. \"move #42 to ready-for-agent\"), trust their judgment and apply the label directly.\n\nStill show a confirmation of what you're about to do: which labels will be added\u002Fremoved, and whether you'll post a comment or close the issue. But skip the grilling session entirely.\n\nIf moving to `ready-for-agent` without a grilling session, ask the maintainer if they want to write a brief agent brief comment or skip it.\n\n## Needs Info Output\n\nWhen moving an issue to `needs-info`, post a comment that captures the grilling progress and tells the reporter what's needed:\n\n```markdown\n## Triage Notes\n\n**What we've established so far:**\n\n- point 1\n- point 2\n\n**What we still need from you (@reporter):**\n\n- question 1\n- question 2\n```\n\nInclude everything resolved during the grilling session in \"established so far\" — this work should not be lost. The questions for the reporter should be specific and actionable, not vague (\"please provide more info\").\n\n## Resuming Previous Sessions\n\nWhen triaging an issue that already has triage notes from a previous session:\n\n1. Read all comments to find prior triage notes\n2. Parse what was already established\n3. Check if the reporter has answered any outstanding questions\n4. Present the maintainer with an updated picture: \"Here's where we left off, and here's what the reporter has said since\"\n5. Continue the grilling from where it stopped — do not re-ask resolved questions\n","# GitHub Issue Triage\n\nTriage issues in the current repo using a label-based state machine. Infer the repo from `git remote`. Use `gh` for all GitHub operations.\n\n## Prerequisites\n\n- The repo must have a GitHub remote.\n- Install GitHub CLI if needed: `brew install gh`, `pnpm dlx @githubnext\u002Fgithub-cli`, or see https:\u002F\u002Fcli.github.com\u002F.\n- Authenticate before use: `gh auth login`\n\n## Reference docs\n\n- [AGENT-BRIEF.md](AGENT-BRIEF.md) — how to write durable agent briefs\n- [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — how the `.out-of-scope\u002F` knowledge base works\n\n## Labels\n\n| Label             | Type     | Description                              |\n| ----------------- | -------- | ---------------------------------------- |\n| `bug`             | Category | Something is broken                      |\n| `enhancement`     | Category | New feature or improvement               |\n| `needs-triage`    | State    | Maintainer needs to evaluate this issue  |\n| `needs-info`      | State    | Waiting on reporter for more information |\n| `ready-for-agent` | State    | Fully specified, ready for AFK agent     |\n| `ready-for-human` | State    | Requires human implementation            |\n| `wontfix`         | State    | Will not be actioned                     |\n\nEvery issue should have exactly **one** state label and **one** category label. If an issue has conflicting state labels (e.g. both `needs-triage` and `ready-for-agent`), flag the conflict and ask the maintainer which state is correct before doing anything else. Provide a recommendation.\n\n## State Machine\n\n| Current State  | Can transition to | Who triggers it        | What happens                                                                                                         |\n| -------------- | ----------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------- |\n| `unlabeled`    | `needs-triage`    | Skill (on first look)  | Issue needs maintainer evaluation. Skill applies label after presenting recommendation.                              |\n| `unlabeled`    | `ready-for-agent` | Maintainer (via skill) | Issue is already well-specified and agent-suitable. Skill writes agent brief comment, applies label.                 |\n| `unlabeled`    | `ready-for-human` | Maintainer (via skill) | Issue requires human implementation. Skill writes a brief comment summarizing the task, applies label.               |\n| `unlabeled`    | `wontfix`         | Maintainer (via skill) | Issue is spam, duplicate, or out of scope. Skill closes with comment (and writes `.out-of-scope\u002F` for enhancements). |\n| `needs-triage` | `needs-info`      | Maintainer (via skill) | Issue is underspecified. Skill posts triage notes capturing progress so far + questions for reporter.                |\n| `needs-triage` | `ready-for-agent` | Maintainer (via skill) | Grilling session complete, agent-suitable. Skill writes agent brief comment, applies label.                          |\n| `needs-triage` | `ready-for-human` | Maintainer (via skill) | Grilling session complete, needs human. Skill writes a brief comment summarizing the task, applies label.            |\n| `needs-triage` | `wontfix`         | Maintainer (via skill) | Maintainer decides not to action. Skill closes with comment (and writes `.out-of-scope\u002F` for enhancements).          |\n| `needs-info`   | `needs-triage`    | Skill (detects reply)  | Reporter has replied. Skill surfaces to maintainer for re-evaluation.                                                |\n\nAn issue can only move along these transitions. The maintainer can override any state directly (see Quick State Override below), but the skill should flag if the transition is unusual.\n\n## Invocation\n\nThe maintainer invokes `\u002Fgithub-triage` then describes what they want in natural language. The skill interprets the request and takes the appropriate action.\n\nExample requests:\n\n- \"Show me anything that needs my attention\"\n- \"Let's look at #42\"\n- \"Move #42 to ready-for-agent\"\n- \"What's ready for agents to pick up?\"\n- \"Are there any unlabeled issues?\"\n\n## Workflow: Show What Needs Attention\n\nWhen the maintainer asks for an overview, query GitHub and present a summary grouped into three buckets:\n\n1. **Unlabeled issues** — new, no labels at all. These have never been triaged.\n2. **`needs-triage` issues** — maintainer needs to evaluate or continue evaluating.\n3. **`needs-info` issues with new activity** — the reporter has commented since the last triage notes comment. Check comment timestamps to determine this.\n\nDisplay counts per group. Within each group, show issues oldest first (longest-waiting gets attention first). For each issue, show: number, title, age, and a one-line summary of the issue body.\n\nLet the maintainer pick which issue to dive into.\n\n## Workflow: Triage a Specific Issue\n\n### Step 1: Gather context\n\nBefore presenting anything to the maintainer:\n\n- Read the full issue: body, all comments, all labels, who reported it, when\n- If there are prior triage notes comments (from previous sessions), parse them to understand what has already been established\n- Explore the codebase to build context — understand the domain, relevant interfaces, and existing behavior related to the issue\n- Read `.out-of-scope\u002F*.md` files and check if this issue matches or is similar to a previously rejected concept\n\n### Step 2: Present a recommendation\n\nTell the maintainer:\n\n- **Category recommendation:** bug or enhancement, with reasoning\n- **State recommendation:** where this issue should go, with reasoning\n- If it matches a prior out-of-scope rejection, surface that: \"This is similar to `.out-of-scope\u002Fconcept-name.md` — we rejected this before because X. Do you still feel the same way?\"\n- A brief summary of what you found in the codebase that's relevant\n\nThen wait for the maintainer's direction. They may:\n\n- Agree and ask you to apply labels → do it\n- Want to flesh it out → start a grilling session\n- Override with a different state → apply their choice\n- Want to discuss → have a conversation\n\n### Step 3: Bug reproduction (bugs only)\n\nIf the issue is categorized as a bug, attempt to reproduce it before starting a grilling session. This will vary by codebase, but do your best:\n\n- Read the reporter's reproduction steps (if provided)\n- Explore the codebase to understand the relevant code paths\n- Try to reproduce the bug: run tests, execute commands, or trace the logic to confirm the reported behavior\n- If reproduction succeeds, report what you found to the maintainer — include the specific behavior you observed and where in the code it originates\n- If reproduction fails, report that too — the bug may be environment-specific, already fixed, or the report may be inaccurate\n- If the report lacks enough detail to attempt reproduction, note that — this is a strong signal the issue should move to `needs-info`\n\nThe reproduction attempt informs the grilling session and the agent brief. A confirmed reproduction with a known code path makes for a much stronger brief.\n\n### Step 4: Grilling session (if needed)\n\nIf the issue needs to be fleshed out before it's ready for an agent, interview the maintainer to build a complete specification. Follow the \u002Fgrill-me pattern:\n\n- Ask questions one at a time\n- Provide a recommended answer for each question\n- If a question can be answered by exploring the codebase, explore the codebase instead\n- If there are prior triage notes on this issue, resume from where you left off — never re-ask questions that were already resolved\n- For bugs: use the reproduction findings to ask targeted questions (\"I confirmed this happens because X — should the fix be Y or Z?\")\n\nThe goal is to reach a point where you can write a complete agent brief. Keep going until you have:\n\n- A clear summary of the desired behavior\n- Concrete acceptance criteria\n- Key interfaces that may need to change\n- A clear boundary of what's out of scope\n\n### Step 5: Apply the outcome\n\nBefore posting any comment or applying any label, show the maintainer a **preview** of exactly what will be posted and which labels will be applied\u002Fremoved. Only proceed on confirmation.\n\nDepending on the outcome:\n\n- **ready-for-agent** — post an agent brief comment (see [AGENT-BRIEF.md](AGENT-BRIEF.md))\n- **ready-for-human** — post a comment summarizing the task, what was established during triage, and why it needs human implementation. Use the same structure as an agent brief but note the reason it can't be delegated to an agent (e.g. requires judgment calls, external system access, design decisions, or manual testing).\n- **needs-info** — post triage notes with progress so far and questions for the reporter (see Needs Info Output below)\n- **wontfix (bug)** — post a polite comment explaining why, then close the issue\n- **wontfix (enhancement)** — write to `.out-of-scope\u002F`, post a comment linking to it, then close the issue (see [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md))\n- **needs-triage** — apply the label. Optionally leave a comment if there's partial progress to capture.\n\n## Workflow: Quick State Override\n\nWhen the maintainer explicitly tells you to move an issue to a specific state (e.g. \"move #42 to ready-for-agent\"), trust their judgment and apply the label directly.\n\nStill show a confirmation of what you're about to do: which labels will be added\u002Fremoved, and whether you'll post a comment or close the issue. But skip the grilling session entirely.\n\nIf moving to `ready-for-agent` without a grilling session, ask the maintainer if they want to write a brief agent brief comment or skip it.\n\n## Needs Info Output\n\nWhen moving an issue to `needs-info`, post a comment that captures the grilling progress and tells the reporter what's needed:\n\n```markdown\n## Triage Notes\n\n**What we've established so far:**\n\n- point 1\n- point 2\n\n**What we still need from you (@reporter):**\n\n- question 1\n- question 2\n```\n\nInclude everything resolved during the grilling session in \"established so far\" — this work should not be lost. The questions for the reporter should be specific and actionable, not vague (\"please provide more info\").\n\n## Resuming Previous Sessions\n\nWhen triaging an issue that already has triage notes from a previous session:\n\n1. Read all comments to find prior triage notes\n2. Parse what was already established\n3. Check if the reporter has answered any outstanding questions\n4. Present the maintainer with an updated picture: \"Here's where we left off, and here's what the reporter has said since\"\n5. Continue the grilling from where it stopped — do not re-ask resolved questions\n",{"name":5,"description":7},"main","c9d0c408715983e993b2f9ebffdbfa7f10153bcb","engineering\u002Fgithub-triage",0,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack","https:\u002F\u002Fgithub.com\u002FNairon-AI","https:\u002F\u002Fwww.naironai.com\u002F","Building the future of Work","2026-09-20 17:40:05",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add Nairon-AI\u002Fagentic-starter-pack --skill github-triage",{"tool":64,"command":65},"bunx","bunx skills add Nairon-AI\u002Fagentic-starter-pack --skill github-triage",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Nairon-AI\u002Fagentic-starter-pack --skill github-triage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fgithub-triage\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"AGENT-BRIEF.md","REFERENCE","参考文档",6243,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fgithub-triage\u002FAGENT-BRIEF.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"OUT-OF-SCOPE.md",4282,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fengineering\u002Fgithub-triage\u002FOUT-OF-SCOPE.md",[83,116,137,158,178,200],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":97,"publishedAt":44},"01M6RBCG630Y8X99XWR9Q4GYNY","writing-shape","Take a markdown file of raw material and shape it into an article through a conversational session — drafting candidate openings, growing the piece paragraph by paragraph, arguing about format (lists, tables, callouts, quotes) at each step. Use when the user has a pile of notes, fragments, or a rough draft and wants help turning it into something publishable.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-shape\u002FSKILL.md",[89,92],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[98,99,100,101,102,103,104,105,106,37,107,108,109,110,111,112,113,114,115,27],"writing","writing shape","shape","notes","help","file","markdown","format","session","take","draft","article","material","it","about","quotes","at","candidate",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":124,"publishedAt":44},"01M6RBCCCB1KMF01P5SYGFWBSW","writing-fragments","Grilling session that mines the user for fragments — heterogeneous nuggets of writing (claims, vignettes, sharp sentences, half-thoughts) — and appends them to a single document as raw material for a future article. Use when the user wants to develop ideas before imposing structure, or mentions \"fragments\", \"ideate\", or \"raw material\" for writing.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-fragments\u002FSKILL.md",[122,123],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},[98,125,126,127,128,129,106,37,130,131,132,109,133,110,134,135,31,136,27],"writing fragments","grilling","ideate","develop","user","document","structure","ideas","as","sharp","claims","single",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":145,"publishedAt":44},"01M6RBC8V7NHHKMTAZB4BPXVYQ","writing-beats","Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-beats\u002FSKILL.md",[143,144],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},[98,146,147,148,37,149,150,100,151,152,153,109,154,133,155,110,156,157,31,27],"writing beats","choose","write","assemble","only","journey","next","options","end","style","narrative","argument",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":166,"publishedAt":44},"01M6RBC58SG5Y5SC4ZV4ZNEFHC","stop-slop","Remove AI writing patterns from prose. Use when drafting, editing, or reviewing text to eliminate predictable AI tells.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fstop-slop\u002FSKILL.md",[164,165],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},[167,168,169,98,170,171,172,173,174,37,175,176,177,31,27],"stop","stop slop","slop","content","https","text","editing","remove","prose","patterns","drafts",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":186,"publishedAt":44},"01M6RBBJTTCJ7KZCP16G9JDFZH","humanizer","Remove signs of AI-generated writing from text. Use when editing or reviewing\ntext to make it sound more natural and human-written. Based on Wikipedia's\ncomprehensive \"Signs of AI writing\" guide. Detects and fixes patterns including:\ninflated symbolism, promotional language, superficial -ing analyses, vague\nattributions, em dash overuse, rule of three, AI vocabulary words, passive\nvoice, negative parallelisms, and filler phrases.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fhumanizer\u002FSKILL.md",[184,185],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},[180,98,187,188,172,189,148,190,191,174,192,193,176,194,195,196,197,198,199,27],"code","em dash","read","edit","generated","guide","opencode","three","human","make","wikipedia","vague","dash",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":44},"01M6RBBEQKJ5HRH8AV9J85QB1T","feedback","Prepare, deliver, and debrief timely interpersonal feedback using a question-first coaching flow, observable behavior, owned experience, and concrete impact. Use when drafting feedback, coaching managers, rehearsing a feedback conversation, praising specific behavior, or reviewing whether feedback landed.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Ffeedback\u002FSKILL.md",[],[202,207,208,209,210,211,37,212,213,214,215,216,27,217],"prepare","flow","first","question","behavior","conversation","coaching","debrief","impact","managers","deliver"]