[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HYYEHBMC69ED9TACXAB8N":3,"skill-same:01M71HYYEHBMC69ED9TACXAB8N":72},{"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},"01M71HYYEHBMC69ED9TACXAB8N","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",292,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.copilot\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","docs","methodology","high","bmad","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\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\n---\n\n# Project README Template\n\nCombined from dbader\u002Freadme-template and jehna\u002Freadme-best-practices. No TOC.\n\n## Navigation\n\n| Lines | Section |\n|-------|---------|\n| 1 | Title |\n| 5–40 | Navigation |\n| 41–42 | Sections |\n| 43–54 | 1. Title + Badges |\n| 55–60 | 2. Tagline |\n| 61–64 | 3. Description |\n| 65–67 | 4. Prerequisites |\n| 68–75 | Prerequisites |\n| 76–78 | 5. Installation |\n| 79–89 | Installation |\n| 90–92 | 6. Usage |\n| 93–102 | Usage |\n| 103–105 | 7. Features |\n| 106–113 | Features |\n| 114–116 | 8. Configuration |\n| 117–125 | Configuration |\n| 126–128 | 9. Development Setup |\n| 129–139 | Development |\n| 140–142 | 10. Running Tests |\n| 143–152 | Tests |\n| 153–155 | 11. Contributing |\n| 156–164 | Contributing |\n| 165–167 | 12. Changelog |\n| 168–172 | Changelog |\n| 173–175 | 13. Links |\n| 176–181 | Links |\n| 182–184 | 14. License |\n| 185–191 | License |\n| 192–194 | 15. Credits (optional) |\n| 195–199 | Credits |\n| 200–202 | Verify |\n\n## Sections\n\n### 1. Title + Badges\n\n```markdown\n# Project Name\n\n![License](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-MIT-yellow.svg)\n![npm version](https:\u002F\u002Fimg.shields.io\u002Fnpm\u002Fv\u002Fyour-package.svg)\n\n```\n\nFill badges from CLAUDE.md stack info if available. Default to license + version badges.\n\n### 2. Tagline\n\n```markdown\n> One-line description of what this project does and why it matters.\n```\n\n### 3. Description\n\n2-3 paragraphs: what problem it solves, who it's for, and what makes it different.\n\n### 4. Prerequisites\n\n```markdown\n## Prerequisites\n\n- **Runtime**: Node.js v18+ (from CLAUDE.md)\n- **Package manager**: npm (or pnpm\u002Fyarn)\n```\n\nAuto-fill from CLAUDE.md commands section when possible.\n\n### 5. Installation\n\n```markdown\n## Installation\n\n```bash\nnpm install -g your-package\n# or\nnpx your-package\n```\n```\n\nPrefer npx one-shot if applicable; list global install as alternative.\n\n### 6. Usage\n\n```markdown\n## Usage\n\n```bash\nyour-command --help\nyour-command do-something\n```\n```\n\nInclude the most common 1-2 commands. Link to full docs if they exist.\n\n### 7. Features\n\n```markdown\n## Features\n\n- Feature 1: short description\n- Feature 2: short description\n```\n\n3-6 bullet points of what the project does. Derived from the project's purpose.\n\n### 8. Configuration\n\n```markdown\n## Configuration\n\n| Variable | Default | Description |\n|----------|---------|-------------|\n| `VAR_NAME` | `value` | What it controls |\n```\n\nUse `TODO` markers if unknown.\n\n### 9. Development Setup\n\n```markdown\n## Development\n\n```bash\ngit clone \u003Crepo-url>\ncd project\nnpm install\n```\n```\n\nAuto-fill from CLAUDE.md `Run` and `Build` commands.\n\n### 10. Running Tests\n\n```markdown\n## Tests\n\n```bash\nnpm test\nnpm run lint\n```\n```\n\nAuto-fill from CLAUDE.md `Test` and `Lint` commands.\n\n### 11. Contributing\n\n```markdown\n## Contributing\n\n1. Fork the repo.\n2. Create a feature branch (`git checkout -b feature\u002Fmy-thing`).\n3. Commit changes (`git commit -am 'Add my thing'`).\n4. Push (`git push origin feature\u002Fmy-thing`).\n5. Open a Pull Request.\n```\n\n### 12. Changelog\n\n```markdown\n## Changelog\n\nSee [CHANGELOG.md](..\u002F..\u002FCHANGELOG.md) or [Releases](https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo\u002Freleases).\n```\n\n### 13. Links\n\n```markdown\n## Links\n\n- Repository: https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo\n- Issue tracker: https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo\u002Fissues\n```\n\n### 14. License\n\n```markdown\n## License\n\nMIT — see [LICENSE](..\u002F..\u002FLICENSE) for details.\n```\n\nDetect from CLAUDE.md or project LICENSE file.\n\n### 15. Credits (optional)\n\n```markdown\n## Credits\n\nBuilt with [bigpowers](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Fbigpowers).\n```\n\n## Verify\n\nAfter generation, run: `grep -c \"^## \" README.md` — expect ≥ 7 section headings.\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\n---\n\n# Project README Template\n\nCombined from dbader\u002Freadme-template and jehna\u002Freadme-best-practices. No TOC.\n\n## Navigation\n\n| Lines | Section |\n|-------|---------|\n| 1 | Title |\n| 5–40 | Navigation |\n| 41–42 | Sections |\n| 43–54 | 1. Title + Badges |\n| 55–60 | 2. Tagline |\n| 61–64 | 3. Description |\n| 65–67 | 4. Prerequisites |\n| 68–75 | Prerequisites |\n| 76–78 | 5. Installation |\n| 79–89 | Installation |\n| 90–92 | 6. Usage |\n| 93–102 | Usage |\n| 103–105 | 7. Features |\n| 106–113 | Features |\n| 114–116 | 8. Configuration |\n| 117–125 | Configuration |\n| 126–128 | 9. Development Setup |\n| 129–139 | Development |\n| 140–142 | 10. Running Tests |\n| 143–152 | Tests |\n| 153–155 | 11. Contributing |\n| 156–164 | Contributing |\n| 165–167 | 12. Changelog |\n| 168–172 | Changelog |\n| 173–175 | 13. Links |\n| 176–181 | Links |\n| 182–184 | 14. License |\n| 185–191 | License |\n| 192–194 | 15. Credits (optional) |\n| 195–199 | Credits |\n| 200–202 | Verify |\n\n## Sections\n\n### 1. Title + Badges\n\n```markdown\n# Project Name\n\n![License](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-MIT-yellow.svg)\n![npm version](https:\u002F\u002Fimg.shields.io\u002Fnpm\u002Fv\u002Fyour-package.svg)\n\n```\n\nFill badges from CLAUDE.md stack info if available. Default to license + version badges.\n\n### 2. Tagline\n\n```markdown\n> One-line description of what this project does and why it matters.\n```\n\n### 3. Description\n\n2-3 paragraphs: what problem it solves, who it's for, and what makes it different.\n\n### 4. Prerequisites\n\n```markdown\n## Prerequisites\n\n- **Runtime**: Node.js v18+ (from CLAUDE.md)\n- **Package manager**: npm (or pnpm\u002Fyarn)\n```\n\nAuto-fill from CLAUDE.md commands section when possible.\n\n### 5. Installation\n\n```markdown\n## Installation\n\n```bash\nnpm install -g your-package\n# or\nnpx your-package\n```\n```\n\nPrefer npx one-shot if applicable; list global install as alternative.\n\n### 6. Usage\n\n```markdown\n## Usage\n\n```bash\nyour-command --help\nyour-command do-something\n```\n```\n\nInclude the most common 1-2 commands. Link to full docs if they exist.\n\n### 7. Features\n\n```markdown\n## Features\n\n- Feature 1: short description\n- Feature 2: short description\n```\n\n3-6 bullet points of what the project does. Derived from the project's purpose.\n\n### 8. Configuration\n\n```markdown\n## Configuration\n\n| Variable | Default | Description |\n|----------|---------|-------------|\n| `VAR_NAME` | `value` | What it controls |\n```\n\nUse `TODO` markers if unknown.\n\n### 9. Development Setup\n\n```markdown\n## Development\n\n```bash\ngit clone \u003Crepo-url>\ncd project\nnpm install\n```\n```\n\nAuto-fill from CLAUDE.md `Run` and `Build` commands.\n\n### 10. Running Tests\n\n```markdown\n## Tests\n\n```bash\nnpm test\nnpm run lint\n```\n```\n\nAuto-fill from CLAUDE.md `Test` and `Lint` commands.\n\n### 11. Contributing\n\n```markdown\n## Contributing\n\n1. Fork the repo.\n2. Create a feature branch (`git checkout -b feature\u002Fmy-thing`).\n3. Commit changes (`git commit -am 'Add my thing'`).\n4. Push (`git push origin feature\u002Fmy-thing`).\n5. Open a Pull Request.\n```\n\n### 12. Changelog\n\n```markdown\n## Changelog\n\nSee [CHANGELOG.md](..\u002F..\u002FCHANGELOG.md) or [Releases](https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo\u002Freleases).\n```\n\n### 13. Links\n\n```markdown\n## Links\n\n- Repository: https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo\n- Issue tracker: https:\u002F\u002Fgithub.com\u002Fuser\u002Frepo\u002Fissues\n```\n\n### 14. License\n\n```markdown\n## License\n\nMIT — see [LICENSE](..\u002F..\u002FLICENSE) for details.\n```\n\nDetect from CLAUDE.md or project LICENSE file.\n\n### 15. Credits (optional)\n\n```markdown\n## Credits\n\nBuilt with [bigpowers](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Fbigpowers).\n```\n\n## Verify\n\nAfter generation, run: `grep -c \"^## \" README.md` — expect ≥ 7 section headings.\n",{"name":5,"model":35,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".copilot\u002Fskills\u002Fwrite-document",23,"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\u002F.copilot\u002Fskills\u002Fwrite-document\u002FSKILL.md",true,[],[73,92,99,106,129,150],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":82,"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",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[83,84,85,86,87,88,89,90,91],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"skillNo":93,"name":94,"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":95,"categories":96,"keywords":97,"publishedAt":44},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[98,88],"negative path",{"skillNo":100,"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":101,"categories":102,"keywords":104,"publishedAt":44},"01M71KBBGF7Y4EB4AMHBZ8CJFC","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[103],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[26,24,25,42,43,32,28,29,30,105,31,41,33,34,35,36,37,38,39,40],"standard",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"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",[],[113,114,115,105,116,31,117,118,119,120,35,121,122,123,124,125,126,41,127,128],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"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":135,"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",[],[136,137,138,139,140,141,142,143,144,145,146,105,147,90,113,35,148,149],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"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":167,"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",[156,159,164],{"categoryNo":157,"categoryName":158,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":160,"categoryName":161,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":165,"categoryName":166,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000033","数据分析师",[168,169,170,171,172,173,174,175,176,35,177,178,179,180,181,182,183,127,184,185],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","plan","browser","api","architecture","project status","http api"]