[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71K4ZW2C11MDCHESBBZX7T0":3,"skill-same:01M71K4ZW2C11MDCHESBBZX7T0":79},{"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":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M71K4ZW2C11MDCHESBBZX7T0","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",290,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\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\neffort: standard\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","\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",{"name":5,"model":32,"effort":49,"description":7},"standard","main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa","skills\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":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add danielvm-git\u002Fbigpowers --skill commit-message",{"tool":65,"command":66},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill commit-message",{"tool":68,"command":69},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill commit-message","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fcommit-message\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"REFERENCE.md","REFERENCE","参考文档",4054,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fcommit-message\u002FREFERENCE.md",[80,101,108,136,159,179],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":91,"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",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[92,93,94,95,96,97,98,99,100],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"skillNo":102,"name":103,"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":104,"categories":105,"keywords":106,"publishedAt":44},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[107,97],"negative path",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":117,"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",[114],{"categoryNo":115,"categoryName":116,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000002","文档处理",[118,119,120,121,122,123,124,125,126,49,127,37,128,129,130,131,132,133,134,135],"write","write document","document","documents","actionable","technical","methodology","high","bmad","use","minimal","bold","sonnet","integrity","organize","sync","directory","guides",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"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",[],[143,144,145,49,146,127,147,148,149,150,130,151,152,153,154,155,156,37,157,158],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"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",[],[166,167,168,169,170,171,172,173,174,175,176,49,177,99,143,130,28,178],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","workflows",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":192,"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",[185,188,189],{"categoryNo":186,"categoryName":187,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":190,"categoryName":191,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[193,194,195,196,197,198,199,200,201,130,202,30,203,204,205,206,207,157,208,209],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","opencode","plan","browser","api","architecture","project status","http api"]