# Global Claude Code instructions (~/.claude/CLAUDE.md) > Source: > Published: 2026-09-18 18:49:31+00:00 After completing each task, create a git commit immediately. Do not batch multiple tasks into a single commit. **Rules:** 1. One commit per completed task — commit as soon as the task is done. This is standing authorization, do not wait for per commit approval. 2. Stage only the files changed for that specific task (use `git add ` , not`git add .` ) 3. Write a concise commit message: `: ` (e.g.,`feat: add user auth endpoint` ,`fix: resolve null check in parser` ) 4. Valid types: `feat` ,`fix` ,`refactor` ,`docs` ,`test` ,`chore` ,`style` 5. Do NOT push automatically — commits stay local until the user explicitly requests a push 6. If a task touches multiple concerns, prefer splitting into smaller sequential commits Model tiers for ANY delegated work — Agent-tool calls and Workflow-script `agent()` calls alike. Set the `model` parameter explicitly on every call; never omit it (omission silently inherits the session model): - `haiku` — mechanical bulk work: renames, boilerplate, format conversion, log triage - `sonnet` — default for well-specified implementation with clear acceptance criteria - `opus` — genuinely tricky work: concurrency, subtle algorithms, adversarial verify/judge panels, gnarly debugging - `fable` — rare; only when independence from your own context is the point (e.g. adversarial review of your own plan or a large diff). If you want to call a Fable sub-agent because the complexity of the task warrants it, ALWAYS check with me first — never spawn one unprompted. When unsure between tiers, pick the cheaper and escalate on failure. Applies to ALL sessions, any model. Dynamic workflows do not need to be avoided — reach for the Workflow tool when a task has 3+ independent parallelizable subtasks or would benefit from a pipeline/judge panel. Standing rule on opt-in: if ultracode is NOT on for the session (no "ultracode" keyword, toggle, or an orchestration request in my own words), check with me first — propose the workflow in one or two sentences with the rough shape and cost, and wait for my reply; my "yes" is the opt-in. If ultracode IS on, invoke directly. **Agent models inside workflow scripts:** every `agent()` call MUST set the `model` parameter explicitly, chosen per "Delegating to sub-agents" above — with one tightening: NEVER use `fable` agents in a dynamic workflow, not even with approval. Only `haiku`, `sonnet`, or `opus`. If a Fable review is warranted, it happens AFTER the workflow completes, as a standalone Agent-tool call (ask first, per above) — never as a workflow stage. Applies ONLY if your system prompt says you are powered by a Fable (Mythos-class) model AND you are the top-level session. Sonnet/Opus/Haiku sessions, and spawned subagents of ANY model (including `fable` subagents): skip this section and work directly. You are the most expensive tier. Your comparative advantage is decomposition, judgment, verification, and integration — spend your tokens there and route execution to cheaper models. These are defaults with criteria, not absolutes. **Act directly (no subagent) when:** - Understanding, not writing: questions, explanations, reads/greps. Delegate reading only for bulk surveys whose raw output would pollute your context. - The change is small (roughly ≤30 lines across 1–2 files), or emerges from an active review loop where you already hold the context. - Writing a self-contained brief would cost more than the task itself — that is the signal delegation is wrong for this task. - Git operations: you own all staging and commits per the atomic-commits policy above. **Delegate via the Agent tool when** implementation spans 3+ files, is mechanical/repetitive, or splits into independent pieces that can run in parallel (fan out only when work partitions cleanly by file with no overlapping writes). Pick the model per "Delegating to sub-agents" above. Delegate to minimize total cost and latency, not to maximize delegation — prefer one subagent with a complete brief over many fragments. **Briefing standard:** subagents see none of our conversation. Every brief must be self-contained — exact file paths, the specific change, acceptance criteria, and the verification command to run — and must state commit policy: default "do NOT commit; the parent session owns commits." Exception — a subagent that is the sole writer in its worktree and is executing multiple sequential tasks may be granted "commit atomically per task as you go"; never grant commit authority to parallel subagents sharing a worktree. **Reserve for yourself:** planning, architecture, judgment calls, resolving ambiguity with me, and final acceptance of delegated work. You hold the full conversation context; a context-free `fable` subagent doing these is equal cost with worse judgment. **Workflow tool:** see "Dynamic workflows (Workflow tool)" above — those rules apply to all sessions, Fable included. **Verify, then commit:** never accept a subagent's self-report as done. Read the actual diff, run the project's verification gate, and check your acceptance criteria — then stage exactly that task's files and commit per the atomic-commits policy above. If you granted a subagent commit authority, verification shifts to its commit series: review `git log -p` over its range and run the gate before treating the work as accepted.