[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XD2P217ZN2DNQVSPPC06M3":3,"skill-same:01M6XD2P217ZN2DNQVSPPC06M3":71},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":70},"01M6XD2P217ZN2DNQVSPPC06M3","deliver",null,"Take one task contract (goal, inputs, constraints, done_when) from a prompt to a reviewable pull request in one run: test first, implement, prove the change works by running it, review the diff once, and open the pull request with the proof. CI on the head is the merge evidence. No review rounds, no local attestation, no merge. Triggers on: \"deliver this\", \"build this and open a PR\", \"implement this issue and open a PR\", \"take this task to a PR\", or a task contract whose output is a pull request.","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\u002Fdeliver\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"take","running","when","request","false","as","local","done","issue","review","goal","evidence","open","attestation","ci","pull","run","merge","change","2026-11-10 10:12:30",false,"---\n# dotbabel:generated projection=sha256:73280827d2a37c0b7332f0e98bd790652ace8afbadc22970092b3f93528b8a22 source=skills\u002Fdeliver\u002FSKILL.md — do not edit directly\nargument-hint: \u003Ctask contract as JSON or prose> [--draft]\ndescription: |\n  Take one task contract (goal, inputs, constraints, done_when) from a prompt to a reviewable pull request in one run: test first, implement, prove the change works by running it, review the diff once, and open the pull request with the proof. CI on the head is the merge evidence. No review rounds, no local attestation, no merge. Triggers on: \"deliver this\", \"build this and open a PR\", \"implement this issue and open a PR\", \"take this task to a PR\", or a task contract whose output is a pull request.\ndisable-model-invocation: false\nname: deliver\nuser-invocable: true\n---\n\nTake one task from its contract to a reviewable pull request, back to back. The proof that the change works is part of the deliverable, not a later phase. Review rounds, `\u002Fpr-conductor`, and `local-attest` are not steps of this flow: the user runs them on demand.\n\nTrigger: when the user gives a task and asks for it to end in a pull request, in prose or as a contract such as:\n\n```json\n{\n  \"goal\": \"ship the feature\",\n  \"inputs\": [\"issue\", \"repository\", \"design\"],\n  \"output\": \"reviewable pull request\",\n  \"constraints\": [\"no schema changes\", \"preserve public API\"],\n  \"done_when\": [\"tests pass\", \"visual check passes\", \"review passes\"]\n}\n```\n\nArguments: `$ARGUMENTS`\n\n- `\u003Ccontract>` — the task, as JSON or prose.\n- `--draft` — open the pull request as a draft.\n\n**Consent.** Start this skill only when the user's prompt asks for the task to end in a pull request, in words or as the contract's `output`. That prompt is the consent to push the task's branch and open its pull request, for this one task. A task that does not ask for a pull request gets the same steps up to step 8, and then stops with local commits. This skill never merges: merging stays an explicit instruction, handed to `\u002Fmerge-pr`.\n\n## 1. Read the contract\n\nNormalize the contract to five fields:\n\n| Field         | Meaning                                    | If absent                                         |\n| ------------- | ------------------------------------------ | ------------------------------------------------- |\n| `goal`        | the change                                 | ask one question; with no goal there is no task   |\n| `inputs`      | the issue, design, files, or links to read | read what the prompt names                        |\n| `output`      | what the run ends with                     | a reviewable pull request                         |\n| `constraints` | what the change must not do                | none beyond the rule floor                        |\n| `done_when`   | the checks that make the task done         | `tests pass`, `the feature runs`, `review passes` |\n\n## 2. Map every item to a check\n\nBefore you write code, give each `done_when` item and each constraint one mechanical check and the evidence it produces:\n\n| Item                | Check                                                                              | Evidence                         |\n| ------------------- | ---------------------------------------------------------------------------------- | -------------------------------- |\n| tests pass          | the new tests, plus the existing tests that cover the changed code                 | the command and its last lines   |\n| the feature runs    | step 6 below                                                                       | the command and its output       |\n| visual check passes | `\u002Frun` the app, open the changed screen, take a screenshot                         | the screenshot and what it shows |\n| review passes       | step 8 below                                                                       | findings found, fixed, answered  |\n| no schema changes   | `git diff --stat origin\u002Fmain...HEAD -- \u003Cschema paths>` is empty                    | the empty output                 |\n| preserve public API | the diff of exports, CLI flags, `bin` entries, and endpoints is empty or only adds | that diff                        |\n| criteria pass       | `dotbabel criteria verify --pr \u003CN> --post`                                         | the evidence comment             |\n\nAn item you cannot map to a check is not done. Write it in the proof as unverified, with the reason. Never tick it.\n\n## 3. Ground and isolate\n\n1. Read the inputs and the code the goal touches. Cite `file:line` for each claim.\n2. If the contract has two readings that lead to different code, ask one question. Otherwise state the reading you chose and continue.\n3. Create a worktree from the latest `origin\u002Fmain` under `.claude\u002Fworktrees\u002F\u003Cslug>\u002F`, per the rule floor. Where `dotbabel fleet` runs, claim the paths you will edit.\n4. From inside the worktree, record the contract, so a later session in that worktree can resume the task. A task record belongs to the worktree it is written from.\n\n   ```bash\n   dotbabel task new \u003Cslug> --goal \"\u003Cgoal>\" --done-when \"\u003Citem>\" ... --constraint \"\u003Citem>\" ...\n   ```\n\n   Skip the record when `dotbabel` is not installed, and say so in the report.\n\n## 4. Plan\n\nWrite at most five bullets in the form `Step → verify: \u003Ccheck>`. Do not wait for approval: the contract is the approval. Stop only for an ambiguity that changes the result, or for a constraint that the goal cannot meet.\n\n## 5. Test first, then implement\n\n1. Write the tests for each behavior: unit tests, and integration tests where the change crosses a process, file, network, or database boundary. Include a negative case and a boundary case.\n2. Run them and see them fail for the right reason.\n3. Implement until they pass. Keep to the constraints.\n\n## 6. Prove it works\n\nRun the feature the way a user does. Choose by the surface the change has:\n\n| Surface     | Run                                                                    |\n| ----------- | ---------------------------------------------------------------------- |\n| CLI         | the command with real arguments, in a temporary directory if it writes |\n| library     | a short script that calls the public function                          |\n| server, API | start it, call the endpoint, read the response                         |\n| UI          | `\u002Frun` the app, open the changed screen, take a screenshot             |\n| docs only   | run each command the changed text shows, and check each link it adds   |\n| none        | write `N\u002FA — \u003Creason>`: a pure refactor that the tests already cover   |\n\nRecord each command and the last ten lines of its output. A run that fails is a bug: fix it, and add the test that would have caught it.\n\n## 7. Check the constraints\n\nRun the check from step 2 for each constraint. A constraint that fails stops the task: report it rather than weaken it.\n\n## 8. Review once\n\nRun one review of the branch diff: `\u002Fcode-review` on the changed files, or `\u002Fquality-review` where the project has a dotbabel quality policy. Fix each correct finding. Answer each wrong one in the proof, in one line. Do not post review comments, and do not start review rounds: `\u002Fpost-pr-review`, `\u002Freview-pr`, and `\u002Fpr-conductor` run only when the user asks.\n\n## 9. Open the pull request\n\n1. Commit with conventional messages. Do not add `[skip ci]`: CI on the head is the merge evidence.\n2. Push the branch once, when the proof is complete, and open the pull request with `gh pr create --body-file \u003Cfile>` (add `--draft` for `--draft`). Where CI minutes are metered (a private repository without a self-hosted runner), every push of the head starts a paid run, so push the fixes of step 10 in one batch.\n3. Write the body with these sections, in this order:\n   - `## Summary` — one to three bullets.\n   - `## Test plan` — a checklist; tick only the items you ran.\n   - `## Proof` — the format below.\n   - `## Spec ID` or `## No-spec rationale` — last, when the project uses specs or the change touches a protected path.\n4. If a linked spec declares active criteria, run `dotbabel criteria verify --pr \u003CN> --post` from the worktree at the pull request head. A failing criterion is a failing `done_when` item.\n\nThe `## Proof` section:\n\n````markdown\n## Proof\n\n| done_when         | Check                                | Result                       |\n| ----------------- | ------------------------------------ | ---------------------------- |\n| tests pass        | `npx vitest run tests\u002Ffoo.test.mjs`  | 14 passed                    |\n| the feature runs  | `dotbabel foo --bar baz`             | prints `3 items`, exit 0     |\n| no schema changes | `git diff --stat main... -- schemas` | empty                        |\n| review passes     | `\u002Fcode-review` on the diff           | 3 found, 2 fixed, 1 answered |\n\n\u003Cdetails>\u003Csummary>Feature run\u003C\u002Fsummary>\n\n```text\n$ dotbabel foo --bar baz\n...\n```\n\n\u003C\u002Fdetails>\n````\n\n## 10. Wait for CI\n\nRun `gh pr checks \u003CN> --watch`. Fix a red check on the branch with a new commit, and repeat step 6 when the fix changes behavior. After three failed fixes for one check, stop and report it.\n\n## 11. Report\n\nGive the completion status: the `done_when` table with each result, the pull request link, and the CI state. Close the task record from the worktree with `dotbabel task close \u003Cslug>`. Name the next step: `\u002Fmerge-pr \u003CN>` when the user says merge, or a review the user may want to run on demand.\n\n## Rules\n\n- The proof is the contract. Never tick a `done_when` item or a test-plan item without evidence in the pull request body.\n- One review pass. No review fleet, no comment rounds, no local attestation, unless the user asks.\n- Never weaken a test, a check, a constraint, or a threshold to reach done.\n- Never add `[skip ci]` to the head commit, and never write the marker in any commit message, even to describe it: GitHub matches it anywhere in the message and skips the whole run. Check with `git log --format=%B -1` before you push.\n- Never merge, and never force-push.\n- Stop and ask only for: an ambiguity that changes the result, a constraint the goal cannot meet, a check that stays red after three fixes, or a destructive action.\n","Take one task from its contract to a reviewable pull request, back to back. The proof that the change works is part of the deliverable, not a later phase. Review rounds, `\u002Fpr-conductor`, and `local-attest` are not steps of this flow: the user runs them on demand.\n\nTrigger: when the user gives a task and asks for it to end in a pull request, in prose or as a contract such as:\n\n```json\n{\n  \"goal\": \"ship the feature\",\n  \"inputs\": [\"issue\", \"repository\", \"design\"],\n  \"output\": \"reviewable pull request\",\n  \"constraints\": [\"no schema changes\", \"preserve public API\"],\n  \"done_when\": [\"tests pass\", \"visual check passes\", \"review passes\"]\n}\n```\n\nArguments: `$ARGUMENTS`\n\n- `\u003Ccontract>` — the task, as JSON or prose.\n- `--draft` — open the pull request as a draft.\n\n**Consent.** Start this skill only when the user's prompt asks for the task to end in a pull request, in words or as the contract's `output`. That prompt is the consent to push the task's branch and open its pull request, for this one task. A task that does not ask for a pull request gets the same steps up to step 8, and then stops with local commits. This skill never merges: merging stays an explicit instruction, handed to `\u002Fmerge-pr`.\n\n## 1. Read the contract\n\nNormalize the contract to five fields:\n\n| Field         | Meaning                                    | If absent                                         |\n| ------------- | ------------------------------------------ | ------------------------------------------------- |\n| `goal`        | the change                                 | ask one question; with no goal there is no task   |\n| `inputs`      | the issue, design, files, or links to read | read what the prompt names                        |\n| `output`      | what the run ends with                     | a reviewable pull request                         |\n| `constraints` | what the change must not do                | none beyond the rule floor                        |\n| `done_when`   | the checks that make the task done         | `tests pass`, `the feature runs`, `review passes` |\n\n## 2. Map every item to a check\n\nBefore you write code, give each `done_when` item and each constraint one mechanical check and the evidence it produces:\n\n| Item                | Check                                                                              | Evidence                         |\n| ------------------- | ---------------------------------------------------------------------------------- | -------------------------------- |\n| tests pass          | the new tests, plus the existing tests that cover the changed code                 | the command and its last lines   |\n| the feature runs    | step 6 below                                                                       | the command and its output       |\n| visual check passes | `\u002Frun` the app, open the changed screen, take a screenshot                         | the screenshot and what it shows |\n| review passes       | step 8 below                                                                       | findings found, fixed, answered  |\n| no schema changes   | `git diff --stat origin\u002Fmain...HEAD -- \u003Cschema paths>` is empty                    | the empty output                 |\n| preserve public API | the diff of exports, CLI flags, `bin` entries, and endpoints is empty or only adds | that diff                        |\n| criteria pass       | `dotbabel criteria verify --pr \u003CN> --post`                                         | the evidence comment             |\n\nAn item you cannot map to a check is not done. Write it in the proof as unverified, with the reason. Never tick it.\n\n## 3. Ground and isolate\n\n1. Read the inputs and the code the goal touches. Cite `file:line` for each claim.\n2. If the contract has two readings that lead to different code, ask one question. Otherwise state the reading you chose and continue.\n3. Create a worktree from the latest `origin\u002Fmain` under `.claude\u002Fworktrees\u002F\u003Cslug>\u002F`, per the rule floor. Where `dotbabel fleet` runs, claim the paths you will edit.\n4. From inside the worktree, record the contract, so a later session in that worktree can resume the task. A task record belongs to the worktree it is written from.\n\n   ```bash\n   dotbabel task new \u003Cslug> --goal \"\u003Cgoal>\" --done-when \"\u003Citem>\" ... --constraint \"\u003Citem>\" ...\n   ```\n\n   Skip the record when `dotbabel` is not installed, and say so in the report.\n\n## 4. Plan\n\nWrite at most five bullets in the form `Step → verify: \u003Ccheck>`. Do not wait for approval: the contract is the approval. Stop only for an ambiguity that changes the result, or for a constraint that the goal cannot meet.\n\n## 5. Test first, then implement\n\n1. Write the tests for each behavior: unit tests, and integration tests where the change crosses a process, file, network, or database boundary. Include a negative case and a boundary case.\n2. Run them and see them fail for the right reason.\n3. Implement until they pass. Keep to the constraints.\n\n## 6. Prove it works\n\nRun the feature the way a user does. Choose by the surface the change has:\n\n| Surface     | Run                                                                    |\n| ----------- | ---------------------------------------------------------------------- |\n| CLI         | the command with real arguments, in a temporary directory if it writes |\n| library     | a short script that calls the public function                          |\n| server, API | start it, call the endpoint, read the response                         |\n| UI          | `\u002Frun` the app, open the changed screen, take a screenshot             |\n| docs only   | run each command the changed text shows, and check each link it adds   |\n| none        | write `N\u002FA — \u003Creason>`: a pure refactor that the tests already cover   |\n\nRecord each command and the last ten lines of its output. A run that fails is a bug: fix it, and add the test that would have caught it.\n\n## 7. Check the constraints\n\nRun the check from step 2 for each constraint. A constraint that fails stops the task: report it rather than weaken it.\n\n## 8. Review once\n\nRun one review of the branch diff: `\u002Fcode-review` on the changed files, or `\u002Fquality-review` where the project has a dotbabel quality policy. Fix each correct finding. Answer each wrong one in the proof, in one line. Do not post review comments, and do not start review rounds: `\u002Fpost-pr-review`, `\u002Freview-pr`, and `\u002Fpr-conductor` run only when the user asks.\n\n## 9. Open the pull request\n\n1. Commit with conventional messages. Do not add `[skip ci]`: CI on the head is the merge evidence.\n2. Push the branch once, when the proof is complete, and open the pull request with `gh pr create --body-file \u003Cfile>` (add `--draft` for `--draft`). Where CI minutes are metered (a private repository without a self-hosted runner), every push of the head starts a paid run, so push the fixes of step 10 in one batch.\n3. Write the body with these sections, in this order:\n   - `## Summary` — one to three bullets.\n   - `## Test plan` — a checklist; tick only the items you ran.\n   - `## Proof` — the format below.\n   - `## Spec ID` or `## No-spec rationale` — last, when the project uses specs or the change touches a protected path.\n4. If a linked spec declares active criteria, run `dotbabel criteria verify --pr \u003CN> --post` from the worktree at the pull request head. A failing criterion is a failing `done_when` item.\n\nThe `## Proof` section:\n\n````markdown\n## Proof\n\n| done_when         | Check                                | Result                       |\n| ----------------- | ------------------------------------ | ---------------------------- |\n| tests pass        | `npx vitest run tests\u002Ffoo.test.mjs`  | 14 passed                    |\n| the feature runs  | `dotbabel foo --bar baz`             | prints `3 items`, exit 0     |\n| no schema changes | `git diff --stat main... -- schemas` | empty                        |\n| review passes     | `\u002Fcode-review` on the diff           | 3 found, 2 fixed, 1 answered |\n\n\u003Cdetails>\u003Csummary>Feature run\u003C\u002Fsummary>\n\n```text\n$ dotbabel foo --bar baz\n...\n```\n\n\u003C\u002Fdetails>\n````\n\n## 10. Wait for CI\n\nRun `gh pr checks \u003CN> --watch`. Fix a red check on the branch with a new commit, and repeat step 6 when the fix changes behavior. After three failed fixes for one check, stop and report it.\n\n## 11. Report\n\nGive the completion status: the `done_when` table with each result, the pull request link, and the CI state. Close the task record from the worktree with `dotbabel task close \u003Cslug>`. Name the next step: `\u002Fmerge-pr \u003CN>` when the user says merge, or a review the user may want to run on demand.\n\n## Rules\n\n- The proof is the contract. Never tick a `done_when` item or a test-plan item without evidence in the pull request body.\n- One review pass. No review fleet, no comment rounds, no local attestation, unless the user asks.\n- Never weaken a test, a check, a constraint, or a threshold to reach done.\n- Never add `[skip ci]` to the head commit, and never write the marker in any commit message, even to describe it: GitHub matches it anywhere in the message and skips the whole run. Check with `git log --format=%B -1` before you push.\n- Never merge, and never force-push.\n- Stop and ask only for: an ambiguity that changes the result, a constraint the goal cannot meet, a check that stays red after three fixes, or a destructive action.\n",{"name":5,"description":48,"argument-hint":49,"user-invocable":50,"disable-model-invocation":44},"Take one task contract (goal, inputs, constraints, done_when) from a prompt to a reviewable pull request in one run: test first, implement, prove the change works by running it, review the diff once, and open the pull request with the proof. CI on the head is the merge evidence. No review rounds, no local attestation, no merge. Triggers on: \"deliver this\", \"build this and open a PR\", \"implement this issue and open a PR\", \"take this task to a PR\", or a task contract whose output is a pull request.\n","\u003Ctask contract as JSON or prose> [--draft]",true,"main","91c337164997b99943fbcc64e8e362577b67bc81","examples\u002Fminimal-consumer\u002F.claude\u002Fskills\u002Fdeliver","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":59,"prompt":69,"zipAvailable":50},[60,63,66],{"tool":61,"command":62},"npx","npx skills add kaiohenricunha\u002Fdotbabel --skill deliver",{"tool":64,"command":65},"bunx","bunx skills add kaiohenricunha\u002Fdotbabel --skill deliver",{"tool":67,"command":68},"pnpm","pnpm dlx skills add kaiohenricunha\u002Fdotbabel --skill deliver","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fexamples\u002Fminimal-consumer\u002F.claude\u002Fskills\u002Fdeliver\u002FSKILL.md",[],[72,100,130,150,172,195],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":81,"publishedAt":43},"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",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师",[74,82,41,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99],"testing","code","start","access","session","ops","autonomy","releases","permission","full","runtime","scope","devex","hook","true","action","for","scoped",{"skillNo":101,"name":102,"nameZh":6,"description":103,"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":112,"publishedAt":43},"01M6XDQ1N21VE4KH98JWGZ7GN9","veracity-audit","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?\".","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fveracity-audit\u002FSKILL.md",[106,111],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[113,114,82,33,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,26],"audit","veracity audit","data pipeline","pipeline","Bash","math","coverage","only","engineer","formula","scoring","time","project","worker","end","at","invoke",{"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":43},"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",[],[137,138,139,82,33,40,140,113,117,141,142,143,120,144,31,145,146,147,148,149],"spec","validate","validate spec","acceptance","work","read","never","max","arch","line","2025","spec-driven","closure",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":159,"publishedAt":43},"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",[156],{"categoryNo":157,"categoryName":158,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000011","运维与部署",[160,161,162,33,163,164,40,113,165,117,142,166,167,144,168,169,147,170,128,171],"terragrunt","specialist","terragrunt specialist","orchestration","debugging","analysis","dependency","hooks","deep","dry","remote","hierarchy",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":185,"publishedAt":43},"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",[178,181,182],{"categoryNo":179,"categoryName":180,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":157,"categoryName":158,"taxonomyType":109,"taxonomyTypeDesc":110},{"categoryNo":183,"categoryName":184,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000015","视觉设计",[186,187,161,82,188,33,189,190,191,164,113,117,142,119,192,193,168,194,147,128],"terraform","terraform specialist","design","workflows","architecture","architecture review","test coverage","workspaces","problem",{"skillNo":196,"name":137,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":204,"publishedAt":43},"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",[200,201],{"categoryNo":183,"categoryName":184,"taxonomyType":109,"taxonomyTypeDesc":110},{"categoryNo":202,"categoryName":203,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[137,188,205,190,206,207,208,209,210,211,212,213,214,215,216,98,217,218,219,220],"component","create","plan","projects","write","interactive","use","document","specification","triggers","opus","technical specification","trade-offs","technical plan","outputs","frontier"]