[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JDX972AXRHS6Y86SR19DR":3,"skill-same:01M71JDX972AXRHS6Y86SR19DR":81},{"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},"01M71JDX972AXRHS6Y86SR19DR","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.pi\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",".pi\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.pi\u002Fskills\u002Faudit-code\u002FSKILL.md",true,[75],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"HEURISTICS.md","REFERENCE","参考文档",3029,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Faudit-code\u002FHEURISTICS.md",[82,101,108,136,159,180],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":93,"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",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[94,95,96,97,98,99,38,33,100],"fixture","open","verify","skill verify fail open fixture","skill verify","path","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":47},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[107,99],"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":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",[114],{"categoryNo":115,"categoryName":116,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000002","文档处理",[118,119,120,121,122,123,124,125,126,127,30,44,128,129,130,131,132,133,134,135],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","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":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",[],[143,144,145,127,146,30,147,148,149,150,130,151,152,153,154,155,156,44,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":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",[],[166,167,168,169,170,171,172,173,174,175,176,127,177,33,143,130,178,179],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":193,"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",[186,189,190],{"categoryNo":187,"categoryName":188,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":191,"categoryName":192,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[194,195,196,197,198,199,200,201,202,130,203,204,205,206,207,208,209,157,210,211],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","plan","browser","api","architecture","project status","http api"]