[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FDGZZS7FFRMHH3392FSAZ":3,"skill-same:01M71FDGZZS7FFRMHH3392FSAZ":71},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":14,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M71FDGZZS7FFRMHH3392FSAZ","diataxis",null,"Router for documentation work under the Diátaxis methodology. Use whenever the user wants to write, add to, expand, reorganize, or audit documentation — \"write docs for X\", \"document this feature\", \"add a page about\", \"improve our README\", \"does this doc work\", \"audit our docs\", \"--audit\" — or mentions Diátaxis, the compass, or a documentation type when no single type skill is the obvious match. Applies the compass (action or cognition? acquisition or application?) to classify the reader's need, then hands off to diataxis-tutorial, diataxis-how-to, diataxis-reference, or diataxis-explanation. When the user points at existing docs or supplies paths, assume the work is adding to or expanding those articles. With --audit, runs an improvement pass instead: classify each unit, run the matching type's drift checklist, and propose relocations and splits that fit the docs to the model without rewriting their substance. Prefer this router over a type skill whenever the type isn't already certain.","esond\u002Fskills","esond","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F4650644?v=4","01M71FCJGKDH30JSHK6XJZXN8Y","Eric Sondergard","01M71FCJHP4WCJVP4HVMEW1KB2",0,"MIT","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fdocs\u002Fskills\u002Fdiataxis\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"work","doc","action","paths","write","at","run","audit","how","classify","acquisition","documentation","router","drift","when","improve","expand","model","unit","2026-11-10 10:12:30",false,"---\nname: diataxis\ndescription: >-\n  Router for documentation work under the Diátaxis methodology. Use whenever\n  the user wants to write, add to, expand, reorganize, or audit documentation\n  — \"write docs for X\", \"document this feature\", \"add a page about\",\n  \"improve our README\", \"does this doc work\", \"audit our docs\", \"--audit\" —\n  or mentions Diátaxis, the compass, or a documentation type when no single\n  type skill is the obvious match. Applies the compass (action or cognition?\n  acquisition or application?) to classify the reader's need, then hands off\n  to diataxis-tutorial, diataxis-how-to, diataxis-reference, or\n  diataxis-explanation. When the user points at existing docs or supplies\n  paths, assume the work is adding to or expanding those articles. With\n  --audit, runs an improvement pass instead: classify each unit, run the\n  matching type's drift checklist, and propose relocations and splits that\n  fit the docs to the model without rewriting their substance. Prefer this\n  router over a type skill whenever the type isn't already certain.\n---\n\n# diataxis\n\nDiátaxis holds that documentation answers four distinct user needs — **tutorials** (learning), **how-to guides** (goals), **reference** (information), **explanation** (understanding) — and that a large share of documentation problems are one piece of content trying to serve two needs at once. Each unit of content should be one of the four types.\n\nHow to hold it: Diátaxis is **a guide, not a plan** — a map for checking that you're in the right place and heading the right way, not a structure you must complete, a specification, or railway tracks. Structure is an *outcome*: documentation assumes the Diátaxis shape because it has been improved, not the other way around. So never open by carving out four sections.\n\nThis skill is the router. It figures out which need the work in front of you serves, then hands off to the matching type skill, where the craft rules live.\n\n## The compass\n\nTwo questions classify any piece of content — proposed or existing:\n\n1. Does it inform **action** (practical steps, doing) or **cognition** (propositional knowledge, thinking)?\n2. Does it serve the reader's **acquisition** of skill (study) or its **application** (work)?\n\n| If the content… | …and serves the user's… | …then it must belong to… |\n| --------------- | ----------------------- | ------------------------ |\n| informs action | acquisition of skill | a tutorial |\n| informs action | application of skill | a how-to guide |\n| informs cognition | application of skill | reference |\n| informs cognition | acquisition of skill | explanation |\n\nUse the terms flexibly — don't fixate on the exact names. The questions work at any scale (a doc set, a page, a paragraph, a sentence) and in any phrasing: \"is the reader at study or at work here?\", \"do they need to do or to know?\" The compass earns its keep precisely when something feels off but you can't yet say why — it forces you to stop and reconsider.\n\nWhen intuition is shaky on the cognition side: if it's boring and unmemorable, it's probably reference; lists and tables almost always are. If you'd read it in the bath, it's explanation. And on the action side, the axis is study vs. work — never basic vs. advanced. A tutorial can be complex; a how-to guide can be basic.\n\n## Mode selection\n\n- **Default — writing.** The user wants documentation written, added to, or expanded. Follow \"Writing mode\" below.\n- **Audit** — the user wants existing documentation examined, whether via a literal `--audit` or phrasing like \"audit our docs\" or \"does this doc work\". An audit is an improvement\u002Frefactoring pass: make the docs fit the Diátaxis model better, without necessarily changing what they say. Follow \"Audit mode\" below.\n\n## Writing mode\n\n### Step 1 — Establish the material and where it lives\n\nIf the user mentioned existing documentation or gave paths, read those articles first — the default assumption is that this work **adds to or expands them**, so establish what type each already is (or is trying to be) before writing a word. For new content, find where it will live among any existing docs, and what neighbors it will link to.\n\nExpanding an article never overrides the compass. When Step 2 classifies the requested material as a different type than the article it was aimed at, \"expanding\" means expanding the article's *family*: the material lands in a linked sibling of the right type, and the original gets at most a one-clause pointer. The compass decides the type; the user's path only decides the neighborhood.\n\n### Step 2 — Run the compass\n\nClassify what the user actually needs written. If their request doesn't settle both questions, ask — one question, in reader terms (\"is this for someone learning the system, or someone mid-task trying to get something done?\") rather than in Diátaxis jargon.\n\nA request that spans types is normal, not a failure: \"document the deploy pipeline\" may need a how-to guide *and* a reference page *and* a paragraph of explanation. Split it into pieces, one type each, and link them — splitting along the straddled axis is the standard repair, in writing as in auditing.\n\n### Step 3 — Hand off\n\nInvoke the matching type skill(s) via the Skill tool — `diataxis-tutorial`, `diataxis-how-to`, `diataxis-reference`, `diataxis-explanation` — passing along what Steps 1–2 established: the reader, the classification, the target file(s), and the neighbors to link. For multi-type work, handle one piece at a time to completion rather than drafting everything at once; each finished piece sharpens the next.\n\n## Audit mode\n\n### Step 1 — Determine the target\n\nEstablish which doc(s) the user wants examined — a file, a directory, a whole docs set. If unclear, ask. Prefer a scope you can actually finish: Diátaxis works by small, completed improvements, not surveys that trail off.\n\n### Step 2 — Classify each unit of content\n\nRead the target docs and run the compass over each unit. The unit is whatever holds one type: usually a page, but for container documents it's the **section** — a README whose overview, setup walkthrough, and options table sit side by side is applying Diátaxis sectionally, and that's legitimate. Judge each section on its own; the finding \"this file is four types stacked\" is only a problem if the sections themselves are muddled or the readers can't find their part. A title and a sentence or two of framing at the top of a page isn't a unit — don't classify it, and don't invent drift findings about it.\n\nWhen a unit's classification is genuinely ambiguous — it could be serving either of two needs, and the answer changes the findings — ask the user, the same way writing mode does: one question, in reader terms. Record the answer in the report rather than silently picking a side.\n\nFor each unit, record: what user need it serves (or is trying to), which type that makes it, and where it blurs — explanation inside a tutorial, teaching inside a how-to, recipes inside reference, procedure inside explanation.\n\n### Step 3 — Run the type checklists\n\nFor each type present, invoke the matching type skill, telling it this is an audit: it applies only its drift checklist — no drafting, no edits. The checklists are the per-type audit lens; this router only contributes the classification and the cross-cutting findings.\n\n### Step 4 — Report, then stop\n\nProduce a findings report before touching anything:\n\n- Per unit: its type, how well it serves that need, and the specific drift found.\n- Proposed moves, smallest first. The repair vocabulary is **relocate, split, link, relabel** — plus outright removal for the rare content that belongs nowhere (trivial guidance, marketing advocacy). An audit makes content fit the model better, it doesn't rewrite the substance. Flag \"this paragraph is explanation living in a tutorial; move it to X and leave a one-line link\" rather than \"rewrite this paragraph.\"\n- Empty quadrants, as observations: sorting existing docs is the cheap half; noticing that a project has reference and how-tos but no tutorial and no written *why* is where the model pays. Usually it's the acquisition column that's missing.\n- Functional-quality problems the sorting exposed (a gap in reference coverage, a step readers are left to figure out) — Diátaxis surfaces these but they're separate findings, not type-drift.\n\nThen **stop and confirm** which moves to apply. On approval, apply them one at a time, each left complete — not as one big-bang restructure.\n\n## Working method\n\nFor any mode: work in single small improvements — each thing done reveals the next. Don't tear a mess down to start over, and don't work on the big picture; small steps arrive there on their own. Documentation is never finished, but at every stage it can be *complete*: useful, healthy, ready for its next step.\n\n## Things not to do\n\n- **Don't** create empty tutorial\u002Fhow-to\u002Freference\u002Fexplanation scaffolding and then fill it. Structure emerges from improved content, never the reverse.\n- **Don't** force one-file-one-type on container docs. A README applying Diátaxis per-section is the model working, not a violation.\n- **Don't** demand exactly four top-level boxes. Larger doc sets may nest (how-to guides grouped by platform) or interleave audiences — fine, as long as no unit muddles its forms and purposes.\n- **Don't** rewrite substance in an audit. Relocate, split, link, relabel — delete only what a type checklist says belongs nowhere; recast wording only where it's doing the wrong type's job in place.\n- **Don't** confuse fitting the model with being good. Diátaxis exposes functional gaps — stale facts, missing coverage — but conformance doesn't guarantee quality. Report both, separately.\n- **Don't** wait for a full understanding of the doc set before improving something. Understanding comes from working on it.\n","# diataxis\n\nDiátaxis holds that documentation answers four distinct user needs — **tutorials** (learning), **how-to guides** (goals), **reference** (information), **explanation** (understanding) — and that a large share of documentation problems are one piece of content trying to serve two needs at once. Each unit of content should be one of the four types.\n\nHow to hold it: Diátaxis is **a guide, not a plan** — a map for checking that you're in the right place and heading the right way, not a structure you must complete, a specification, or railway tracks. Structure is an *outcome*: documentation assumes the Diátaxis shape because it has been improved, not the other way around. So never open by carving out four sections.\n\nThis skill is the router. It figures out which need the work in front of you serves, then hands off to the matching type skill, where the craft rules live.\n\n## The compass\n\nTwo questions classify any piece of content — proposed or existing:\n\n1. Does it inform **action** (practical steps, doing) or **cognition** (propositional knowledge, thinking)?\n2. Does it serve the reader's **acquisition** of skill (study) or its **application** (work)?\n\n| If the content… | …and serves the user's… | …then it must belong to… |\n| --------------- | ----------------------- | ------------------------ |\n| informs action | acquisition of skill | a tutorial |\n| informs action | application of skill | a how-to guide |\n| informs cognition | application of skill | reference |\n| informs cognition | acquisition of skill | explanation |\n\nUse the terms flexibly — don't fixate on the exact names. The questions work at any scale (a doc set, a page, a paragraph, a sentence) and in any phrasing: \"is the reader at study or at work here?\", \"do they need to do or to know?\" The compass earns its keep precisely when something feels off but you can't yet say why — it forces you to stop and reconsider.\n\nWhen intuition is shaky on the cognition side: if it's boring and unmemorable, it's probably reference; lists and tables almost always are. If you'd read it in the bath, it's explanation. And on the action side, the axis is study vs. work — never basic vs. advanced. A tutorial can be complex; a how-to guide can be basic.\n\n## Mode selection\n\n- **Default — writing.** The user wants documentation written, added to, or expanded. Follow \"Writing mode\" below.\n- **Audit** — the user wants existing documentation examined, whether via a literal `--audit` or phrasing like \"audit our docs\" or \"does this doc work\". An audit is an improvement\u002Frefactoring pass: make the docs fit the Diátaxis model better, without necessarily changing what they say. Follow \"Audit mode\" below.\n\n## Writing mode\n\n### Step 1 — Establish the material and where it lives\n\nIf the user mentioned existing documentation or gave paths, read those articles first — the default assumption is that this work **adds to or expands them**, so establish what type each already is (or is trying to be) before writing a word. For new content, find where it will live among any existing docs, and what neighbors it will link to.\n\nExpanding an article never overrides the compass. When Step 2 classifies the requested material as a different type than the article it was aimed at, \"expanding\" means expanding the article's *family*: the material lands in a linked sibling of the right type, and the original gets at most a one-clause pointer. The compass decides the type; the user's path only decides the neighborhood.\n\n### Step 2 — Run the compass\n\nClassify what the user actually needs written. If their request doesn't settle both questions, ask — one question, in reader terms (\"is this for someone learning the system, or someone mid-task trying to get something done?\") rather than in Diátaxis jargon.\n\nA request that spans types is normal, not a failure: \"document the deploy pipeline\" may need a how-to guide *and* a reference page *and* a paragraph of explanation. Split it into pieces, one type each, and link them — splitting along the straddled axis is the standard repair, in writing as in auditing.\n\n### Step 3 — Hand off\n\nInvoke the matching type skill(s) via the Skill tool — `diataxis-tutorial`, `diataxis-how-to`, `diataxis-reference`, `diataxis-explanation` — passing along what Steps 1–2 established: the reader, the classification, the target file(s), and the neighbors to link. For multi-type work, handle one piece at a time to completion rather than drafting everything at once; each finished piece sharpens the next.\n\n## Audit mode\n\n### Step 1 — Determine the target\n\nEstablish which doc(s) the user wants examined — a file, a directory, a whole docs set. If unclear, ask. Prefer a scope you can actually finish: Diátaxis works by small, completed improvements, not surveys that trail off.\n\n### Step 2 — Classify each unit of content\n\nRead the target docs and run the compass over each unit. The unit is whatever holds one type: usually a page, but for container documents it's the **section** — a README whose overview, setup walkthrough, and options table sit side by side is applying Diátaxis sectionally, and that's legitimate. Judge each section on its own; the finding \"this file is four types stacked\" is only a problem if the sections themselves are muddled or the readers can't find their part. A title and a sentence or two of framing at the top of a page isn't a unit — don't classify it, and don't invent drift findings about it.\n\nWhen a unit's classification is genuinely ambiguous — it could be serving either of two needs, and the answer changes the findings — ask the user, the same way writing mode does: one question, in reader terms. Record the answer in the report rather than silently picking a side.\n\nFor each unit, record: what user need it serves (or is trying to), which type that makes it, and where it blurs — explanation inside a tutorial, teaching inside a how-to, recipes inside reference, procedure inside explanation.\n\n### Step 3 — Run the type checklists\n\nFor each type present, invoke the matching type skill, telling it this is an audit: it applies only its drift checklist — no drafting, no edits. The checklists are the per-type audit lens; this router only contributes the classification and the cross-cutting findings.\n\n### Step 4 — Report, then stop\n\nProduce a findings report before touching anything:\n\n- Per unit: its type, how well it serves that need, and the specific drift found.\n- Proposed moves, smallest first. The repair vocabulary is **relocate, split, link, relabel** — plus outright removal for the rare content that belongs nowhere (trivial guidance, marketing advocacy). An audit makes content fit the model better, it doesn't rewrite the substance. Flag \"this paragraph is explanation living in a tutorial; move it to X and leave a one-line link\" rather than \"rewrite this paragraph.\"\n- Empty quadrants, as observations: sorting existing docs is the cheap half; noticing that a project has reference and how-tos but no tutorial and no written *why* is where the model pays. Usually it's the acquisition column that's missing.\n- Functional-quality problems the sorting exposed (a gap in reference coverage, a step readers are left to figure out) — Diátaxis surfaces these but they're separate findings, not type-drift.\n\nThen **stop and confirm** which moves to apply. On approval, apply them one at a time, each left complete — not as one big-bang restructure.\n\n## Working method\n\nFor any mode: work in single small improvements — each thing done reveals the next. Don't tear a mess down to start over, and don't work on the big picture; small steps arrive there on their own. Documentation is never finished, but at every stage it can be *complete*: useful, healthy, ready for its next step.\n\n## Things not to do\n\n- **Don't** create empty tutorial\u002Fhow-to\u002Freference\u002Fexplanation scaffolding and then fill it. Structure emerges from improved content, never the reverse.\n- **Don't** force one-file-one-type on container docs. A README applying Diátaxis per-section is the model working, not a violation.\n- **Don't** demand exactly four top-level boxes. Larger doc sets may nest (how-to guides grouped by platform) or interleave audiences — fine, as long as no unit muddles its forms and purposes.\n- **Don't** rewrite substance in an audit. Relocate, split, link, relabel — delete only what a type checklist says belongs nowhere; recast wording only where it's doing the wrong type's job in place.\n- **Don't** confuse fitting the model with being good. Diátaxis exposes functional gaps — stale facts, missing coverage — but conformance doesn't guarantee quality. Report both, separately.\n- **Don't** wait for a full understanding of the doc set before improving something. Understanding comes from working on it.\n",{"name":5,"description":7},"main","029bf6d49f3d270442ace55a01cccb40113f7efa","plugins\u002Fdocs\u002Fskills\u002Fdiataxis","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills","https:\u002F\u002Fgithub.com\u002Fesond","https:\u002F\u002Flinktr.ee\u002Fesond0","Serial pragmatist.\r\n\r\nCheck out my other repos at @hexagram-solutions! ","2026-11-07 00:00:12",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add esond\u002Fskills --skill diataxis",{"tool":57,"command":58},"bunx","bunx skills add esond\u002Fskills --skill diataxis",{"tool":60,"command":61},"pnpm","pnpm dlx skills add esond\u002Fskills --skill diataxis","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fdocs\u002Fskills\u002Fdiataxis\u002FSKILL.md",true,[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"agents\u002Fopenai.yaml","REFERENCE","参考文档",123,"https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fdocs\u002Fskills\u002Fdiataxis\u002Fagents\u002Fopenai.yaml",[72,97,123,150,161,195],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":38},"01M71FF0KCP66CRNT9AT1T18Z9","work-item-voice","Write or edit the user's issues in their own voice, in any work tracker — Jira, Linear, GitHub Issues, Azure DevOps. Covers features (new behavior), tasks (work that needs doing), and bugs (behavior that does not match expectation). Load this whenever the deliverable is an issue body, whether they say \"file a bug\", \"write a ticket\", \"draft a story\", \"create an issue for this\", \"turn this into a Jira\", \"write this up in Linear\", or paste a thread and ask for an issue out of it. Load it too whenever text goes into an issue that already exists — \"record this in the issue\", \"add what we found to the ticket\", \"note this on the card\", \"update the one about refunds\", or naming an issue by its key and asking for a fact to go in it — and when writing or updating one is a step inside a larger task. Features get behavior-driven framing with no implementation prescribed, and bugs get expected versus actual. Not for a comment on an issue, which is a conversation turn.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fesond\u002Fskills\u002Fwork-item-voice\u002FSKILL.md",[],[19,79,80,81,82,83,84,85,86,87,88,89,90,91,33,92,93,94,95,96],"work item voice","work item","voice","conversation","which","get","card","ticket","up","issues","new","writing","azure devops","ask","tasks","text","create","tracker",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":108,"publishedAt":38},"01M71FETV1H7JPCTSKMW3XZV1T","conversational-voice","Write the user's side of a conversation with another person, in the user's own voice: Slack messages and replies, DMs, email, PR and code-review comments, Linear or Jira comments, and any other turn in an exchange that goes out under the user's name. Load this whenever the deliverable is a message a human will read as written by the user, whether they say \"draft a Slack message\", \"reply to this\", \"how should I word this\", \"tell the team\", \"ask them about X\", \"send a note to\", or just paste a thread and ask what to say back. Load it too when tightening, shortening, or sanity-checking a message they already wrote, and when a message is one step of a larger task. The register is direct and informal, the way they'd talk to a friend or acquaintance, with the answer up front for a reader who skims. Not for something the user authors rather than sends — an issue body, a PR description, a commit message — even though a person reads those too.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fesond\u002Fskills\u002Fconversational-voice\u002FSKILL.md",[103],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[109,81,110,82,111,112,87,113,33,92,114,115,116,117,118,119,120,121,122,27],"conversational voice","back","messages","send","slack messages","code","commit","team","code-review","review","sanity","message","slack","human",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":134,"publishedAt":38},"01M71FEN36NS9Y4RVX6KQ704TB","sync-core-repo-docs","Create or audit a repo's three core doc files — README.md, the agent instructions file (AGENTS.md or CLAUDE.md), and REVIEW.md — in that dependency order. If a file is missing, generate it from the codebase; if it exists, audit it against the current code and apply targeted fixes after confirmation. README.md gets a developer from clone to running the project; AGENTS.md captures coding guidance for the agent (delegating to \u002Finit or claude-md-improver); REVIEW.md holds guidance for code reviewers, human or automated, without duplicating AGENTS.md. Target files with --readme, --claude, and --review, or run all three. Use whenever the user wants to set up, bootstrap, scaffold, refresh, audit, update, or sync a repo's docs, or says things like \"create a README\", \"is my README still accurate\", \"write a CLAUDE.md\", \"write an AGENTS.md\", \"audit our docs\", or \"get this repo ready for contributors\" — even when only one file is named. Prefer it over claude-md-improver when README or REVIEW are also in scope.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Fsync-core-repo-docs\u002FSKILL.md",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[135,136,137,138,139,140,141,142,143,84,144,145,87,146,147,148,149,33,114,118],"sync","sync core repo docs","repo docs","core","repo","docs","agent instructions","SET","ready","scope","project","init","only","files","confirmation",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":38},"01M71FEKJQ2G2NQ4NCXRR9SD63","sync-core-docs","Create or audit a repo's README.md, AGENTS.md\u002FCLAUDE.md, and REVIEW.md docs.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Fsync-core-docs\u002FSKILL.md",[],[157,140,138,135,95,158,159,26,160,139,118],"sync core docs","true","md docs","README",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":176,"publishedAt":38},"01M71FEAWPC8BM27EE0A90VT8T","righting-software-system-design","Opt-in, collaborative system-design workflow based on Juval Löwy's iDesign methodology in *Righting Software*. Conducts a multi-phase interview (framing → use cases → volatility analysis → components → call-chain validation → report) that surfaces unknown-unknowns and produces a written recommendation at `decompositions\u002F{system-name}\u002Freport.md`. **Run only when the user explicitly invites this workflow** — not for general architecture questions, lightweight design conversations, or quick \"where should X live?\" questions. Valid triggers: the user names the skill directly, references *Righting Software* \u002F Juval Löwy \u002F iDesign \u002F \"The Method\" \u002F volatility-based decomposition and asks to run a full session, asks for a \"deep\" or \"structured\" or \"Löwy-style\" system design session, or accepts a prior suggestion to run it. Wait for an explicit yes before entering Phase 0. The skill is interrogative — a back-and-forth interview that challenges each volatility candidate and proposes ones the user hasn't considered.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Frighting-software-system-design\u002FSKILL.md",[167,170,173],{"categoryNo":168,"categoryName":169,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":171,"categoryName":172,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":174,"categoryName":175,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000032","设计师",[177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,25,24,192,193,194],"system design","design","software","system","righting software","righting software system design","deep","quick","wait for","unknown","components","candidate","architecture","phase","valid","wait","live","full",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":38},"01M71FE4QYB436ZS8H3SWWHA4F","reorganize-branch-commits","Reorganize the commits on a non-default git branch into a clean, logical history by rewriting the branch — `git reset` + re-commit by default, `git rebase -i` when commit boundaries already align. Propose groupings based on the actual work done (features, refactors, tests, fixes, docs), get explicit user approval, back the branch up, then rewrite history. Use this skill whenever the user wants to tidy up, clean up, reorganize, restructure, squash, or curate commits on a feature branch — even if they phrase it as \"my branch is a mess\", \"squash this down\", \"combine these commits\", \"fix up the commit log before I open a PR\", or \"make the commits presentable for review\". Trigger proactively when the user is about to open or push a PR and the branch has scrappy\u002FWIP\u002F\"fix\" commits to collapse. Refuses to operate on default or release-shaped branches (main, master, develop, trunk, production, release, or the repo default) — a feature-branch-only tool.","https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Feng\u002Fskills\u002Freorganize-branch-commits\u002FSKILL.md",[],[202,203,204,110,205,84,206,207,208,87,209,210,211,212,147,213,43,33,214,115],"branch","reorganize branch commits","commits","operate","align","re","default","fix","clean","branches","open","tidy","done"]