[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J9RGCS237K56KZ5THEDXN7":3,"skill-same:01M6J9RGCS237K56KZ5THEDXN7":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":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6J9RGCS237K56KZ5THEDXN7","harn-docs",null,"Choose one Diátaxis purpose, use canonical Harn terms, prove examples, and remove stock AI prose.","burin-labs\u002Fharn","burin-labs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F270508823?v=4","01M6J9MTN4TKZ12YF6BAX0DARN","Burin Labs","01M6J9MTSTW6RRQ2TWKYV1A3X1",31,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fburin-labs\u002Fharn\u002Fblob\u002Fmain\u002Fcrates\u002Fharn-skills\u002Fsrc\u002Fcorpus\u002Fharn-docs\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,44,45,46,47],"docs","harn docs","when","writing","inline","developer documentation","canonical","guides","pages","stock","task","api documentation","use","remove","write","README","choose","text","how","api","developer","examples","notes","documentation","2026-11-10 10:12:30",false,"---\nname: harn-docs\nshort: Write task-shaped developer documentation in plain language.\ndescription: Choose one Diátaxis purpose, use canonical Harn terms, prove examples, and remove stock AI prose.\nwhen_to_use: Use when writing or reviewing Harn or Burin tutorials, how-to guides, reference pages, explanations, README text, migration notes, or inline API documentation.\n---\n\n# Write Harn developer documentation\n\nWrite for the developer who has a task. Pair this skill with\n[[harn-language]] for checked Harn examples, [[harn-testing]] for executable\nproof, and [[harn-product-quality]] for a complete user path.\n\n## Set the page contract\n\n- Read the nearest `AGENTS.md`, the publishing index, the glossary, and the\n  source that owns the behavior.\n- Name the reader, their task, and a falsifier for each material claim.\n- Give the page one [Diátaxis](https:\u002F\u002Fdiataxis.fr\u002F) purpose: tutorial, how-to,\n  reference, or explanation.\n- Split mixed-purpose pages and link them where the reader needs to switch.\n- In Harn, `docs\u002Fsrc\u002FSUMMARY.md` is the published index and\n  `docs\u002Fsrc\u002Fconcepts\u002Fglossary.md` owns public terms.\n- In Burin, read `site\u002Fsrc\u002Fcontent\u002FREADME.md` before choosing a help-center\n  category.\n\n## Draft from evidence\n\n- Lead with the result or action.\n- Use the exact command, type, state, default, limit, error, and path from\n  source. Do not invent friendly aliases.\n- Explain permissions, side effects, and recovery where they affect a choice.\n- Put examples on the canonical product path and run them.\n- Link the next local page inline. Link primary external sources for protocols,\n  providers, model cards, licenses, and third-party setup.\n- For current or comparative claims, inspect the peer page that serves the same\n  developer task. Useful agent-framework checks include Flue's\n  [quickstart](https:\u002F\u002Fflueframework.com\u002Fdocs\u002Fgetting-started\u002Fquickstart\u002F),\n  [agent guide](https:\u002F\u002Fflueframework.com\u002Fdocs\u002Fguide\u002Fbuilding-agents\u002F), and\n  [event reference](https:\u002F\u002Fflueframework.com\u002Fdocs\u002Fapi\u002Fevents-reference\u002F).\n- State observed facts as facts. Mark inference and remove unsupported claims.\n\n## Edit the prose\n\nApply the current [Slopwash](https:\u002F\u002Fwww.slopwash.com\u002F) rules. Where they are\nsilent on a question of usage, the\n[Google developer documentation style guide](https:\u002F\u002Fdevelopers.google.com\u002Fstyle\u002F)\n(CC BY 4.0) is the reference; the\n[Microsoft writing style guide](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fstyle-guide\u002Fwelcome\u002F)\nis the second opinion. Neither overrides a rule below.\n\nHarn does not write in\n[ASD-STE100 Simplified Technical English](https:\u002F\u002Fasd-ste100.org\u002F). That\nstandard is built around a roughly 900-word approved dictionary aimed at\naerospace procedures read by non-native speakers, and it is ASD-copyrighted\nrather than openly licensed, so it cannot be vendored here. Four of its rules\nare worth keeping anyway, because they are checkable rather than a matter of\ntaste:\n\n- Cap noun clusters at three words. “Provider capability matrix generation\n  policy” is five; name the thing instead.\n- Keep instructions under about 20 words per sentence, and descriptive prose\n  under about 25.\n- Use active voice in tutorials and how-to guides. Passive is fine in\n  explanation when the actor is genuinely irrelevant.\n- Give a word one meaning across the page, and one part of speech.\n\n- Use plain verbs: “is,” “has,” “runs,” and “writes.”\n- Use common contractions: “it's,” “you're,” “that's,” “doesn't,” “can't.”\n  Contract negations especially — a reader scanning a page skips over “not”\n  but cannot misread “don't.” Avoid noun-verb contractions (“Harn's shipping\n  a new release”), invented ones, and awkward ones such as “there'd” or\n  “it'll.” Keep one form per page rather than mixing “can't” with “cannot.”\n- Delete throat-clearing introductions, section summaries, transition filler,\n  praise, vague importance, rhetorical questions, and speculative endings.\n- Remove staged contrasts, false balance, stock AI vocabulary, decorative bold\n  text, emoji, and repeated em dashes.\n- Use sentence-case headings. Use a list only when it scans better than prose.\n- Keep one exact term instead of cycling through synonyms. Explain unavoidable\n  jargon once.\n- Prefer a real number, date, state, or failure over an adjective.\n\nRead the page aloud. A tired developer should understand each sentence once.\n\n## Check the result\n\n- Confirm the page's Diátaxis section and index position.\n- Follow every link. Run every command and example that can run locally.\n- Search for competing terms and copied guidance.\n- Run `make check-docs-snippets` for Harn docs, plus the language checks named\n  in `AGENTS.md` when syntax or semantics changed.\n- Re-read the first sentence of every section as an outline.\n- Delete closing sentences that only repeat the section.\n- Report the checks that ran and any claim without direct proof.\n\n## Review each page type\n\nFor a tutorial:\n\n- Give the reader one complete first success.\n- Keep choices out of the main path unless the tutorial teaches that choice.\n- Show the expected result after each material action.\n\nFor a how-to guide:\n\n- Start from the task and its prerequisites.\n- Put the working command before background information.\n- Link reference details instead of copying them into the procedure.\n\nFor a reference page:\n\n- Mirror the source contract and use a stable, scannable order.\n- State defaults, accepted values, return shapes, effects, and errors.\n- Generate tables where a registry or schema already owns the rows.\n\nFor an explanation:\n\n- Name the design question in the first paragraph.\n- Explain ownership, constraints, and tradeoffs with links to the task pages.\n- Keep instructions in linked tutorials or how-to guides.\n\n## Keep documentation current\n\n- Change the owning page in the same patch as a public behavior change.\n- Search for old names, commands, and defaults across every published surface.\n- Prefer generated projections or drift tests when facts repeat across pages.\n- Add redirects or migration notes when a renamed page already has readers.\n- Remove obsolete pages after their useful content has one clear owner.\n","# Write Harn developer documentation\n\nWrite for the developer who has a task. Pair this skill with\n[[harn-language]] for checked Harn examples, [[harn-testing]] for executable\nproof, and [[harn-product-quality]] for a complete user path.\n\n## Set the page contract\n\n- Read the nearest `AGENTS.md`, the publishing index, the glossary, and the\n  source that owns the behavior.\n- Name the reader, their task, and a falsifier for each material claim.\n- Give the page one [Diátaxis](https:\u002F\u002Fdiataxis.fr\u002F) purpose: tutorial, how-to,\n  reference, or explanation.\n- Split mixed-purpose pages and link them where the reader needs to switch.\n- In Harn, `docs\u002Fsrc\u002FSUMMARY.md` is the published index and\n  `docs\u002Fsrc\u002Fconcepts\u002Fglossary.md` owns public terms.\n- In Burin, read `site\u002Fsrc\u002Fcontent\u002FREADME.md` before choosing a help-center\n  category.\n\n## Draft from evidence\n\n- Lead with the result or action.\n- Use the exact command, type, state, default, limit, error, and path from\n  source. Do not invent friendly aliases.\n- Explain permissions, side effects, and recovery where they affect a choice.\n- Put examples on the canonical product path and run them.\n- Link the next local page inline. Link primary external sources for protocols,\n  providers, model cards, licenses, and third-party setup.\n- For current or comparative claims, inspect the peer page that serves the same\n  developer task. Useful agent-framework checks include Flue's\n  [quickstart](https:\u002F\u002Fflueframework.com\u002Fdocs\u002Fgetting-started\u002Fquickstart\u002F),\n  [agent guide](https:\u002F\u002Fflueframework.com\u002Fdocs\u002Fguide\u002Fbuilding-agents\u002F), and\n  [event reference](https:\u002F\u002Fflueframework.com\u002Fdocs\u002Fapi\u002Fevents-reference\u002F).\n- State observed facts as facts. Mark inference and remove unsupported claims.\n\n## Edit the prose\n\nApply the current [Slopwash](https:\u002F\u002Fwww.slopwash.com\u002F) rules. Where they are\nsilent on a question of usage, the\n[Google developer documentation style guide](https:\u002F\u002Fdevelopers.google.com\u002Fstyle\u002F)\n(CC BY 4.0) is the reference; the\n[Microsoft writing style guide](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fstyle-guide\u002Fwelcome\u002F)\nis the second opinion. Neither overrides a rule below.\n\nHarn does not write in\n[ASD-STE100 Simplified Technical English](https:\u002F\u002Fasd-ste100.org\u002F). That\nstandard is built around a roughly 900-word approved dictionary aimed at\naerospace procedures read by non-native speakers, and it is ASD-copyrighted\nrather than openly licensed, so it cannot be vendored here. Four of its rules\nare worth keeping anyway, because they are checkable rather than a matter of\ntaste:\n\n- Cap noun clusters at three words. “Provider capability matrix generation\n  policy” is five; name the thing instead.\n- Keep instructions under about 20 words per sentence, and descriptive prose\n  under about 25.\n- Use active voice in tutorials and how-to guides. Passive is fine in\n  explanation when the actor is genuinely irrelevant.\n- Give a word one meaning across the page, and one part of speech.\n\n- Use plain verbs: “is,” “has,” “runs,” and “writes.”\n- Use common contractions: “it's,” “you're,” “that's,” “doesn't,” “can't.”\n  Contract negations especially — a reader scanning a page skips over “not”\n  but cannot misread “don't.” Avoid noun-verb contractions (“Harn's shipping\n  a new release”), invented ones, and awkward ones such as “there'd” or\n  “it'll.” Keep one form per page rather than mixing “can't” with “cannot.”\n- Delete throat-clearing introductions, section summaries, transition filler,\n  praise, vague importance, rhetorical questions, and speculative endings.\n- Remove staged contrasts, false balance, stock AI vocabulary, decorative bold\n  text, emoji, and repeated em dashes.\n- Use sentence-case headings. Use a list only when it scans better than prose.\n- Keep one exact term instead of cycling through synonyms. Explain unavoidable\n  jargon once.\n- Prefer a real number, date, state, or failure over an adjective.\n\nRead the page aloud. A tired developer should understand each sentence once.\n\n## Check the result\n\n- Confirm the page's Diátaxis section and index position.\n- Follow every link. Run every command and example that can run locally.\n- Search for competing terms and copied guidance.\n- Run `make check-docs-snippets` for Harn docs, plus the language checks named\n  in `AGENTS.md` when syntax or semantics changed.\n- Re-read the first sentence of every section as an outline.\n- Delete closing sentences that only repeat the section.\n- Report the checks that ran and any claim without direct proof.\n\n## Review each page type\n\nFor a tutorial:\n\n- Give the reader one complete first success.\n- Keep choices out of the main path unless the tutorial teaches that choice.\n- Show the expected result after each material action.\n\nFor a how-to guide:\n\n- Start from the task and its prerequisites.\n- Put the working command before background information.\n- Link reference details instead of copying them into the procedure.\n\nFor a reference page:\n\n- Mirror the source contract and use a stable, scannable order.\n- State defaults, accepted values, return shapes, effects, and errors.\n- Generate tables where a registry or schema already owns the rows.\n\nFor an explanation:\n\n- Name the design question in the first paragraph.\n- Explain ownership, constraints, and tradeoffs with links to the task pages.\n- Keep instructions in linked tutorials or how-to guides.\n\n## Keep documentation current\n\n- Change the owning page in the same patch as a public behavior change.\n- Search for old names, commands, and defaults across every published surface.\n- Prefer generated projections or drift tests when facts repeat across pages.\n- Add redirects or migration notes when a renamed page already has readers.\n- Remove obsolete pages after their useful content has one clear owner.\n",{"name":5,"short":53,"description":7,"when_to_use":54},"Write task-shaped developer documentation in plain language.","Use when writing or reviewing Harn or Burin tutorials, how-to guides, reference pages, explanations, README text, migration notes, or inline API documentation.","main","a52b7979c25b6be41bc82c4a6e583959a048f618","crates\u002Fharn-skills\u002Fsrc\u002Fcorpus\u002Fharn-docs",6,"https:\u002F\u002Fgithub.com\u002Fburin-labs\u002Fharn","https:\u002F\u002Fharnlang.com","https:\u002F\u002Fgithub.com\u002Fburin-labs","2026-11-14 03:15:13",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add burin-labs\u002Fharn --skill harn-docs",{"tool":69,"command":70},"bunx","bunx skills add burin-labs\u002Fharn --skill harn-docs",{"tool":72,"command":73},"pnpm","pnpm dlx skills add burin-labs\u002Fharn --skill harn-docs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fburin-labs\u002Fharn\u002Fblob\u002Fmain\u002Fcrates\u002Fharn-skills\u002Fsrc\u002Fcorpus\u002Fharn-docs\u002FSKILL.md",true,[],[78,97,118,132,153,166],{"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":48},"01M6J9Y4B3NZ9C24GN47159AEQ","stream-fan-in","Stream trigger example for routing or grouping event batches.","https:\u002F\u002Fgithub.com\u002Fburin-labs\u002Fharn\u002Fblob\u002Fmain\u002Fexamples\u002Ftriggers\u002Fstream-fan-in\u002FSKILL.md",[],[85,86,87,88,89,90,91,92,93,94,95,96,36],"stream","stream fan in","routing","customize","trigger","pipeline","for","batches","event","events","grouping","example",{"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":103,"publishedAt":48},"01M6J9WNJHJV0K3CBZJFG8GD1R","github-stale-pr-nudger","Cron recipe for scanning repositories and nudging old pull requests.","https:\u002F\u002Fgithub.com\u002Fburin-labs\u002Fharn\u002Fblob\u002Fmain\u002Fexamples\u002Ftriggers\u002Fgithub-stale-pr-nudger\u002FSKILL.md",[],[104,105,106,107,108,91,109,110,111,112,113,36,114,115,116,88,117],"github stale pr nudger","stale","github","pr","requests","scheduled","follow-up","recipe","up","scanning","cron","pull","pull request","pull requests",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":48},"01M6J9Y7X1D3ZSWWAG1GXFTWWY","webhook-generic-hmac","Generic webhook recipe with signed inbound requests.","https:\u002F\u002Fgithub.com\u002Fburin-labs\u002Fharn\u002Fblob\u002Fmain\u002Fexamples\u002Ftriggers\u002Fwebhook-generic-hmac\u002FSKILL.md",[],[125,126,127,88,26,108,128,111,89,129,130,131,36],"generic","webhook","webhook generic hmac","with","webhook trigger","provider","webhooks",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":143,"publishedAt":48},"01M6J9Y10NVP86YMXCD9FQ2XZV","slack-thread-summarizer","Slack webhook recipe with a local summarize predicate.","https:\u002F\u002Fgithub.com\u002Fburin-labs\u002Fharn\u002Fblob\u002Fmain\u002Fexamples\u002Ftriggers\u002Fslack-thread-summarizer\u002FSKILL.md",[138],{"categoryNo":139,"categoryName":140,"taxonomyType":141,"taxonomyTypeDesc":142},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[144,145,146,147,148,149,26,150,151,128,126,111,89,88,152,36],"slack thread","slack thread summarizer","thread","summarizer","slack","local","summaries","threads","summarize",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"publishedAt":48},"01M6J9XWKSBQJ881KBP2TGMN3Z","slack-reaction-action","Slack Events API recipe for reaction_added workflows.","https:\u002F\u002Fgithub.com\u002Fburin-labs\u002Fharn\u002Fblob\u002Fmain\u002Fexamples\u002Ftriggers\u002Fslack-reaction-action\u002FSKILL.md",[159],{"categoryNo":139,"categoryName":140,"taxonomyType":141,"taxonomyTypeDesc":142},[148,161,162,91,36,26,110,94,111,89,163,112,164,43,88,165],"action","slack reaction action","reactions","work","workflows",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":173,"publishedAt":48},"01M6J9XRE6PD3J99VKA1TYWS9Y","slack-keyword-router","Slack webhook recipe for routing messages by keyword.","https:\u002F\u002Fgithub.com\u002Fburin-labs\u002Fharn\u002Fblob\u002Fmain\u002Fexamples\u002Ftriggers\u002Fslack-keyword-router\u002FSKILL.md",[172],{"categoryNo":139,"categoryName":140,"taxonomyType":141,"taxonomyTypeDesc":142},[174,175,148,176,36,90,177,87,88,126,26,178,91,111],"slack keyword router","router","simple","messages","slack messages"]