メニュー
Use when the user asks to install a skill or skill framework from a GitHub URL ("install https://github.com/...", "add the X framework", "pull in superpowers/gsd/bmad/speckit/openspec", "set up this framework").
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | install-skill-framework |
| description | Use when the user asks to install a skill or skill framework from a GitHub URL ("install https://github.com/...", "add the X framework", "pull in superpowers/gsd/bmad/speckit/openspec", "set up this framework"). |
Install an external Claude Code skill framework from a GitHub URL. Handles the four shapes Mike has encountered: Claude Code plugin marketplace, install.{sh,js} scripts, flat skills/ dirs, and one-off skills.
PAIRED WITH: uninstall-skill reads the install manifest this skill writes at ~/.claude/skill-installs/<framework>.json.
Use when the user's message contains:
install https://github.com/...Do NOT use when:
new-skill for thatResolve target directory. Default is ~/dev/<repo-name> (derived from the GitHub URL). If Mike specified "in this dir" and cwd is empty, use cwd.
Clone: git clone <url> <target>.
Detect framework shape — check these, in order:
| Shape | Signal | Install via |
|---|---|---|
| Plugin marketplace | .claude-plugin/ or plugin.json at root | Follow README — usually claude plugin install |
| Install script | install.sh, install.js, bin/install.* | Dry-run the script, confirm, run |
| Flat skills dir | skills/<skill-name>/SKILL.md layout | Symlink each skill into ~/.claude/skills/ |
| Single skill | SKILL.md at root | Symlink repo root as ~/.claude/skills/<name> |
| Other | README has manual instructions | Follow README, ask Mike to confirm each step |
For install-script shapes: read the script first, print a one-sentence summary of what it will do (files touched, symlinks made, settings.json changes), and ask Mike via AskUserQuestion before running.
For symlink shapes: ln -s <target>/skills/<name> ~/.claude/skills/<name> for each skill. Skip any collisions and report them.
Settings.json permissions. If the framework's README or plugin.json declares hooks, commands, or tools that need permissions, update ~/.claude/settings.json via the existing update-config skill.
Write install manifest at ~/.claude/skill-installs/<framework>.json:
{
"name": "<framework>",
"source_url": "<github-url>",
"target_dir": "<resolved path>",
"installed_at": "<ISO timestamp>",
"shape": "plugin|script|flat|single",
"symlinks": ["~/.claude/skills/foo", "~/.claude/skills/bar"],
"settings_changes": ["permissions.allow += ..."],
"script_run": "install.sh"
}
This is what uninstall-skill reads to reverse the install cleanly.
Verify. Run ls ~/.claude/skills/ and confirm the new symlinks resolve. If any are orphans, flag and stop.
Report. Summarize: framework name, shape detected, N skills installed, settings.json keys added (if any), and the install manifest path.
Mike has installed these five before. Use as priors for shape detection:
| Framework | URL | Shape | Notes |
|---|---|---|---|
| superpowers | github.com/obra/superpowers | plugin (has marketplace) OR flat skills | Also shippable as Claude plugin |
| gsd | github.com/gsd-build/get-shit-done | install script (bin/install.js) | Node-based installer |
| bmad | github.com/bmad-code-org/BMAD-METHOD | flat + AGENTS.md | Method-focused, not all skills |
| speckit | github.com/github/spec-kit | script + manual README steps | GitHub's spec-kit |
| openspec | github.com/Fission-AI/OpenSpec | flat | Smaller framework |
~/.claude/skills/foo already exists, don't overwrite — report and ask.uninstall-skill falls back to heuristics and may leave orphans.~/dev/ as the target. If the user explicitly passed "in this dir" and cwd is a valid empty workspace, use cwd.On first run, create ~/.claude/skill-installs/ if it doesn't exist. This directory is the source of truth for what's been installed via this skill.
Use when the user wants Claude, Codex, agy, and the Cursor models Composer 2.5 and Grok Build to iterate together until they converge on a mutually-agreed result — or hit a deadlock the user must arbitrate — and for fresh-eyes adversarial review of drafted artifacts. Five modes — plan, implement, verify, review, and audit (the folded-in adversarial review). Triggers — "converge", "have claude and codex work it out", "iterate until you agree", "three-AI consensus", "multi-AI consensus", "deadlock me a decision", "adversarial review this", "audit my drafts", "fresh eyes on this", "review for fabrications".
Use when starting any substantial feature — the before/during/after development lifecycle: interview rounds, parallel blind-spot/references/reality-probe passes, a knowns matrix folded into the plan, an implementation-notes log during the build, and a compounding step after (explainer, quiz, memory/skill extraction). Triggers — "feature passes", "run the pre-build passes", "blind spot pass", "knowns matrix", "interview me about this feature", "compound the learnings".
Use before baking an external config value — a model id, endpoint, ARN, bucket, region, credential, API version, image tag — into code or a deploy. Invoke the real dependency ONCE against the target account/environment and read the response, so a dead/renamed/deprecated/permission-blocked value is caught at the source instead of failing in production. The config equivalent of "verify against reality, not the doc." Triggers — "probe before wire", "smoke the dependency first", "is this model/endpoint/ARN actually live", "verify the config before deploy", "does this id still work", "check it against the real account".
Use when an agent, workflow, or fan-out died mid-work — API connection drops, session/spend limits, forced structured-output timeouts — and work must be recovered without loss. Triggers — "resume the run", "the agent died", "hit the session limit", "recover the workflow", "connection closed mid-response".
Use when you need to maximally verify a piece of code — especially AI-generated code — by stacking every independent check it admits (differential/property/metamorphic/fuzz/concurrency/static/cross-model), anchored on the strongest available oracle, and breaking the correlated-failure trap (one agent wrote both code and tests). Triggers — "how do I maximally verify this", "make this bulletproof", "how should I test this", "make this safe to optimize/refactor with AI", "what oracle should I use", "I don't trust the agent's tests", "maximize verification", "is my test suite actually verifying anything".
Use when a deployed/wired integration is FAILING (silently or opaquely) and you're tempted to try a fix. The failure lives at one of several layers — your wiring, your env, your IAM, an org policy/SCP, an account-level enablement/subscription, or the provider's response format — and each layer has a DIFFERENT OWNER. Ladder down them, verify what you own is actually applied, and get to the ONE authoritative signal (the real log line, an elevated-creds probe, latency-as-discriminator) before attributing blame or attempting a fix. Triggers — "why is this silently failing", "it deployed but doesn't work", "ladder the failure", "localize before fixing", "read the real error", "is it my code or their config", "diagnose the integration", "AccessDenied but the IAM looks right".