القائمة
Use when choosing between Claude models for a task — decision tree for Haiku/Sonnet/Opus based on task type, cost estimates, escalation triggers, and cascade patterns.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | model-selection-guide |
| description | Use when choosing between Claude models for a task — decision tree for Haiku/Sonnet/Opus based on task type, cost estimates, escalation triggers, and cascade patterns. |
Step 1: Identify task type
Is this primarily reading + pattern matching + structured output?
→ Haiku (fast, cheap, accurate for structured tasks)
Examples: code review, lint check, classify intent, format output,
summarize doc, extract fields, check compliance
Is this implementation, debugging, or moderate reasoning?
→ Sonnet (balanced quality + cost)
Examples: write code, fix bug, explain concept, write tests,
analyze trade-offs (simple), build feature
Is this deep architecture, novel problem, or complex multi-step reasoning?
→ Opus (highest capability, use sparingly)
Examples: system design, architecture decisions, evaluate complex trade-offs,
research synthesis, "should we X or Y?" with many unknowns
Step 2: Apply cost heuristic
| Model | Relative cost | Speed | Best for |
|---|---|---|---|
| Haiku | $ (1x) | Fastest | Review, classify, format, extract |
| Sonnet | $$ (5x) | Fast | Implement, debug, explain, write |
| Opus | $$$$ (15x) | Slower | Design, architecture, deep analysis |
Step 3: Check override conditions
Use Opus even for "simple" tasks if:
Use Haiku even for "complex" tasks if:
| Workflow | Phase | Agent | Model | Why |
|---|---|---|---|---|
| feature | plan | @architect | Opus | Architecture decisions need deep reasoning |
| feature | implement | subagent | Sonnet | Code generation, balanced |
| feature | test | subagent | Sonnet | Test writing needs understanding |
| feature | review | @reviewer | Haiku | Pattern matching, structured output |
| bugfix | reproduce | subagent | Sonnet | Needs to understand codebase |
| bugfix | diagnose | @debugger | Sonnet | Systematic debugging |
| bugfix | fix | subagent | Sonnet | Code fix, minimal |
| bugfix | verify | @reviewer | Haiku | Check fix completeness |
| refactor | analyze | @architect | Opus | Understanding complex structure |
| refactor | plan | @architect | Opus | Design target state |
| refactor | implement | subagent | Sonnet | Mechanical refactoring |
| refactor | review | @reviewer | Haiku | Pattern check |
| research | gather | subagent | Sonnet | Information gathering |
| research | synthesize | @architect | Opus | Complex reasoning over options |
| research | document | @technical-writer | Haiku | Structured doc output |
| incident | triage | @debugger | Sonnet | Fast diagnosis |
| incident | hotfix | subagent | Sonnet | Minimal fix |
| incident | postmortem | @technical-writer | Haiku | Structured template |
When uncertain, start cheaper and escalate only if needed:
1. Try Haiku → evaluate output quality
2. If insufficient → escalate to Sonnet → evaluate
3. If still insufficient → escalate to Opus
4. Never auto-escalate without notifying user of cost increase
| Task type | Model | Estimated cost |
|---|---|---|
| Code review (500 lines) | Haiku | ~$0.01 |
| Bug fix (small) | Sonnet | ~$0.05-0.15 |
| Feature implementation | Sonnet | ~$0.10-0.50 |
| Architecture design | Opus | ~$0.50-2.00 |
| Research synthesis | Opus | ~$0.50-1.50 |
Cost reminder: Opus = 15x Haiku. Code review in Opus costs 15x more with same quality output.
workflow-templates — model assignments per phase come from this skill@workflow-model-advisor uses this as its decision framework@workflow-orchestrator reads model assignments when dispatching phase subagentsUse when conducting quality audits — reviewing process compliance, identifying gaps between defined process and actual practice, conducting structured inspections (code review audits, test quality reviews), and producing audit reports with remediation plans.
Use when managing quality risk — identifying quality risks in a product or release, applying risk-based testing prioritization, creating risk mitigation plans, and communicating quality risk to stakeholders for go/no-go decisions.
Use when designing or implementing test automation — choosing the right automation framework (Playwright, pytest, JUnit), Page Object Model, selector strategies, test isolation, managing flaky tests, and CI integration.
Use when managing defects — writing effective bug reports, applying severity/priority matrix, tracking defect lifecycle, conducting root cause analysis, and measuring defect metrics for process improvement.
Use when measuring and reporting QA quality — defect escape rate, test coverage analysis, flaky test rate, mean time to detect, shift-left metrics, and building quality dashboards for stakeholders.
Use when managing test data — designing test data strategies, using factories and builders, creating fixtures, generating synthetic data, masking PII for testing, and managing test database state.