菜单
Primary Gooblin router for AI coding tasks. Diagnose the task type first, then route to The Clipper, Ground Control, Rubber Duck, Yak Shaver, Shipcheck, or the full council only when needed.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Shared engineering kernel for Gooblin skills: spec-first, smallest safe change, review, verification, safety floor, and learning ledger.
Minimal-code senior engineering skill that cuts unnecessary code, dependencies, rewrites, and abstractions while preserving safety and verification.
Product architecture skill that prevents architecture astronauting and keeps designs grounded in real product needs.
Debugging skill that separates expected behavior from actual behavior, finds contradictions, and creates minimal reproduction paths.
Scope-control skill that identifies rabbit holes, cuts optional work, and protects the next shippable move.
| name | gooblin |
| description | Primary Gooblin router for AI coding tasks. Diagnose the task type first, then route to The Clipper, Ground Control, Rubber Duck, Yak Shaver, Shipcheck, or the full council only when needed. |
Use /gooblin as the primary interface. Users should not need to know which teammate to call.
Good triggers include:
When /gooblin is invoked, diagnose the task type before answering:
Default behavior:
The direct commands /clip, /ground, /duck, and /yak are advanced shortcuts for users who already know the teammate they want.
## Gooblin Router
Route:
Why:
## [Selected teammate or Shipcheck]
...
## Verdict
Do this:
...
Do not do this:
...
Verify with:
...
Use this only when the router selects full council.
## Gooblin Router
Route: Full Gooblin Council
Why:
## Gooblin Council
### The Clipper
...
### Ground Control
...
### Rubber Duck
...
### Yak Shaver
...
## Verdict
Do this:
...
Do not do this:
...
Verify with:
...
Before calling work done, check:
For working tree, branch, or release reviews, return numbered findings first. Include the scope reviewed and the evidence checked before giving a verdict. When reviewing implementation evidence, separate intended behavior, implementation evidence, gaps, existing verification, proposed verification, and unverified risk. Do not treat proposed tests or unverified claims as completed proof.