chore(claude): tier model pins across commands, agents, and templates

.claude/commands/add-component.md

@@ -1,3 +1,9 @@
+---
+description: "Add a new DaisyUI component with full test coverage and documentation. Use when creating a component that doesn't exist yet."
+model: sonnet
+argument-hint: "component name in snake_case (e.g., floating_label, bottom_nav)"
+---
+
 # Add New Component
 
 Create a new DaisyUI component with full test coverage and documentation.

.claude/commands/audit-components.md

@@ -1,3 +1,8 @@
+---
+description: "Audit all gem components against DaisyUI 5 documentation for inconsistencies. Use when checking alignment after a DaisyUI version bump."
+model: sonnet
+---
+
 # Audit All Components
 
 Check all gem components against DaisyUI 5 documentation for inconsistencies.

.claude/commands/check-component.md

@@ -1,3 +1,9 @@
+---
+description: "Compare a gem component against official DaisyUI 5 docs. Use when verifying a single component's alignment."
+model: sonnet
+argument-hint: "component name (e.g., button, card, modal)"
+---
+
 # Check Component Against DaisyUI 5
 
 Compare a gem component against the official DaisyUI 5 documentation.

.claude/commands/fix-docs-tests.md

@@ -1,3 +1,8 @@
+---
+description: "Run docs tests and fix any failures. Use when docs specs are red after component or example changes."
+model: sonnet
+---
+
 # Fix Docs Tests
 
 Run docs tests and fix any failures.

.claude/commands/github-ci-failures.md

@@ -1,6 +1,6 @@
 ---
 description: "Use when CI checks are failing on a PR — fetches failure logs, diagnoses root causes, implements fixes, and pushes until CI is green."
-model: claude-opus-4-6
+model: opus
 argument-hint: "PR number (e.g., 41 or #41)"
 allowed-tools: Bash(gh pr view:*), Bash(gh pr checks:*), Bash(gh pr diff:*), Bash(gh api:*), Bash(gh run view:*), Bash(git log:*), Bash(git diff:*), Bash(git push:*), Bash(git commit:*), Bash(git add:*), Bash(bundle exec:*), Read, Write, Edit, Glob, Grep, Agent
 ---

.claude/commands/github-review-comments.md

@@ -1,6 +1,6 @@
 ---
 description: "Use when a PR has unresolved review comments that need responses -- evaluates each comment, implements valid fixes, pushes back on incorrect suggestions, and resolves all threads."
-model: claude-opus-4-6
+model: opus
 argument-hint: "PR number (e.g., 123 or #123)"
 allowed-tools: Bash(gh pr view:*), Bash(gh pr diff:*), Bash(gh pr comment:*), Bash(gh api:*), Bash(git log:*), Bash(git blame:*), Bash(git push:*), Bash(git commit:*), Bash(git add:*), Bash(bundle exec:*), Read, Write, Edit, Glob, Grep, Agent
 ---

.claude/commands/lfg.md

@@ -1,6 +1,6 @@
 ---
 description: "Executes full autonomous engineering workflow with verification. Use when implementing complete features, tackling GitHub issues, or running end-to-end development cycles."
-model: claude-opus-4-6
+model: opus
 argument-hint: "GitHub issue number/URL or feature description"
 allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr create:*), Bash(gh pr view:*), Bash(bundle exec:*), Bash(git:*), Read, Write, Edit, Glob, Grep, Agent, mcp__daisyui__daisyUI-Snippets
 ---

.claude/commands/plan.md

@@ -0,0 +1,80 @@
+---
+description: "Investigates the codebase, designs a solution, and produces a durable plan artifact — a GitHub issue or a plan markdown under docs/plans/. Read-only: never edits application code. Use before /lfg for anything non-trivial."
+model: fable
+argument-hint: "issue <feature or problem> | md <feature or problem> | <feature or problem>"
+allowed-tools: Bash(gh issue create:*), Bash(gh issue list:*), Bash(gh issue view:*), Bash(gh search:*), Bash(gh label list:*), Bash(git log:*), Bash(git diff:*), Bash(git branch:*), Bash(date:*), Read, Grep, Glob, Write, Agent
+---
+
+# Plan — design expensive, execute cheap
+
+You are the planning specialist. This command runs on the most capable model deliberately: the thinking happens here, the execution happens later on cheaper models (`/lfg` on Opus, layer specialists on Sonnet). That split only works if the plan is **self-contained** — an executor with none of this session's context must be able to implement it without guessing.
+
+## Output mode from $ARGUMENTS
+
+| $ARGUMENTS starts with | Artifact |
+|------------------------|----------|
+| `issue` | GitHub issue (default — feeds directly into `/lfg <issue-number>`) |
+| `md` or `file` | Markdown file at `docs/plans/YYYY-MM-DD-<slug>.md` (date from `date +%F`) |
+| anything else | GitHub issue |
+
+## Hard constraints
+
+- **Read-only for source code.** Never edit application code, never commit, never create branches. The only file you may Write is a new plan markdown under `docs/plans/`.
+- **Never reproduce secrets** (keys, tokens, credentials) in the plan, even redacted ones you encounter while reading config.
+- **Dedupe before creating an issue**: `gh issue list --search "<keywords>"` — if an existing issue covers this, extend it in your summary instead of duplicating.
+
+## Phase 1 — Investigate
+
+Protect this session's context: delegate mechanical exploration to cheaper subagents and keep Fable for judgment.
+
+1. Fan out Explore agents (`model: haiku`) for file discovery and naming-convention sweeps; use `model: sonnet` agents when a subsystem needs to be read and summarized. Launch independent explorations in parallel.
+2. Read the load-bearing files yourself — the ones the design decision actually hinges on. Don't design from subagent summaries alone.
+3. Check CLAUDE.md and any layer-specific CLAUDE.md files for past decisions and gotchas.
+4. Check `git log` for recent related work; the design should extend it, not fight it.
+
+## Phase 2 — Design
+
+- Develop 2–3 candidate approaches with real tradeoffs. Pick one and say why; record why the others lost.
+- The chosen design must respect project invariants: Phlex components inheriting from DaisyUI::Base, register_modifiers with responsive comments, TDD (specs named before implementation steps), MCP server for DaisyUI class verification.
+- Decide the test strategy: unit specs for gem components in `spec/lib/daisy_ui/`, request/system specs for docs.
+
+## Phase 3 — Emit the plan artifact
+
+Use this structure for the issue body or markdown file. Every section is load-bearing — an executor uses Context to avoid re-discovery, Steps to act, Gates to verify, Boundaries to stop.
+
+```markdown
+# <Title>
+
+## Problem / Goal
+<What's wrong or missing, who it affects, what done looks like.>
+
+## Context (read these first)
+<Bullet list: `path/to/file.rb` — why it matters to this change. Include components, specs, docs examples, base class. Self-contained: no references to "as discussed" or this session.>
+
+## Decision
+<Chosen approach and rationale. Then: alternatives considered and why each was rejected.>
+
+## Implementation steps
+<Ordered, small, each mapped to a specialist where useful (/add-component, /check-component, /tdd). Specs come before the code they cover. Name exact files to create or change.>
+
+## Verification gates
+<Exact commands + expected outcome:>
+- `bundle exec rspec` — all green (gem)
+- `cd docs && bundle exec rspec` — all green (docs)
+- `bundle exec rubocop` — no offenses
+- `cd docs && bin/rubocop` — no offenses
+
+## Out of scope
+<Explicit boundaries — the adjacent things an eager executor must NOT do.>
+
+## Execution
+Execute with `/lfg <issue-number>` (or `/lfg docs/plans/<file>.md`).
+```
+
+For GitHub issues: create with `gh issue create --title "..." --body "$(cat <<'EOF' ... EOF)"` — single-quoted heredoc delimiter. Apply the `plan` label if it exists (`gh label list`); don't create labels.
+
+For markdown files: Write to `docs/plans/YYYY-MM-DD-<slug>.md`. Leave it uncommitted — committing is the user's call.
+
+## Phase 4 — Handoff
+
+Report back: link to the issue (or file path), the chosen approach in 2–3 sentences, and the exact execute command. Stop there — do not start implementing.

.claude/commands/review-pr.md

@@ -1,6 +1,6 @@
 ---
 description: Review a GitHub pull request for code quality, patterns, and best practices
-model: claude-opus-4-6
+model: opus
 argument-hint: "PR URL or number (e.g., 5 or https://github.com/mhenrixon/daisyui/pull/5)"
 ---
 

.claude/commands/tdd.md

@@ -1,5 +1,6 @@
 ---
 description: "Use when implementing any feature or fixing any bug -- enforces RED-GREEN-REFACTOR: write failing test first, implement minimum code to pass, then refactor."
+model: sonnet
 ---
 
 # TDD Command

.claude/commands/test-all.md

@@ -1,3 +1,8 @@
+---
+description: "Run the complete test suite for both the gem and docs site. Use after broad changes to verify nothing is broken."
+model: sonnet
+---
+
 # Run All Tests
 
 Run the complete test suite for both the gem and docs site.

CLAUDE.md

@@ -115,6 +115,26 @@ bundle exec rspec spec/system/           # Only system tests
 HEADLESS=false bundle exec rspec         # Watch browser tests run
 ```
 
+## Slash Commands
+
+| Command | Purpose |
+|---------|---------|
+| `/plan` | Fable-powered planning → GitHub issue or `docs/plans/` markdown (read-only; execute with `/lfg`) |
+| `/lfg` | Full autonomous engineering workflow with verification |
+| `/add-component` | Create a new DaisyUI component with tests and docs |
+| `/check-component` | Verify a single component against DaisyUI 5 spec |
+| `/audit-components` | Audit all components against DaisyUI 5 |
+| `/tdd` | RED → GREEN → REFACTOR cycle |
+| `/test-all` | Run complete test suite (gem + docs) |
+| `/fix-docs-tests` | Fix failing docs specs |
+| `/review-pr` | Review a GitHub PR for quality and patterns |
+| `/github-review-comments` | Respond to unresolved PR review comments |
+| `/github-ci-failures` | Diagnose and fix CI failures |
+
+### Model tier convention
+
+Commands and agents pin a model tier via frontmatter aliases: `haiku` for mechanical/config work, `sonnet` for layer specialists (the default), `opus` for orchestration and PR review, `fable` for read-only planning. Always use tier aliases, never full model IDs — aliases track the latest model in each tier. When spawning subagents for mechanical work (file finding, pattern scans), pass a cheaper model explicitly rather than letting them inherit the session model.
+
 ## CI Pipeline
 
 All jobs run in parallel: