[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6XDQ7QMASPFZ355MYKCD06T":3,"skill-same:01M6XDQ7QMASPFZ355MYKCD06T":98},{"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":62,"commitSha":63,"skillDirectory":64,"forksCount":14,"repositoryHtmlUrl":65,"repositoryHomepageUrl":6,"ownerHtmlUrl":66,"ownerBlogUrl":6,"ownerDescription":67,"updatedAt":68,"install":69,"resources":81},"01M6XDQ7QMASPFZ355MYKCD06T","yolo",null,"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.","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\u002Fskills\u002Fyolo\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"full","scoped","for","action","true","hook","devex","scope","runtime","testing","permission","releases","autonomy","ops","session","access","start","code","merge","2026-11-10 10:12:30",false,"---\nid: yolo\nname: yolo\ntype: skill\nversion: 1.5.0\ndomain: [devex]\nplatform: [none]\ntask: [runtime-ops]\nmaturity: draft\nowner: \"@kaiohenricunha\"\ncreated: 2026-10-12\nupdated: 2026-10-17\ndescription: >\n  Start temporary autonomy for the current task or an explicit scope with a required\n  --for expiry. Codex permits scoped pushes, merges, deploys, and releases after\n  strict testing and validation; Full access is a separate runtime setting.\n  Claude Code uses a session permission hook with a protected-action denylist.\nargument-hint: \"--for \u003Cduration> [--merge|--no-merge] [scope] | off\"\ndisable-model-invocation: true\nuser-invocable: true\n---\n\n# yolo\n\n`disable-model-invocation: true` is deliberate. Only the owner can start this\nmode. In Claude Code, type `\u002Fyolo --for \u003Cduration> [scope]`. In Codex, type\n`$yolo --for \u003Cduration> [scope]`. Only `--for` is required; scope text and\n`--merge` or `--no-merge` are optional. `off` needs no duration.\n\n## Choose the runtime\n\n**Codex:** Read [references\u002Fcodex.md](references\u002Fcodex.md) and follow that path.\nIt authorizes all necessary work in the scope, including deploys and releases,\nsubject to strict verification. Check the active permissions and prompt once for\nFull access when needed, as the reference explains. The Codex instructions are\ncomplete; do not inherit the Claude\nstanding-grant limits or stops below.\nDo not run the Claude grant steps below in Codex.\n\n**Claude Code:** Follow the hook-backed path below. A missing Claude grant never\nselects the Codex path. For any other runtime, report that it is unsupported and stop.\n\n## Claude Code\n\nWithout scope text, use only the current task already agreed in this session.\nState that task before work starts. If no task exists, ask the owner for one.\nAn omitted scope never grants merge permission or includes unrelated work.\nMerges require `--merge` or an explicit merge instruction in the scope.\nThe invocation is the approval for that task or scope, never for unrelated work.\n\nThe `yolo.sh` hook does the mechanical part (see\n[docs\u002Fhooks.md](..\u002F..\u002Fdocs\u002Fhooks.md#yolosh)). When the owner types the command,\nthe hook writes a grant for this session and adds one context line. While the\ngrant lives, the hook approves the permission dialogs of this session, except\nfor a denylist. This skill does the rest: it tells you what the grant lets you\ndecide alone, and where you must still stop.\n\n## 1. Read the grant line\n\nFind the line the hook added to your context for this command. It starts with\none of these:\n\n- `YOLO GRANT REMOVED` — the owner typed `\u002Fyolo off`. Tell the owner, in one\n  sentence, that every permission default is back. Stop.\n- `YOLO GRANT ACTIVE` — read the session, the expiry, the grant file path,\n  `merge: yes|no`, and the scope from it. Resolve \"the current task in this\n  session\" to the agreed task before step 2.\n- Neither line — no hook grant is available, so every permission default stays.\n  Tell the owner to check the four `yolo.sh` entries in `docs\u002Fhooks.md#yolosh`,\n  and stop. Do not start the scope as if\n  it were autonomous.\n\nDo not edit any settings file to make the mode work. The mode must never\nchange `settings.json` at runtime. Never write or change a grant file or a\ntranscript. Only a `\u002Fyolo` that the owner types starts the mode, and the\npermission gate checks the transcript for it.\n\n## 2. The standing grant\n\nTell the owner, in at most three lines: the scope, `merge: yes|no`, the expiry,\nand the stops in step 3. Then start the work. Do not ask \"should I start?\".\n\nThe owner designates this session as autonomous for the scope in the grant\nline, and only for that scope. This is the standing grant that the\n\"When designated as autonomous\" clause of CLAUDE.md expects. Inside the scope,\nit is the explicit instruction that these rules ask for:\n\n- **Push.** Push the branches you create for the scope. Never force-push.\n- **Plan and audit sign-off.** Where a rule says to wait for approval of a plan\n  or an audit, write the plan or audit, state your choice, and continue.\n- **Pull requests.** Open the pull requests the scope needs with `\u002Fdeliver`:\n  prove each change works, review it once, and fix the findings. Run\n  `\u002Fpr-conductor` or local attestation only when the scope asks for them.\n- **Merge, only when `merge: yes`.** Merge each pull request in the scope when\n  its required checks are green and its evidence covers the head SHA. Use the\n  repository's merge path (`\u002Fmerge-pr`, or `gh pr merge --squash --delete-branch`).\n  Deleting the merged pull request's own head branch is part of the merge. When\n  `merge: no`, stop at a green pull request and report it.\n\nDo not ask \"push?\", \"merge?\", \"approved?\", or \"should I continue?\" about a\ndecision inside the scope. Make the decision, and record it in the final\nreport.\n\nEvery other rule still applies: worktrees from `origin\u002Fmain`, TDD, the merge\nevidence (CI on the head, or the explicit path), the PR body sections, the protected-path Spec ID or\nno-spec rationale, and the coordination with other sessions.\n\n## 3. Where you still stop\n\nStop, report what you found and why you stopped, and ask one question, for\neach of these:\n\n1. A force push, `git reset --hard`, or any other command\n   `guard-destructive-git.sh` asks for.\n2. A deletion of a branch or a repository, except the head branch of a pull\n   request you merge in the scope.\n3. An `rm -r` outside your worktree.\n4. `terraform destroy`, `tofu destroy`, or `apply -destroy`.\n5. A production deploy or a release.\n6. A check that fails and that you cannot fix inside the scope. Do not disable,\n   skip, or weaken the check, and do not lower a threshold.\n7. A change to owner-approved spec text (`docs\u002Fspecs\u002F`).\n8. Any work outside the scope. If the scope does not clearly cover a step,\n   treat it as outside.\n9. A change to a settings file, a hook, `~\u002F.claude\u002F`, or the grant file\n   (except the `rm -f` in step 4). A change there outlives the grant.\n\nThe hook keeps the dialog for items 1 to 5, 7, and 9 when Claude Code would show\none. It cannot see items 6 and 8, and it cannot add a dialog that your\nsettings or auto mode would skip. So these stops are your duty, not only the\nhook's. Do not route around a stop: no bypass variable, no split or encoded\ncommand, no script file, and no other session.\n\nIf a dialog shows for a step you expected to pass, the grant has possibly\nexpired. Report it, and do not ask the owner to approve a run of dialogs.\n\n## 4. Finish\n\nWhen the scope is done, or a stop ends the work:\n\n1. Report the result. Give what is done, what remains, and each pull request\n   with its link, its check state, and whether you merged it. Then give the\n   decisions you made alone under the grant.\n2. End the grant, as `\u002Fyolo off` does: remove the grant file named in the grant\n   line with `rm -f \u003Cgrant file>`.\n3. Tell the owner in one line that the mode is off and every default is back.\n","# yolo\n\n`disable-model-invocation: true` is deliberate. Only the owner can start this\nmode. In Claude Code, type `\u002Fyolo --for \u003Cduration> [scope]`. In Codex, type\n`$yolo --for \u003Cduration> [scope]`. Only `--for` is required; scope text and\n`--merge` or `--no-merge` are optional. `off` needs no duration.\n\n## Choose the runtime\n\n**Codex:** Read [references\u002Fcodex.md](references\u002Fcodex.md) and follow that path.\nIt authorizes all necessary work in the scope, including deploys and releases,\nsubject to strict verification. Check the active permissions and prompt once for\nFull access when needed, as the reference explains. The Codex instructions are\ncomplete; do not inherit the Claude\nstanding-grant limits or stops below.\nDo not run the Claude grant steps below in Codex.\n\n**Claude Code:** Follow the hook-backed path below. A missing Claude grant never\nselects the Codex path. For any other runtime, report that it is unsupported and stop.\n\n## Claude Code\n\nWithout scope text, use only the current task already agreed in this session.\nState that task before work starts. If no task exists, ask the owner for one.\nAn omitted scope never grants merge permission or includes unrelated work.\nMerges require `--merge` or an explicit merge instruction in the scope.\nThe invocation is the approval for that task or scope, never for unrelated work.\n\nThe `yolo.sh` hook does the mechanical part (see\n[docs\u002Fhooks.md](..\u002F..\u002Fdocs\u002Fhooks.md#yolosh)). When the owner types the command,\nthe hook writes a grant for this session and adds one context line. While the\ngrant lives, the hook approves the permission dialogs of this session, except\nfor a denylist. This skill does the rest: it tells you what the grant lets you\ndecide alone, and where you must still stop.\n\n## 1. Read the grant line\n\nFind the line the hook added to your context for this command. It starts with\none of these:\n\n- `YOLO GRANT REMOVED` — the owner typed `\u002Fyolo off`. Tell the owner, in one\n  sentence, that every permission default is back. Stop.\n- `YOLO GRANT ACTIVE` — read the session, the expiry, the grant file path,\n  `merge: yes|no`, and the scope from it. Resolve \"the current task in this\n  session\" to the agreed task before step 2.\n- Neither line — no hook grant is available, so every permission default stays.\n  Tell the owner to check the four `yolo.sh` entries in `docs\u002Fhooks.md#yolosh`,\n  and stop. Do not start the scope as if\n  it were autonomous.\n\nDo not edit any settings file to make the mode work. The mode must never\nchange `settings.json` at runtime. Never write or change a grant file or a\ntranscript. Only a `\u002Fyolo` that the owner types starts the mode, and the\npermission gate checks the transcript for it.\n\n## 2. The standing grant\n\nTell the owner, in at most three lines: the scope, `merge: yes|no`, the expiry,\nand the stops in step 3. Then start the work. Do not ask \"should I start?\".\n\nThe owner designates this session as autonomous for the scope in the grant\nline, and only for that scope. This is the standing grant that the\n\"When designated as autonomous\" clause of CLAUDE.md expects. Inside the scope,\nit is the explicit instruction that these rules ask for:\n\n- **Push.** Push the branches you create for the scope. Never force-push.\n- **Plan and audit sign-off.** Where a rule says to wait for approval of a plan\n  or an audit, write the plan or audit, state your choice, and continue.\n- **Pull requests.** Open the pull requests the scope needs with `\u002Fdeliver`:\n  prove each change works, review it once, and fix the findings. Run\n  `\u002Fpr-conductor` or local attestation only when the scope asks for them.\n- **Merge, only when `merge: yes`.** Merge each pull request in the scope when\n  its required checks are green and its evidence covers the head SHA. Use the\n  repository's merge path (`\u002Fmerge-pr`, or `gh pr merge --squash --delete-branch`).\n  Deleting the merged pull request's own head branch is part of the merge. When\n  `merge: no`, stop at a green pull request and report it.\n\nDo not ask \"push?\", \"merge?\", \"approved?\", or \"should I continue?\" about a\ndecision inside the scope. Make the decision, and record it in the final\nreport.\n\nEvery other rule still applies: worktrees from `origin\u002Fmain`, TDD, the merge\nevidence (CI on the head, or the explicit path), the PR body sections, the protected-path Spec ID or\nno-spec rationale, and the coordination with other sessions.\n\n## 3. Where you still stop\n\nStop, report what you found and why you stopped, and ask one question, for\neach of these:\n\n1. A force push, `git reset --hard`, or any other command\n   `guard-destructive-git.sh` asks for.\n2. A deletion of a branch or a repository, except the head branch of a pull\n   request you merge in the scope.\n3. An `rm -r` outside your worktree.\n4. `terraform destroy`, `tofu destroy`, or `apply -destroy`.\n5. A production deploy or a release.\n6. A check that fails and that you cannot fix inside the scope. Do not disable,\n   skip, or weaken the check, and do not lower a threshold.\n7. A change to owner-approved spec text (`docs\u002Fspecs\u002F`).\n8. Any work outside the scope. If the scope does not clearly cover a step,\n   treat it as outside.\n9. A change to a settings file, a hook, `~\u002F.claude\u002F`, or the grant file\n   (except the `rm -f` in step 4). A change there outlives the grant.\n\nThe hook keeps the dialog for items 1 to 5, 7, and 9 when Claude Code would show\none. It cannot see items 6 and 8, and it cannot add a dialog that your\nsettings or auto mode would skip. So these stops are your duty, not only the\nhook's. Do not route around a stop: no bypass variable, no split or encoded\ncommand, no script file, and no other session.\n\nIf a dialog shows for a step you expected to pass, the grant has possibly\nexpired. Report it, and do not ask the owner to approve a run of dialogs.\n\n## 4. Finish\n\nWhen the scope is done, or a stop ends the work:\n\n1. Report the result. Give what is done, what remains, and each pull request\n   with its link, its check state, and whether you merged it. Then give the\n   decisions you made alone under the grant.\n2. End the grant, as `\u002Fyolo off` does: remove the grant file named in the grant\n   line with `rm -f \u003Cgrant file>`.\n3. Tell the owner in one line that the mode is off and every default is back.\n",{"id":5,"name":5,"task":48,"type":50,"owner":51,"domain":52,"created":53,"updated":54,"version":55,"maturity":56,"platform":57,"description":59,"argument-hint":60,"user-invocable":61,"disable-model-invocation":61},[49],"runtime-ops","skill","@kaiohenricunha",[30],1791763200000,1792195200000,"1.5.0","draft",[58],"none","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.\n","--for \u003Cduration> [--merge|--no-merge] [scope] | off",true,"main","91c337164997b99943fbcc64e8e362577b67bc81","skills\u002Fyolo","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":70,"prompt":80,"zipAvailable":61},[71,74,77],{"tool":72,"command":73},"npx","npx skills add kaiohenricunha\u002Fdotbabel --skill yolo",{"tool":75,"command":76},"bunx","bunx skills add kaiohenricunha\u002Fdotbabel --skill yolo",{"tool":78,"command":79},"pnpm","pnpm dlx skills add kaiohenricunha\u002Fdotbabel --skill yolo","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fyolo\u002FSKILL.md",[82,88,92],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fyolo\u002Fagents\u002Fopenai.yaml",{"path":89,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fcodex.md",9127,"https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fyolo\u002Freferences\u002Fcodex.md",{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"scripts\u002Fcodex-yolo.mjs","SCRIPT","脚本",2297,"https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fyolo\u002Fscripts\u002Fcodex-yolo.mjs",[99,133,155,177,200,226],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":113,"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",[105,110],{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务",[114,115,33,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132],"audit","veracity audit","review","data pipeline","pipeline","Bash","math","coverage","only","engineer","formula","scoring","time","project","worker","end","at","invoke","when",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"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",[],[140,141,142,33,116,143,144,114,119,145,146,147,122,148,149,150,151,152,153,154],"spec","validate","validate spec","run","acceptance","work","read","never","max","done","arch","line","2025","spec-driven","closure",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":164,"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",[161],{"categoryNo":162,"categoryName":163,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000011","运维与部署",[165,166,167,116,168,169,143,114,170,119,146,171,172,148,173,174,152,175,130,176],"terragrunt","specialist","terragrunt specialist","orchestration","debugging","analysis","dependency","hooks","deep","dry","remote","hierarchy",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":190,"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",[183,186,187],{"categoryNo":184,"categoryName":185,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":162,"categoryName":163,"taxonomyType":108,"taxonomyTypeDesc":109},{"categoryNo":188,"categoryName":189,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000015","视觉设计",[191,192,166,33,193,116,194,195,196,169,114,119,146,121,197,198,173,199,152,130],"terraform","terraform specialist","design","workflows","architecture","architecture review","test coverage","workspaces","problem",{"skillNo":201,"name":140,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":209,"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",[205,206],{"categoryNo":188,"categoryName":189,"taxonomyType":108,"taxonomyTypeDesc":109},{"categoryNo":207,"categoryName":208,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[140,193,210,195,211,212,213,214,215,216,217,218,219,220,221,26,222,223,224,225],"component","create","plan","projects","write","interactive","use","document","specification","triggers","opus","technical specification","trade-offs","technical plan","outputs","frontier",{"skillNo":227,"name":228,"nameZh":6,"description":229,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":230,"categories":231,"keywords":233,"publishedAt":43},"01M6XDP2DCRZ004WMTWGECQC2F","smoke-test","Run the smoke checks a repository declares for its deploy targets and report whether production actually answers after a release. Use after a deploy, during release verification, and when confirming a rollback landed. Triggers on: \"smoke test\", \"run smoke checks\", \"is production healthy\", \"did the deploy work\", \"verify the release is live\".","https:\u002F\u002Fgithub.com\u002Fkaiohenricunha\u002Fdotbabel\u002Fblob\u002Fmain\u002Fskills\u002Fsmoke-test\u002FSKILL.md",[232],{"categoryNo":184,"categoryName":185,"taxonomyType":108,"taxonomyTypeDesc":109},[234,235,236,237,143,238,239,240,119,145,146,241,242,174,243,30,244,26,245,132],"test","smoke","smoke test","diagnostics","release","verification","repository","infra","live","sep","sonnet","routine"]