[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XD893B3WH7G2TPAG3EMEDD":3,"skill-same:01M6XD893B3WH7G2TPAG3EMEDD":73},{"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":52,"commitSha":53,"skillDirectory":54,"forksCount":14,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6XD893B3WH7G2TPAG3EMEDD","veracity-audit",null,"Audit a data pipeline for Veracity and Value. Dispatches data-scientist, compliance-auditor, and data-engineer agents with project context injected at dispatch time. All source paths are supplied via flags — no defaults, no project assumptions. Subcommands: audit (full pipeline walk), score-check (scoring math only), gate-check (gate coverage only), source-trace \u003Clabel> (single source end-to-end). Invoke when: \"audit pipeline\", \"veracity check\", \"scoring math correct?\", \"check gates\", \"trace source\", \"verify quality gates\", \"formula correct?\".","kaiohenricunha\u002Fdotbabel","kaiohenricunha","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F69804490?v=4","01M6XCZD37W0KPCDGEA40Y610V","Kaio Cunha","01M6XCZD7SX714D114H3ZPNW09",0,"MIT","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fexamples\u002Fminimal-consumer\u002F.claude\u002Fskills\u002Fveracity-audit\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"veracity audit","audit","formula","when","invoke","at","paths","end","project","time","scoring","config","engineer","only","coverage","read","math","Bash","pipeline","data pipeline","2026-11-10 10:12:30",false,"---\n# dotbabel:generated projection=sha256:4acf71d62231a825bc4e3b0ed8d80a0908e3591ececce6010044f7ff4e6ed9f8 source=skills\u002Fveracity-audit\u002FSKILL.md — do not edit directly\nallowed-tools: Read Grep Glob Bash Agent\nargument-hint: audit | score-check | gate-check | source-trace \u003Clabel> --config \u003Cpath> --quality-config \u003Cpath> --pipeline-dir \u003Cpath> --scoring-dir \u003Cpath>\ndescription: |\n  Audit a data pipeline for Veracity and Value. Dispatches data-scientist, compliance-auditor, and data-engineer agents with project context injected at dispatch time. All source paths are supplied via flags — no defaults, no project assumptions. Subcommands: audit (full pipeline walk), score-check (scoring math only), gate-check (gate coverage only), source-trace \u003Clabel> (single source end-to-end). Invoke when: \"audit pipeline\", \"veracity check\", \"scoring math correct?\", \"check gates\", \"trace source\", \"verify quality gates\", \"formula correct?\".\nname: veracity-audit\n---\n\n# Veracity Audit\n\nOrchestrating audit skill for data pipelines. Dispatches specialized sub-agents\n(`data-scientist`, `compliance-auditor`, `data-engineer`) with project context\ninjected at dispatch time. Produces inline findings; `--save` writes to `docs\u002Faudits\u002F`.\n\n**Covers:**\n\n- **Veracity** — source reliability, scoring math integrity, quality gate completeness\n- **Value** — primary score vs. legacy output correctness, blend-config wiring\n\n---\n\n## Required Arguments\n\nAll paths must be provided explicitly. The skill has no built-in defaults.\n\n| Flag                      | Required                  | Description                                                     |\n| ------------------------- | ------------------------- | --------------------------------------------------------------- |\n| `--config \u003Cpath>`         | yes (score-check, audit)  | Scoring\u002Frating config file (YAML or JSON)                       |\n| `--quality-config \u003Cpath>` | yes (gate-check, audit)   | Data quality gate declarations file                             |\n| `--pipeline-dir \u003Cpath>`   | yes (audit, source-trace) | Directory containing pipeline step source files                 |\n| `--scoring-dir \u003Cpath>`    | yes (score-check, audit)  | Directory containing scoring\u002Fmath source files                  |\n| `--save`                  | no                        | Write findings to `docs\u002Faudits\u002Fveracity-\u003CYYYY-MM-DD>.md`        |\n| `--since \u003Cspec>`          | no, gate-check only       | Focus on checks added within this window (e.g. `\"30 days ago\"`) |\n\nIf a required flag is missing, print which flags are needed and halt.\n\n---\n\n## Pre-flight (always runs first)\n\nConfirm the three required agents are installed:\n\n```\n~\u002F.claude\u002Fagents\u002Fdata-engineer.md\n~\u002F.claude\u002Fagents\u002Fdata-scientist.md\n~\u002F.claude\u002Fagents\u002Fcompliance-auditor.md\n```\n\nIf any are missing, halt:\n\n```\nMissing agent(s): \u003Clist>\nRun: dotbabel bootstrap\nThen re-invoke this skill.\n```\n\n---\n\n## Subcommand: `audit`\n\nFull pipeline walk. Dispatches three agents in parallel, then synthesizes.\n\n**Required flags:** `--config`, `--quality-config`, `--pipeline-dir`, `--scoring-dir`\n\n### Step 1 — Read shared context\n\nRead both config files in full. Retain their content to inject as a preamble into every agent prompt so all agents share the same source of truth.\n\n### Step 2 — Dispatch three agents in parallel\n\n#### Agent: data-engineer\n\n```\nTask: Audit source reliability across all pipeline steps.\nScope: \u003C--pipeline-dir> (all step\u002Fstage source files), provider or adapter directories nearby\nPreamble: [inject --config and --quality-config content]\nChecks:\n  - Ingestion steps: how are missing\u002Fnull entity IDs handled? What happens on HTTP 429\u002F503?\n  - Time-windowed queries: is the cutoff calendar or epoch-based? Any timezone assumptions?\n  - For each external source: schema version check? Fallback when unavailable? IDs validated before use?\n  - Last-resort fallback case: when does it trigger silently vs. with a logged warning?\nOutput: P0\u002FP1\u002FP2 findings table per source, file:line.\n  P0 = data loss\u002Fcorruption, P1 = reliability gap, P2 = efficiency improvement.\nConstraints: read-only\n```\n\n#### Agent: data-scientist\n\n```\nTask: Validate scoring math integrity.\nScope: \u003C--scoring-dir> (rating\u002Fmath source files), \u003C--pipeline-dir> (transform and aggregation steps)\nPreamble: [inject --config content in full]\nChecks:\n  - Tier\u002Fexponent selection: boundary conditions match config exactly (strict vs. loose comparisons).\n  - Core adjustment formula: matches declared mathematical intent.\n  - Credibility-weighting formula: trust horizon, curve shape, and [0,1] clamp.\n  - Multi-source cap: applied in the correct order relative to other adjustments; cite the line.\n  - Fallback case chain: for each case, state trigger condition, rating produced, and whether output\n    is bounded to a sane range. Flag any case that can produce an out-of-range value.\n  - Empty-collection edge case in aggregation: division-by-zero risk?\n  - Primary score vs. legacy output: does any export path still apply a scale conversion\n    (e.g. ×10 or \u002F10) from the old output range? Grep service, export, and handler files.\nOutput: math integrity table (Formula | Expected | Code Behavior | Verdict | File:Line).\n  Verdict: PASS \u002F FAIL \u002F AMBIGUOUS. FAIL entries include a one-line fix.\nConstraints: read-only\n```\n\n#### Agent: compliance-auditor\n\n```\nTask: Gate completeness — coverage matrix of --quality-config declarations vs. enforcement code.\nScope: \u003C--quality-config>, \u003C--pipeline-dir> (gate\u002Fvalidation step), \u003C--scoring-dir> (gate helpers)\nPreamble: [inject both config file contents]\nChecks:\n  - Build coverage matrix for all named checks in quality config.\n  - Flag DECLARED-NOT-ENFORCED (CRITICAL) and ENFORCED-NOT-DECLARED (WARNING).\n  - Per-entity gate function: verify it is called for every entity in every run\n    (trace call site in pipeline gate step, not just in unit tests).\n  - Gate outcome persistence: verify pass\u002Ffail and reason are written to a durable store.\n  - Threshold mismatch: compare threshold values in quality config vs. hardcoded literals in gate step.\n  - Test coverage: flag any check with no corresponding test in the gate test file.\nOutput: coverage matrix (Check | Declared | Enforced | Blocking | Threshold Match | Test | File:Line)\n  + gap list (Severity | Gap Type | Check Name | Detail | File:Line).\nConstraints: read-only\n```\n\n### Step 3 — Synthesize\n\n1. Deduplicate findings that share the same `file:line`.\n2. Assign the highest severity from any agent that flagged the same location.\n3. Output:\n\n```\n## Source Reliability\n[data-engineer P0\u002FP1\u002FP2 table]\n\n## Scoring Math\n[data-scientist PASS\u002FFAIL\u002FAMBIGUOUS table]\n\n## Gate Coverage\n[compliance-auditor matrix + gap list]\n\n## Summary\nN CRITICAL · N WARNING · N INFO\nTop action: \u003Chighest-severity finding's recommended fix>\n```\n\nIf `--save`: write to `docs\u002Faudits\u002Fveracity-\u003CYYYY-MM-DD>.md`.\n\n---\n\n## Subcommand: `score-check`\n\n**Required flags:** `--config`, `--scoring-dir`\n\n1. Read `--config` in full.\n2. Dispatch `data-scientist` with Agent B spec above, config injected as preamble.\n3. Output the math integrity table directly — no synthesis.\n\n---\n\n## Subcommand: `gate-check`\n\n**Required flags:** `--quality-config`, `--pipeline-dir`\n\n1. Read `--quality-config` and the pipeline gate step files in full.\n2. If `--since` is present:\n   - Run: `git log --since=\"\u003Cvalue>\" --oneline -- \u003C--quality-config>`\n   - Extract check names added in recent commits.\n   - Prepend to agent prompt: \"Focus on these recently added checks: `[check-names]`. Verify each has enforcement AND a test.\"\n3. Dispatch `compliance-auditor` with Agent C spec above.\n4. Output coverage matrix and gap list directly — no synthesis.\n\n---\n\n## Subcommand: `source-trace \u003Clabel>`\n\n**Required flags:** `--pipeline-dir`, `--config`\n\n1. Require one positional argument: the source label to trace. If missing, grep `--pipeline-dir` for provider\u002Fadapter import names and print a list, then halt.\n2. Build a targeted file list by grepping `--pipeline-dir` and nearby adapter\u002Fservice directories for the label.\n3. Dispatch `data-engineer`:\n   ```\n   Task: Trace \u003Clabel> end-to-end through the pipeline.\n   Scope: [targeted file list] + --config for scoring context\n   For each file:\n     (a) Where does this source's data enter?\n     (b) What schema fields are consumed?\n     (c) What happens when the source returns stale, null, or out-of-schema data?\n     (d) Is the source ID space validated against a reference set before use?\n     (e) What is the downstream scoring impact if this source fails silently?\n   Output: Stage | File:Line | Fields consumed | Failure mode | Mitigation (Y\u002FN).\n   Constraints: read-only\n   ```\n\n---\n\n## Key Principles\n\n1. **Audit, don't fix.** Findings only — let the user decide what to act on.\n2. **Inject context.** Always read and inject the config files into agent prompts. Never let agents re-read them independently — shared preamble is the source of truth.\n3. **Parallel where independent.** `audit` runs three agents concurrently; the other subcommands are single-agent.\n4. **Evidence before verdict.** Every FAIL\u002FCRITICAL must cite `file:line`. AMBIGUOUS is a valid verdict — do not guess.\n5. **No project assumptions.** All paths come from flags. The skill works for any pipeline that has a scoring config, a quality gate config, and a multi-step pipeline directory.\n","# Veracity Audit\n\nOrchestrating audit skill for data pipelines. Dispatches specialized sub-agents\n(`data-scientist`, `compliance-auditor`, `data-engineer`) with project context\ninjected at dispatch time. Produces inline findings; `--save` writes to `docs\u002Faudits\u002F`.\n\n**Covers:**\n\n- **Veracity** — source reliability, scoring math integrity, quality gate completeness\n- **Value** — primary score vs. legacy output correctness, blend-config wiring\n\n---\n\n## Required Arguments\n\nAll paths must be provided explicitly. The skill has no built-in defaults.\n\n| Flag                      | Required                  | Description                                                     |\n| ------------------------- | ------------------------- | --------------------------------------------------------------- |\n| `--config \u003Cpath>`         | yes (score-check, audit)  | Scoring\u002Frating config file (YAML or JSON)                       |\n| `--quality-config \u003Cpath>` | yes (gate-check, audit)   | Data quality gate declarations file                             |\n| `--pipeline-dir \u003Cpath>`   | yes (audit, source-trace) | Directory containing pipeline step source files                 |\n| `--scoring-dir \u003Cpath>`    | yes (score-check, audit)  | Directory containing scoring\u002Fmath source files                  |\n| `--save`                  | no                        | Write findings to `docs\u002Faudits\u002Fveracity-\u003CYYYY-MM-DD>.md`        |\n| `--since \u003Cspec>`          | no, gate-check only       | Focus on checks added within this window (e.g. `\"30 days ago\"`) |\n\nIf a required flag is missing, print which flags are needed and halt.\n\n---\n\n## Pre-flight (always runs first)\n\nConfirm the three required agents are installed:\n\n```\n~\u002F.claude\u002Fagents\u002Fdata-engineer.md\n~\u002F.claude\u002Fagents\u002Fdata-scientist.md\n~\u002F.claude\u002Fagents\u002Fcompliance-auditor.md\n```\n\nIf any are missing, halt:\n\n```\nMissing agent(s): \u003Clist>\nRun: dotbabel bootstrap\nThen re-invoke this skill.\n```\n\n---\n\n## Subcommand: `audit`\n\nFull pipeline walk. Dispatches three agents in parallel, then synthesizes.\n\n**Required flags:** `--config`, `--quality-config`, `--pipeline-dir`, `--scoring-dir`\n\n### Step 1 — Read shared context\n\nRead both config files in full. Retain their content to inject as a preamble into every agent prompt so all agents share the same source of truth.\n\n### Step 2 — Dispatch three agents in parallel\n\n#### Agent: data-engineer\n\n```\nTask: Audit source reliability across all pipeline steps.\nScope: \u003C--pipeline-dir> (all step\u002Fstage source files), provider or adapter directories nearby\nPreamble: [inject --config and --quality-config content]\nChecks:\n  - Ingestion steps: how are missing\u002Fnull entity IDs handled? What happens on HTTP 429\u002F503?\n  - Time-windowed queries: is the cutoff calendar or epoch-based? Any timezone assumptions?\n  - For each external source: schema version check? Fallback when unavailable? IDs validated before use?\n  - Last-resort fallback case: when does it trigger silently vs. with a logged warning?\nOutput: P0\u002FP1\u002FP2 findings table per source, file:line.\n  P0 = data loss\u002Fcorruption, P1 = reliability gap, P2 = efficiency improvement.\nConstraints: read-only\n```\n\n#### Agent: data-scientist\n\n```\nTask: Validate scoring math integrity.\nScope: \u003C--scoring-dir> (rating\u002Fmath source files), \u003C--pipeline-dir> (transform and aggregation steps)\nPreamble: [inject --config content in full]\nChecks:\n  - Tier\u002Fexponent selection: boundary conditions match config exactly (strict vs. loose comparisons).\n  - Core adjustment formula: matches declared mathematical intent.\n  - Credibility-weighting formula: trust horizon, curve shape, and [0,1] clamp.\n  - Multi-source cap: applied in the correct order relative to other adjustments; cite the line.\n  - Fallback case chain: for each case, state trigger condition, rating produced, and whether output\n    is bounded to a sane range. Flag any case that can produce an out-of-range value.\n  - Empty-collection edge case in aggregation: division-by-zero risk?\n  - Primary score vs. legacy output: does any export path still apply a scale conversion\n    (e.g. ×10 or \u002F10) from the old output range? Grep service, export, and handler files.\nOutput: math integrity table (Formula | Expected | Code Behavior | Verdict | File:Line).\n  Verdict: PASS \u002F FAIL \u002F AMBIGUOUS. FAIL entries include a one-line fix.\nConstraints: read-only\n```\n\n#### Agent: compliance-auditor\n\n```\nTask: Gate completeness — coverage matrix of --quality-config declarations vs. enforcement code.\nScope: \u003C--quality-config>, \u003C--pipeline-dir> (gate\u002Fvalidation step), \u003C--scoring-dir> (gate helpers)\nPreamble: [inject both config file contents]\nChecks:\n  - Build coverage matrix for all named checks in quality config.\n  - Flag DECLARED-NOT-ENFORCED (CRITICAL) and ENFORCED-NOT-DECLARED (WARNING).\n  - Per-entity gate function: verify it is called for every entity in every run\n    (trace call site in pipeline gate step, not just in unit tests).\n  - Gate outcome persistence: verify pass\u002Ffail and reason are written to a durable store.\n  - Threshold mismatch: compare threshold values in quality config vs. hardcoded literals in gate step.\n  - Test coverage: flag any check with no corresponding test in the gate test file.\nOutput: coverage matrix (Check | Declared | Enforced | Blocking | Threshold Match | Test | File:Line)\n  + gap list (Severity | Gap Type | Check Name | Detail | File:Line).\nConstraints: read-only\n```\n\n### Step 3 — Synthesize\n\n1. Deduplicate findings that share the same `file:line`.\n2. Assign the highest severity from any agent that flagged the same location.\n3. Output:\n\n```\n## Source Reliability\n[data-engineer P0\u002FP1\u002FP2 table]\n\n## Scoring Math\n[data-scientist PASS\u002FFAIL\u002FAMBIGUOUS table]\n\n## Gate Coverage\n[compliance-auditor matrix + gap list]\n\n## Summary\nN CRITICAL · N WARNING · N INFO\nTop action: \u003Chighest-severity finding's recommended fix>\n```\n\nIf `--save`: write to `docs\u002Faudits\u002Fveracity-\u003CYYYY-MM-DD>.md`.\n\n---\n\n## Subcommand: `score-check`\n\n**Required flags:** `--config`, `--scoring-dir`\n\n1. Read `--config` in full.\n2. Dispatch `data-scientist` with Agent B spec above, config injected as preamble.\n3. Output the math integrity table directly — no synthesis.\n\n---\n\n## Subcommand: `gate-check`\n\n**Required flags:** `--quality-config`, `--pipeline-dir`\n\n1. Read `--quality-config` and the pipeline gate step files in full.\n2. If `--since` is present:\n   - Run: `git log --since=\"\u003Cvalue>\" --oneline -- \u003C--quality-config>`\n   - Extract check names added in recent commits.\n   - Prepend to agent prompt: \"Focus on these recently added checks: `[check-names]`. Verify each has enforcement AND a test.\"\n3. Dispatch `compliance-auditor` with Agent C spec above.\n4. Output coverage matrix and gap list directly — no synthesis.\n\n---\n\n## Subcommand: `source-trace \u003Clabel>`\n\n**Required flags:** `--pipeline-dir`, `--config`\n\n1. Require one positional argument: the source label to trace. If missing, grep `--pipeline-dir` for provider\u002Fadapter import names and print a list, then halt.\n2. Build a targeted file list by grepping `--pipeline-dir` and nearby adapter\u002Fservice directories for the label.\n3. Dispatch `data-engineer`:\n   ```\n   Task: Trace \u003Clabel> end-to-end through the pipeline.\n   Scope: [targeted file list] + --config for scoring context\n   For each file:\n     (a) Where does this source's data enter?\n     (b) What schema fields are consumed?\n     (c) What happens when the source returns stale, null, or out-of-schema data?\n     (d) Is the source ID space validated against a reference set before use?\n     (e) What is the downstream scoring impact if this source fails silently?\n   Output: Stage | File:Line | Fields consumed | Failure mode | Mitigation (Y\u002FN).\n   Constraints: read-only\n   ```\n\n---\n\n## Key Principles\n\n1. **Audit, don't fix.** Findings only — let the user decide what to act on.\n2. **Inject context.** Always read and inject the config files into agent prompts. Never let agents re-read them independently — shared preamble is the source of truth.\n3. **Parallel where independent.** `audit` runs three agents concurrently; the other subcommands are single-agent.\n4. **Evidence before verdict.** Every FAIL\u002FCRITICAL must cite `file:line`. AMBIGUOUS is a valid verdict — do not guess.\n5. **No project assumptions.** All paths come from flags. The skill works for any pipeline that has a scoring config, a quality gate config, and a multi-step pipeline directory.\n",{"name":5,"description":49,"allowed-tools":50,"argument-hint":51},"Audit a data pipeline for Veracity and Value. Dispatches data-scientist, compliance-auditor, and data-engineer agents with project context injected at dispatch time. All source paths are supplied via flags — no defaults, no project assumptions. Subcommands: audit (full pipeline walk), score-check (scoring math only), gate-check (gate coverage only), source-trace \u003Clabel> (single source end-to-end). Invoke when: \"audit pipeline\", \"veracity check\", \"scoring math correct?\", \"check gates\", \"trace source\", \"verify quality gates\", \"formula correct?\".\n","Read Grep Glob Bash Agent","audit | score-check | gate-check | source-trace \u003Clabel> --config \u003Cpath> --quality-config \u003Cpath> --pipeline-dir \u003Cpath> --scoring-dir \u003Cpath>","main","91c337164997b99943fbcc64e8e362577b67bc81","examples\u002Fminimal-consumer\u002F.claude\u002Fskills\u002Fveracity-audit","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha","I'm a Platform\u002FInfra engineer who happens to work in cybersec and write Go code.","2026-10-26 14:12:51",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add kaiohenricunha\u002Fdotbabel --skill veracity-audit",{"tool":65,"command":66},"bunx","bunx skills add kaiohenricunha\u002Fdotbabel --skill veracity-audit",{"tool":68,"command":69},"pnpm","pnpm dlx skills add kaiohenricunha\u002Fdotbabel --skill veracity-audit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fexamples\u002Fminimal-consumer\u002F.claude\u002Fskills\u002Fveracity-audit\u002FSKILL.md",true,[],[74,103,116,137,159,182],{"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":83,"publishedAt":44},"01M6XDQ7QMASPFZ355MYKCD06T","yolo","Start temporary autonomy for the current task or an explicit scope with a required --for expiry. Codex permits scoped pushes, merges, deploys, and releases after strict testing and validation; Full access is a separate runtime setting. Claude Code uses a session permission hook with a protected-action denylist.","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fyolo\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师",[76,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102],"testing","merge","code","start","access","session","ops","autonomy","releases","permission","full","runtime","scope","devex","hook","true","action","for","scoped",{"skillNo":104,"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":105,"categories":106,"keywords":113,"publishedAt":44},"01M6XDQ1N21VE4KH98JWGZ7GN9","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fveracity-audit\u002FSKILL.md",[107,112],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[25,24,84,114,43,42,41,40,38,37,36,26,34,33,32,115,31,29,28,27],"review","worker",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":44},"01M6XDPVDKBR376C06CEK9BC5S","validate-spec","Audit an already-implemented spec against the codebase. Walks each constraint (ARCH-N, PERF-N, KD-N, etc.) and acceptance criterion, grounds findings in file:line evidence, runs the spec.json acceptance_commands, and writes a single audit doc to docs\u002Faudits\u002F. Use whenever the user asks to \"validate a spec\", \"audit a spec\", \"check if spec is implemented\", \"verify the spec is done\", \"is this spec really done\", or otherwise wants closure on spec-driven work. Read-only against the spec — produces an audit, never modifies the spec itself.","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fvalidate-spec\u002FSKILL.md",[],[123,124,125,84,114,126,127,25,41,128,39,129,37,130,131,132,133,134,135,136],"spec","validate","validate spec","run","acceptance","work","never","max","done","arch","line","2025","spec-driven","closure",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":146,"publishedAt":44},"01M6XDPMMECH82RAW553Y94HDS","terragrunt-specialist","Deep-dive Terragrunt hierarchy review, DRY pattern audits, and run-all orchestration analysis. Use for structured investigations of multi-environment Terragrunt layouts, dependency graphs, remote state config, and hook correctness. Triggers on: \"Terragrunt audit\", \"run-all review\", \"dependency block\", \"DRY pattern review\", \"env hierarchy audit\", \"mock_outputs\", \"terragrunt hooks\".","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fterragrunt-specialist\u002FSKILL.md",[143],{"categoryNo":144,"categoryName":145,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000011","运维与部署",[147,148,149,114,150,151,126,25,152,41,39,153,154,130,155,156,134,157,29,158],"terragrunt","specialist","terragrunt specialist","orchestration","debugging","analysis","dependency","hooks","deep","dry","remote","hierarchy",{"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":172,"publishedAt":44},"01M6XDPFJS2HGSE13RXF1HV8S7","terraform-specialist","Deep-dive Terraform architecture review, module design, state management, and migration. Use for structured investigations of Terraform workspaces, provider configuration, module coupling, import workflows, and test coverage. Triggers on: \"Terraform audit\", \"module review\", \"state management\", \"Terraform import\", \"workspace design\", \"provider config review\", \"Terraform testing\".","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fterraform-specialist\u002FSKILL.md",[165,168,169],{"categoryNo":166,"categoryName":167,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":144,"categoryName":145,"taxonomyType":110,"taxonomyTypeDesc":111},{"categoryNo":170,"categoryName":171,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000015","视觉设计",[173,174,148,84,175,114,176,177,178,151,25,41,39,38,179,180,155,181,134,29],"terraform","terraform specialist","design","workflows","architecture","architecture review","test coverage","workspaces","problem",{"skillNo":183,"name":123,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":191,"publishedAt":44},"01M6XDP7V6H8WYPSXVEKYE6HJ6","Create structured engineering specs through interactive pairing. Use when the user wants to create a spec, design doc, technical specification, architecture document, RFC, or engineering plan. Triggers on \"let's spec this out\", \"create a spec\", \"design doc\", \"write a technical plan\", \"plan the architecture\". Works for greenfield and brownfield projects. Outputs to docs\u002Fspecs\u002F.","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fspec\u002FSKILL.md",[187,188],{"categoryNo":170,"categoryName":171,"taxonomyType":110,"taxonomyTypeDesc":111},{"categoryNo":189,"categoryName":190,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[123,175,192,177,193,194,195,196,197,198,199,200,201,202,203,101,204,205,206,207],"component","create","plan","projects","write","interactive","use","document","specification","triggers","opus","technical specification","trade-offs","technical plan","outputs","frontier"]