[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71C6KNCMF9Z6ST5VKY0K0V7":3,"skill-same:01M71C6KNCMF9Z6ST5VKY0K0V7":59},{"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":18,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":14,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":43,"updatedAt":44,"install":45,"resources":58},"01M71C6KNCMF9Z6ST5VKY0K0V7","audit-v2",null,"Execution-based code audit that forces verification through evidence, not assumptions. Replaces superficial structural reviews with functional verification. Every claim must be backed by executed proof.","yqecea\u002Fgem-swarm","yqecea","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F196189405?v=4","01M71C12KWH5QPTE12J69335KF","Yusuf","01M71C12MFS3BRGNE5SSHB4DY9",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Faudit-v2\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32],"audit v2","audit","reviews","evidence","structural","claim","execution","code","assumptions","with","verification","functional","proof","code audit","2026-11-10 10:12:30",false,"---\nname: audit-v2\ndescription: Execution-based code audit that forces verification through evidence, not assumptions. Replaces superficial structural reviews with functional verification. Every claim must be backed by executed proof.\n---\n\n# Audit-v2: Evidence-Based Verification\n\nActivate this skill for any code audit, review, or quality gate where the goal is finding REAL bugs — not commenting on style. This skill supplements `code-review` and `code-review-checklist` by adding mandatory execution-based verification.\n\n## Core Principle\n\n**Reading code is not verification. Running code is verification.**\n\nA review that reads `generate-stubs.js` and says \"looks correct\" is worthless. A review that runs `generate-stubs.js`, checks the output, and says \"website-cloner has 0 tools — parser fails on multi-line YAML\" is useful.\n\n---\n\n## The 5-Layer Methodology\n\nEvery audit MUST execute all 5 layers in order. Skipping a layer requires explicit justification.\n\n### Layer 1: Execution Verification (MANDATORY)\n\n**Rule:** Every claim MUST be backed by a tool invocation that PRODUCED the evidence.\n\nDo not:\n- Say \"build succeeds\" without showing exit code AND checking output content\n- Say \"agent has tools\" without showing the actual tool count for EVERY agent\n- Say \"hook works\" without triggering the hook and verifying the side-effect\n- Say \"tests pass\" without running them and showing results\n\nDo:\n- Run the build. Check the output files contain expected data.\n- Query the registry. Assert every entry has non-empty required fields.\n- Execute the parser with representative inputs. Compare actual vs expected output.\n- Trigger the workflow end-to-end. Verify the final state matches expectations.\n\n**Evidence format:**\n```\n✅ VERIFIED: [claim]\n   Command: [what was executed]\n   Output: [relevant output excerpt]\n   Assertion: [what was checked]\n```\n\n```\n❌ FAILED: [claim]\n   Command: [what was executed]\n   Output: [actual output]\n   Expected: [what should have been]\n   Root cause: [why it failed]\n```\n\n### Layer 2: Edge Case Tracing (MANDATORY)\n\nFor every parser, transformer, generator, or data pipeline in scope:\n\n1. **Identify input format variants.** What are ALL the ways data can be shaped?\n   - Example: YAML tools can be `tools: [a, b, c]` OR multi-line `tools:\\n  - a\\n  - b`\n2. **Feed EACH variant** through the code path (mentally trace or literally execute).\n3. **Report what happens** for each variant — does it produce correct output?\n\nThe question to ask: **\"What's the ONE file\u002Finput that uses a different format than all the others?\"**\n\nThis is what would have caught the website-cloner bug: 19 agents use inline arrays, 1 uses multi-line lists. The parser handles inline. Nobody checked multi-line.\n\n### Layer 3: Output Invariant Checking\n\nDefine success as **assertions on output**, not on process.\n\nBad:\n- \"Registry build is correct\" (how do you know?)\n- \"Hooks are registered\" (registered ≠ functional)\n\nGood:\n- \"EVERY agent in registry has `tools.length > 0`\"\n- \"EVERY hook lifecycle event has a handler AND the handler produces a non-empty side-effect\"\n- \"EVERY stub file contains at least one `  - ` tool entry\"\n\n**Write these assertions. Execute them. Report results.**\n\nWhen possible, add permanent assertions to the build pipeline itself so future builds catch regressions automatically.\n\n### Layer 4: Adversarial Thinking (Architect → Skeptic → Judge)\n\nAfter completing the first 3 layers, switch from verification to attack mode.\n\n**Stage 1 — Architect (Generate hypotheses):**\nFor each critical component, generate 3 failure scenarios:\n- **Conservative:** \"What if the input is slightly malformed?\" (extra whitespace, trailing comma, empty value)\n- **Aggressive:** \"What if the input is completely wrong?\" (missing key, wrong type, corrupted file)\n- **Unconventional:** \"What if everything works but the ASSUMPTION is wrong?\" (parser works but output format changed, build passes but consumer expects different schema)\n\n**Stage 2 — Skeptic (Attack your own findings):**\n- For each Layer 1-3 finding, ask: \"Is this REALLY a problem or am I pattern-matching?\"\n- **Bias check — Confirmation:** \"Am I finding this because I expected to find it?\"\n- **Bias check — Sunk Cost:** \"Am I ignoring this finding because fixing it would invalidate previous work?\"\n- **Bias check — Survivor:** \"Am I only looking at the code that EXISTS? What about the code that SHOULD exist but doesn't?\"\n\n**Stage 3 — Judge (Rate confidence):**\n- For each finding, assign confidence: Low \u002F Medium \u002F High\n- Low confidence findings go to ❓ UNVERIFIED, not 🔴 BLOCKING\n- State what evidence would CHANGE your rating\n\n**The 3 adversarial questions (MANDATORY):**\n1. **\"What assumptions does this code make?\"** — list them, then test each one.\n2. **\"If I were a malicious\u002Funusual input, how would I break this?\"** — try it.\n3. **\"What's the one edge case nobody thought of?\"** — the file that uses a different format, the config that has an empty value, the agent that has no skills.\n\n### Layer 5: Cross-Component Chain Verification\n\nTrace data flow ACROSS components, not just within a single file.\n\n**Pattern: Source → Parser → Output → Consumer → Runtime**\n\nExample from the website-cloner failure:\n```\nwebsite-cloner.md (source)\n  → generate-stubs.js (parser) — FAILED HERE: multi-line YAML not parsed\n  → agents\u002Fwebsite_cloner.md (stub output) — had 0 tools\n  → agent-registry.json (registry) — registered with empty tools array\n  → CLI runtime — agent couldn't use any tools\n```\n\nA review of generate-stubs.js in isolation would say \"looks fine.\" Tracing the CHAIN reveals the break.\n\nFor every audit, identify the data chain and verify EACH link:\n1. Is the source data in the expected format?\n2. Does the parser handle ALL source format variants?\n3. Does the output contain the expected data?\n4. Does the consumer read the output correctly?\n5. Does the runtime behave as expected with this data?\n\n---\n\n## Enforcement: Banned Phrases\n\nThese phrases indicate an unverified claim. If you catch yourself writing one, STOP and verify.\n\n| Banned Phrase | Why | Required Alternative |\n|---|---|---|\n| \"Looks correct\" | No evidence provided | \"Verified by executing X, output was Y\" |\n| \"Should work\" | Speculation, not verification | \"Executed with input X, confirmed output Y\" |\n| \"No issues found\" | Absence of evidence ≠ evidence of absence | \"Tested N scenarios, all produced expected results: [list]\" |\n| \"Build passes\" | exit 0 ≠ correct output | \"Build passes AND output contains [specific assertions]\" |\n| \"Code review complete\" | Reading ≠ verification | \"Reviewed N files, verified M assertions, found K issues\" |\n| \"LGTM\" | Lazy approval with no substance | \"Approved: verified [specific claims] with [specific evidence]\" |\n| \"Seems fine\" | Hedging without checking | \"Confirmed by [method]: [result]\" |\n\n---\n\n## Scope Calibration\n\nInherit from `code-review` skill's calibration rules:\n\n- **New files**: Full 5-layer audit\n- **Modified files (behavior change)**: Layers 1-3 on the diff, Layer 5 on affected chains\n- **Modified files (refactoring)**: Layer 1 (verify same outputs), Layer 3 (assert behavior preserved)\n- **Deleted files**: Layer 5 (verify no broken consumers)\n- **Configuration changes**: Layer 2 (edge cases in config values), Layer 5 (environment chain)\n- **Build\u002Ftooling changes**: ALL 5 layers — this is where the website-cloner bug lived\n\n---\n\n## Severity Classification\n\nUse the 4-tier markers from `code-review-checklist`:\n\n- 🔴 **BLOCKING**: Verified bug, security vulnerability, data loss risk, or broken functionality\n- 🟡 **IMPORTANT**: Verified logic issue, missing validation, or significant maintainability problem\n- 🟢 **SUGGESTION**: Verified improvement opportunity, not a bug\n- ❓ **UNVERIFIED**: Could not verify — needs manual confirmation or additional context\n\n**New category — unique to audit-v2:**\n- ⚫ **SYSTEMIC**: Same root cause appears in 3+ locations. Report once with all affected locations. (From `code-review` deduplication protocol.)\n\n---\n\n## Finding Format\n\nEvery finding uses this structure (adapted from `\u002Faudit_back` Rule ID format):\n\n```\n### [SEVERITY] AV2-NNN: [Title]\n\n**File:** `path\u002Fto\u002Ffile.ext:line`\n**Evidence:**\n  Command: [what was executed or traced]\n  Actual: [what happened]\n  Expected: [what should have happened]\n**Impact:** [what breaks or degrades]\n**Fix:** [concrete remediation]\n**Chain:** [which components are affected downstream] (Layer 5 only)\n```\n\n---\n\n## Quality Gate (Pre-Report Checklist)\n\nBefore finalizing the audit report, run this self-check (from `security-threat-model` step 8):\n\n- [ ] Every finding has file:line evidence\n- [ ] Every \"verified\" claim has an executed command or traced path\n- [ ] No banned phrases remain in the report\n- [ ] Edge case variants were tested, not just the happy path\n- [ ] At least one cross-component chain was traced end-to-end\n- [ ] Systemic findings are deduplicated\n- [ ] The report contains at least one Layer 2 (edge case) check\n- [ ] Output invariants were defined AND checked, not just stated\n\n---\n\n## Report Format\n\n```markdown\n# 🔍 Audit-v2 Report\n\n## Scope\n- Files reviewed: N\n- Assertions executed: M\n- Edge case variants tested: K\n- Chains traced: L\n\n## 🔴 Blocking (N)\n[findings with full evidence]\n\n## 🟡 Important (M)\n[findings with full evidence]\n\n## 🟢 Suggestions (K)\n[findings with evidence]\n\n## ⚫ Systemic Issues (L)\n[deduplicated findings with all affected locations]\n\n## ❓ Unverified (requires manual check)\n[items that could not be verified with available tools]\n\n## ✅ Verified Working\n[things that WERE checked and confirmed correct — with evidence]\n\n## Invariants Checked\n| Invariant | Result | Evidence |\n|-----------|--------|----------|\n| Every agent has tools > 0 | ✅ PASS | Checked N agents |\n| Build output matches expected | ✅ PASS | Compared output hash |\n| ... | ... | ... |\n```\n\n---\n\n## Integration\n\nThis skill supplements, not replaces:\n\n| Existing Skill | What it does | audit-v2 adds |\n|---|---|---|\n| `code-review` | Structural review, scope calibration, deduplication | Execution-based verification (Layers 1-5) |\n| `code-review-checklist` | Static checklist (security, quality, AI patterns) | Dynamic assertion checking |\n| `validation` | Build\u002Flint\u002Ftest gating | Output correctness verification |\n| `security-best-practices` | Framework-specific security patterns | Chain tracing through security boundaries |\n| `security-threat-model` | Trust boundaries, abuse paths | Applied to code correctness, not just security |\n\n## When NOT to use audit-v2\n\n- Single-line typo fixes — use `code-review` alone\n- Style-only changes — use `code-review-checklist` alone\n- Pure documentation changes — overkill\n\n## When to ALWAYS use audit-v2\n\n- Build system or tooling changes (parsers, generators, registries)\n- Agent or skill registration changes\n- Hook modifications\n- Any change that survived a previous audit without being caught\n","# Audit-v2: Evidence-Based Verification\n\nActivate this skill for any code audit, review, or quality gate where the goal is finding REAL bugs — not commenting on style. This skill supplements `code-review` and `code-review-checklist` by adding mandatory execution-based verification.\n\n## Core Principle\n\n**Reading code is not verification. Running code is verification.**\n\nA review that reads `generate-stubs.js` and says \"looks correct\" is worthless. A review that runs `generate-stubs.js`, checks the output, and says \"website-cloner has 0 tools — parser fails on multi-line YAML\" is useful.\n\n---\n\n## The 5-Layer Methodology\n\nEvery audit MUST execute all 5 layers in order. Skipping a layer requires explicit justification.\n\n### Layer 1: Execution Verification (MANDATORY)\n\n**Rule:** Every claim MUST be backed by a tool invocation that PRODUCED the evidence.\n\nDo not:\n- Say \"build succeeds\" without showing exit code AND checking output content\n- Say \"agent has tools\" without showing the actual tool count for EVERY agent\n- Say \"hook works\" without triggering the hook and verifying the side-effect\n- Say \"tests pass\" without running them and showing results\n\nDo:\n- Run the build. Check the output files contain expected data.\n- Query the registry. Assert every entry has non-empty required fields.\n- Execute the parser with representative inputs. Compare actual vs expected output.\n- Trigger the workflow end-to-end. Verify the final state matches expectations.\n\n**Evidence format:**\n```\n✅ VERIFIED: [claim]\n   Command: [what was executed]\n   Output: [relevant output excerpt]\n   Assertion: [what was checked]\n```\n\n```\n❌ FAILED: [claim]\n   Command: [what was executed]\n   Output: [actual output]\n   Expected: [what should have been]\n   Root cause: [why it failed]\n```\n\n### Layer 2: Edge Case Tracing (MANDATORY)\n\nFor every parser, transformer, generator, or data pipeline in scope:\n\n1. **Identify input format variants.** What are ALL the ways data can be shaped?\n   - Example: YAML tools can be `tools: [a, b, c]` OR multi-line `tools:\\n  - a\\n  - b`\n2. **Feed EACH variant** through the code path (mentally trace or literally execute).\n3. **Report what happens** for each variant — does it produce correct output?\n\nThe question to ask: **\"What's the ONE file\u002Finput that uses a different format than all the others?\"**\n\nThis is what would have caught the website-cloner bug: 19 agents use inline arrays, 1 uses multi-line lists. The parser handles inline. Nobody checked multi-line.\n\n### Layer 3: Output Invariant Checking\n\nDefine success as **assertions on output**, not on process.\n\nBad:\n- \"Registry build is correct\" (how do you know?)\n- \"Hooks are registered\" (registered ≠ functional)\n\nGood:\n- \"EVERY agent in registry has `tools.length > 0`\"\n- \"EVERY hook lifecycle event has a handler AND the handler produces a non-empty side-effect\"\n- \"EVERY stub file contains at least one `  - ` tool entry\"\n\n**Write these assertions. Execute them. Report results.**\n\nWhen possible, add permanent assertions to the build pipeline itself so future builds catch regressions automatically.\n\n### Layer 4: Adversarial Thinking (Architect → Skeptic → Judge)\n\nAfter completing the first 3 layers, switch from verification to attack mode.\n\n**Stage 1 — Architect (Generate hypotheses):**\nFor each critical component, generate 3 failure scenarios:\n- **Conservative:** \"What if the input is slightly malformed?\" (extra whitespace, trailing comma, empty value)\n- **Aggressive:** \"What if the input is completely wrong?\" (missing key, wrong type, corrupted file)\n- **Unconventional:** \"What if everything works but the ASSUMPTION is wrong?\" (parser works but output format changed, build passes but consumer expects different schema)\n\n**Stage 2 — Skeptic (Attack your own findings):**\n- For each Layer 1-3 finding, ask: \"Is this REALLY a problem or am I pattern-matching?\"\n- **Bias check — Confirmation:** \"Am I finding this because I expected to find it?\"\n- **Bias check — Sunk Cost:** \"Am I ignoring this finding because fixing it would invalidate previous work?\"\n- **Bias check — Survivor:** \"Am I only looking at the code that EXISTS? What about the code that SHOULD exist but doesn't?\"\n\n**Stage 3 — Judge (Rate confidence):**\n- For each finding, assign confidence: Low \u002F Medium \u002F High\n- Low confidence findings go to ❓ UNVERIFIED, not 🔴 BLOCKING\n- State what evidence would CHANGE your rating\n\n**The 3 adversarial questions (MANDATORY):**\n1. **\"What assumptions does this code make?\"** — list them, then test each one.\n2. **\"If I were a malicious\u002Funusual input, how would I break this?\"** — try it.\n3. **\"What's the one edge case nobody thought of?\"** — the file that uses a different format, the config that has an empty value, the agent that has no skills.\n\n### Layer 5: Cross-Component Chain Verification\n\nTrace data flow ACROSS components, not just within a single file.\n\n**Pattern: Source → Parser → Output → Consumer → Runtime**\n\nExample from the website-cloner failure:\n```\nwebsite-cloner.md (source)\n  → generate-stubs.js (parser) — FAILED HERE: multi-line YAML not parsed\n  → agents\u002Fwebsite_cloner.md (stub output) — had 0 tools\n  → agent-registry.json (registry) — registered with empty tools array\n  → CLI runtime — agent couldn't use any tools\n```\n\nA review of generate-stubs.js in isolation would say \"looks fine.\" Tracing the CHAIN reveals the break.\n\nFor every audit, identify the data chain and verify EACH link:\n1. Is the source data in the expected format?\n2. Does the parser handle ALL source format variants?\n3. Does the output contain the expected data?\n4. Does the consumer read the output correctly?\n5. Does the runtime behave as expected with this data?\n\n---\n\n## Enforcement: Banned Phrases\n\nThese phrases indicate an unverified claim. If you catch yourself writing one, STOP and verify.\n\n| Banned Phrase | Why | Required Alternative |\n|---|---|---|\n| \"Looks correct\" | No evidence provided | \"Verified by executing X, output was Y\" |\n| \"Should work\" | Speculation, not verification | \"Executed with input X, confirmed output Y\" |\n| \"No issues found\" | Absence of evidence ≠ evidence of absence | \"Tested N scenarios, all produced expected results: [list]\" |\n| \"Build passes\" | exit 0 ≠ correct output | \"Build passes AND output contains [specific assertions]\" |\n| \"Code review complete\" | Reading ≠ verification | \"Reviewed N files, verified M assertions, found K issues\" |\n| \"LGTM\" | Lazy approval with no substance | \"Approved: verified [specific claims] with [specific evidence]\" |\n| \"Seems fine\" | Hedging without checking | \"Confirmed by [method]: [result]\" |\n\n---\n\n## Scope Calibration\n\nInherit from `code-review` skill's calibration rules:\n\n- **New files**: Full 5-layer audit\n- **Modified files (behavior change)**: Layers 1-3 on the diff, Layer 5 on affected chains\n- **Modified files (refactoring)**: Layer 1 (verify same outputs), Layer 3 (assert behavior preserved)\n- **Deleted files**: Layer 5 (verify no broken consumers)\n- **Configuration changes**: Layer 2 (edge cases in config values), Layer 5 (environment chain)\n- **Build\u002Ftooling changes**: ALL 5 layers — this is where the website-cloner bug lived\n\n---\n\n## Severity Classification\n\nUse the 4-tier markers from `code-review-checklist`:\n\n- 🔴 **BLOCKING**: Verified bug, security vulnerability, data loss risk, or broken functionality\n- 🟡 **IMPORTANT**: Verified logic issue, missing validation, or significant maintainability problem\n- 🟢 **SUGGESTION**: Verified improvement opportunity, not a bug\n- ❓ **UNVERIFIED**: Could not verify — needs manual confirmation or additional context\n\n**New category — unique to audit-v2:**\n- ⚫ **SYSTEMIC**: Same root cause appears in 3+ locations. Report once with all affected locations. (From `code-review` deduplication protocol.)\n\n---\n\n## Finding Format\n\nEvery finding uses this structure (adapted from `\u002Faudit_back` Rule ID format):\n\n```\n### [SEVERITY] AV2-NNN: [Title]\n\n**File:** `path\u002Fto\u002Ffile.ext:line`\n**Evidence:**\n  Command: [what was executed or traced]\n  Actual: [what happened]\n  Expected: [what should have happened]\n**Impact:** [what breaks or degrades]\n**Fix:** [concrete remediation]\n**Chain:** [which components are affected downstream] (Layer 5 only)\n```\n\n---\n\n## Quality Gate (Pre-Report Checklist)\n\nBefore finalizing the audit report, run this self-check (from `security-threat-model` step 8):\n\n- [ ] Every finding has file:line evidence\n- [ ] Every \"verified\" claim has an executed command or traced path\n- [ ] No banned phrases remain in the report\n- [ ] Edge case variants were tested, not just the happy path\n- [ ] At least one cross-component chain was traced end-to-end\n- [ ] Systemic findings are deduplicated\n- [ ] The report contains at least one Layer 2 (edge case) check\n- [ ] Output invariants were defined AND checked, not just stated\n\n---\n\n## Report Format\n\n```markdown\n# 🔍 Audit-v2 Report\n\n## Scope\n- Files reviewed: N\n- Assertions executed: M\n- Edge case variants tested: K\n- Chains traced: L\n\n## 🔴 Blocking (N)\n[findings with full evidence]\n\n## 🟡 Important (M)\n[findings with full evidence]\n\n## 🟢 Suggestions (K)\n[findings with evidence]\n\n## ⚫ Systemic Issues (L)\n[deduplicated findings with all affected locations]\n\n## ❓ Unverified (requires manual check)\n[items that could not be verified with available tools]\n\n## ✅ Verified Working\n[things that WERE checked and confirmed correct — with evidence]\n\n## Invariants Checked\n| Invariant | Result | Evidence |\n|-----------|--------|----------|\n| Every agent has tools > 0 | ✅ PASS | Checked N agents |\n| Build output matches expected | ✅ PASS | Compared output hash |\n| ... | ... | ... |\n```\n\n---\n\n## Integration\n\nThis skill supplements, not replaces:\n\n| Existing Skill | What it does | audit-v2 adds |\n|---|---|---|\n| `code-review` | Structural review, scope calibration, deduplication | Execution-based verification (Layers 1-5) |\n| `code-review-checklist` | Static checklist (security, quality, AI patterns) | Dynamic assertion checking |\n| `validation` | Build\u002Flint\u002Ftest gating | Output correctness verification |\n| `security-best-practices` | Framework-specific security patterns | Chain tracing through security boundaries |\n| `security-threat-model` | Trust boundaries, abuse paths | Applied to code correctness, not just security |\n\n## When NOT to use audit-v2\n\n- Single-line typo fixes — use `code-review` alone\n- Style-only changes — use `code-review-checklist` alone\n- Pure documentation changes — overkill\n\n## When to ALWAYS use audit-v2\n\n- Build system or tooling changes (parsers, generators, registries)\n- Agent or skill registration changes\n- Hook modifications\n- Any change that survived a previous audit without being caught\n",{"name":5,"description":7},"main","923c514d4d5e15bbfd65ec7eaf949a997679aa3e","src\u002Fskills\u002Fshared\u002Faudit-v2","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm","https:\u002F\u002Fgithub.com\u002Fyqecea","15 y.o Data Science,Student","2026-04-26 20:00:27",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add yqecea\u002Fgem-swarm --skill audit-v2",{"tool":51,"command":52},"bunx","bunx skills add yqecea\u002Fgem-swarm --skill audit-v2",{"tool":54,"command":55},"pnpm","pnpm dlx skills add yqecea\u002Fgem-swarm --skill audit-v2","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Faudit-v2\u002FSKILL.md",true,[],[60,74,88,99,109,134],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":33},"01M71C74XVPP23ST10E8MYJZA0","validation","Cross-cutting validation methodology for verifying phase outputs and project integrity","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fvalidation\u002FSKILL.md",[],[62,67,68,69,70,71,72,73],"validation methodology","for","project","outputs","phase","methodology","integrity",{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":33},"01M71C72PTKRV481M975R3QDDE","session-management","Manages orchestration session state, tracking, and resumption","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fsession-management\u002FSKILL.md",[],[81,82,83,84,85,86,87],"session management","session","management","session state","orchestration","state","tracking",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":33},"01M71C6ZY1EGM4SGVYT4B2HHD7","implementation-planning","Generates detailed implementation plans from finalized designs","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fimplementation-planning\u002FSKILL.md",[],[95,96,97,98],"planning","implementation","implementation planning","plans",{"skillNo":100,"name":25,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":33},"01M71C6XQVGMDFJ50BP5SBDS76","Phase execution methodology for orchestration workflows with error handling and completion protocols","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fexecution\u002FSKILL.md",[],[25,68,72,105,106,85,71,107,108,28],"error","workflows","protocols","error handling",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":125,"publishedAt":33},"01M71C6VY8APWMNK1XEJ3WP7A2","design-dialogue","Guides structured design conversations for complex engineering tasks","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fdesign-dialogue\u002FSKILL.md",[115,120],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[126,127,128,129,130,68,131,132,133],"dialogue","design","design dialogue","guides","conversations","tasks","engineering","structured",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":146,"publishedAt":33},"01M71C6R4RJWG3S2R26778TPD8","delegation","Agent delegation best practices for constructing effective subagent prompts with proper scoping","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fdelegation\u002FSKILL.md",[140,143],{"categoryNo":141,"categoryName":142,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":144,"categoryName":145,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000023","Skill与智能体开发",[136,147,148,68,149,28,150],"subagent","scoping","best practices","prompts"]