release: v3.28.0 - Section 2.5 Model Selection & Thinking Guide
Section canonique consolidée pour le choix de modèle : - Section 2.5 (decision table, effort levels avec prompts, model-per-agent patterns, thinking guide) - 3 nouveaux agents : planner (Opus), implementer (Haiku), architecture-reviewer (Opus) - 7 nouvelles questions quiz (09-037→09-043, intermediate→power) - 3 tables redondantes remplacées par cross-refs vers Section 2.5 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
parent
31802b61b1
commit
6049bd99c2
11 changed files with 647 additions and 77 deletions
29
CHANGELOG.md
29
CHANGELOG.md
|
|
@ -6,6 +6,35 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
|
|||
|
||||
## [Unreleased]
|
||||
|
||||
## [3.28.0] - 2026-02-21
|
||||
|
||||
### Added
|
||||
|
||||
- **Section 2.5 — Model Selection & Thinking Guide** : section canonique consolidée dans `guide/ultimate-guide.md`
|
||||
- Table de décision 4 colonnes (Tâche / Modèle / Effort / Coût estimé par tâche)
|
||||
- Effort levels avec exemples concrets de prompts calibrés (low/medium/high/max)
|
||||
- Patterns model-per-agent : planner (Opus), implementer (Haiku), architecture-reviewer (Opus)
|
||||
- Tableau "When Thinking Helps vs. Wastes Tokens"
|
||||
- Cross-refs vers OpusPlan, Rev the Engine, Cost Awareness
|
||||
- **3 nouveaux agent templates** (`examples/agents/`)
|
||||
- `planner.md` — Opus, read-only, stratégie avant implémentation
|
||||
- `implementer.md` — Haiku, exécution mécanique, note d'escalade vers Sonnet si logique métier
|
||||
- `architecture-reviewer.md` — Opus, review critique read-only, protocole de vérification avant assertion
|
||||
- **7 nouvelles questions quiz** (09-037 → 09-043) dans `quiz/questions/09-advanced-patterns.yaml`
|
||||
- Couvre : choix modèle par tâche, frontmatter `model:`, paramètre `effort`, Adaptive Thinking Opus 4.6
|
||||
|
||||
### Changed
|
||||
|
||||
- **3 tables redondantes remplacées** par cross-refs vers Section 2.5 :
|
||||
- Tactical Model Selection Matrix (Section 4)
|
||||
- Cost-Effective Model Selection (Section 12)
|
||||
- Model Selection Matrix (Section 9.13)
|
||||
- **Effort levels enrichis** (Section 9 Adaptive Thinking) : exemples de prompts concrets ajoutés + cross-ref vers 2.5
|
||||
- **Sections 2.6→2.10 renommées** pour faire de la place à la nouvelle 2.5 (ex-Mental Model 2.5 → 2.6, etc.)
|
||||
- **Cheatsheet** : table condensée Quick Model Selection ajoutée (3 lignes + cross-ref)
|
||||
- **`examples/README.md`** : agents count 6 → 9, 3 nouvelles lignes dans le tableau
|
||||
- **`machine-readable/reference.yaml`** : stale line numbers corrigés, 4 nouvelles entrées
|
||||
|
||||
## [3.27.9] - 2026-02-21
|
||||
|
||||
### Documentation
|
||||
|
|
|
|||
32
README.md
32
README.md
|
|
@ -6,9 +6,9 @@
|
|||
|
||||
<p align="center">
|
||||
<a href="https://github.com/FlorianBruniaux/claude-code-ultimate-guide/stargazers"><img src="https://img.shields.io/github/stars/FlorianBruniaux/claude-code-ultimate-guide?style=for-the-badge" alt="Stars"/></a>
|
||||
<a href="./CHANGELOG.md"><img src="https://img.shields.io/badge/Updated-Feb_21,_2026_·_v3.27.9-brightgreen?style=for-the-badge" alt="Last Update"/></a>
|
||||
<a href="./quiz/"><img src="https://img.shields.io/badge/Quiz-274_questions-orange?style=for-the-badge" alt="Quiz"/></a>
|
||||
<a href="./examples/"><img src="https://img.shields.io/badge/Templates-172-green?style=for-the-badge" alt="Templates"/></a>
|
||||
<a href="./CHANGELOG.md"><img src="https://img.shields.io/badge/Updated-Feb_21,_2026_·_v3.28.0-brightgreen?style=for-the-badge" alt="Last Update"/></a>
|
||||
<a href="./quiz/"><img src="https://img.shields.io/badge/Quiz-271_questions-orange?style=for-the-badge" alt="Quiz"/></a>
|
||||
<a href="./examples/"><img src="https://img.shields.io/badge/Templates-175-green?style=for-the-badge" alt="Templates"/></a>
|
||||
<a href="./guide/security-hardening.md"><img src="https://img.shields.io/badge/🛡️_Threat_DB-19_CVEs_·_655_malicious_skills-red?style=for-the-badge" alt="Threat Database"/></a>
|
||||
</p>
|
||||
|
||||
|
|
@ -32,7 +32,7 @@
|
|||
- ✅ **Build mental models** — How Claude Code works internally (architecture, context flow, tool orchestration)
|
||||
- ✅ **Master methodologies** — TDD, SDD, BDD with AI collaboration (not just templates)
|
||||
- ✅ **Security mindset** — Threat modeling for AI systems (only guide with 18 CVEs + 341 malicious skills database)
|
||||
- ✅ **Test your knowledge** — 274-question quiz to validate understanding (no other resource offers this)
|
||||
- ✅ **Test your knowledge** — 271-question quiz to validate understanding (no other resource offers this)
|
||||
|
||||
**Outcome**: Go from copy-pasting configs to designing your own agentic workflows with confidence.
|
||||
|
||||
|
|
@ -48,9 +48,9 @@ Both guides serve different needs. Choose based on your priority.
|
|||
| **Quick setup** for projects | Available but not the priority | Battle-tested production configs |
|
||||
| **Learn trade-offs** (agents vs skills) | Decision frameworks + comparisons | Lists patterns, no trade-off analysis |
|
||||
| **Security hardening** | Only threat database (18 CVEs) | Basic patterns only |
|
||||
| **Test understanding** | 274-question quiz | Not available |
|
||||
| **Test understanding** | 271-question quiz | Not available |
|
||||
| **Methodologies** (TDD/SDD/BDD) | Full workflow guides | Not covered |
|
||||
| **Copy-paste ready** templates | 172 templates | 200+ templates |
|
||||
| **Copy-paste ready** templates | 175 templates | 200+ templates |
|
||||
|
||||
### Ecosystem Positioning
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ Both guides serve different needs. Choose based on your priority.
|
|||
1. **Security-First** — 18 CVEs + 341 malicious skills tracked (no competitor has this depth)
|
||||
2. **Methodology Workflows** — TDD/SDD/BDD comparison + step-by-step guides
|
||||
3. **Comprehensive Reference** — 19K lines across 16 specialized guides (24× more reference material than everything-cc)
|
||||
4. **Educational Progression** — 274-question quiz, beginner → expert path
|
||||
4. **Educational Progression** — 271-question quiz, beginner → expert path
|
||||
|
||||
**Recommended workflow:**
|
||||
1. Learn concepts here (mental models, trade-offs, security)
|
||||
|
|
@ -136,8 +136,8 @@ graph LR
|
|||
root[📦 Repository<br/>Root]
|
||||
|
||||
root --> guide[📖 guide/<br/>19K lines]
|
||||
root --> examples[📋 examples/<br/>172 templates]
|
||||
root --> quiz[🧠 quiz/<br/>274 questions]
|
||||
root --> examples[📋 examples/<br/>175 templates]
|
||||
root --> quiz[🧠 quiz/<br/>271 questions]
|
||||
root --> tools[🔧 tools/<br/>utils]
|
||||
root --> machine[🤖 machine-readable/<br/>AI index]
|
||||
root --> docs[📚 docs/<br/>83 evaluations]
|
||||
|
|
@ -166,14 +166,14 @@ graph LR
|
|||
│ ├─ mcp-servers-ecosystem.md Official & community MCP servers
|
||||
│ └─ workflows/ Step-by-step guides
|
||||
│
|
||||
├─ 📋 examples/ 172 Production Templates
|
||||
│ ├─ agents/ 6 custom AI personas
|
||||
├─ 📋 examples/ 175 Production Templates
|
||||
│ ├─ agents/ 9 custom AI personas
|
||||
│ ├─ commands/ 26 slash commands
|
||||
│ ├─ hooks/ 31 hooks (bash + PowerShell)
|
||||
│ ├─ skills/ 14 skills (9 on SkillHub)
|
||||
│ └─ scripts/ Utility scripts (audit, search)
|
||||
│
|
||||
├─ 🧠 quiz/ 264 Questions
|
||||
├─ 🧠 quiz/ 271 Questions
|
||||
│ ├─ 9 categories Setup, Agents, MCP, Trust, Advanced...
|
||||
│ ├─ 4 profiles Junior, Senior, Power User, PM
|
||||
│ └─ Instant feedback Doc links + score tracking
|
||||
|
|
@ -224,7 +224,7 @@ graph LR
|
|||
|
||||
---
|
||||
|
||||
### 📝 264-Question Knowledge Validation (Unique in Ecosystem)
|
||||
### 📝 271-Question Knowledge Validation (Unique in Ecosystem)
|
||||
|
||||
**Outcome**: Verify your understanding + identify knowledge gaps.
|
||||
|
||||
|
|
@ -680,7 +680,7 @@ Use this guide critically. Experiment. Share what works for you.
|
|||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>Knowledge Quiz</strong> (274 questions)</summary>
|
||||
<summary><strong>Knowledge Quiz</strong> (271 questions)</summary>
|
||||
|
||||
Test your Claude Code knowledge with an interactive CLI quiz covering all guide sections.
|
||||
|
||||
|
|
@ -770,12 +770,12 @@ See [CONTRIBUTING.md](./CONTRIBUTING.md) for guidelines.
|
|||
|
||||
### Tools
|
||||
- [Ask Zread](https://zread.ai/FlorianBruniaux/claude-code-ultimate-guide) — Ask questions about this guide
|
||||
- [Interactive Quiz](./quiz/) — 274 questions
|
||||
- [Interactive Quiz](./quiz/) — 271 questions
|
||||
- [Landing Site](https://florianbruniaux.github.io/claude-code-ultimate-guide-landing/) — Visual navigation
|
||||
|
||||
---
|
||||
|
||||
*Version 3.27.9 | Updated daily · Feb 21, 2026 | Crafted with Claude*
|
||||
*Version 3.28.0 | Updated daily · Feb 21, 2026 | Crafted with Claude*
|
||||
|
||||
<!-- SEO Keywords -->
|
||||
<!-- claude code, claude code tutorial, anthropic cli, ai coding assistant, claude code mcp,
|
||||
|
|
|
|||
2
VERSION
2
VERSION
|
|
@ -1 +1 @@
|
|||
3.27.9
|
||||
3.28.0
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Annotated templates that teach you **why** patterns work, not just how to config
|
|||
|
||||
| Folder | Description | Count |
|
||||
|--------|-------------|-------|
|
||||
| [`agents/`](./agents/) | Custom AI personas for specialized tasks | 6 |
|
||||
| [`agents/`](./agents/) | Custom AI personas for specialized tasks | 9 |
|
||||
| [`commands/`](./commands/) | Slash commands (workflow automation) | 26 |
|
||||
| [`hooks/`](./hooks/) | Event-driven security & automation scripts | 31 |
|
||||
| [`skills/`](./skills/) | Reusable knowledge modules — [9 on SkillHub](https://skills.palebluedot.live/owner/FlorianBruniaux) | 13 |
|
||||
|
|
@ -53,7 +53,7 @@ Annotated templates that teach you **why** patterns work, not just how to config
|
|||
|
||||
## Templates Index
|
||||
|
||||
### Agents (6)
|
||||
### Agents (9)
|
||||
|
||||
| File | Purpose | Model |
|
||||
|------|---------|-------|
|
||||
|
|
@ -63,6 +63,9 @@ Annotated templates that teach you **why** patterns work, not just how to config
|
|||
| [refactoring-specialist.md](./agents/refactoring-specialist.md) | Clean code refactoring | Sonnet |
|
||||
| [output-evaluator.md](./agents/output-evaluator.md) | LLM-as-a-Judge quality gate | Haiku |
|
||||
| [devops-sre.md](./agents/devops-sre.md) | Infrastructure troubleshooting with FIRE framework | Sonnet |
|
||||
| [planner.md](./agents/planner.md) | Strategic planning — read-only, before implementation | Opus |
|
||||
| [implementer.md](./agents/implementer.md) | Mechanical execution — bounded scope | Haiku |
|
||||
| [architecture-reviewer.md](./agents/architecture-reviewer.md) | Architecture & design review — read-only | Opus |
|
||||
|
||||
### Skills (13) — [9 on SkillHub](https://skills.palebluedot.live/owner/FlorianBruniaux)
|
||||
|
||||
|
|
|
|||
89
examples/agents/architecture-reviewer.md
Normal file
89
examples/agents/architecture-reviewer.md
Normal file
|
|
@ -0,0 +1,89 @@
|
|||
---
|
||||
name: architecture-reviewer
|
||||
description: Architecture and design review agent — read-only. Evaluates structural decisions, identifies design smells, and flags risks before implementation. Never modifies code. Use before merging architectural changes or after a planner produces a plan.
|
||||
model: opus
|
||||
tools: Read, Grep, Glob
|
||||
---
|
||||
|
||||
# Architecture Reviewer Agent
|
||||
|
||||
Read-only critical review of architectural and design decisions. Produces a structured assessment with risks, alternatives, and recommendations. Never writes or edits files.
|
||||
|
||||
**Role**: Devil's advocate for structural decisions. Finds what the implementer will miss.
|
||||
|
||||
## Review Scope
|
||||
|
||||
| Dimension | What to Evaluate |
|
||||
|-----------|-----------------|
|
||||
| **Coupling** | Hidden dependencies, tight coupling between modules |
|
||||
| **Cohesion** | Single-responsibility violations, mixed concerns |
|
||||
| **Reversibility** | Is this decision easy to undo if wrong? |
|
||||
| **Scalability** | Does this break at 10x load / 10x data? |
|
||||
| **Security** | Attack surface, trust boundaries, data exposure |
|
||||
| **Testability** | Can this be unit tested without a running system? |
|
||||
| **Conventions** | Does this align with existing patterns in the codebase? |
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Architecture Review: [Feature/PR Name]
|
||||
|
||||
### Summary
|
||||
[2-3 sentence overall assessment]
|
||||
|
||||
### 🔴 Blockers (Must address before implementing)
|
||||
1. **[Issue]** — `path/to/file.ts`
|
||||
- **Problem**: [What's wrong]
|
||||
- **Risk**: [What breaks if left as-is]
|
||||
- **Alternative**: [Concrete alternative approach]
|
||||
|
||||
### 🟡 Concerns (Address in current iteration)
|
||||
[Same structure]
|
||||
|
||||
### 🟢 Suggestions (Next iteration or skip)
|
||||
[Same structure]
|
||||
|
||||
### ❓ Open Questions
|
||||
- [ ] [Decision that needs human input]
|
||||
|
||||
### What's Solid
|
||||
[Specific patterns done well — be concrete, reference file:line]
|
||||
```
|
||||
|
||||
## Verification Protocol
|
||||
|
||||
Before making any architectural claim:
|
||||
1. **Verify file existence**: Use Glob to confirm referenced files exist
|
||||
2. **Verify patterns**: Use Grep to count pattern occurrences before calling them "established"
|
||||
3. **Read full context**: Don't judge from a snippet — read the whole file for coupling analysis
|
||||
|
||||
```
|
||||
Pattern >5 occurrences = Established (note if new code deviates)
|
||||
Pattern 2-5 occurrences = Emerging (ask if intentional)
|
||||
Pattern 1 occurrence = Isolated (don't generalize)
|
||||
```
|
||||
|
||||
## When to Use
|
||||
|
||||
- After planner produces a plan, before handing off to implementer
|
||||
- Before merging any PR touching >3 files or introducing new abstractions
|
||||
- When the team is unsure about a design decision
|
||||
- For security-sensitive features (auth, payments, data access)
|
||||
|
||||
## What This Agent Does NOT Do
|
||||
|
||||
- Write code or modify files
|
||||
- Perform security audits (use `security-auditor` for OWASP-level review)
|
||||
- Review style or formatting (use `code-reviewer`)
|
||||
- Test the implementation (use `test-writer`)
|
||||
|
||||
## Model Rationale
|
||||
|
||||
Architecture decisions are expensive to reverse. Opus's reasoning depth is justified here: a missed coupling or a wrong abstraction caught in review costs minutes to fix; the same issue found post-implementation costs days. This agent runs once per significant change — the Opus cost is amortized across all the implementation work it protects.
|
||||
|
||||
---
|
||||
|
||||
**Sources**:
|
||||
- Model Selection Guide: [Section 2.5](../guide/ultimate-guide.md#25-model-selection--thinking-guide)
|
||||
- Code Reviewer (for style/quality review): [code-reviewer.md](./code-reviewer.md)
|
||||
- Security Auditor (for OWASP review): [security-auditor.md](./security-auditor.md)
|
||||
65
examples/agents/implementer.md
Normal file
65
examples/agents/implementer.md
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
name: implementer
|
||||
description: Mechanical execution agent for bounded, well-defined tasks. Scope and approach must be explicit in the task prompt. Use after a planner has produced a plan. For complex logic or design decisions, use Sonnet instead.
|
||||
model: haiku
|
||||
tools: Write, Edit, Bash, Read, Grep, Glob
|
||||
---
|
||||
|
||||
# Implementer Agent
|
||||
|
||||
Mechanical execution agent. Translates a clear, bounded plan into code. No design decisions — those belong in the planner phase.
|
||||
|
||||
**Role**: Execute what's specified. Flag if the task requires judgment beyond mechanics.
|
||||
|
||||
## What "Mechanical" Means
|
||||
|
||||
Haiku is cost-effective for tasks where:
|
||||
- The approach is already decided (by the planner or the user)
|
||||
- Patterns are repetitive (rename, boilerplate, format, migration scripts)
|
||||
- Logic is simple (no business rules, no edge-case reasoning)
|
||||
- Scope is bounded (specific files listed, specific function names)
|
||||
|
||||
## When to Escalate to Sonnet
|
||||
|
||||
If during implementation you encounter:
|
||||
- A decision the task prompt doesn't answer
|
||||
- Complex conditional logic requiring judgment
|
||||
- Integration with external APIs where error handling strategy is unclear
|
||||
- Security-sensitive code (auth, encryption, data access)
|
||||
|
||||
**→ Stop and report**: "This task requires design decisions beyond mechanical execution. Delegate to Sonnet."
|
||||
|
||||
## Task Prompt Requirements
|
||||
|
||||
For this agent to work effectively, the calling prompt must include:
|
||||
|
||||
```
|
||||
Files: [explicit list of files to modify]
|
||||
Approach: [exact pattern to apply]
|
||||
Example: [before/after or reference implementation]
|
||||
Out of scope: [what NOT to touch]
|
||||
```
|
||||
|
||||
## Anti-patterns to Avoid
|
||||
|
||||
- **Don't invent scope**: Only touch files explicitly listed
|
||||
- **Don't make architecture decisions**: Ask the user or stop and report
|
||||
- **Don't add features**: Implement exactly what's specified, nothing more
|
||||
- **Don't break tests**: Run tests after changes if a test command is provided
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Read the referenced files to understand current state
|
||||
2. Apply the specified pattern to each file
|
||||
3. Verify the changes compile / tests pass (if test command provided)
|
||||
4. Report: files modified, what changed, any escalations needed
|
||||
|
||||
## Model Rationale
|
||||
|
||||
Haiku is 60x cheaper than Opus for input tokens. Mechanical tasks — renames, format migrations, boilerplate generation — don't benefit from deeper reasoning. Cost savings from Haiku on mechanical work fund Opus usage where it matters (architecture, security).
|
||||
|
||||
---
|
||||
|
||||
**Sources**:
|
||||
- Model Selection Guide: [Section 2.5](../guide/ultimate-guide.md#25-model-selection--thinking-guide)
|
||||
- Planner/Implementer pattern: [Section 2.5 Model per Agent Patterns](../guide/ultimate-guide.md#model-per-agent-patterns)
|
||||
64
examples/agents/planner.md
Normal file
64
examples/agents/planner.md
Normal file
|
|
@ -0,0 +1,64 @@
|
|||
---
|
||||
name: planner
|
||||
description: Strategic planning agent — read-only exploration before implementation. Use to decompose tasks, analyze codebases, and produce a detailed plan. Never modifies files.
|
||||
model: opus
|
||||
tools: Read, Grep, Glob
|
||||
---
|
||||
|
||||
# Planner Agent
|
||||
|
||||
Read-only strategic planning. Analyzes the codebase, identifies dependencies, and produces a structured implementation plan without touching any files.
|
||||
|
||||
**Role**: Strategy before action. Always run planner before implementer on non-trivial tasks.
|
||||
|
||||
## Responsibilities
|
||||
|
||||
1. **Understand scope**: Read relevant files, trace dependencies, identify affected components
|
||||
2. **Identify risks**: Flag breaking changes, tight couplings, missing test coverage
|
||||
3. **Produce plan**: Ordered steps with file paths and rationale
|
||||
4. **Call out unknowns**: List what needs clarification before implementation starts
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Plan: [Task Name]
|
||||
|
||||
### Scope
|
||||
- Files to modify: [list]
|
||||
- Files to read for context: [list]
|
||||
- External dependencies: [list]
|
||||
|
||||
### Implementation Steps
|
||||
1. [Step] — `path/to/file.ts` — [rationale]
|
||||
2. [Step] — `path/to/other.ts` — [rationale]
|
||||
...
|
||||
|
||||
### Risks
|
||||
- [Risk]: [Mitigation]
|
||||
|
||||
### Open Questions
|
||||
- [ ] [Question that needs human input before proceeding]
|
||||
```
|
||||
|
||||
## Anti-patterns to Avoid
|
||||
|
||||
- **Don't implement**: Any file write or edit is out of scope
|
||||
- **Don't assume**: Verify file paths and function signatures with Glob/Grep/Read before including them in the plan
|
||||
- **Don't over-plan**: Stop at the level of detail an implementer needs — not API docs
|
||||
|
||||
## When to Use
|
||||
|
||||
- Before any task touching >3 files
|
||||
- Before architectural changes
|
||||
- When the user asks `/plan` or enters Plan Mode
|
||||
- As the "think" phase in OpusPlan mode (Opus → Sonnet handoff)
|
||||
|
||||
## Model Rationale
|
||||
|
||||
Opus is used here for its reasoning depth during planning. Planning errors compound — a wrong architecture decision in the plan propagates through all implementation steps. Sonnet or Haiku handle execution after the plan is validated.
|
||||
|
||||
---
|
||||
|
||||
**Sources**:
|
||||
- Model Selection Guide: [Section 2.5](../guide/ultimate-guide.md#25-model-selection--thinking-guide)
|
||||
- OpusPlan workflow: [Section 2.3](../guide/ultimate-guide.md#23-plan-mode)
|
||||
|
|
@ -12,7 +12,7 @@ tags: [cheatsheet, reference]
|
|||
|
||||
**Written with**: Claude (Anthropic)
|
||||
|
||||
**Version**: 3.27.9 | **Last Updated**: February 2026
|
||||
**Version**: 3.28.0 | **Last Updated**: February 2026
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -226,6 +226,16 @@ Model: Sonnet | Ctx: 89.5k | Cost: $2.11 | Ctx(u): 56.0%
|
|||
|
||||
**Required for**: features >3 files, architecture, complex debugging
|
||||
|
||||
### Quick Model Selection
|
||||
|
||||
| Task | Model | Effort |
|
||||
|------|-------|--------|
|
||||
| Rename, boilerplate, test gen | Haiku | low |
|
||||
| Feature dev, debug, refactor | Sonnet | medium–high |
|
||||
| Architecture, security audit | Opus | high–max |
|
||||
|
||||
> Full decision table with cost estimates: [Section 2.5 Model Selection & Thinking Guide](ultimate-guide.md#25-model-selection--thinking-guide)
|
||||
|
||||
### Dynamic Model Switching (Mid-Session)
|
||||
|
||||
**Pattern**: Start Sonnet (speed) → swap Opus (complexity) → back Sonnet
|
||||
|
|
@ -545,4 +555,4 @@ where.exe claude; claude doctor; claude mcp list
|
|||
|
||||
**Author**: Florian BRUNIAUX | [@Méthode Aristote](https://methode-aristote.fr) | Written with Claude
|
||||
|
||||
*Last updated: February 2026 | Version 3.27.9*
|
||||
*Last updated: February 2026 | Version 3.28.0*
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ tags: [guide, reference, workflows, agents, hooks, mcp, security]
|
|||
|
||||
**Last updated**: January 2026
|
||||
|
||||
**Version**: 3.27.9
|
||||
**Version**: 3.28.0
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -122,9 +122,12 @@ Context full → /compact or /clear
|
|||
- [2.2 Context Management](#22-context-management)
|
||||
- [2.3 Plan Mode](#23-plan-mode)
|
||||
- [2.4 Rewind](#24-rewind)
|
||||
- [2.5 Mental Model](#25-mental-model)
|
||||
- [2.6 Data Flow & Privacy](#26-data-flow--privacy)
|
||||
- [2.7 Under the Hood](#27-under-the-hood)
|
||||
- [2.5 Model Selection & Thinking Guide](#25-model-selection--thinking-guide)
|
||||
- [2.6 Mental Model](#26-mental-model)
|
||||
- [2.7 Structured Prompting with XML Tags](#27-structured-prompting-with-xml-tags)
|
||||
- [2.8 Semantic Anchors](#28-semantic-anchors)
|
||||
- [2.9 Data Flow & Privacy](#29-data-flow--privacy)
|
||||
- [2.10 Under the Hood](#210-under-the-hood)
|
||||
- [3. Memory & Settings](#3-memory--settings)
|
||||
- [3.1 Memory Files (CLAUDE.md)](#31-memory-files-claudemd)
|
||||
- [3.2 The .claude/ Folder Structure](#32-the-claude-folder-structure)
|
||||
|
|
@ -1293,7 +1296,7 @@ VERIFY: Login persists after browser refresh
|
|||
- **Skills**: Reusable workflows (`/review`, `/deploy`) for consistent execution
|
||||
- **Hooks**: Automated guardrails (lint, security, formatting) — zero manual effort
|
||||
|
||||
Start with CLAUDE.md in Week 1. See [§2.5 Mental Model](#from-chatbot-to-context-system) for the full framework.
|
||||
Start with CLAUDE.md in Week 1. See [§2.6 Mental Model](#from-chatbot-to-context-system) for the full framework.
|
||||
|
||||
### Quick Self-Check
|
||||
|
||||
|
|
@ -1311,7 +1314,7 @@ Before your next session, verify:
|
|||
|
||||
# 2. Core Concepts
|
||||
|
||||
_Quick jump:_ [The Interaction Loop](#21-the-interaction-loop) · [Context Management](#22-context-management) · [Plan Mode](#23-plan-mode) · [Rewind](#24-rewind) · [Mental Model](#25-mental-model) · [Data Flow & Privacy](#26-data-flow--privacy)
|
||||
_Quick jump:_ [The Interaction Loop](#21-the-interaction-loop) · [Context Management](#22-context-management) · [Plan Mode](#23-plan-mode) · [Rewind](#24-rewind) · [Model Selection](#25-model-selection--thinking-guide) · [Mental Model](#26-mental-model) · [Data Flow & Privacy](#29-data-flow--privacy)
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -2628,7 +2631,116 @@ For systematic experimentation, use the checkpoint pattern to create safe restor
|
|||
- Lightweight for quick experiments
|
||||
- Works across multiple files
|
||||
|
||||
## 2.5 Mental Model
|
||||
## 2.5 Model Selection & Thinking Guide
|
||||
|
||||
Choosing the right model for each task is the fastest ROI improvement most Claude Code users can make. One decision per task — no overthinking.
|
||||
|
||||
_Quick jump:_ [Decision Table](#decision-table) · [Effort Levels](#effort-levels) · [Model per Agent](#model-per-agent-patterns) · [When Thinking Helps](#when-thinking-helps-vs-wastes-tokens)
|
||||
|
||||
> **Cross-references**: [OpusPlan Mode](#opusplan-mode) · [Rev the Engine](#rev-the-engine) · [Cost Awareness](#cost-awareness--optimization)
|
||||
|
||||
---
|
||||
|
||||
### Decision Table
|
||||
|
||||
| Task | Model | Effort | Est. cost/task |
|
||||
|------|-------|--------|----------------|
|
||||
| Rename, format, boilerplate | Haiku | low | ~$0.02 |
|
||||
| Generate unit tests | Haiku | low | ~$0.03 |
|
||||
| CI/CD PR review (volume) | Haiku | low | ~$0.02 |
|
||||
| Feature dev, standard debug | Sonnet | medium | ~$0.23 |
|
||||
| Module refactoring | Sonnet | high | ~$0.75 |
|
||||
| System architecture | Opus | high | ~$1.25 |
|
||||
| Critical security audit | Opus | max | ~$2+ |
|
||||
| Multi-agent orchestration | Sonnet + Haiku | mixed | variable |
|
||||
|
||||
> **Note on costs**: Estimates based on API pricing (Haiku $0.25/$1.25 per MTok, Sonnet $3/$15, Opus $15/$75). Pro/Max subscribers pay a flat rate — prioritize quality over cost. Opus activates thinking by default. Toggle: `Alt+T`. See [Section 2.2](#cost-awareness--optimization) for full pricing breakdown.
|
||||
|
||||
---
|
||||
|
||||
### Effort Levels
|
||||
|
||||
The `effort` parameter (Opus 4.6 API) controls the model's **overall computational budget** — not just thinking tokens, but tool calls, verbosity, and analysis depth. Low effort = fewer tool calls, no preamble. High effort = more explanations, detailed analysis.
|
||||
|
||||
**Calibrated gradient — one real prompt per level:**
|
||||
|
||||
- **`low`** — Mechanical, no design decisions needed
|
||||
> `"Rename getUserById to findUserById across src/"` — Find-replace scope, zero reasoning required.
|
||||
|
||||
- **`medium`** — Clear pattern, defined scope, one concern
|
||||
> `"Convert fetchUser() in api/users.ts from callbacks to async/await"` — Pattern is known, scope bounded.
|
||||
|
||||
- **`high`** — Design decisions, edge cases, multiple concerns
|
||||
> `"Redesign error handling in the payment module: add retry logic, partial failure recovery, and idempotency guarantees"` — Architectural choices, not just pattern application.
|
||||
|
||||
- **`max`** _(Opus 4.6 only — returns error on other models)_ — Cross-system reasoning, irreversible decisions
|
||||
> `"Analyze the microservices event pipeline for race conditions across order-service, inventory-service, and notification-service"` — Multi-service hypothesis testing, adversarial thinking.
|
||||
|
||||
---
|
||||
|
||||
### Model per Agent Patterns
|
||||
|
||||
Assign models to agents based on **role**, not importance:
|
||||
|
||||
**Planner** (`examples/agents/planner.md`) — Strategy, read-only exploration
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: planner
|
||||
description: Strategic planning agent — read-only. Use before implementation.
|
||||
model: opus
|
||||
tools: Read, Grep, Glob
|
||||
---
|
||||
```
|
||||
|
||||
**Implementer** (`examples/agents/implementer.md`) — Mechanical execution, bounded scope
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: implementer
|
||||
description: Mechanical execution agent. Scope must be defined explicitly in the task.
|
||||
model: haiku
|
||||
tools: Write, Edit, Bash, Read, Grep, Glob
|
||||
---
|
||||
```
|
||||
|
||||
> **Note**: Haiku is for mechanical tasks only. If the implementation requires design decisions or complex business logic, use Sonnet — state this in the task prompt.
|
||||
|
||||
**Architecture Reviewer** (`examples/agents/architecture-reviewer.md`) — Critical design review
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: architecture-reviewer
|
||||
description: Architecture and design review — read-only. Never modifies code.
|
||||
model: opus
|
||||
tools: Read, Grep, Glob
|
||||
---
|
||||
```
|
||||
|
||||
> **Pro tip**: Add a model reminder to your CLAUDE.md:
|
||||
> ```
|
||||
> # Model reminder
|
||||
> Default: Sonnet. Haiku for mechanical tasks. Opus for architecture and security audits.
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
### When Thinking Helps vs. Wastes Tokens
|
||||
|
||||
| Scenario | Thinking | Reason |
|
||||
|----------|----------|--------|
|
||||
| Rename 50 files | OFF | Zero reasoning — pure mechanics |
|
||||
| Bug spanning 3+ services | ON (high) | Multi-layer hypothesis testing |
|
||||
| Boilerplate / test generation | OFF | Repetitive pattern, no decisions |
|
||||
| Architecture migration | ON (max) | Irreversible decisions |
|
||||
| Direct factual questions | OFF (low) | Immediate answer sufficient |
|
||||
| Security code review | ON (high) | Adversarial reasoning needed |
|
||||
|
||||
Toggle: `Alt+T` (current session) · `/config` (permanent)
|
||||
|
||||
---
|
||||
|
||||
## 2.6 Mental Model
|
||||
|
||||
Understanding how Claude Code "thinks" makes you more effective.
|
||||
|
||||
|
|
@ -2670,7 +2782,7 @@ Understanding how Claude Code "thinks" makes you more effective.
|
|||
3. **Your Intent**: Claude needs clear instructions
|
||||
4. **Hidden Files**: Claude respects .gitignore by default
|
||||
|
||||
> **⚠️ Pattern Amplification**: Claude mirrors the patterns it finds. In well-structured codebases, it produces consistent, idiomatic code. In messy codebases without clear abstractions, it perpetuates the mess. If your code lacks good patterns, provide them explicitly in CLAUDE.md or use semantic anchors (Section 2.7).
|
||||
> **⚠️ Pattern Amplification**: Claude mirrors the patterns it finds. In well-structured codebases, it produces consistent, idiomatic code. In messy codebases without clear abstractions, it perpetuates the mess. If your code lacks good patterns, provide them explicitly in CLAUDE.md or use semantic anchors (Section 2.8).
|
||||
|
||||
### You Are the Main Thread
|
||||
|
||||
|
|
@ -2756,7 +2868,7 @@ Login is broken
|
|||
|
||||
The more context you provide, the better Claude can help.
|
||||
|
||||
## 2.6 Structured Prompting with XML Tags
|
||||
## 2.7 Structured Prompting with XML Tags
|
||||
|
||||
XML-structured prompts provide **semantic organization** for complex requests, helping Claude distinguish between different aspects of your task for clearer understanding and better results.
|
||||
|
||||
|
|
@ -3209,7 +3321,7 @@ cat claudedocs/templates/code-review.xml | \
|
|||
|
||||
> **Source**: [DeepTo Claude Code Guide - XML-Structured Prompts](https://cc.deeptoai.com/docs/en/best-practices/claude-code-comprehensive-guide)
|
||||
|
||||
### 2.6.1 Prompting as Provocation
|
||||
### 2.7.1 Prompting as Provocation
|
||||
|
||||
The Claude Code team internally treats prompts as **challenges to a peer**, not instructions to an assistant. This subtle shift produces higher-quality outputs because it forces Claude to prove its reasoning rather than simply comply.
|
||||
|
||||
|
|
@ -3243,7 +3355,7 @@ This forces a substantive second attempt with accumulated context rather than in
|
|||
|
||||
> **Source**: [10 Tips from Inside the Claude Code Team](https://paddo.dev/blog/claude-code-team-tips/) (Boris Cherny thread, Feb 2026)
|
||||
|
||||
## 2.7 Semantic Anchors
|
||||
## 2.8 Semantic Anchors
|
||||
|
||||
LLMs are statistical pattern matchers trained on massive text corpora. Using **precise technical vocabulary** helps Claude activate the right patterns in its training data, leading to higher-quality outputs.
|
||||
|
||||
|
|
@ -3284,7 +3396,7 @@ Follow these patterns:
|
|||
|
||||
### Combining with XML Tags
|
||||
|
||||
Semantic anchors work powerfully with XML-structured prompts (Section 2.6):
|
||||
Semantic anchors work powerfully with XML-structured prompts (Section 2.7):
|
||||
|
||||
```xml
|
||||
<instruction>
|
||||
|
|
@ -3336,7 +3448,7 @@ Semantic anchors work powerfully with XML-structured prompts (Section 2.6):
|
|||
|
||||
> **Source**: Concept by Alexandre Soyer. Original catalog: [github.com/LLM-Coding/Semantic-Anchors](https://github.com/LLM-Coding/Semantic-Anchors) (Apache-2.0)
|
||||
|
||||
## 2.8 Data Flow & Privacy
|
||||
## 2.9 Data Flow & Privacy
|
||||
|
||||
> **Important**: Everything you share with Claude Code is sent to Anthropic servers. Understanding this data flow is critical for protecting sensitive information.
|
||||
|
||||
|
|
@ -3392,7 +3504,7 @@ When you use Claude Code, the following data leaves your machine:
|
|||
|
||||
> **Full guide**: For complete privacy documentation including known risks, community incidents, and enterprise considerations, see [Data Privacy & Retention Guide](./data-privacy.md).
|
||||
|
||||
## 2.9 Under the Hood
|
||||
## 2.10 Under the Hood
|
||||
|
||||
> **Reading time**: 5 minutes
|
||||
> **Goal**: Understand the core architecture that powers Claude Code
|
||||
|
|
@ -4354,7 +4466,7 @@ The `.claude/` folder is your project's Claude Code directory for memory, settin
|
|||
| Personal preferences | `CLAUDE.md` | ❌ Gitignore |
|
||||
| Personal permissions | `settings.local.json` | ❌ Gitignore |
|
||||
|
||||
### 3.27.9 Version Control & Backup
|
||||
### 3.28.0 Version Control & Backup
|
||||
|
||||
**Problem**: Without version control, losing your Claude Code configuration means hours of manual reconfiguration across agents, skills, hooks, and MCP servers.
|
||||
|
||||
|
|
@ -5809,15 +5921,7 @@ Scope-focused agents for comprehensive PR review:
|
|||
|
||||
### Tactical Model Selection Matrix
|
||||
|
||||
| Task | Model | Justification |
|
||||
|------|-------|---------------|
|
||||
| Read and summarize a file | Haiku | Simple, fast |
|
||||
| Write a standard component | Sonnet | Good balance |
|
||||
| Debug complex issue | Opus (thinking default) | Depth needed |
|
||||
| System architecture | Opus | Maximum reasoning |
|
||||
| Critical security review | Opus | High stakes |
|
||||
| Generate tests | Haiku | Repetitive pattern |
|
||||
| Refactor 50 files | Sonnet orchestrate + Haiku workers | Optimized cost |
|
||||
> See [Section 2.5 Model Selection & Thinking Guide](#25-model-selection--thinking-guide) for the canonical decision table with effort levels and cost estimates.
|
||||
|
||||
**Cost Optimization Example**:
|
||||
```
|
||||
|
|
@ -10965,10 +11069,16 @@ The most powerful Claude Code pattern combines three techniques:
|
|||
**Key insight**: `effort` affects everything, even when thinking is disabled. Lower effort = fewer tool calls, more concise text. Higher effort = more tool calls with explanations, detailed analysis.
|
||||
|
||||
**Effort levels** (API only, official descriptions):
|
||||
- **`max`**: Maximum capability, no constraints. **Opus 4.6 only** (returns error on other models). Use for most complex tasks requiring unlimited reasoning depth.
|
||||
- **`max`**: Maximum capability, no constraints. **Opus 4.6 only** (returns error on other models). Cross-system reasoning, irreversible decisions.
|
||||
> Example: `"Analyze the microservices event pipeline for race conditions across order-service, inventory-service, and notification-service"`
|
||||
- **`high`** (default): Complex reasoning, coding, agentic tasks. Best for production workflows requiring deep analysis.
|
||||
> Example: `"Redesign error handling in the payment module: add retry logic, partial failure recovery, and idempotency guarantees"`
|
||||
- **`medium`**: Balance between speed, cost, and performance. Good for agentic tasks with moderate complexity.
|
||||
> Example: `"Convert fetchUser() in api/users.ts from callbacks to async/await"`
|
||||
- **`low`**: Most efficient. Ideal for classification, lookups, sub-agents, or tasks where speed matters more than depth.
|
||||
> Example: `"Rename getUserById to findUserById across src/"`
|
||||
|
||||
> See [Section 2.5 Model Selection & Thinking Guide](#25-model-selection--thinking-guide) for a complete decision table with effort, model, and cost estimates.
|
||||
|
||||
**API syntax**:
|
||||
```python
|
||||
|
|
@ -12926,14 +13036,7 @@ class UserManager {
|
|||
|
||||
**Cost-Effective Model Selection:**
|
||||
|
||||
| Task Type | Recommended Model | Reasoning |
|
||||
|-----------|------------------|-----------|
|
||||
| Typo fixes | Haiku | Simple, fast, cheap |
|
||||
| Feature implementation | Sonnet | Best balance |
|
||||
| Code review | Haiku/Sonnet | Depends on depth |
|
||||
| Architecture design | Opus (plan) → Sonnet (execute) | OpusPlan mode |
|
||||
| Complex debugging | Opus with thinking prompts | Worth the cost |
|
||||
| Batch operations | Sonnet | Efficient at scale |
|
||||
> See [Section 2.5 Model Selection & Thinking Guide](#25-model-selection--thinking-guide) for the canonical decision table with effort levels and cost estimates.
|
||||
|
||||
### Learning & Adoption Pitfalls
|
||||
|
||||
|
|
@ -13635,17 +13738,7 @@ Practical techniques to minimize API costs while maximizing productivity.
|
|||
|
||||
Choose the right model for each task to balance cost and capability.
|
||||
|
||||
| Task Type | Model | Cost | When to Use |
|
||||
|-----------|-------|------|-------------|
|
||||
| **Typo fixes** | Haiku | $ | Simple edits, obvious changes |
|
||||
| **Code review** | Haiku | $ | Linting, style checks, simple review |
|
||||
| **Unit tests** | Haiku | $ | Straightforward test generation |
|
||||
| **Feature implementation** | Sonnet | $$ | Most development work |
|
||||
| **Refactoring** | Sonnet | $$ | Code restructuring |
|
||||
| **Bug investigation** | Sonnet | $$ | Moderate debugging |
|
||||
| **Architecture design** | Opus | $$$ | System design, critical decisions |
|
||||
| **Complex debugging** | Opus | $$$ | Multi-layered issues |
|
||||
| **Critical reviews** | Opus | $$$ | Security audits, production code |
|
||||
> See [Section 2.5 Model Selection & Thinking Guide](#25-model-selection--thinking-guide) for the canonical decision table with effort levels and cost estimates.
|
||||
|
||||
**OpusPlan mode (recommended):**
|
||||
- **Planning**: Opus for high-level thinking
|
||||
|
|
@ -19976,4 +20069,4 @@ We'll evaluate and add it to this section if it meets quality criteria.
|
|||
|
||||
**Contributions**: Issues and PRs welcome.
|
||||
|
||||
**Last updated**: January 2026 | **Version**: 3.27.9
|
||||
**Last updated**: January 2026 | **Version**: 3.28.0
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
# Source: guide/ultimate-guide.md
|
||||
# Purpose: Condensed index for LLMs to quickly answer user questions about Claude Code
|
||||
|
||||
version: "3.27.9"
|
||||
version: "3.28.0"
|
||||
updated: "2026-02-17"
|
||||
|
||||
# ════════════════════════════════════════════════════════════════
|
||||
|
|
@ -69,6 +69,13 @@ deep_dive:
|
|||
session_migration_community_tool: "guide/observability.md:175"
|
||||
session_migration_issue: "https://github.com/anthropics/claude-code/issues/1516"
|
||||
session_migration_weller_skill: "https://github.com/jimweller/dotfiles/tree/main/dotfiles/claude-code/skills/claude-migrate-session"
|
||||
# Activity monitoring
|
||||
activity_monitoring: "guide/observability.md:467" # Tool call audit via JSONL
|
||||
activity_monitoring_queries: "guide/observability.md:492" # jq queries for audit
|
||||
activity_monitoring_alerts: "guide/observability.md:506" # Sensitive pattern detection
|
||||
external_monitoring_tools: "guide/observability.md:527" # ccusage, claude-code-otel, Akto, MLflow, ccboard
|
||||
proxying_claude_code: "guide/observability.md:581" # Proxyman, mitmproxy, ANTHROPIC_API_URL
|
||||
ccboard_activity_plan: "docs/resource-evaluations/ccboard-activity-module-plan.md"
|
||||
# Cost optimization - Local execution bridge
|
||||
bridge_script: "examples/scripts/bridge.py"
|
||||
bridge_schema: "examples/scripts/bridge-plan-schema.json"
|
||||
|
|
@ -230,7 +237,7 @@ deep_dive:
|
|||
third_party_toad: "https://github.com/batrachianai/toad"
|
||||
third_party_conductor: "https://docs.conductor.build"
|
||||
# Configuration Management & Backup (Added 2026-02-02)
|
||||
config_management_guide: "guide/ultimate-guide.md:4085" # Section 3.27.9
|
||||
config_management_guide: "guide/ultimate-guide.md:4085" # Section 3.28.0
|
||||
config_hierarchy: "guide/ultimate-guide.md:4095" # Global → Project → Local precedence
|
||||
config_git_strategy_project: "guide/ultimate-guide.md:4110" # What to commit in .claude/
|
||||
config_git_strategy_global: "guide/ultimate-guide.md:4133" # Version control ~/.claude/
|
||||
|
|
@ -329,9 +336,15 @@ deep_dive:
|
|||
# Debug Command (v2.1.30+) - Added 2026-02-09
|
||||
debug_command: 16280 # /debug in commands table
|
||||
debug_purpose: "Systematic troubleshooting and error investigation"
|
||||
# Opus 4.6 Features (Feb 2026) - Added 2026-02-09
|
||||
opus_4_6_adaptive_thinking: 9911
|
||||
opus_4_6_effort_parameter: 9985
|
||||
# Model Selection & Thinking Guide (Section 2.5) - Added 2026-02-21
|
||||
model_selection_guide: 2634 # Section 2.5 — canonical table, effort levels, agent patterns
|
||||
model_selection_anchor: "#25-model-selection--thinking-guide"
|
||||
planner_agent: "examples/agents/planner.md"
|
||||
implementer_agent: "examples/agents/implementer.md"
|
||||
architecture_reviewer_agent: "examples/agents/architecture-reviewer.md"
|
||||
# Opus 4.6 Features (Feb 2026) - Added 2026-02-09, line numbers updated 2026-02-21
|
||||
opus_4_6_adaptive_thinking: 11065
|
||||
opus_4_6_effort_parameter: 11071
|
||||
opus_4_6_pricing: 1722
|
||||
opus_4_6_api_breaking_changes: 10044
|
||||
opus_4_6_assistant_prefill_removed: 10047
|
||||
|
|
@ -1258,7 +1271,7 @@ ecosystem:
|
|||
- "Cross-links modified → Update all 4 repos"
|
||||
history:
|
||||
- date: "2026-01-20"
|
||||
event: "Code Landing sync v3.27.9, 66 templates, cross-links"
|
||||
event: "Code Landing sync v3.28.0, 66 templates, cross-links"
|
||||
commit: "5b5ce62"
|
||||
- date: "2026-01-20"
|
||||
event: "Cowork Landing fix (paths, README, UI badges)"
|
||||
|
|
@ -1270,7 +1283,7 @@ ecosystem:
|
|||
onboarding_matrix_meta:
|
||||
version: "2.0.0"
|
||||
last_updated: "2026-02-05"
|
||||
aligned_with_guide: "3.27.9"
|
||||
aligned_with_guide: "3.28.0"
|
||||
changelog:
|
||||
- version: "2.0.0"
|
||||
date: "2026-02-05"
|
||||
|
|
@ -1298,7 +1311,7 @@ onboarding_matrix:
|
|||
core: [rules, sandbox_native_guide, commands]
|
||||
time_budget: "5 min"
|
||||
topics_max: 3
|
||||
note: "SECURITY FIRST - sandbox before commands (v3.27.9 critical fix)"
|
||||
note: "SECURITY FIRST - sandbox before commands (v3.28.0 critical fix)"
|
||||
|
||||
beginner_15min:
|
||||
core: [rules, sandbox_native_guide, workflow, essential_commands]
|
||||
|
|
@ -1383,7 +1396,7 @@ onboarding_matrix:
|
|||
- default: agent_validation_checklist
|
||||
time_budget: "60 min"
|
||||
topics_max: 6
|
||||
note: "Dual-instance pattern for quality workflows (v3.27.9)"
|
||||
note: "Dual-instance pattern for quality workflows (v3.28.0)"
|
||||
|
||||
learn_security:
|
||||
intermediate_30min:
|
||||
|
|
@ -1394,7 +1407,7 @@ onboarding_matrix:
|
|||
- default: permission_modes
|
||||
time_budget: "30 min"
|
||||
topics_max: 4
|
||||
note: "NEW goal (v3.27.9) - Security-focused learning path"
|
||||
note: "NEW goal (v3.28.0) - Security-focused learning path"
|
||||
|
||||
power_60min:
|
||||
core: [sandbox_native_guide, mcp_secrets_management, security_hardening]
|
||||
|
|
@ -1419,7 +1432,7 @@ onboarding_matrix:
|
|||
core: [rules, sandbox_native_guide, workflow, essential_commands, context_management, plan_mode]
|
||||
time_budget: "60 min"
|
||||
topics_max: 6
|
||||
note: "Security foundation + core workflow (v3.27.9 sandbox added)"
|
||||
note: "Security foundation + core workflow (v3.28.0 sandbox added)"
|
||||
|
||||
intermediate_120min:
|
||||
core: [plan_mode, agents, skills, config_hierarchy, git_mcp_guide, hooks, mcp_servers]
|
||||
|
|
|
|||
|
|
@ -860,3 +860,207 @@ questions:
|
|||
file: "guide/workflows/agent-teams.md"
|
||||
section: "Cost Trade-offs"
|
||||
anchor: "#cost-trade-offs"
|
||||
|
||||
- id: "09-037"
|
||||
difficulty: "intermediate"
|
||||
profiles: ["intermediate", "senior", "power"]
|
||||
question: "You need to rename a function across 50 files. Which model and effort level is most appropriate?"
|
||||
options:
|
||||
a: "Opus, effort: max — renaming at scale requires deep reasoning"
|
||||
b: "Sonnet, effort: high — large scope requires careful analysis"
|
||||
c: "Haiku, effort: low — mechanical find-replace, no design decisions"
|
||||
d: "Sonnet, effort: medium — safe default for any multi-file operation"
|
||||
correct: "c"
|
||||
explanation: |
|
||||
**Haiku + low effort** is correct for mechanical tasks like renaming across files.
|
||||
|
||||
The key question: does this task require reasoning, design decisions, or judgment?
|
||||
- Rename = find-replace. Pattern is known, approach is decided.
|
||||
- No edge cases requiring analysis.
|
||||
- Haiku is 60x cheaper than Opus on input tokens.
|
||||
|
||||
Using Opus here wastes tokens on reasoning that doesn't add value.
|
||||
Save Opus for tasks where its depth changes the outcome.
|
||||
doc_reference:
|
||||
file: "guide/ultimate-guide.md"
|
||||
section: "2.5 Model Selection & Thinking Guide"
|
||||
anchor: "#25-model-selection--thinking-guide"
|
||||
|
||||
- id: "09-038"
|
||||
difficulty: "intermediate"
|
||||
profiles: ["intermediate", "senior", "power"]
|
||||
question: "What does `model: haiku` in an agent's YAML frontmatter do?"
|
||||
options:
|
||||
a: "Sets the agent's communication style to be more concise"
|
||||
b: "Forces the agent to use Haiku for all its sub-agent spawning"
|
||||
c: "Configures the agent to run on the Haiku model instead of the session default"
|
||||
d: "Enables cost-saving mode that reduces tool calls"
|
||||
correct: "c"
|
||||
explanation: |
|
||||
`model: haiku` in agent frontmatter sets the **model used for that specific agent**,
|
||||
overriding the session default.
|
||||
|
||||
This is how you implement the planner/implementer pattern:
|
||||
```yaml
|
||||
# planner.md
|
||||
model: opus # Deep reasoning for strategy
|
||||
|
||||
# implementer.md
|
||||
model: haiku # Cost-effective for mechanical execution
|
||||
```
|
||||
|
||||
Each agent runs independently with its configured model.
|
||||
The session model (your default Sonnet) is unaffected.
|
||||
doc_reference:
|
||||
file: "guide/ultimate-guide.md"
|
||||
section: "2.5 Model per Agent Patterns"
|
||||
anchor: "#model-per-agent-patterns"
|
||||
|
||||
- id: "09-039"
|
||||
difficulty: "senior"
|
||||
profiles: ["senior", "power"]
|
||||
question: "What does the `effort` parameter actually control in Opus 4.6?"
|
||||
options:
|
||||
a: "Only the thinking token budget (how many tokens for extended reasoning)"
|
||||
b: "The overall computational budget: thinking, tool calls, text verbosity, and analysis depth"
|
||||
c: "The maximum number of tool calls per response"
|
||||
d: "A quality gate that filters low-confidence outputs"
|
||||
correct: "b"
|
||||
explanation: |
|
||||
`effort` controls the **overall computational budget** — not just thinking.
|
||||
|
||||
At `effort: low`:
|
||||
- Fewer tool calls (combines operations when possible)
|
||||
- No explanatory preamble before actions
|
||||
- Concise responses
|
||||
|
||||
At `effort: high`:
|
||||
- More tool calls with detailed explanations
|
||||
- Describes plan before executing
|
||||
- Comprehensive analysis and summaries
|
||||
|
||||
This means `effort` affects behavior even when thinking is disabled (Alt+T off).
|
||||
It's a holistic efficiency dial, not a thinking toggle.
|
||||
doc_reference:
|
||||
file: "guide/ultimate-guide.md"
|
||||
section: "2.5 Effort Levels"
|
||||
anchor: "#effort-levels"
|
||||
|
||||
- id: "09-040"
|
||||
difficulty: "senior"
|
||||
profiles: ["senior", "power"]
|
||||
question: "What is the observable impact of `effort: low` on tool usage?"
|
||||
options:
|
||||
a: "Claude refuses to use any tools and responds from memory only"
|
||||
b: "Claude combines tool operations to minimize calls and skips explanatory preamble"
|
||||
c: "Claude limits itself to 3 tool calls maximum per response"
|
||||
d: "Claude uses only Read tools, no Write or Edit tools"
|
||||
correct: "b"
|
||||
explanation: |
|
||||
At `effort: low`, Claude optimizes for efficiency:
|
||||
|
||||
**Tool usage**: Combines operations that would normally be separate calls.
|
||||
Instead of Read → Analyze → Read → Analyze, it might do a single targeted Read.
|
||||
|
||||
**No preamble**: Skips "I'll now read the file to understand..." introductions.
|
||||
Actions happen directly, without narration.
|
||||
|
||||
**Result**: Faster, cheaper execution for tasks that don't need transparency.
|
||||
Best for sub-agents in automated pipelines, classification tasks, lookups.
|
||||
|
||||
Example task suited for `low`: `"Rename getUserById to findUserById across src/"`
|
||||
doc_reference:
|
||||
file: "guide/ultimate-guide.md"
|
||||
section: "2.5 Effort Levels"
|
||||
anchor: "#effort-levels"
|
||||
|
||||
- id: "09-041"
|
||||
difficulty: "senior"
|
||||
profiles: ["senior", "power"]
|
||||
question: "In the planner/implementer agent pattern, which model should each role use?"
|
||||
options:
|
||||
a: "Planner: Sonnet, Implementer: Haiku"
|
||||
b: "Planner: Opus, Implementer: Sonnet"
|
||||
c: "Planner: Opus, Implementer: Haiku"
|
||||
d: "Both: Sonnet (consistency matters more than cost)"
|
||||
correct: "c"
|
||||
explanation: |
|
||||
**Planner: Opus** — Strategy requires deep reasoning.
|
||||
Planning errors compound through all implementation steps.
|
||||
A wrong architecture decision caught at planning cost = minutes to fix.
|
||||
The same error found post-implementation = days.
|
||||
|
||||
**Implementer: Haiku** — Mechanical execution.
|
||||
The approach is already decided by the planner.
|
||||
No design decisions = no need for deep reasoning.
|
||||
Haiku is 60x cheaper than Opus on input tokens.
|
||||
|
||||
**When Haiku isn't enough**: If the implementation requires judgment calls,
|
||||
the implementer should stop and report rather than decide — or you use Sonnet instead.
|
||||
doc_reference:
|
||||
file: "guide/ultimate-guide.md"
|
||||
section: "2.5 Model per Agent Patterns"
|
||||
anchor: "#model-per-agent-patterns"
|
||||
|
||||
- id: "09-042"
|
||||
difficulty: "power"
|
||||
profiles: ["power"]
|
||||
question: "What is Adaptive Thinking in Opus 4.6, and how does it differ from Opus 4.5's thinking?"
|
||||
options:
|
||||
a: "Adaptive Thinking lets the model choose which language to respond in based on complexity"
|
||||
b: "The model dynamically allocates reasoning depth based on query complexity, replacing the fixed budget_tokens parameter"
|
||||
c: "Thinking is now split across multiple API calls for longer reasoning chains"
|
||||
d: "Adaptive Thinking is always-on at maximum depth, same as Opus 4.5 v2.0.67+"
|
||||
correct: "b"
|
||||
explanation: |
|
||||
**Opus 4.6 Adaptive Thinking** replaces the fixed `budget_tokens` approach.
|
||||
|
||||
| Version | Thinking Control |
|
||||
|---------|-----------------|
|
||||
| Opus 4.5 (pre-v2.0.67) | Keyword-triggered, fixed budgets (4K/10K/32K) |
|
||||
| Opus 4.5 (v2.0.67+) | Always-on at max budget, toggled with Alt+T |
|
||||
| **Opus 4.6** | Dynamic depth via `effort` parameter |
|
||||
|
||||
With Adaptive Thinking, the model decides HOW MUCH reasoning a query needs:
|
||||
- Simple lookup → minimal reasoning depth
|
||||
- Multi-system architecture analysis → maximum depth
|
||||
|
||||
`budget_tokens` is **deprecated** on Opus 4.6 and returns an error if used.
|
||||
doc_reference:
|
||||
file: "guide/ultimate-guide.md"
|
||||
section: "2.5 Effort Levels"
|
||||
anchor: "#effort-levels"
|
||||
|
||||
- id: "09-043"
|
||||
difficulty: "power"
|
||||
profiles: ["power"]
|
||||
question: "When should you use `effort: max`, and what happens if you use it on Sonnet?"
|
||||
options:
|
||||
a: "Use for any complex task; Sonnet silently downgrades to `effort: high`"
|
||||
b: "Use for cross-system reasoning on Opus 4.6 only; returns an API error on other models"
|
||||
c: "Use when you want maximum thinking tokens; works on all models but costs more"
|
||||
d: "Use for batch operations; Sonnet uses it to parallelize tool calls"
|
||||
correct: "b"
|
||||
explanation: |
|
||||
**`effort: max` is Opus 4.6 exclusive.**
|
||||
|
||||
Use it for tasks requiring:
|
||||
- Cross-system race condition analysis
|
||||
- Multi-service dependency tracing
|
||||
- Decisions that are expensive or impossible to reverse
|
||||
- Adversarial security reasoning across a full codebase
|
||||
|
||||
Example:
|
||||
```
|
||||
"Analyze the microservices event pipeline for race conditions across
|
||||
order-service, inventory-service, and notification-service"
|
||||
```
|
||||
|
||||
**On any other model** (Sonnet, Haiku, Opus 4.5): API returns an error.
|
||||
It is not silently downgraded. You must explicitly use a different effort level.
|
||||
|
||||
`effort: high` is the default and works across models that support the parameter.
|
||||
doc_reference:
|
||||
file: "guide/ultimate-guide.md"
|
||||
section: "2.5 Effort Levels"
|
||||
anchor: "#effort-levels"
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue