[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71KBBGF7Y4EB4AMHBZ8CJFC":3,"skill-same:01M71KBBGF7Y4EB4AMHBZ8CJFC":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document",null,"Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",289,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"write document","document","write","methodology","high","bmad","standard","use","technical","minimal","bold","sonnet","integrity","organize","sync","directory","guides","when","documents","actionable","2026-11-10 10:12:30",false,"---\nname: write-document\nmodel: sonnet\neffort: standard\ndescription: Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.\n---\n\n# Write Document (BMAD)\n\nCreate high-signal technical documentation that serves as an expert collaborator for both humans and AI. This skill enforces the BMAD principles to prevent context rot and ensure architectural durability.\n\n**Distinct from `edit-document`:** Use this skill to create a document that does not yet exist. Use `edit-document` when a document already exists and needs restructuring, clarity, or prose improvements.\n\n> **HARD GATE** — Every document must have a clear \"Reason for Existence.\" If a document doesn't provide actionable leverage for a caller or test, do not create it.\n\n## The BMAD Principles\n\n| Principle | Execution |\n| :--- | :--- |\n| **B**old | Make strong assertions. Define clear boundaries and \"Never\" rules. No \"it might\" or \"usually.\" |\n| **M**inimal | High-density, low-filler. **Circuit Breaker**: If the file exceeds 300 lines or the session exceeds 20 turns, you MUST run `terse-mode` and compact state before saving. |\n| **A**ctionable | Link every doc to a verifiable outcome. **Architectural Docs**: Verify via Gherkin features (`specs\u002Fverifications\u002Ffeatures\u002F`) or grep-based structure checks (`grep -c \"pattern\" file`) that prove the design's *constraints* are present. |\n| **D**urable | Design for the long-term. **Scalability**: Use \"Nested Indexing\"—root files link to module-level `GEMINI.md` indexes; do not list individual sub-files in the root. |\n\n## Process\n\n### 1. Identify the Artifact Type & Scope\n\nChoose the correct BMAD-BigPowers artifact:\n- **Decision Record (ADR)**: For \"Why\" decisions (saved to `specs\u002Fadr\u002F`).\n- **Context Map**: For system-wide architectural mapping (`specs\u002Ftech-architecture\u002Ftech-stack.md`).\n- **Technical Guide**: For \"How-to\" with verification (saved to `\u003Cmodule>\u002FREFERENCE.md`).\n- **Behavioral Feature**: Gherkin-style compliance specs (saved to `specs\u002Fverifications\u002Ffeatures\u002F`).\n- **Project README**: Project-facing documentation (saved to `README.md` at project root).\n\n**Cross-Cutting Concerns**: If a doc affects multiple modules, place the authoritative source in the lowest common ancestor directory and use \"Delegates\" (one-line pointers) in sub-directories to maintain the Single Source of Truth without violating the Stepdown Rule.\n\n### 2. Draft with Semantic Velocity\n\n> **STREAM CONTINUITY** — When writing file content, output in continuous chunks of ~200 lines. Do not pause. Continue immediately until complete. If you need time, emit a placeholder comment rather than going silent.\n\nWrite the document focusing on \"Expert Collaboration\":\n- **Instructions over Descriptions**: Tell the reader (human or AI) exactly how to interact with the system.\n- **Provenance Links**: Link to ADRs, Issues, or Commits to preserve intent.\n- **The Stepdown Rule**: Information should descend exactly one level of abstraction. If a root doc needs to explain a leaf-level detail, it must point to a sub-index first.\n\n### Quick README (Project READMEs only)\n\n1. Ask: \"Project name? One-sentence description?\"\n2. Generate `README.md` at project root using the template in [REFERENCE.md](REFERENCE.md) — no TOC, no second interview round.\n3. Fill gaps from `CLAUDE.md` \u002F `AGENTS.md` commands if available (prefer `AGENTS.md`); use `TODO` markers otherwise.\n4. Output and suggest `edit-document` for polish.\n\n→ verify: `test -f README.md && [ \"$(grep -c '^## ' README.md)\" -ge 7 ]`\n\n### 3. Apply the 94% Quality Gate\n\nBefore finalizing, audit the document against these red flags:\n- [ ] **Filler Language**: Are there pleasantries or \"I hope this helps\"? (Delete them).\n- [ ] **Ambiguity**: Are there \"usually,\" \"often,\" or \"it depends\" without specific conditions?\n- [ ] **Dead Ends**: Does the document end without a \"Next Step\" or \"Verification\" command?\n- [ ] **Shallow Content**: Does it restate the code without explaining the *intent* or *contracts*?\n\n### 4. Sync and Organize\n\n- **Big Powers Hierarchy**: Place the document in the correct tier (Global -> Project -> Sub-directory). Project READMEs are an exception — they go to project root (`README.md`), not `specs\u002F`.\n- **Nested Indexing**: If adding a module-level doc, ensure the module's `GEMINI.md` is updated. If the module's index is new, add it to the root `GEMINI.md`.\n- **Sync**: Run `scripts\u002Fsync-skills.sh` if the document is a `SKILL.md` or affects generated artifacts.\n\n## Rules\n\n- **Minimalism is a requirement**: If a document can be a 5-line table, do not make it a 5-line essay.\n- **Verifiable outcomes**: Every technical document must include at least one `verify:` command. For architecture, this can be a `grep` or `run_shell_command` that validates the existence of required files or patterns.\n- **No speculative docs**: Do not write documentation for features that do not exist yet unless explicitly doing `elaborate-spec`.\n\n\nSuggest next skill: `audit-code` or `sync-skills.sh`.\n","# Write Document (BMAD)\n\nCreate high-signal technical documentation that serves as an expert collaborator for both humans and AI. This skill enforces the BMAD principles to prevent context rot and ensure architectural durability.\n\n**Distinct from `edit-document`:** Use this skill to create a document that does not yet exist. Use `edit-document` when a document already exists and needs restructuring, clarity, or prose improvements.\n\n> **HARD GATE** — Every document must have a clear \"Reason for Existence.\" If a document doesn't provide actionable leverage for a caller or test, do not create it.\n\n## The BMAD Principles\n\n| Principle | Execution |\n| :--- | :--- |\n| **B**old | Make strong assertions. Define clear boundaries and \"Never\" rules. No \"it might\" or \"usually.\" |\n| **M**inimal | High-density, low-filler. **Circuit Breaker**: If the file exceeds 300 lines or the session exceeds 20 turns, you MUST run `terse-mode` and compact state before saving. |\n| **A**ctionable | Link every doc to a verifiable outcome. **Architectural Docs**: Verify via Gherkin features (`specs\u002Fverifications\u002Ffeatures\u002F`) or grep-based structure checks (`grep -c \"pattern\" file`) that prove the design's *constraints* are present. |\n| **D**urable | Design for the long-term. **Scalability**: Use \"Nested Indexing\"—root files link to module-level `GEMINI.md` indexes; do not list individual sub-files in the root. |\n\n## Process\n\n### 1. Identify the Artifact Type & Scope\n\nChoose the correct BMAD-BigPowers artifact:\n- **Decision Record (ADR)**: For \"Why\" decisions (saved to `specs\u002Fadr\u002F`).\n- **Context Map**: For system-wide architectural mapping (`specs\u002Ftech-architecture\u002Ftech-stack.md`).\n- **Technical Guide**: For \"How-to\" with verification (saved to `\u003Cmodule>\u002FREFERENCE.md`).\n- **Behavioral Feature**: Gherkin-style compliance specs (saved to `specs\u002Fverifications\u002Ffeatures\u002F`).\n- **Project README**: Project-facing documentation (saved to `README.md` at project root).\n\n**Cross-Cutting Concerns**: If a doc affects multiple modules, place the authoritative source in the lowest common ancestor directory and use \"Delegates\" (one-line pointers) in sub-directories to maintain the Single Source of Truth without violating the Stepdown Rule.\n\n### 2. Draft with Semantic Velocity\n\n> **STREAM CONTINUITY** — When writing file content, output in continuous chunks of ~200 lines. Do not pause. Continue immediately until complete. If you need time, emit a placeholder comment rather than going silent.\n\nWrite the document focusing on \"Expert Collaboration\":\n- **Instructions over Descriptions**: Tell the reader (human or AI) exactly how to interact with the system.\n- **Provenance Links**: Link to ADRs, Issues, or Commits to preserve intent.\n- **The Stepdown Rule**: Information should descend exactly one level of abstraction. If a root doc needs to explain a leaf-level detail, it must point to a sub-index first.\n\n### Quick README (Project READMEs only)\n\n1. Ask: \"Project name? One-sentence description?\"\n2. Generate `README.md` at project root using the template in [REFERENCE.md](REFERENCE.md) — no TOC, no second interview round.\n3. Fill gaps from `CLAUDE.md` \u002F `AGENTS.md` commands if available (prefer `AGENTS.md`); use `TODO` markers otherwise.\n4. Output and suggest `edit-document` for polish.\n\n→ verify: `test -f README.md && [ \"$(grep -c '^## ' README.md)\" -ge 7 ]`\n\n### 3. Apply the 94% Quality Gate\n\nBefore finalizing, audit the document against these red flags:\n- [ ] **Filler Language**: Are there pleasantries or \"I hope this helps\"? (Delete them).\n- [ ] **Ambiguity**: Are there \"usually,\" \"often,\" or \"it depends\" without specific conditions?\n- [ ] **Dead Ends**: Does the document end without a \"Next Step\" or \"Verification\" command?\n- [ ] **Shallow Content**: Does it restate the code without explaining the *intent* or *contracts*?\n\n### 4. Sync and Organize\n\n- **Big Powers Hierarchy**: Place the document in the correct tier (Global -> Project -> Sub-directory). Project READMEs are an exception — they go to project root (`README.md`), not `specs\u002F`.\n- **Nested Indexing**: If adding a module-level doc, ensure the module's `GEMINI.md` is updated. If the module's index is new, add it to the root `GEMINI.md`.\n- **Sync**: Run `scripts\u002Fsync-skills.sh` if the document is a `SKILL.md` or affects generated artifacts.\n\n## Rules\n\n- **Minimalism is a requirement**: If a document can be a 5-line table, do not make it a 5-line essay.\n- **Verifiable outcomes**: Every technical document must include at least one `verify:` command. For architecture, this can be a `grep` or `run_shell_command` that validates the existence of required files or patterns.\n- **No speculative docs**: Do not write documentation for features that do not exist yet unless explicitly doing `elaborate-spec`.\n\n\nSuggest next skill: `audit-code` or `sync-skills.sh`.\n",{"name":5,"model":35,"effort":30,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa","skills\u002Fwrite-document",24,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add danielvm-git\u002Fbigpowers --skill write-document",{"tool":64,"command":65},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill write-document",{"tool":67,"command":68},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill write-document","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"REFERENCE.md","REFERENCE","参考文档",3673,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FREFERENCE.md",[79,98,105,128,149,185],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":88,"publishedAt":44},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,90,91,92,93,94,95,96,97],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"skillNo":99,"name":100,"nameZh":6,"description":6,"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":44},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[104,94],"negative path",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":44},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[112,113,114,115,41,116,117,118,30,31,119,120,121,122,35,123,124,125,126,127],"wire observability","observability","idempotent","project","phase","logging","readiness","development","as","production-readiness","add","instrumentation","commands","scripts","at","structured logging",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":44},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[135,136,113,137,138,139,140,141,30,142,96,143,144,145,146,147,148,35],"ci","wire ci","setup","templates","validation","REST","with","ci pipeline setup","git","workflows","forge","remote","local","pipeline",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":166,"publishedAt":44},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[155,158,163],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":159,"categoryName":160,"taxonomyType":161,"taxonomyTypeDesc":162},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":164,"categoryName":165,"taxonomyType":161,"taxonomyTypeDesc":162},"01JBSEEDCAT000000000000033","数据分析师",[167,168,169,115,170,171,172,173,174,175,176,177,35,178,179,180,181,182,183,184],"visual","visual dashboard","dashboard","project status","http api","architecture","planning","artifacts","http","plans","panel","start","status","release","opencode","plan","browser","api",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":192,"publishedAt":44},"01M71KB0SHK1RE5RW5N7847EB9","verify-work","Multi-phase UAT gate — cold-start smoke, build, typecheck, lint, tests, step-by-step manual verification, gaps-closure loop. Use after execute-plan or develop-tdd, before audit-code.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fverify-work\u002FSKILL.md",[191],{"categoryNo":159,"categoryName":160,"taxonomyType":161,"taxonomyTypeDesc":162},[193,91,194,195,31,196,197,198,199,178,200,201,182,202,116,203,204,205,206,207],"work","verify work","typecheck","tests","manual","smoke","uat","audit","haiku","verification","code","loop","closure","cold-start","cold"]