[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71J71DMX79G9CXT8743RK4F":3,"skill-same:01M71J71DMX79G9CXT8743RK4F":75},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M71J71DMX79G9CXT8743RK4F","audit-code",null,"Self-review checklist for the coding agent to run before dispatching a reviewer. Checks CONVENTIONS.md compliance, Boy Scout Rule, test coverage, types, and SOLID. Produces a pass\u002Ffail checklist. Use before request-review, before committing, or when user asks for a code quality check.","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\u002F.opencode\u002Fskills\u002Faudit-code\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"audit","audit code","code","use","coding agent","quality check","for","code quality","coding","request","test coverage","run","haiku","self","review","review checklist","reviewer","when","types","coverage","2026-11-10 10:12:30",false,"---\nname: audit-code\nmodel: haiku\ndescription: \"Self-review checklist for the coding agent to run before dispatching a reviewer. Checks CONVENTIONS.md compliance, Boy Scout Rule, test coverage, types, and SOLID. Produces a pass\u002Ffail checklist. Use before request-review, before committing, or when user asks for a code quality check.\"\n---\n\n# Audit Code\n> **HARD GATE** — Audit must check for: bugs (correctness), security, performance, and clarity. Do NOT skip security review if the code touches user data, auth, or external APIs.\n\n## Target (argument)\n\nIf an argument was passed after `\u002Faudit` (e.g. `\u002Faudit abc1234` or `\u002Faudit HEAD~3..HEAD`), use it as the diff target:\n\n```bash\ngit diff \u003Carg>        # range or two-ref form: abc..def, HEAD~3..HEAD\ngit show \u003Carg>        # single commit: abc1234\n```\n\nIf no argument was given, review uncommitted working-tree changes (`git diff` + `git diff --staged`).\n\nRun this self-review before asking anyone else to look at the code. The goal is to catch everything that is clearly wrong or missing — so the reviewer can focus on design and architecture, not hygiene.\n\n**Distinct from `request-review`:** This is the coding agent checking its own work. No second agent is involved. Run this first; run `request-review` after this passes.\n\n## Look-here-first (churn heuristic)\n\nBefore the checklist, rank changed files by git churn and review **high-churn hotspots first** — they carry the most latent risk regardless of diff size.\n\n```bash\nbash scripts\u002Fbp-churn-rank.sh --since 90.days --limit 15\n```\n\nApply the full checklist to churn-ranked files in descending order. Files with zero recent commits but large diffs still get reviewed; churn only sets priority, not scope.\n\n## Modes\n\n- Default: full checklist\n- --quick: Run only Supply Chain and Test Coverage. Use for changes under 50 LOC.\n- --gate: Non-interactive mode for automated CI gating (used by build-epic step 6). Exit with non-zero status code (`exit 1`) on ANY checklist failure; `exit 0` only if ALL items pass. Produces a compact pass\u002Ffail summary to stderr. On failure, list every ✗ item with reason.\n- --parallel: Run checklist sections in **isolated git worktrees** (e45s18) so concurrent checks cannot corrupt each other's working tree:\n\n```bash\nbash scripts\u002Flib\u002Fparallel-review-worktrees.sh audit-code\n```\n\n## Checklist\n\n### Supply Chain & Security\n\n- [ ] slopcheck run for new dependencies; packages tagged in plan-work: `[OK]`, `[SUS]`, or `[SLOP]`\n- [ ] No `[SLOP]` packages without documented human approval\n- [ ] No secrets in diff (`sk-`, `ghp_`, `AKIA`, `.env` values) — see `guard-git` patterns\n- [ ] OWASP Top 10 spot-check: injection, broken auth, sensitive data exposure, misconfiguration (see `docs\u002Freferences\u002Fsecurity-threats.md`)\n- [ ] Security: diff scanned — no unaddressed HIGH findings (or deviations documented in `specs\u002Fsecurity\u002FEXCEPTIONS.md`)\n\n### Provenance & Metadata\n\n- [ ] New plan artefacts include `type:` and `context:` metadata\n- [ ] Implementation steps reference ADR or commit SHA where decisions were made\n\n### Law of Demeter\n\n- [ ] No method chains through unrelated objects (e.g. `a.getB().getC().doX()`)\n- [ ] Collaborators talk to immediate neighbors only; law violations need explicit justification\n\n### CONVENTIONS.md Compliance\n\n- [ ] All output files are in `specs\u002F` (no docs written to project root)\n- [ ] No `gh issue create` calls anywhere in new\u002Fmodified skills or scripts\n- [ ] `gh` used only for PRs and repo clone operations\n- [ ] No GitHub REST API called directly (no curl\u002Ffetch to api.github.com)\n\n### Scope\n\n- [ ] Changes are limited to what was asked — nothing extra refactored or reorganized\n- [ ] No speculative features added\n- [ ] No files touched outside the stated scope\n- [ ] **Discovered defects:** Reproducible gate failures (Preflight, CI, golden suite) require fix-or-log — `quick-fix` or `fix-bug` — even when \"outside\" the story scope. Scope-minimization does not waive Always Green.\n- [ ] Boy Scout Rule applies to files opened to fix a gate failure; it does not excuse skipping red Preflight\n\n### Boy Scout Rule\n\n- [ ] Every file I touched is cleaner than when I found it\n- [ ] No dead code left behind\n- [ ] No commented-out code blocks\n\n### Types and Safety\n\n- [ ] No `any` types introduced (TypeScript) or untyped public functions (Python\u002FGo\u002Fetc.)\n- [ ] No `@ts-ignore` or `\u002F\u002F eslint-disable` added\n- [ ] No `as unknown as X` casts that bypass type safety\n\n### Test Coverage\n\n- [ ] Every new function has at least one test\n- [ ] Every bug fix has a regression test\n- [ ] Tests verify behavior through public interfaces (not implementation details)\n- [ ] Tests are F.I.R.S.T compliant (per CONVENTIONS.md §Tests; use `enforce-first` if unsure)\n\n### SOLID and Heuristics\n\n- [ ] Single Responsibility: no function or module doing two unrelated things\n- [ ] Open\u002FClosed: extended through interfaces, not by modifying stable code\n- [ ] Dependency Inversion: dependencies injected, not imported globally where avoidable\n- [ ] **Chapter 17 Heuristics**: Code is free of smells documented in `audit-code\u002FHEURISTICS.md` (G, N, C, T)\n\n### Refactoring Smells (Fowler)\n\nExplicitly name any detected smells: Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Message Chains, Middle Man.\n\n### Code Style (CONVENTIONS.md)\n\n- [ ] Functions: 4–20 lines; split if longer\n- [ ] Functions: descend exactly one level of abstraction (The Stepdown Rule \u002F G34)\n- [ ] Files: under 300 lines (ideally 200–300)\n- [ ] Names: specific and unique (grep returns \u003C 5 hits for each name)\n- [ ] No duplication — shared logic extracted (DRY \u002F G5)\n- [ ] Early returns over nested ifs; max 2 levels of indentation\n- [ ] Conditionals: expressed as positives (G29)\n- [ ] Comments explain WHY, not WHAT\n\n### Red Flags\n\nBefore reporting, name any rationalization you caught yourself making for skipping a checklist item. Silence is not acceptable — if you skipped an item, state the reason explicitly.\n\n## Output\n\nReport the checklist with ✓ \u002F ✗ per item. For each ✗, describe what needs to be fixed.\n\nIf all items pass: suggest running `request-review` for an independent second opinion.\nIf any items fail: fix them before proceeding.\n\nIn `--gate` mode, print one summary line per checklist section (`PASS Supply Chain` \u002F `FAIL Provenance (2 items)`). Exit `0` only if all PASS. Write full report to `specs\u002Fverifications\u002FAUDIT-\u003Cepic>-\u003Cstory>.md`.\n\n## Verify\n\n→ verify: `test -f CONVENTIONS.md && test -d skills\u002Fenforce-first && test -d skills\u002Frequest-review`\n\n## Handoff\n\nGate: READY -> next: commit-message\nWrites: state.yaml handoff.next_skill = commit-message\n\n\u003C!-- story: e01s02 -->\n\u003C!-- story: e06s03 -->\n\u003C!-- story: e07s01 -->\n\n---\n\n# Clean Code Heuristics (Chapter 17)\n\nA summary of Robert C. Martin's catalogue of code smells and heuristics, used as the technical benchmark for `audit-code`.\n\n## Comments (C)\n- **C1: Inappropriate Information**: Comments should only hold technical notes. Metadata (author, change history) belongs in Git.\n- **C2: Obsolete Comment**: Update or delete comments that are no longer accurate.\n- **C3: Redundant Comment**: Don't describe code that adequately describes itself (e.g., `i++; \u002F\u002F increment i`).\n- **C4: Poorly Written Comment**: If you write a comment, spend time making it the best it can be.\n- **C5: Commented-Out Code**: Delete it. Git remembers it.\n\n## Environment (E)\n- **E1: Build Requires More Than One Step**: Building should be a single trivial operation (e.g., `bash install.sh`).\n- **E2: Tests Require More Than One Step**: Running all tests should be one simple command (e.g., `npm test`).\n\n## Functions (F)\n- **F1: Too Many Arguments**: 0 is ideal, 1-2 is fine, 3 requires special justification. Never > 3.\n- **F2: Output Arguments**: Avoid them. If a function changes state, it should change the state of its owning object.\n- **F3: Flag Arguments**: Boolean arguments are a smell that the function does > 1 thing.\n- **F4: Dead Function**: Discard methods that are never called.\n\n## General (G)\n- **G1: Multiple Languages in One Source File**: Try to minimize the mixing of languages (e.g., HTML inside Java).\n- **G5: Duplication (DRY)**: **The root of all evil.** Every time you see duplication, it's a missed opportunity for abstraction.\n- **G6: Code at Wrong Level of Abstraction**: High-level concepts in base classes; low-level details in derivatives.\n- **G25: Replace Magic Numbers with Named Constants**: No \"naked\" numbers or strings.\n- **G28: Encapsulate Conditionals**: Prefer `if (shouldBePublished())` over complex boolean logic.\n- **G29: Avoid Negative Conditionals**: Prefer `if (buffer.shouldCompact())` over `if (!buffer.shouldNotCompact())`.\n- **G30: Functions Should Do One Thing**: If a function can be split into sections, it's doing too much.\n- **G31: Hidden Temporal Couplings**: If execution order matters, make the dependency explicit via arguments.\n- **G34: Functions Should Descend Only One Level of Abstraction**: The Stepdown Rule.\n\n## Naming (N)\n- **N1: Choose Descriptive Names**: Names should reveal intent and be updated as code evolves.\n- **N4: Unambiguous Names**: Names should make the working of a function\u002Fvariable clear.\n- **N7: Names Should Describe Side-Effects**: Describe everything the function is or does.\n\n## Tests (T)\n- **T1: Insufficient Tests**: A test suite should test everything that could possibly break.\n- **T4: An Ignored Test Is a Question about an Ambiguity**: Document the reason for `@Ignore`.\n- **T5: Test Boundary Conditions**: Most bugs happen at the boundaries; test them exhaustively.\n- **T8: Test Coverage Patterns Can Be Revealing**: Analyze what code is *not* executed to find gaps.\n- **T9: Tests Should Be Fast**: Slow tests don't get run.\n","# Audit Code\n> **HARD GATE** — Audit must check for: bugs (correctness), security, performance, and clarity. Do NOT skip security review if the code touches user data, auth, or external APIs.\n\n## Target (argument)\n\nIf an argument was passed after `\u002Faudit` (e.g. `\u002Faudit abc1234` or `\u002Faudit HEAD~3..HEAD`), use it as the diff target:\n\n```bash\ngit diff \u003Carg>        # range or two-ref form: abc..def, HEAD~3..HEAD\ngit show \u003Carg>        # single commit: abc1234\n```\n\nIf no argument was given, review uncommitted working-tree changes (`git diff` + `git diff --staged`).\n\nRun this self-review before asking anyone else to look at the code. The goal is to catch everything that is clearly wrong or missing — so the reviewer can focus on design and architecture, not hygiene.\n\n**Distinct from `request-review`:** This is the coding agent checking its own work. No second agent is involved. Run this first; run `request-review` after this passes.\n\n## Look-here-first (churn heuristic)\n\nBefore the checklist, rank changed files by git churn and review **high-churn hotspots first** — they carry the most latent risk regardless of diff size.\n\n```bash\nbash scripts\u002Fbp-churn-rank.sh --since 90.days --limit 15\n```\n\nApply the full checklist to churn-ranked files in descending order. Files with zero recent commits but large diffs still get reviewed; churn only sets priority, not scope.\n\n## Modes\n\n- Default: full checklist\n- --quick: Run only Supply Chain and Test Coverage. Use for changes under 50 LOC.\n- --gate: Non-interactive mode for automated CI gating (used by build-epic step 6). Exit with non-zero status code (`exit 1`) on ANY checklist failure; `exit 0` only if ALL items pass. Produces a compact pass\u002Ffail summary to stderr. On failure, list every ✗ item with reason.\n- --parallel: Run checklist sections in **isolated git worktrees** (e45s18) so concurrent checks cannot corrupt each other's working tree:\n\n```bash\nbash scripts\u002Flib\u002Fparallel-review-worktrees.sh audit-code\n```\n\n## Checklist\n\n### Supply Chain & Security\n\n- [ ] slopcheck run for new dependencies; packages tagged in plan-work: `[OK]`, `[SUS]`, or `[SLOP]`\n- [ ] No `[SLOP]` packages without documented human approval\n- [ ] No secrets in diff (`sk-`, `ghp_`, `AKIA`, `.env` values) — see `guard-git` patterns\n- [ ] OWASP Top 10 spot-check: injection, broken auth, sensitive data exposure, misconfiguration (see `docs\u002Freferences\u002Fsecurity-threats.md`)\n- [ ] Security: diff scanned — no unaddressed HIGH findings (or deviations documented in `specs\u002Fsecurity\u002FEXCEPTIONS.md`)\n\n### Provenance & Metadata\n\n- [ ] New plan artefacts include `type:` and `context:` metadata\n- [ ] Implementation steps reference ADR or commit SHA where decisions were made\n\n### Law of Demeter\n\n- [ ] No method chains through unrelated objects (e.g. `a.getB().getC().doX()`)\n- [ ] Collaborators talk to immediate neighbors only; law violations need explicit justification\n\n### CONVENTIONS.md Compliance\n\n- [ ] All output files are in `specs\u002F` (no docs written to project root)\n- [ ] No `gh issue create` calls anywhere in new\u002Fmodified skills or scripts\n- [ ] `gh` used only for PRs and repo clone operations\n- [ ] No GitHub REST API called directly (no curl\u002Ffetch to api.github.com)\n\n### Scope\n\n- [ ] Changes are limited to what was asked — nothing extra refactored or reorganized\n- [ ] No speculative features added\n- [ ] No files touched outside the stated scope\n- [ ] **Discovered defects:** Reproducible gate failures (Preflight, CI, golden suite) require fix-or-log — `quick-fix` or `fix-bug` — even when \"outside\" the story scope. Scope-minimization does not waive Always Green.\n- [ ] Boy Scout Rule applies to files opened to fix a gate failure; it does not excuse skipping red Preflight\n\n### Boy Scout Rule\n\n- [ ] Every file I touched is cleaner than when I found it\n- [ ] No dead code left behind\n- [ ] No commented-out code blocks\n\n### Types and Safety\n\n- [ ] No `any` types introduced (TypeScript) or untyped public functions (Python\u002FGo\u002Fetc.)\n- [ ] No `@ts-ignore` or `\u002F\u002F eslint-disable` added\n- [ ] No `as unknown as X` casts that bypass type safety\n\n### Test Coverage\n\n- [ ] Every new function has at least one test\n- [ ] Every bug fix has a regression test\n- [ ] Tests verify behavior through public interfaces (not implementation details)\n- [ ] Tests are F.I.R.S.T compliant (per CONVENTIONS.md §Tests; use `enforce-first` if unsure)\n\n### SOLID and Heuristics\n\n- [ ] Single Responsibility: no function or module doing two unrelated things\n- [ ] Open\u002FClosed: extended through interfaces, not by modifying stable code\n- [ ] Dependency Inversion: dependencies injected, not imported globally where avoidable\n- [ ] **Chapter 17 Heuristics**: Code is free of smells documented in `audit-code\u002FHEURISTICS.md` (G, N, C, T)\n\n### Refactoring Smells (Fowler)\n\nExplicitly name any detected smells: Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Message Chains, Middle Man.\n\n### Code Style (CONVENTIONS.md)\n\n- [ ] Functions: 4–20 lines; split if longer\n- [ ] Functions: descend exactly one level of abstraction (The Stepdown Rule \u002F G34)\n- [ ] Files: under 300 lines (ideally 200–300)\n- [ ] Names: specific and unique (grep returns \u003C 5 hits for each name)\n- [ ] No duplication — shared logic extracted (DRY \u002F G5)\n- [ ] Early returns over nested ifs; max 2 levels of indentation\n- [ ] Conditionals: expressed as positives (G29)\n- [ ] Comments explain WHY, not WHAT\n\n### Red Flags\n\nBefore reporting, name any rationalization you caught yourself making for skipping a checklist item. Silence is not acceptable — if you skipped an item, state the reason explicitly.\n\n## Output\n\nReport the checklist with ✓ \u002F ✗ per item. For each ✗, describe what needs to be fixed.\n\nIf all items pass: suggest running `request-review` for an independent second opinion.\nIf any items fail: fix them before proceeding.\n\nIn `--gate` mode, print one summary line per checklist section (`PASS Supply Chain` \u002F `FAIL Provenance (2 items)`). Exit `0` only if all PASS. Write full report to `specs\u002Fverifications\u002FAUDIT-\u003Cepic>-\u003Cstory>.md`.\n\n## Verify\n\n→ verify: `test -f CONVENTIONS.md && test -d skills\u002Fenforce-first && test -d skills\u002Frequest-review`\n\n## Handoff\n\nGate: READY -> next: commit-message\nWrites: state.yaml handoff.next_skill = commit-message\n\n\u003C!-- story: e01s02 -->\n\u003C!-- story: e06s03 -->\n\u003C!-- story: e07s01 -->\n\n---\n\n# Clean Code Heuristics (Chapter 17)\n\nA summary of Robert C. Martin's catalogue of code smells and heuristics, used as the technical benchmark for `audit-code`.\n\n## Comments (C)\n- **C1: Inappropriate Information**: Comments should only hold technical notes. Metadata (author, change history) belongs in Git.\n- **C2: Obsolete Comment**: Update or delete comments that are no longer accurate.\n- **C3: Redundant Comment**: Don't describe code that adequately describes itself (e.g., `i++; \u002F\u002F increment i`).\n- **C4: Poorly Written Comment**: If you write a comment, spend time making it the best it can be.\n- **C5: Commented-Out Code**: Delete it. Git remembers it.\n\n## Environment (E)\n- **E1: Build Requires More Than One Step**: Building should be a single trivial operation (e.g., `bash install.sh`).\n- **E2: Tests Require More Than One Step**: Running all tests should be one simple command (e.g., `npm test`).\n\n## Functions (F)\n- **F1: Too Many Arguments**: 0 is ideal, 1-2 is fine, 3 requires special justification. Never > 3.\n- **F2: Output Arguments**: Avoid them. If a function changes state, it should change the state of its owning object.\n- **F3: Flag Arguments**: Boolean arguments are a smell that the function does > 1 thing.\n- **F4: Dead Function**: Discard methods that are never called.\n\n## General (G)\n- **G1: Multiple Languages in One Source File**: Try to minimize the mixing of languages (e.g., HTML inside Java).\n- **G5: Duplication (DRY)**: **The root of all evil.** Every time you see duplication, it's a missed opportunity for abstraction.\n- **G6: Code at Wrong Level of Abstraction**: High-level concepts in base classes; low-level details in derivatives.\n- **G25: Replace Magic Numbers with Named Constants**: No \"naked\" numbers or strings.\n- **G28: Encapsulate Conditionals**: Prefer `if (shouldBePublished())` over complex boolean logic.\n- **G29: Avoid Negative Conditionals**: Prefer `if (buffer.shouldCompact())` over `if (!buffer.shouldNotCompact())`.\n- **G30: Functions Should Do One Thing**: If a function can be split into sections, it's doing too much.\n- **G31: Hidden Temporal Couplings**: If execution order matters, make the dependency explicit via arguments.\n- **G34: Functions Should Descend Only One Level of Abstraction**: The Stepdown Rule.\n\n## Naming (N)\n- **N1: Choose Descriptive Names**: Names should reveal intent and be updated as code evolves.\n- **N4: Unambiguous Names**: Names should make the working of a function\u002Fvariable clear.\n- **N7: Names Should Describe Side-Effects**: Describe everything the function is or does.\n\n## Tests (T)\n- **T1: Insufficient Tests**: A test suite should test everything that could possibly break.\n- **T4: An Ignored Test Is a Question about an Ambiguity**: Document the reason for `@Ignore`.\n- **T5: Test Boundary Conditions**: Most bugs happen at the boundaries; test them exhaustively.\n- **T8: Test Coverage Patterns Can Be Revealing**: Analyze what code is *not* executed to find gaps.\n- **T9: Tests Should Be Fast**: Slow tests don't get run.\n",{"name":5,"model":39,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".opencode\u002Fskills\u002Faudit-code",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":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add danielvm-git\u002Fbigpowers --skill audit-code",{"tool":67,"command":68},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill audit-code",{"tool":70,"command":71},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill audit-code","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.opencode\u002Fskills\u002Faudit-code\u002FSKILL.md",true,[],[76,95,102,130,153,174],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":87,"publishedAt":47},"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",[82],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[88,89,90,91,92,93,38,33,94],"fixture","open","verify","skill verify fail open fixture","skill verify","path","never",{"skillNo":96,"name":97,"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":98,"categories":99,"keywords":100,"publishedAt":47},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[101,93],"negative path",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":111,"publishedAt":47},"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",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000002","文档处理",[112,113,114,115,116,117,118,119,120,121,30,44,122,123,124,125,126,127,128,129],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","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":47},"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,121,140,30,141,142,143,144,124,145,146,147,148,149,150,44,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":47},"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,121,171,33,137,124,172,173],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":187,"publishedAt":47},"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",[180,183,184],{"categoryNo":181,"categoryName":182,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[188,189,190,191,192,193,194,195,196,124,197,198,199,200,201,202,203,151,204,205],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","plan","browser","api","architecture","project status","http api"]