claude

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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

From dzhng/skills, MIT.

More from dzhng/skills