claude-ai-dangerous: Command for Claude Code

Resolve the build-vs-adopt question for a piece of work before implementing it.

For each critical concern, walk the hierarchy Rent > Adopt > Extend > Fork > Build, research current options, recommend one, and record the decision as an ADR block. Choosing to build something a mature tool already does well is the failure this gate prevents.

This command is self-contained. It works inside the OpenSpec pipeline when OpenSpec is present, and equally well without it — the hierarchy and rubric below are the authority, not a pointer into openspec/. If .canon/guidelines.md exists it is the fuller reference and wins on any detail; if it doesn't, nothing here degrades.

Input: Optionally a scope name (e.g. /ai:decide add-auth) — an OpenSpec change name, a feature name, or nothing. If omitted, infer from context; if ambiguous, ask via AskUserQuestion. Announce: "Deciding for: ".

Steps

1. Resolve where the decision gets recorded — take the first that applies:

   Condition	Target
   openspec CLI available and an active change matches	openspec status --change "<name>" --json → artifactPaths.design.resolvedOutputPath
   openspec/changes/<scope>/design.md exists on disk	that file
   PROJECT.md exists (post-/ai:migration)	its ## Decisions (ADRs) section
   none of the above	ask the user; default DECISIONS.md at the project root

   Read whatever context exists for the scope (proposal, specs, design, or the surrounding code) before deciding. If the CLI reports actionContext.mode: workspace-planning, STOP — not supported here.

2. List the critical concerns — the correctness-, security-, or reliability-sensitive parts of this work. Take them from the proposal's flagged capabilities if present; otherwise scan the scope and propose a short list, then confirm with the user.

3. For each concern, run the gate:

   • Infrastructure? → decision is Rent, no further evaluation.
   • On the never-hand-roll list? → the decision is which tool, never whether to build.
   • Otherwise research with WebSearch — find current, actively-maintained options. Do NOT rely on memory; tooling moves.
   • Score candidates against the maturity rubric. Apply hard rejects.
   • Present at most 3 options as pure-build vs adopt-a-tool, each a one-line trade-off, and always end with a clear recommendation (which, and why) plus its hierarchy tier.
   • Wait for the user's pick before treating any tool as settled. Each decision is draft until the user confirms, then approved. (No "rejected" state — an unpicked option is simply dropped.)

4. Record it — append/update a ## Decisions section in the target, one block per concern:

   ### Decision: <concern> — <Rent|Adopt|Extend|Fork|Build> <tool-or-"hand-written">
   
   - **Status**: approved
   - **Why**: <one line>
   - **Considered**: <other 1–2 options, one line each>
   - **Isolation**: <the adapter/boundary the choice lives behind>
   

   Concrete tool names live here only — never push them into config.yaml or specs/, which stay abstract. If the target is PROJECT.md, match its existing ADR shape instead.

5. Summary — each concern → decision → status. Note any left in draft.