[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FD68W9EK2CXPRRVXH4G6Q":3,"skill-same:01M71FD68W9EK2CXPRRVXH4G6Q":77},{"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":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71FD68W9EK2CXPRRVXH4G6Q","diataxis-reference",null,"Write, expand, or audit reference documentation — information-oriented technical description in the Diátaxis sense: austere, accurate, consistent facts about the machinery, consulted while working. Use whenever the user wants API docs, a configuration or parameter listing, CLI or command documentation, an options table, schema or data-model docs, error-code catalogs, environment-variable docs, or any \"document what X is \u002F what settings exist\" request — even if they never say \"reference\". Also loaded by the `diataxis` router when the compass points to cognition + application: the reader needs *facts to consult* while *getting work done*. If the content is mostly why-and-context discussion, that's `diataxis-explanation`; if it directs the reader's actions step by step, that's `diataxis-how-to`. When the type is in doubt or mixed, consult the `diataxis` skill first.","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-reference\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"diataxis","reference","diataxis reference","cli","work","documentation","router","consult","api","listing","code","done","when","information","environment-variable","actions","expand","model","never","error","2026-11-10 10:12:30",false,"---\nname: diataxis-reference\ndescription: >-\n  Write, expand, or audit reference documentation — information-oriented\n  technical description in the Diátaxis sense: austere, accurate, consistent\n  facts about the machinery, consulted while working. Use whenever the user\n  wants API docs, a configuration or parameter listing, CLI or command\n  documentation, an options table, schema or data-model docs, error-code\n  catalogs, environment-variable docs, or any \"document what X is \u002F what\n  settings exist\" request — even if they never say \"reference\". Also loaded\n  by the `diataxis` router when the compass points to cognition + application:\n  the reader needs *facts to consult* while *getting work done*. If the\n  content is mostly why-and-context discussion, that's `diataxis-explanation`;\n  if it directs the reader's actions step by step, that's `diataxis-how-to`.\n  When the type is in doubt or mixed, consult the `diataxis` skill first.\n---\n\n# diataxis-reference\n\nReference is **a map of the machinery**. A map tells you what you need to know about the territory without your having to go out and survey it yourself — and like a map, reference is neutral: it doesn't care what the reader is doing. The same chart serves the navigator plotting a course and the judge investigating a wreck. Diátaxis places reference at *cognition* + *application*: propositional knowledge, consulted in the middle of work.\n\nWhat the working reader needs from it is **truth and certainty** — a firm platform to stand on. That single need dictates the style: austere, uncompromising, consistent, complete.\n\n## Check you're writing the right thing\n\n- The content **discusses, contextualizes, justifies** — answers \"why\" → `diataxis-explanation`. Heuristics from the boundary: if it's boring and unmemorable, it's probably reference; lists and tables almost always belong in reference; anything you'd introduce with \"can you tell me more about…\" leans explanation. The real test — consulted *while actively working* → reference; read *away from the work* to understand → explanation.\n- The content **directs action toward a goal** → `diataxis-how-to`.\n- The content **walks a beginner through a lesson** → `diataxis-tutorial`.\n- Mixed or unclear → step back to the `diataxis` router and run the compass.\n\n## Step 1 — Let the machinery dictate the structure\n\nThe structure of reference documentation should mirror the structure of the product, the way a map mirrors the territory. If a method belongs to a class inside a module, the documentation shows that same nesting. The reader navigates the docs by their knowledge of the thing itself — so before writing, identify the product's own architecture and organize by it, not by task, audience, or narrative.\n\nFor anything derivable from the code (signatures, defaults, options, types), read the source and derive it — never write a fact about the machinery you haven't verified against the machinery.\n\n## Step 2 — Adopt a pattern, then never deviate\n\nReference is useful when it is consistent: the reader should always find the same kind of information in the same place in the same form. Decide the standard entry shape up front — e.g., for each option: name, type, default, effect, constraints — and apply it uniformly. One voice throughout; a reference that changes register between entries makes the reader re-learn how to read it at every entry.\n\nIf auditing an existing reference, infer the dominant pattern first and bring outliers into line with it rather than inventing a new one.\n\n## Step 3 — Describe. Do nothing else.\n\nNeutral description is the key imperative. State facts, plainly:\n\n- Flat declaratives: \"Django's default logging configuration inherits Python's defaults.\"\n- Plain enumeration: \"Sub-commands are: a, b, c, d, e, f.\"\n- Normative statements where the machinery imposes them, stated as fact, not persuasion: \"You must use a. Never d while b is active.\"\n- Warnings the same way — factual, in the entry they belong to.\n\nUsage examples are welcome and often the fastest way to convey a fact — but keep them illustrative. An example that starts narrating steps has become instruction; one that starts justifying the design has become explanation.\n\n## Step 4 — The drift checklist\n\nUse this on your own draft, and as the audit lens when the `diataxis` router sends an existing reference here. An audit invocation runs only this step — skip Steps 1–3 and report findings without editing; edits wait for explicit confirmation — the router's gate, or the user's when invoked directly. The repair move is usually **relocation, not deletion**.\n\n- Explanatory asides — rationale, history, design discussion sprinkled between entries → consolidate into an explanation article and link; digressions interrupt and obscure the reference, and the fragments never add up to a proper explanation either.\n- Instructional creep — recipes and step sequences inside entries → relocate to a how-to guide; link.\n- Examples grown too expansive → trim back to illustration; move the surplus where it belongs.\n- Inconsistent entry shapes, register shifts, creative vocabulary → normalize to the standard pattern.\n- Structure organized by narrative or audience instead of by the machinery → restructure to mirror the product.\n- Marketing or opinion (\"the powerful x subsystem\") → delete; reference carries no advocacy.\n- Unverified or stale facts → check against the source; a reference the reader can't trust is worse than none.\n\n## Things not to do\n\n- **Don't** instruct, explain, discuss, or opine. Describe — and link outward for everything else.\n- **Don't** organize by use case. That's a how-to guide's job; the machinery's own structure is the reference's index.\n- **Don't** vary the pattern for interest's sake. Boring and predictable is the virtue here.\n- **Don't** rely solely on auto-generated output. Generated docs inherit the code's structure but still need curation, examples, and accuracy checks.\n- **Don't** state a fact you haven't verified against the product.\n","# diataxis-reference\n\nReference is **a map of the machinery**. A map tells you what you need to know about the territory without your having to go out and survey it yourself — and like a map, reference is neutral: it doesn't care what the reader is doing. The same chart serves the navigator plotting a course and the judge investigating a wreck. Diátaxis places reference at *cognition* + *application*: propositional knowledge, consulted in the middle of work.\n\nWhat the working reader needs from it is **truth and certainty** — a firm platform to stand on. That single need dictates the style: austere, uncompromising, consistent, complete.\n\n## Check you're writing the right thing\n\n- The content **discusses, contextualizes, justifies** — answers \"why\" → `diataxis-explanation`. Heuristics from the boundary: if it's boring and unmemorable, it's probably reference; lists and tables almost always belong in reference; anything you'd introduce with \"can you tell me more about…\" leans explanation. The real test — consulted *while actively working* → reference; read *away from the work* to understand → explanation.\n- The content **directs action toward a goal** → `diataxis-how-to`.\n- The content **walks a beginner through a lesson** → `diataxis-tutorial`.\n- Mixed or unclear → step back to the `diataxis` router and run the compass.\n\n## Step 1 — Let the machinery dictate the structure\n\nThe structure of reference documentation should mirror the structure of the product, the way a map mirrors the territory. If a method belongs to a class inside a module, the documentation shows that same nesting. The reader navigates the docs by their knowledge of the thing itself — so before writing, identify the product's own architecture and organize by it, not by task, audience, or narrative.\n\nFor anything derivable from the code (signatures, defaults, options, types), read the source and derive it — never write a fact about the machinery you haven't verified against the machinery.\n\n## Step 2 — Adopt a pattern, then never deviate\n\nReference is useful when it is consistent: the reader should always find the same kind of information in the same place in the same form. Decide the standard entry shape up front — e.g., for each option: name, type, default, effect, constraints — and apply it uniformly. One voice throughout; a reference that changes register between entries makes the reader re-learn how to read it at every entry.\n\nIf auditing an existing reference, infer the dominant pattern first and bring outliers into line with it rather than inventing a new one.\n\n## Step 3 — Describe. Do nothing else.\n\nNeutral description is the key imperative. State facts, plainly:\n\n- Flat declaratives: \"Django's default logging configuration inherits Python's defaults.\"\n- Plain enumeration: \"Sub-commands are: a, b, c, d, e, f.\"\n- Normative statements where the machinery imposes them, stated as fact, not persuasion: \"You must use a. Never d while b is active.\"\n- Warnings the same way — factual, in the entry they belong to.\n\nUsage examples are welcome and often the fastest way to convey a fact — but keep them illustrative. An example that starts narrating steps has become instruction; one that starts justifying the design has become explanation.\n\n## Step 4 — The drift checklist\n\nUse this on your own draft, and as the audit lens when the `diataxis` router sends an existing reference here. An audit invocation runs only this step — skip Steps 1–3 and report findings without editing; edits wait for explicit confirmation — the router's gate, or the user's when invoked directly. The repair move is usually **relocation, not deletion**.\n\n- Explanatory asides — rationale, history, design discussion sprinkled between entries → consolidate into an explanation article and link; digressions interrupt and obscure the reference, and the fragments never add up to a proper explanation either.\n- Instructional creep — recipes and step sequences inside entries → relocate to a how-to guide; link.\n- Examples grown too expansive → trim back to illustration; move the surplus where it belongs.\n- Inconsistent entry shapes, register shifts, creative vocabulary → normalize to the standard pattern.\n- Structure organized by narrative or audience instead of by the machinery → restructure to mirror the product.\n- Marketing or opinion (\"the powerful x subsystem\") → delete; reference carries no advocacy.\n- Unverified or stale facts → check against the source; a reference the reader can't trust is worse than none.\n\n## Things not to do\n\n- **Don't** instruct, explain, discuss, or opine. Describe — and link outward for everything else.\n- **Don't** organize by use case. That's a how-to guide's job; the machinery's own structure is the reference's index.\n- **Don't** vary the pattern for interest's sake. Boring and predictable is the virtue here.\n- **Don't** rely solely on auto-generated output. Generated docs inherit the code's structure but still need curation, examples, and accuracy checks.\n- **Don't** state a fact you haven't verified against the product.\n",{"name":5,"description":7},"main","029bf6d49f3d270442ace55a01cccb40113f7efa","plugins\u002Fdocs\u002Fskills\u002Fdiataxis-reference","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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add esond\u002Fskills --skill diataxis-reference",{"tool":63,"command":64},"bunx","bunx skills add esond\u002Fskills --skill diataxis-reference",{"tool":66,"command":67},"pnpm","pnpm dlx skills add esond\u002Fskills --skill diataxis-reference","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fdocs\u002Fskills\u002Fdiataxis-reference\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"agents\u002Fopenai.yaml","REFERENCE","参考文档",130,"https:\u002F\u002Fgithub.com\u002Fesond\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fdocs\u002Fskills\u002Fdiataxis-reference\u002Fagents\u002Fopenai.yaml",[78,103,129,152,164,200],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":44},"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",[],[28,85,86,87,88,89,90,91,92,93,94,95,96,97,36,98,99,100,101,102],"work item voice","work item","voice","conversation","which","get","card","ticket","up","issues","new","writing","azure devops","ask","tasks","text","create","tracker",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":114,"publishedAt":44},"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",[109],{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[115,87,116,88,117,118,93,119,36,98,34,120,121,122,123,124,125,126,127,128],"conversational voice","back","messages","send","slack messages","commit","team","code-review","review","sanity","message","slack","human","how",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":136,"publishedAt":44},"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",[135],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[137,138,139,140,141,142,143,144,145,90,146,147,93,148,149,150,151,36,34,123],"sync","sync core repo docs","repo docs","core","repo","docs","agent instructions","SET","ready","scope","project","init","only","files","confirmation",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":44},"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",[],[159,142,140,137,101,160,161,162,163,141,123],"sync core docs","true","md docs","audit","README",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":179,"publishedAt":44},"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",[170,173,176],{"categoryNo":171,"categoryName":172,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":174,"categoryName":175,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":177,"categoryName":178,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199],"system design","design","software","system","righting software","righting software system design","deep","quick","wait for","unknown","components","candidate","architecture","phase","valid","run","at","wait","live","full",{"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},"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",[],[207,208,209,116,210,90,211,212,213,93,214,215,216,217,149,218,49,36,35,120],"branch","reorganize branch commits","commits","operate","align","re","default","fix","clean","branches","open","tidy"]