docs: update model references to Sonnet 4.6 and Opus 4.6

Author: Habib0x0

CLAUDE.md

@@ -44,19 +44,19 @@ The plugin automatically uses the optimal model for each phase:
 | Agent | Model | Phase | Rationale |
 |-------|-------|-------|-----------|
 | spec-planner | Opus 4.6 | Requirements + Design | Deep reasoning for edge cases, security, architecture |
-| spec-tasker | Sonnet | Task breakdown | Fast, structured decomposition |
-| spec-validator | Sonnet | Validation | Checklist-based verification |
-| spec-implementer | Sonnet | Implementation | Writes code for tasks |
-| spec-tester | Sonnet | Testing | Verifies with Playwright/tests |
-| spec-reviewer | Opus | Review | Code quality, security, architecture |
-| spec-consultant | Sonnet | Consultation | Domain expert analysis during brainstorming (spawned by /spec-brainstorm) |
-| spec-acceptor | Sonnet | Acceptance | Requirement traceability, non-functional verification, formal sign-off |
-| spec-documenter | Sonnet | Documentation | Generates docs from spec and code |
-| spec-debugger | Sonnet | Debugging | Fixes issues when rejected |
+| spec-tasker | Sonnet 4.6 | Task breakdown | Fast, structured decomposition |
+| spec-validator | Sonnet 4.6 | Validation | Checklist-based verification |
+| spec-implementer | Sonnet 4.6 | Implementation | Writes code for tasks |
+| spec-tester | Sonnet 4.6 | Testing | Verifies with Playwright/tests |
+| spec-reviewer | Opus 4.6 | Review | Code quality, security, architecture |
+| spec-consultant | Sonnet 4.6 | Consultation | Domain expert analysis during brainstorming (spawned by /spec-brainstorm) |
+| spec-acceptor | Sonnet 4.6 | Acceptance | Requirement traceability, non-functional verification, formal sign-off |
+| spec-documenter | Sonnet 4.6 | Documentation | Generates docs from spec and code |
+| spec-debugger | Sonnet 4.6 | Debugging | Fixes issues when rejected |
 
 The `/spec` command delegates to these agents via the Task tool. Users don't need to manually switch models.
 
-For implementation after spec completion, Sonnet is recommended — the spec provides all the context needed for accurate code generation.
+For implementation after spec completion, Sonnet 4.6 is recommended — the spec provides all the context needed for accurate code generation.
 
 ## Key Concepts
 

docs/agents/index.md

@@ -9,21 +9,21 @@ Each agent is assigned the model that best fits its task. Reasoning-heavy phases
 | Agent | Model | Phase | Why |
 |-------|-------|-------|-----|
 | [spec-planner](spec-planner.md) | Opus 4.6 | Requirements + Design | Deep reasoning for edge cases, security, and architectural tradeoffs |
-| [spec-tasker](spec-tasker.md) | Sonnet | Task breakdown | Fast, structured decomposition from a completed design |
-| [spec-validator](spec-validator.md) | Sonnet | Validation | Checklist-based verification across all three spec documents |
-| [spec-implementer](spec-implementer.md) | Sonnet | Implementation | Writes code and wires it into the running application |
-| [spec-tester](spec-tester.md) | Sonnet | Testing | Verifies features end-to-end using Playwright and test suites |
+| [spec-tasker](spec-tasker.md) | Sonnet 4.6 | Task breakdown | Fast, structured decomposition from a completed design |
+| [spec-validator](spec-validator.md) | Sonnet 4.6 | Validation | Checklist-based verification across all three spec documents |
+| [spec-implementer](spec-implementer.md) | Sonnet 4.6 | Implementation | Writes code and wires it into the running application |
+| [spec-tester](spec-tester.md) | Sonnet 4.6 | Testing | Verifies features end-to-end using Playwright and test suites |
 | [spec-reviewer](spec-reviewer.md) | Opus 4.6 | Code review | Catches security issues, architectural drift, and subtle bugs |
-| [spec-debugger](spec-debugger.md) | Sonnet | Debugging | Fixes issues identified by the Tester or Reviewer |
-| [spec-consultant](spec-consultant.md) | Sonnet | Brainstorm consultation | Domain expert analysis during `/spec-brainstorm` sessions |
-| [spec-acceptor](spec-acceptor.md) | Sonnet | Acceptance | Requirement traceability, non-functional verification, formal sign-off |
-| [spec-documenter](spec-documenter.md) | Sonnet | Documentation | Generates API refs, user guides, and ADRs from spec and code |
+| [spec-debugger](spec-debugger.md) | Sonnet 4.6 | Debugging | Fixes issues identified by the Tester or Reviewer |
+| [spec-consultant](spec-consultant.md) | Sonnet 4.6 | Brainstorm consultation | Domain expert analysis during `/spec-brainstorm` sessions |
+| [spec-acceptor](spec-acceptor.md) | Sonnet 4.6 | Acceptance | Requirement traceability, non-functional verification, formal sign-off |
+| [spec-documenter](spec-documenter.md) | Sonnet 4.6 | Documentation | Generates API refs, user guides, and ADRs from spec and code |
 
 ## Agent Roles
 
 ### Planning pipeline
 
-**[spec-planner](spec-planner.md)** runs during `/spec` to produce `requirements.md` and `design.md`. It uses Opus to reason carefully about edge cases, security implications, and architectural tradeoffs before a single line of code is written.
+**[spec-planner](spec-planner.md)** runs during `/spec` to produce `requirements.md` and `design.md`. It uses Opus 4.6 to reason carefully about edge cases, security implications, and architectural tradeoffs before a single line of code is written.
 
 **[spec-tasker](spec-tasker.md)** picks up after the planner and breaks the design into discrete, trackable tasks organized across five phases: Setup, Core Implementation, Integration, Testing, and Polish. It syncs tasks to Claude Code's todo system.
 

docs/commands/index.md

@@ -26,7 +26,7 @@ All plugin commands are slash commands used within a Claude Code session. Execut
 |---------|-------------|---------------|
 | `/spec-exec` | Run one autonomous implementation iteration: pick a task, implement, wire, test, commit. | `/spec-exec` |
 | `/spec-loop` | Trigger the loop script from inside Claude Code. Runs until all tasks are verified. | `/spec-loop` |
-| `/spec-team` | Execute with a four-agent team: Implementer, Tester, Reviewer (Opus), Debugger. Higher token cost, stronger guarantees. | `/spec-team` |
+| `/spec-team` | Execute with a four-agent team: Implementer, Tester, Reviewer (Opus 4.6), Debugger. Higher token cost, stronger guarantees. | `/spec-team` |
 
 ## Post-implementation commands
 

docs/getting-started/concepts.md

@@ -83,14 +83,14 @@ The plugin automatically selects the appropriate model for each phase. You do no
 | Agent | Model | Phase | Rationale |
 |-------|-------|-------|-----------|
 | spec-planner | Opus 4.6 | Requirements + Design | Deep reasoning for edge cases, security, architecture |
-| spec-tasker | Sonnet | Task breakdown | Fast, structured decomposition |
-| spec-validator | Sonnet | Validation | Checklist-based verification |
-| spec-implementer | Sonnet | Implementation | Writes code for tasks |
-| spec-tester | Sonnet | Testing | Verifies with Playwright/tests |
-| spec-reviewer | Opus | Review | Code quality, security, architecture |
-| spec-consultant | Sonnet | Consultation | Domain expert analysis during brainstorming |
-| spec-acceptor | Sonnet | Acceptance | Requirement traceability, formal sign-off |
-| spec-documenter | Sonnet | Documentation | Generates docs from spec and code |
-| spec-debugger | Sonnet | Debugging | Fixes issues when rejected |
+| spec-tasker | Sonnet 4.6 | Task breakdown | Fast, structured decomposition |
+| spec-validator | Sonnet 4.6 | Validation | Checklist-based verification |
+| spec-implementer | Sonnet 4.6 | Implementation | Writes code for tasks |
+| spec-tester | Sonnet 4.6 | Testing | Verifies with Playwright/tests |
+| spec-reviewer | Opus 4.6 | Review | Code quality, security, architecture |
+| spec-consultant | Sonnet 4.6 | Consultation | Domain expert analysis during brainstorming |
+| spec-acceptor | Sonnet 4.6 | Acceptance | Requirement traceability, formal sign-off |
+| spec-documenter | Sonnet 4.6 | Documentation | Generates docs from spec and code |
+| spec-debugger | Sonnet 4.6 | Debugging | Fixes issues when rejected |
 
 Opus is used where careful reasoning matters most (planning and review). Sonnet handles the high-frequency work (implementation, testing, documentation).

docs/getting-started/quick-start.md

@@ -10,7 +10,7 @@ Run the `/spec` command with a feature name:
 /spec user-authentication
 ```
 
-The spec-planner agent (Opus) will ask if you want to start from a preset template or from scratch. For a new authentication feature, you might choose the preset to get pre-filled user stories covering common scenarios.
+The spec-planner agent (Opus 4.6) will ask if you want to start from a preset template or from scratch. For a new authentication feature, you might choose the preset to get pre-filled user stories covering common scenarios.
 
 The agent then guides you through two phases interactively:
 

docs/workflow/design.md

@@ -1,6 +1,6 @@
 # Design
 
-The design phase defines how the system will implement the requirements. It follows immediately after requirements in the `/spec` workflow, handled by the same spec-planner agent (Opus).
+The design phase defines how the system will implement the requirements. It follows immediately after requirements in the `/spec` workflow, handled by the same spec-planner agent (Opus 4.6).
 
 ## What goes in design.md
 

docs/workflow/execution.md

@@ -51,7 +51,7 @@ Implementer writes code
       |
 Tester verifies (Playwright / test suite)
       |
-  PASS -> Reviewer checks quality and security (Opus)
+  PASS -> Reviewer checks quality and security (Opus 4.6)
                |
            APPROVE -> commit
            REJECT  -> Debugger fixes -> back to Tester

docs/workflow/overview.md

@@ -18,7 +18,7 @@ See [Brainstorming](brainstorming.md).
 
 ## Stage 1: Requirements
 
-`/spec <feature-name>` starts the three-phase workflow. The spec-planner agent (Opus) guides you through:
+`/spec <feature-name>` starts the three-phase workflow. The spec-planner agent (Opus 4.6) guides you through:
 
 - Identifying user roles and their goals
 - Writing user stories in standard format
@@ -46,7 +46,7 @@ See [Design](design.md).
 
 ## Stage 3: Tasks
 
-The spec-tasker agent (Sonnet) breaks the design into discrete, trackable tasks:
+The spec-tasker agent (Sonnet 4.6) breaks the design into discrete, trackable tasks:
 
 - Five phases: Setup, Core Implementation, Integration, Testing, Polish
 - Each task has status, wired, and verified fields

docs/workflow/requirements.md

@@ -4,7 +4,7 @@ The requirements phase captures what the system must do. Every requirement is wr
 
 ## Starting requirements
 
-Run `/spec <feature-name>` to start. The spec-planner (Opus) will:
+Run `/spec <feature-name>` to start. The spec-planner (Opus 4.6) will:
 
 1. Ask clarifying questions about feature scope
 2. Identify user roles and their goals

docs/workflow/tasks.md

@@ -1,6 +1,6 @@
 # Tasks
 
-The tasks phase breaks the design into discrete, trackable implementation items. The spec-tasker agent (Sonnet) generates `tasks.md` and syncs tasks to Claude Code's todo system.
+The tasks phase breaks the design into discrete, trackable implementation items. The spec-tasker agent (Sonnet 4.6) generates `tasks.md` and syncs tasks to Claude Code's todo system.
 
 ## Task structure