[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HRAXPZX0Y7ADTBDV0VTWE":3,"skill-same:01M71HRAXPZX0Y7ADTBDV0VTWE":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},"01M71HRAXPZX0Y7ADTBDV0VTWE","commit-message",null,"Reviews working-tree changes, then drafts a Conventional Commits title\u002Fbody and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release \u002F semver-consistent messaging before git commit.","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\u002F.copilot\u002Fskills\u002Fcommit-message\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],"message","commit message","commit","semver","git","drafts","release","title","haiku","work","notes","code","conventional commits","when","bump","states","messaging","which","reviews","categories","2026-11-10 10:12:30",false,"---\nname: commit-message\nmodel: haiku\ndescription: \"Reviews working-tree changes, then drafts a Conventional Commits title\u002Fbody and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release \u002F semver-consistent messaging before git commit.\"\n---\n\n\u003C!-- story: e82s02 -->\n\n# Commit Message\n> **HARD GATE** — **HARD GATE** — Commits must follow Conventional Commits spec (type(scope): description). Do NOT use vague messages like 'fix' or 'updates.' The message must explain the 'why,' not the 'what.'\n\n\n## Modes\n\n- Default: standard Conventional Commits message\n- --fix-type: Forces type=fix. Use when commit type is unambiguous.\n\n## What \"last chat\" means\n\n- **Primary source of truth:** Read `state.yaml` `vcs.kind`. Git uses `git status`, `git diff`, and `git diff --cached`; Jujutsu uses `jj status`, `jj diff`, and `jj log -r @`. Run in the repo root.\n- **Context:** use the current conversation to summarize *intent* and to spot **breaking** API\u002Fbehavior changes that diff alone may not show.\n- If the user tracks a session baseline (e.g. branch, tag, or `git stash create` at start), you may `git diff \u003Cbaseline>..HEAD` plus uncommitted diffs; otherwise use only the index and working tree.\n\n## Quick workflow\n\n1. **Inventory** — List changed paths; group by feature vs chore vs docs vs test-only.\n2. **Decide commit shape** — One atomic commit is ideal. If the diff mixes unrelated concerns, recommend **multiple commits** (each with its own type\u002Fscope) before suggesting one message.\n3. **Classify for semantic release** — `fix` → patch, `feat` → minor, **breaking** → major.\n4. **Write the message** — `type(optional-scope)!: description` (see [REFERENCE.md](REFERENCE.md#message-format)). Use `!` or a `BREAKING CHANGE:` footer when behavior contracts change.\n5. **Note defensive-code categories touched** — from CONVENTIONS.md: Rate limit | Retry with backoff | Circuit breaker | Timeout | Graceful degradation\n6. **Note fix-ratio contribution** — Each `fix:` commit counts toward `metrics.commit_ratio.fix` in `specs\u002Fstate.yaml`. After `release-branch`, `session-state` recalculates the ratio automatically. A high fix rate (>30%) triggers a deploy + smoke-test suggestion.\n7. **Deliver** — Output:\n   - Proposed **full commit message** (title + optional body + footers).\n   - **Release bump** this commit would drive: `patch` | `minor` | `major` | `none`.\n   - Optional native command: Git `git commit -m`; Jujutsu `jj commit -m`. Never omit `-m` or run destructive commands unless asked.\n\n## Checklist before finalizing\n\n- [ ] **Audit pass confirmed (HARD GATE — Issue #182):** In active epic flow, `bash scripts\u002Flib\u002Fassert-epic-gate.sh commit` passes.\n- [ ] Type matches the **dominant** user-visible outcome (`feat` vs `fix` vs `perf`, etc.).\n- [ ] **Scope** is a short noun in parentheses if it helps (e.g. `fix(api): …`).\n- [ ] Breaking changes are explicit (`!` and\u002For `BREAKING CHANGE:` in the body\u002Ffooter).\n- [ ] Description is imperative, lowercase start after the prefix, no trailing period in the title line.\n- [ ] **NO `Co-authored-by` or `Co-Authored-By` footers** — P1 rule (CONVENTIONS.md § Git Attribution). All commits must appear as if authored solely by the human user. The git hook and `land-branch.sh` both block these.\n\n## When not to invent a bump\n\nIf the repo uses a custom `@semantic-release\u002Fcommit-analyzer` preset, note that your bump is **heuristic** and they should match `.releaserc` \u002F `release.config.*`. See [REFERENCE.md](REFERENCE.md#custom-repositories).\n\n## Further reading\n\n- [REFERENCE.md](REFERENCE.md) — Message shape, footers, release mapping, squashing notes.\n\n\n\n## Handoff\n\nGate: READY -> next: release-branch\nWrites: state.yaml handoff.next_skill = release-branch\n\n---\n\n# Conventional Commits + semantic-style release (reference)\n\n## Message format\n\nFrom [Conventional Commits 1.0.0](https:\u002F\u002Fwww.conventionalcommits.org\u002Fen\u002Fv1.0.0\u002F#specification):\n\n```text\n\u003Ctype>[optional scope][optional !]: \u003Cdescription>\n\n[optional body]\n\n[optional footer(s)]\n```\n\n- **Scope:** parenthesized noun, e.g. `feat(parser): …`.\n- **Breaking:** `!` before `:` (e.g. `feat(api)!: …`) and\u002For footer `BREAKING CHANGE: description` (token must be uppercase per spec for that footer name).\n- **Description:** short summary; body explains *why* or migration steps.\n\nCommon **types** (not exhaustive): `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` — as in [Angular \u002F commitlint conventions](https:\u002F\u002Fgithub.com\u002Fconventional-changelog\u002Fcommitlint).\n\n## Advanced Specification Patterns\n\n### Reverts\nIf the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit. In the body, it should say: `This reverts commit \u003Chash>.`.\n\n```text\nrevert: feat(api): add user endpoint\n\nThis reverts commit 676104e.\n```\n\n### Breaking Changes\nA breaking change can be signaled by:\n1.  A **`BREAKING CHANGE:`** footer (must be uppercase, at the start of the footer). This is the **most compatible** way to trigger a Major release in `semantic-release` (Angular preset).\n2.  A **`!`** after the type\u002Fscope: `feat(api)!: change user response shape`.\n\n**Pro-tip:** For maximum compatibility with all tooling (older and newer), use BOTH the `!` and the `BREAKING CHANGE:` footer.\n\n### Footers (Tokens & Values)\nFooters follow the same `Token: value` pattern as Git Trailers. Common tokens:\n- `Refs: #123`\n- `See-also: docs\u002FADR-001.md`\n- `Signed-off-by: Name \u003Cemail>`\n\n**Multi-line footers:** If a footer value spans multiple lines, each subsequent line must be indented.\n\n### Squashing & History\nWhen using `gh pr merge --squash`, the PR title is usually used as the commit subject. \n- **PR Title:** MUST follow `\u003Ctype>(\u003Cscope>): \u003Cdescription>`\n- **PR Body:** Content will be moved to the commit body.\n\n## Release Type Mapping (Default Angular Preset)\n\nThis table reflects the **out-of-the-box** behavior of `semantic-release` using the `@semantic-release\u002Fcommit-analyzer` default (Angular) rules.\n\n| Commit pattern | Release | Notes |\n|----------------|---------|-------|\n| `fix:` | **Patch** | Bug fixes |\n| `feat:` | **Minor** | New features |\n| `perf:` | **Patch** | Performance improvements |\n| `any type` + `BREAKING CHANGE:` footer | **Major** | **Mandatory** for Major version bumps in default configs. |\n| `any type!:` (exclamation mark) | **Major** | Supported by modern CC parsers, but use footer for max safety. |\n| `docs:`, `chore:`, `test:`, `ci:`, `refactor:`, `style:` | **None** | Does not trigger a new release by default. |\n\n> **Warning:** While `refactor:` and `style:` improve code, they do NOT trigger a release in the default Angular preset. Use `fix:` if a refactor also fixes a bug, or `feat:` if it adds new behavior.\n\n## Custom Repositories\n\n- Read `release.config.js`, `.releaserc`, or `package.json` → `release` \u002F `semantic-release` config.\n- The **@semantic-release\u002Fcommit-analyzer** preset may map types differently; prefer **their** rules when they conflict with this reference.\n\n## Squash and PR titles\n\n- If the team squashes on merge, the **PR title** often becomes the single squashed commit subject — it should still follow `type(scope): description` for tooling.\n- `revert:` type and `Refs:` footers are valid patterns; revert handling varies by [tooling](https:\u002F\u002Fwww.conventionalcommits.org\u002Fen\u002Fv1.0.0\u002F#specification).\n\n## Links\n\n- [Conventional Commits — specification](https:\u002F\u002Fwww.conventionalcommits.org\u002Fen\u002Fv1.0.0\u002F#specification)\n- [semantic-release — README (commit format & flow)](https:\u002F\u002Fgithub.com\u002Fsemantic-release\u002Fsemantic-release#commit-message-format)\n- Automation and docs align with [semantic-release](https:\u002F\u002Fgithub.com\u002Fsemantic-release\u002Fsemantic-release) upstream; a fork may be substituted without changing this guidance.\n","\u003C!-- story: e82s02 -->\n\n# Commit Message\n> **HARD GATE** — **HARD GATE** — Commits must follow Conventional Commits spec (type(scope): description). Do NOT use vague messages like 'fix' or 'updates.' The message must explain the 'why,' not the 'what.'\n\n\n## Modes\n\n- Default: standard Conventional Commits message\n- --fix-type: Forces type=fix. Use when commit type is unambiguous.\n\n## What \"last chat\" means\n\n- **Primary source of truth:** Read `state.yaml` `vcs.kind`. Git uses `git status`, `git diff`, and `git diff --cached`; Jujutsu uses `jj status`, `jj diff`, and `jj log -r @`. Run in the repo root.\n- **Context:** use the current conversation to summarize *intent* and to spot **breaking** API\u002Fbehavior changes that diff alone may not show.\n- If the user tracks a session baseline (e.g. branch, tag, or `git stash create` at start), you may `git diff \u003Cbaseline>..HEAD` plus uncommitted diffs; otherwise use only the index and working tree.\n\n## Quick workflow\n\n1. **Inventory** — List changed paths; group by feature vs chore vs docs vs test-only.\n2. **Decide commit shape** — One atomic commit is ideal. If the diff mixes unrelated concerns, recommend **multiple commits** (each with its own type\u002Fscope) before suggesting one message.\n3. **Classify for semantic release** — `fix` → patch, `feat` → minor, **breaking** → major.\n4. **Write the message** — `type(optional-scope)!: description` (see [REFERENCE.md](REFERENCE.md#message-format)). Use `!` or a `BREAKING CHANGE:` footer when behavior contracts change.\n5. **Note defensive-code categories touched** — from CONVENTIONS.md: Rate limit | Retry with backoff | Circuit breaker | Timeout | Graceful degradation\n6. **Note fix-ratio contribution** — Each `fix:` commit counts toward `metrics.commit_ratio.fix` in `specs\u002Fstate.yaml`. After `release-branch`, `session-state` recalculates the ratio automatically. A high fix rate (>30%) triggers a deploy + smoke-test suggestion.\n7. **Deliver** — Output:\n   - Proposed **full commit message** (title + optional body + footers).\n   - **Release bump** this commit would drive: `patch` | `minor` | `major` | `none`.\n   - Optional native command: Git `git commit -m`; Jujutsu `jj commit -m`. Never omit `-m` or run destructive commands unless asked.\n\n## Checklist before finalizing\n\n- [ ] **Audit pass confirmed (HARD GATE — Issue #182):** In active epic flow, `bash scripts\u002Flib\u002Fassert-epic-gate.sh commit` passes.\n- [ ] Type matches the **dominant** user-visible outcome (`feat` vs `fix` vs `perf`, etc.).\n- [ ] **Scope** is a short noun in parentheses if it helps (e.g. `fix(api): …`).\n- [ ] Breaking changes are explicit (`!` and\u002For `BREAKING CHANGE:` in the body\u002Ffooter).\n- [ ] Description is imperative, lowercase start after the prefix, no trailing period in the title line.\n- [ ] **NO `Co-authored-by` or `Co-Authored-By` footers** — P1 rule (CONVENTIONS.md § Git Attribution). All commits must appear as if authored solely by the human user. The git hook and `land-branch.sh` both block these.\n\n## When not to invent a bump\n\nIf the repo uses a custom `@semantic-release\u002Fcommit-analyzer` preset, note that your bump is **heuristic** and they should match `.releaserc` \u002F `release.config.*`. See [REFERENCE.md](REFERENCE.md#custom-repositories).\n\n## Further reading\n\n- [REFERENCE.md](REFERENCE.md) — Message shape, footers, release mapping, squashing notes.\n\n\n\n## Handoff\n\nGate: READY -> next: release-branch\nWrites: state.yaml handoff.next_skill = release-branch\n\n---\n\n# Conventional Commits + semantic-style release (reference)\n\n## Message format\n\nFrom [Conventional Commits 1.0.0](https:\u002F\u002Fwww.conventionalcommits.org\u002Fen\u002Fv1.0.0\u002F#specification):\n\n```text\n\u003Ctype>[optional scope][optional !]: \u003Cdescription>\n\n[optional body]\n\n[optional footer(s)]\n```\n\n- **Scope:** parenthesized noun, e.g. `feat(parser): …`.\n- **Breaking:** `!` before `:` (e.g. `feat(api)!: …`) and\u002For footer `BREAKING CHANGE: description` (token must be uppercase per spec for that footer name).\n- **Description:** short summary; body explains *why* or migration steps.\n\nCommon **types** (not exhaustive): `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` — as in [Angular \u002F commitlint conventions](https:\u002F\u002Fgithub.com\u002Fconventional-changelog\u002Fcommitlint).\n\n## Advanced Specification Patterns\n\n### Reverts\nIf the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit. In the body, it should say: `This reverts commit \u003Chash>.`.\n\n```text\nrevert: feat(api): add user endpoint\n\nThis reverts commit 676104e.\n```\n\n### Breaking Changes\nA breaking change can be signaled by:\n1.  A **`BREAKING CHANGE:`** footer (must be uppercase, at the start of the footer). This is the **most compatible** way to trigger a Major release in `semantic-release` (Angular preset).\n2.  A **`!`** after the type\u002Fscope: `feat(api)!: change user response shape`.\n\n**Pro-tip:** For maximum compatibility with all tooling (older and newer), use BOTH the `!` and the `BREAKING CHANGE:` footer.\n\n### Footers (Tokens & Values)\nFooters follow the same `Token: value` pattern as Git Trailers. Common tokens:\n- `Refs: #123`\n- `See-also: docs\u002FADR-001.md`\n- `Signed-off-by: Name \u003Cemail>`\n\n**Multi-line footers:** If a footer value spans multiple lines, each subsequent line must be indented.\n\n### Squashing & History\nWhen using `gh pr merge --squash`, the PR title is usually used as the commit subject. \n- **PR Title:** MUST follow `\u003Ctype>(\u003Cscope>): \u003Cdescription>`\n- **PR Body:** Content will be moved to the commit body.\n\n## Release Type Mapping (Default Angular Preset)\n\nThis table reflects the **out-of-the-box** behavior of `semantic-release` using the `@semantic-release\u002Fcommit-analyzer` default (Angular) rules.\n\n| Commit pattern | Release | Notes |\n|----------------|---------|-------|\n| `fix:` | **Patch** | Bug fixes |\n| `feat:` | **Minor** | New features |\n| `perf:` | **Patch** | Performance improvements |\n| `any type` + `BREAKING CHANGE:` footer | **Major** | **Mandatory** for Major version bumps in default configs. |\n| `any type!:` (exclamation mark) | **Major** | Supported by modern CC parsers, but use footer for max safety. |\n| `docs:`, `chore:`, `test:`, `ci:`, `refactor:`, `style:` | **None** | Does not trigger a new release by default. |\n\n> **Warning:** While `refactor:` and `style:` improve code, they do NOT trigger a release in the default Angular preset. Use `fix:` if a refactor also fixes a bug, or `feat:` if it adds new behavior.\n\n## Custom Repositories\n\n- Read `release.config.js`, `.releaserc`, or `package.json` → `release` \u002F `semantic-release` config.\n- The **@semantic-release\u002Fcommit-analyzer** preset may map types differently; prefer **their** rules when they conflict with this reference.\n\n## Squash and PR titles\n\n- If the team squashes on merge, the **PR title** often becomes the single squashed commit subject — it should still follow `type(scope): description` for tooling.\n- `revert:` type and `Refs:` footers are valid patterns; revert handling varies by [tooling](https:\u002F\u002Fwww.conventionalcommits.org\u002Fen\u002Fv1.0.0\u002F#specification).\n\n## Links\n\n- [Conventional Commits — specification](https:\u002F\u002Fwww.conventionalcommits.org\u002Fen\u002Fv1.0.0\u002F#specification)\n- [semantic-release — README (commit format & flow)](https:\u002F\u002Fgithub.com\u002Fsemantic-release\u002Fsemantic-release#commit-message-format)\n- Automation and docs align with [semantic-release](https:\u002F\u002Fgithub.com\u002Fsemantic-release\u002Fsemantic-release) upstream; a fork may be substituted without changing this guidance.\n",{"name":5,"model":32,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".copilot\u002Fskills\u002Fcommit-message",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 commit-message",{"tool":64,"command":65},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill commit-message",{"tool":67,"command":68},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill commit-message","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.copilot\u002Fskills\u002Fcommit-message\u002FSKILL.md",true,[],[73,94,101,130,153,173],{"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":84,"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":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[85,86,87,88,89,90,91,92,93],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"skillNo":95,"name":96,"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":97,"categories":98,"keywords":99,"publishedAt":44},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[100,90],"negative path",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":110,"publishedAt":44},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","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.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000002","文档处理",[111,112,113,114,115,116,117,118,119,120,121,37,122,123,124,125,126,127,128,129],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","use","minimal","bold","sonnet","integrity","organize","sync","directory","guides",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"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",[],[137,138,139,120,140,121,141,142,143,144,124,145,146,147,148,149,150,37,151,152],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"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":159,"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",[],[160,161,162,163,164,165,166,167,168,169,170,120,171,92,137,124,28,172],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","workflows",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":186,"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",[179,182,183],{"categoryNo":180,"categoryName":181,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[187,188,189,190,191,192,193,194,195,124,196,30,197,198,199,200,201,151,202,203],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","opencode","plan","browser","api","architecture","project status","http api"]