claude

# Claude Claude Code is an independent agent on PATH (`claude`), sharing this working tree and already authenticated. Use it as a second opinion or delegated worker, not as ground truth: verify its claims, own any changes, and keep its task contract narrow. ## Defaults Use `claude -p --model opus --effort high` unless the user or task calls for a different model or thinking level. Keep `opus` as an alias so Claude Code resolves the current Opus release; do not pin a dated model ID in this skill. - **Model:** prefer aliases such as `opus`, `sonnet`, or `fable`, which follow the current Claude releases. Accept a full model name only when the user or task requires that specific model, and verify it is current first. Default `opus`. - **Thinking level:** pass Claude Code's `--effort` flag. Valid levels are `low`, `medium`, `high`, `xhigh`, and `max`. Default `high`. - **Cost guard:** for exploratory asks, add `--max-budget-usd <amount>` when the user gives a budget or the task is likely to sprawl. Example: ```sh claude -p --model opus --effort high "<prompt>" ``` ## Prompting Claude Prompt Claude like an operator: compact, block-structured, and explicit about the artifact you need. A sharper contract beats higher effort. - **One task per run.** Split review, implementation, and docs into separate prompts. - **Name repo skills when relevant.** Claude can read repo files; say "follow write-docs for the doc" or "obey refactor-clean: no compatibility wrappers" instead of pasting those skills into the prompt. - **Blocks, added only where useful:** - `<task>` — the concrete job, context, and expected end state. - `<output_contract>` — exact response shape, highest-value first. - `<default_follow_through>` — take low-risk interpretations and continue; stop only when a missing detail changes correctness, safety, or an irreversible action. - `<verification_loop>` — inspect the result against requirements and revise before finalizing. - `<grounding>` — ground every claim in code or tool output; label inferences. - `<action_safety>` — keep the diff tightly scoped; no drive-by refactors. - **Anti-patterns:** vague prompts, mixed jobs, no output contract, asking it to "think harder" instead of tightening the task, and accepting its answer without checking the evidence. ## Consultation Use Claude for consultation when the user asks for Claude's view or when a second-agent read would materially reduce risk. Keep it read-oriented unless the user explicitly asks it to edit. 1. Ask for evidence, not vibes: require file paths, observed behavior, command output, or labelled inferences. 2. Prefer a read-only tool surface for reviews: `--tools "Read,Grep,Glob,Bash" --permission-mode dontAsk`. 3. **Never grant fewer tools than your output contract requires.** Read your own prompt and ask which tool produces each claim you demanded. A judge that cannot run a command will still answer a question posed in numbers — with numbers, self-consistent and measured from nothing, and with the artifacts it says it wrote. Trimming the tool surface does not make the answer cautious; it makes the fabrication harder to spot. Either grant the tool or stop asking for the claim. 4. Require the receipt with the number: any quantity in the response must arrive with the command that produced it and that command's output. Findings that fail this are struck, not discounted. 5. Triage every finding against the code before acting. Report what Claude flagged, what you accepted, and what you dismissed. ## Implementation — explicit ask only Delegate implementation to Claude only when the user names Claude for the task. Never hand it work on your own initiative, and never re-delegate follow-up work without a fresh ask. 1. Slice the task sharply: goal, constraints, allowed scope, and verification. An underspecified task stays with you until a fresh agent could not misread it. 2. Start from a clean tree or record the baseline commit so Claude's diff is separable from yours. Tell Claude to keep scratch files (probes, dumps, notes) out of the tree — its diff must contain only the deliverable. 3. Choose permissions by what the task must do: - Read/review: `--tools "Read,Grep,Glob,Bash" --permission-mode dontAsk`. - Narrow edits: add edit tools and keep the prompt's allowed paths explicit. - Broad autonomous work: use `--dangerously-skip-permissions` only in a dedicated worktree, with a self-authored prompt and a mandatory diff review after. 4. Capture the response with `--output-format text` by default. Use `--output-format json` only when the caller needs structured metadata. 5. You own the result: inspect the diff, run the relevant tests, and only then report it. "Claude says it's done" is not done. ## Liveness `claude -p` is a networked, authenticated non-interactive run. If it fails, classify the failure before retrying. - Auth failure: do not repair credentials unless the user asks; report the blocker. If sandboxed `claude -p` says `Not logged in`, retry once with the required approval because local auth can depend on keychain/session access. - Sandbox/network failure: rerun with the required approval if the command is important to the task. - Long run: prefer `--max-budget-usd` or a narrower prompt before raising effort. - Workspace trust: `-p` skips the interactive trust dialog, so run it only from a repo or worktree you intentionally trust. ## Rules - Use `claude -p --model opus --effort high` as the default invocation; keep the alias unversioned so it follows the current Opus release. - Let the user override model and effort in plain language; translate that to `--model` and `--effort`. - Keep Claude's writes out of the working tree unless delegation was explicit. - Do not touch the same working tree while Claude is making edits. - Treat Claude output as evidence to verify, not authority to relay. - Match the tool surface to the output contract; a claim shape you granted no tool for comes back invented.