[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAV3CX14R6Z752BZMMEF5Y":3,"skill-same:01M6DAV3CX14R6Z752BZMMEF5Y":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":13,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6DAV3CX14R6Z752BZMMEF5Y","documentation",null,"Use when creating, reviewing, or auditing a codebase's documentation — README and docs\u002F trees, architecture\u002Fworkflow diagrams, API references, formal doc sites (OpenAPI, MkDocs, Sphinx, ReadTheDocs) — and you need the bar for accessibility (concise synthesis, diagrams where structure beats prose) and accuracy over time (code-cited facts under an explicit maintenance contract).","tzeusy-org\u002Fai-bootstrap","tzeusy-org","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141543652?v=4","01M6DAM1AP09H27BYGFY9QCNPB","01M6DAM1F4R187EK11XDN9JZKH",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdocumentation\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"use","contract","active","time","structure","prose","references","mkdocs","diagrams","maintenance","docs","README","api","openapi","doc","code","architecture","accessibility","workflow","2026-11-10 10:12:30",false,"---\nname: documentation\ndescription: >\n  Use when creating, reviewing, or auditing a codebase's documentation — README and docs\u002F\n  trees, architecture\u002Fworkflow diagrams, API references, formal doc sites (OpenAPI, MkDocs,\n  Sphinx, ReadTheDocs) — and you need the bar for accessibility (concise synthesis,\n  diagrams where structure beats prose) and accuracy over time (code-cited facts under an\n  explicit maintenance contract).\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n  status: active\n  last_reviewed: \"2026-06-12\"\n---\n\n# Documentation\n\nDocumentation keeps a codebase accessible to reviewers and future\nmaintainers — load-bearing in a spec-driven workflow. Its failure mode\nis not absence but rot: confident prose no longer matching the code.\nHold docs to two standards at once: **accessible** (newcomer orients in\nminutes) and **maintainable** (every claim re-verifiable against code).\n\n## Use This Skill When\n\n- Writing or restructuring a project's README, docs\u002F tree, or doc site\n- Reviewing whether a change's documentation is adequate and current\n- Auditing existing docs for staleness, missing synthesis, or missing diagrams\n- Documenting an interface's behavioral contract — side effects, statefulness,\n  idempotency, failure semantics — in docstrings or endpoint descriptions\n- Setting up or judging formal doc tooling (OpenAPI, MkDocs, Sphinx,\n  ReadTheDocs, docstring-generated references)\n\n## Do Not Use This Skill For\n\n- Five-pillar knowledge architecture (doctrine, contracts, specs, topology,\n  standards) — `\u002Fth-projects` (project-shape). This subskill governs the\n  everyday docs of any repo, shaped or not.\n- Skill packages — [skill-standards](..\u002Fskill-standards\u002FSKILL.md)\n- Code comments — [code-readability](..\u002Fcode-readability\u002FSKILL.md)\n\n## Core Rule\n\n**Document the contract; cite the code.** Every documented fact is a claim\nabout the code: couple it to the location it derives from, and state it at\nan altitude where only a behavior change — never a behavior-preserving\nrefactor — can falsify it. A doc that cannot be re-verified is already\nrotting; a doc narrating internals re-rots on every refactor.\n\n## The Bar\n\nCite the item violated, with doc and code evidence:\n\n1. **A concise synthesis orients first** — Top of `README.md` or the docs\u002F\n   intro states, in a screenful: what the project does, who it is for, goals\n   and non-goals, how the pieces fit. Missing or buried synthesis is the\n   highest-severity finding.\n2. **Diagrams wherever structure beats prose** — Architecture, happy-path\n   data flow, error handling, and lifecycle\u002Fstate each get a diagram when\n   the project has real structure there. Generate via\n   [excalidraw-diagram](..\u002Fexcalidraw-diagram\u002FSKILL.md); commit `.excalidraw`\n   source plus rendered SVG beside the embedding doc; fall back to Mermaid.\n   Real component and event names — never generic boxes.\n3. **Facts carry citations to interface sites** — Each claim links the code\n   making it true (`path\u002Fto\u002Ffile.py:Symbol`), anchored at definition and\n   interface sites — module, endpoint handler, schema — never internal call\n   chains. Prefer symbol anchors over line numbers. Uncited claims and\n   stale citations are findings.\n4. **Claims survive behavior-preserving refactors** — If a behavior-preserving\n   refactor would falsify a claim, it documents internals: raise\n   it to what callers observe, or delete it.\n5. **Public interfaces carry a semantics card** — Endpoints, exported\n   functions, jobs, and CLI commands document side effects, state,\n   idempotency, failure, and (where it matters) concurrency as a few\n   labeled lines adjacent to the interface, per\n   [`references\u002Finterface-semantics.md`](.\u002Freferences\u002Finterface-semantics.md).\n6. **Docs operate under a maintenance contract** — The docs entry point\n   states it: behavior changes update affected docs in the same change\n   ([engineering-bar](..\u002Fengineering-bar\u002FSKILL.md) bias 7); stale claims get\n   fixed or marked `STALE` with evidence, never left silently. Living\n   catalogs open with their own write-back contract.\n7. **Prose earns its place** — Types, names, and defaults already\n   document; prose states only what they cannot: semantics,\n   invariants, units, the why. Every doc has a nameable reader and a\n   question it answers — can't name both, delete or merge it.\n8. **Formal doc tooling serves human readers** — OpenAPI\u002FMkDocs\u002FSphinx\n   output is judged as prose: human-written summaries, intent and failure\n   modes, happy-path examples. Schema dumps, empty autogenerated stubs, and\n   boilerplate padding are findings. Concise beats complete.\n9. **Content lives at the right distance** — Structure follows the reader's\n   journey (orient → run → how it works, where diagrams live → change →\n   reference); placement follows the gradient: semantics at the interface,\n   architecture in `docs\u002F`, synthesis in the README. Wrong-distance and\n   twice-homed content are findings.\n\n## Workflow\n\n1. **Inventory** — README, docs\u002F tree, doc-site config, embedded diagrams;\n   note what is generated and what claims to be current.\n2. **Synthesis first** (bar 1) — Draft or fix it before judging anything\n   else; keep it a screenful.\n3. **Diagram pass** (bar 2) — List the architecture\u002Fdata-flow\u002Ferror-handling\n   shapes the project actually has; generate missing high-value diagrams;\n   embed them where the prose discusses that structure.\n4. **Citation and altitude audit** (bars 3–4, 6) — Trace claims to code\n   (all in review scope; a sample in a repo audit); label each\n   cited-and-true, stale, uncited, or wrong-altitude. Fix in scope; add the\n   maintenance contract if absent.\n5. **Semantics-card audit** (bar 5) — Each public interface in scope has a\n   card, adjacent to its definition, matching the code. A wrong card is\n   worse than no card.\n6. **Rendered-output pass** (bars 7–9) — Read as the intended consumer;\n   flag schema dumps, signature-restating prose, empty stubs, and\n   wrong-distance content; fix what is in scope.\n7. **Verify** — Build the doc site (broken builds and dead links are\n   findings); re-read the synthesis end-to-end after edits.\n\n## Trigger Sanity Check\n\n- Should trigger: \"Document this service so a reviewer can follow the data\n  flow\", \"audit docs\u002F for stale claims\", \"our Sphinx site is a schema dump\".\n- Should not trigger: \"Bootstrap the five-pillar knowledge architecture\"\n  (`\u002Fth-projects`) or \"review this SKILL.md\" (skill-standards).\n","# Documentation\n\nDocumentation keeps a codebase accessible to reviewers and future\nmaintainers — load-bearing in a spec-driven workflow. Its failure mode\nis not absence but rot: confident prose no longer matching the code.\nHold docs to two standards at once: **accessible** (newcomer orients in\nminutes) and **maintainable** (every claim re-verifiable against code).\n\n## Use This Skill When\n\n- Writing or restructuring a project's README, docs\u002F tree, or doc site\n- Reviewing whether a change's documentation is adequate and current\n- Auditing existing docs for staleness, missing synthesis, or missing diagrams\n- Documenting an interface's behavioral contract — side effects, statefulness,\n  idempotency, failure semantics — in docstrings or endpoint descriptions\n- Setting up or judging formal doc tooling (OpenAPI, MkDocs, Sphinx,\n  ReadTheDocs, docstring-generated references)\n\n## Do Not Use This Skill For\n\n- Five-pillar knowledge architecture (doctrine, contracts, specs, topology,\n  standards) — `\u002Fth-projects` (project-shape). This subskill governs the\n  everyday docs of any repo, shaped or not.\n- Skill packages — [skill-standards](..\u002Fskill-standards\u002FSKILL.md)\n- Code comments — [code-readability](..\u002Fcode-readability\u002FSKILL.md)\n\n## Core Rule\n\n**Document the contract; cite the code.** Every documented fact is a claim\nabout the code: couple it to the location it derives from, and state it at\nan altitude where only a behavior change — never a behavior-preserving\nrefactor — can falsify it. A doc that cannot be re-verified is already\nrotting; a doc narrating internals re-rots on every refactor.\n\n## The Bar\n\nCite the item violated, with doc and code evidence:\n\n1. **A concise synthesis orients first** — Top of `README.md` or the docs\u002F\n   intro states, in a screenful: what the project does, who it is for, goals\n   and non-goals, how the pieces fit. Missing or buried synthesis is the\n   highest-severity finding.\n2. **Diagrams wherever structure beats prose** — Architecture, happy-path\n   data flow, error handling, and lifecycle\u002Fstate each get a diagram when\n   the project has real structure there. Generate via\n   [excalidraw-diagram](..\u002Fexcalidraw-diagram\u002FSKILL.md); commit `.excalidraw`\n   source plus rendered SVG beside the embedding doc; fall back to Mermaid.\n   Real component and event names — never generic boxes.\n3. **Facts carry citations to interface sites** — Each claim links the code\n   making it true (`path\u002Fto\u002Ffile.py:Symbol`), anchored at definition and\n   interface sites — module, endpoint handler, schema — never internal call\n   chains. Prefer symbol anchors over line numbers. Uncited claims and\n   stale citations are findings.\n4. **Claims survive behavior-preserving refactors** — If a behavior-preserving\n   refactor would falsify a claim, it documents internals: raise\n   it to what callers observe, or delete it.\n5. **Public interfaces carry a semantics card** — Endpoints, exported\n   functions, jobs, and CLI commands document side effects, state,\n   idempotency, failure, and (where it matters) concurrency as a few\n   labeled lines adjacent to the interface, per\n   [`references\u002Finterface-semantics.md`](.\u002Freferences\u002Finterface-semantics.md).\n6. **Docs operate under a maintenance contract** — The docs entry point\n   states it: behavior changes update affected docs in the same change\n   ([engineering-bar](..\u002Fengineering-bar\u002FSKILL.md) bias 7); stale claims get\n   fixed or marked `STALE` with evidence, never left silently. Living\n   catalogs open with their own write-back contract.\n7. **Prose earns its place** — Types, names, and defaults already\n   document; prose states only what they cannot: semantics,\n   invariants, units, the why. Every doc has a nameable reader and a\n   question it answers — can't name both, delete or merge it.\n8. **Formal doc tooling serves human readers** — OpenAPI\u002FMkDocs\u002FSphinx\n   output is judged as prose: human-written summaries, intent and failure\n   modes, happy-path examples. Schema dumps, empty autogenerated stubs, and\n   boilerplate padding are findings. Concise beats complete.\n9. **Content lives at the right distance** — Structure follows the reader's\n   journey (orient → run → how it works, where diagrams live → change →\n   reference); placement follows the gradient: semantics at the interface,\n   architecture in `docs\u002F`, synthesis in the README. Wrong-distance and\n   twice-homed content are findings.\n\n## Workflow\n\n1. **Inventory** — README, docs\u002F tree, doc-site config, embedded diagrams;\n   note what is generated and what claims to be current.\n2. **Synthesis first** (bar 1) — Draft or fix it before judging anything\n   else; keep it a screenful.\n3. **Diagram pass** (bar 2) — List the architecture\u002Fdata-flow\u002Ferror-handling\n   shapes the project actually has; generate missing high-value diagrams;\n   embed them where the prose discusses that structure.\n4. **Citation and altitude audit** (bars 3–4, 6) — Trace claims to code\n   (all in review scope; a sample in a repo audit); label each\n   cited-and-true, stale, uncited, or wrong-altitude. Fix in scope; add the\n   maintenance contract if absent.\n5. **Semantics-card audit** (bar 5) — Each public interface in scope has a\n   card, adjacent to its definition, matching the code. A wrong card is\n   worse than no card.\n6. **Rendered-output pass** (bars 7–9) — Read as the intended consumer;\n   flag schema dumps, signature-restating prose, empty stubs, and\n   wrong-distance content; fix what is in scope.\n7. **Verify** — Build the doc site (broken builds and dead links are\n   findings); re-read the synthesis end-to-end after edits.\n\n## Trigger Sanity Check\n\n- Should trigger: \"Document this service so a reviewer can follow the data\n  flow\", \"audit docs\u002F for stale claims\", \"our Sphinx site is a schema dump\".\n- Should not trigger: \"Bootstrap the five-pillar knowledge architecture\"\n  (`\u002Fth-projects`) or \"review this SKILL.md\" (skill-standards).\n",{"name":5,"metadata":47,"description":52},{"owner":48,"status":25,"authors":49,"last_reviewed":51},"tze",[48,50],"Claude Fable 5","2026-06-12","Use when creating, reviewing, or auditing a codebase's documentation — README and docs\u002F trees, architecture\u002Fworkflow diagrams, API references, formal doc sites (OpenAPI, MkDocs, Sphinx, ReadTheDocs) — and you need the bar for accessibility (concise synthesis, diagrams where structure beats prose) and accuracy over time (code-cited facts under an explicit maintenance contract).\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdocumentation","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap","https:\u002F\u002Fgithub.com\u002Ftzeusy-org","2026-11-10 23:17:25",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill documentation",{"tool":65,"command":66},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill documentation",{"tool":68,"command":69},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill documentation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdocumentation\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Finterface-semantics.md","REFERENCE","参考文档",3189,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdocumentation\u002Freferences\u002Finterface-semantics.md",[80,104,128,143,162,173],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":42},"01M6DAZD21TWH2ET70V9FF75CQ","user-run","Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable \u002Fhome\u002Forca\u002F.tmp\u002F\u003Cslug>\u002Frun.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: \"I'll run it for you\", \"permission denied on docker.sock\", \"needs sudo\", \"sudo: a password is required\", \"run as tze\", \"\u002Fuser-run\".","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",[],[87,88,89,90,91,23,92,93,94,95,25,26,96,97,98,99,100,101,102,103],"user run","user","run","docker","logs","host","as","triggers","permission","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":118,"publishedAt":42},"01M6DAZAHTCBAD2WF0GAHWPST8","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Frequesting-code-review\u002FSKILL.md",[110,113],{"categoryNo":111,"categoryName":112,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[119,38,120,121,122,123,25,124,125,23,126,127],"requesting code review","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":136,"publishedAt":42},"01M6DAZ7CJ82D81XZB2YHVVY48","receiving-code-review","Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Freceiving-code-review\u002FSKILL.md",[134,135],{"categoryNo":111,"categoryName":112,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},[137,38,120,121,25,124,138,125,23,139,140,141,142],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":42},"01M6DAZ4ER76ADXJ9KRFP7V3Q9","finishing-a-development-branch","Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Ffinishing-a-development-branch\u002FSKILL.md",[],[150,151,152,153,23,154,122,155,156,157,125,158,159,160,25,124,161,138],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":42},"01M6DAYZFWWW2YPKP89QNQR96H","executing-plans","Use when you have a written implementation plan to execute in a separate session with review checkpoints","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fexecuting-plans\u002FSKILL.md",[],[169,170,171,120,172,25,124,138,125,23,98],"plans","executing plans","plan","execute",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":42},"01M6DAYWM2YQHYCK7C35K1D29J","dispatching-parallel-agents","Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fdispatching-parallel-agents\u002FSKILL.md",[],[180,181,182,23,125,124,183,25,184,127,185],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]