From ba9e2c1700f151160b5711f882652ed7368443bc Mon Sep 17 00:00:00 2001 From: adthoms Date: Tue, 1 Sep 2026 17:43:05 -0700 Subject: [PATCH 1/2] feat: add fable as the escalation ceiling above opus in sdd Claude Code now exposes `fable` (Claude Fable, the tier above Opus) as a model alias, but the sdd plan-task and implement-task skills only knew the haiku/sonnet/opus ladder, so `--model fable` was not accepted and an `opus`-tier failure had nowhere to escalate. - Accept `fable` in the `--model` argument of plan-task and implement-task and in the `Model:` / `Reviewer model:` enums of the task file format. - Extend the escalation ladder to haiku -> sonnet -> opus -> fable; fable is the new ceiling. - Keep automatic selection unchanged: the tier tables still top out at opus, the Phase 3 / reviewer "+1" caps stay at opus, and fable is never pre-assigned. It is spent only after an opus attempt has failed or on explicit request, so no existing run changes cost or behaviour unless opus already failed. - Add a fable row to the cross-provider equivalence tables and a "fable pre-assigned" row to the tech-lead anti-pattern table; Judge 5 now checks that plans do not pre-assign fable. - Bump sdd to 3.7.0 and the marketplace to 3.11.0. Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_011j7h5Ytw56h4D198aHUKG6 --- .claude-plugin/marketplace.json | 4 ++-- docs/plugins/sdd/implement-task.md | 2 +- docs/plugins/sdd/plan-task.md | 2 +- plugins/sdd/.claude-plugin/plugin.json | 2 +- plugins/sdd/agents/tech-lead.md | 16 +++++++++------- plugins/sdd/skills/implement-task/SKILL.md | 12 ++++++------ plugins/sdd/skills/plan-task/SKILL.md | 17 +++++++++-------- 7 files changed, 29 insertions(+), 26 deletions(-) diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 4a9f0d1..7ec24a1 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -1,7 +1,7 @@ { "$schema": "https://anthropic.com/claude-code/marketplace.schema.json", "name": "context-engineering-kit", - "version": "3.10.0", + "version": "3.11.0", "description": "Hand-crafted collection of advanced context engineering techniques and patterns with minimal token footprint focused on improving agent result quality.", "owner": { "name": "NeoLabHQ", @@ -77,7 +77,7 @@ { "name": "sdd", "description": "Specification Driven Development workflow commands and agents, based on Github Spec Kit and OpenSpec. Uses specialized agents for effective context management and quality review.", - "version": "3.6.0", + "version": "3.7.0", "author": { "name": "Vlad Goncharov", "email": "vlad.goncharov@neolab.finance" diff --git a/docs/plugins/sdd/implement-task.md b/docs/plugins/sdd/implement-task.md index c6356be..8cdc9fc 100644 --- a/docs/plugins/sdd/implement-task.md +++ b/docs/plugins/sdd/implement-task.md @@ -22,7 +22,7 @@ Execute task implementation steps using automated LLM-as-Judge quality verificat | Argument | Format | Default | Description | |----------|--------|---------|-------------| | `task-file` | Path or filename | Auto-detect | Task file name or path (e.g., `add-validation.feature.md`). Auto-selects from `in-progress/` or `todo/` if only one task exists. | -| `--model` | `opus\|sonnet\|haiku` | Unset | Model for all sub-agents — implementation agents and `sdd:code-reviewer`. Overrides every model in the task specification file. When omitted, step models come from the Parallelization Overview and reviewer models from the Phase Overview. | +| `--model` | `fable\|opus\|sonnet\|haiku` | Unset | Model for all sub-agents — implementation agents and `sdd:code-reviewer`. Overrides every model in the task specification file. When omitted, step models come from the Parallelization Overview and reviewer models from the Phase Overview. | | `--target-quality` | `--target-quality X.X` | `4.0` | The single quality threshold applied to every implementation phase review. There is no separate standard/critical value and no comma-separated form. | | `--max-iterations` | `--max-iterations N` | `3` | Maximum fix→re-review cycles per implementation phase. Set to `unlimited` for no limit. | | `--human-in-the-loop` | `--human-in-the-loop [Phase 1,Phase 3,...]` | None | Implementation **phases** after whose review to pause. If no phases are specified, the process pauses after every implementation phase. | diff --git a/docs/plugins/sdd/plan-task.md b/docs/plugins/sdd/plan-task.md index 28e58f2..eaa187a 100644 --- a/docs/plugins/sdd/plan-task.md +++ b/docs/plugins/sdd/plan-task.md @@ -24,7 +24,7 @@ Refine a draft task specification into a fully planned, implementation-ready tas | `--skip-judges` | flag | `false` | Skip all judge validation checks | | `--refine` | flag | `false` | Detect changes via git diff and re-run only affected stages | | `--continue` | `--continue [stage]` | None | Resume from a specific stage (auto-detects if stage not provided) | -| `--model` | `opus\|sonnet\|haiku` | *auto-selected* | Explicit override for every planning agent and judge. When omitted, the orchestrator picks a baseline tier from the task's shape (`sonnet` is the working default; `opus` must be earned by a breadth, critical-domain or open-design trigger) and runs architecture synthesis one tier above it, capped at `opus`. | +| `--model` | `fable\|opus\|sonnet\|haiku` | *auto-selected* | Explicit override for every planning agent and judge. When omitted, the orchestrator picks a baseline tier from the task's shape (`sonnet` is the working default; `opus` must be earned by a breadth, critical-domain or open-design trigger) and runs architecture synthesis one tier above it, capped at `opus`. `fable` is never auto-selected: escalation reaches it only after an `opus` attempt has failed. | | `--strict` | flag | `false` | Disable iteration discretion — a phase passes ONLY when its score reaches the threshold, otherwise retry until `--max-iterations` | ## Stage Names diff --git a/plugins/sdd/.claude-plugin/plugin.json b/plugins/sdd/.claude-plugin/plugin.json index ca6580e..7f1cd4d 100644 --- a/plugins/sdd/.claude-plugin/plugin.json +++ b/plugins/sdd/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "sdd", - "version": "3.6.0", + "version": "3.7.0", "description": "Specification Driven Development workflow commands and agents, based on Github Spec Kit and OpenSpec. Uses specialized agents for effective context management and quality review.", "author": { "name": "Vlad Goncharov", diff --git a/plugins/sdd/agents/tech-lead.md b/plugins/sdd/agents/tech-lead.md index dd95b09..bfb86b3 100644 --- a/plugins/sdd/agents/tech-lead.md +++ b/plugins/sdd/agents/tech-lead.md @@ -28,7 +28,7 @@ Use a scratchpad-first approach: think deeply and analyze everything in a scratc - **Task File**: Path to the task file (e.g., `.specs/tasks/draft/.md`) - Contains: Initial User Prompt, Description, Acceptance Criteria, Architecture Overview -- **Available agents** (optional): the launch prompt MAY list the agents available in this project (e.g. `sdd:developer`, `review:bug-hunter`, plus the general agents `opus`, `sonnet`, `haiku`). If it does, you MUST use ONLY agents from that list. If it does not, use the [Agent Selection Guide](#agent-selection-guide) below. +- **Available agents** (optional): the launch prompt MAY list the agents available in this project (e.g. `sdd:developer`, `review:bug-hunter`, plus the general agents `fable`, `opus`, `sonnet`, `haiku`). If it does, you MUST use ONLY agents from that list. If it does not, use the [Agent Selection Guide](#agent-selection-guide) below. - **Model Selection Policy** (optional): the launch prompt MAY paste a per-step model tier policy. If it does, apply it. If it does not, use the [Model Selection Guide](#model-selection-guide) below. ## CRITICAL: Load Context @@ -742,7 +742,7 @@ Model choice is not a formality — it is the single biggest factor in whether a **Selection Rules** -**Tier default:** `sonnet`/`haiku` cover the majority of steps. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure or "to be safe." +**Tier default:** `sonnet`/`haiku` cover the majority of steps. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure or "to be safe." `fable` sits above `opus` and is never pre-assigned to a step or a reviewer: no row below selects it. It is reserved for implementation-time escalation after `opus` has failed, or for an explicit `--model fable`. | Step shape | Tier | Examples | |---|---|---| @@ -763,6 +763,7 @@ When this skill runs outside the Anthropic model context, map the tier to the ne | `haiku` | Fast and cheap; mechanical work | `gemini-flash-lite`, `gemma` class, `gpt-oss` class, small open-weight models | | `sonnet` | Balanced workhorse; most planning phases | `gemini-pro` class and full `gemini-flash` (**not** the `-lite` variant, which is `haiku`-tier), `GPT-5-mini` class, large `Qwen` / `DeepSeek` class | | `opus` | Frontier reasoning; critical or complex work | whatever the provider sells as its extended / deliberate-reasoning tier — currently `GPT-5.5`, deep-think modes, `Kimi K3` class, any model whose advantage is longer deliberation rather than throughput | +| `fable` | Ceiling; reached only by escalation or explicit request | Anthropic's Claude Fable, the tier above Opus. On another provider, the deliberate-reasoning edition it sells *above* its `opus`-class model (`-pro`, `-ultra`, deep-think variants); if the provider has no such tier, map `fable` to the same model as `opus` and the ladder ends there | The mapping is by **capability tier, not by name** — exact names drift as vendors ship new models. Every rule above is expressed in tiers, so on another provider: map tier → your model of that class, then apply the selection, weighting, pairing and escalation rules unchanged. @@ -784,7 +785,7 @@ Each step has an implementation model. Each **phase** additionally has a **revie - Take the HIGHEST implementation tier in the phase as the baseline, then decide whether to go one tier up. - Go one tier up (the usual case) when the phase mixes concerns, crosses a contract, or its checklist items are the essential ones. - Stay at the same tier when the phase is small, uniform and mechanical and the higher tier would add nothing — e.g. a phase of two `sonnet` steps that both apply one established pattern may keep `sonnet`. -- `opus` is the ceiling; a phase containing an `opus` step is reviewed by `opus`. +- `opus` is the highest tier this rule assigns; a phase containing an `opus` step is reviewed by `opus`. `fable` is not pre-assigned as a reviewer — implementation-time escalation reaches it when an `opus` review lets a structural defect through. - Never review below the highest implementation tier used in the phase. ##### Common Mistakes to AVOID @@ -795,6 +796,7 @@ Each step has an implementation model. Each **phase** additionally has a **revie | `developer` for writing README | README is documentation | `tech-writer` | | `opus` "to be safe" when unsure | `opus` must be EARNED by a breadth/critical/open-design trigger — uncertainty is not a trigger | `sonnet` (the tie-breaker default); escalate later if the step turns out to need it | | `opus` for ordinary feature/fix/refactor work | Local design choices on an established pattern are exactly what `sonnet` is for | `sonnet` | +| `fable` pre-assigned to a step or reviewer | `fable` is the escalation ceiling, not a planning tier — a plan never spends it before `opus` has failed | `opus` (if earned); implementation escalates to `fable` when an `opus` attempt fails | | `haiku` for anything requiring judgment | Haiku is for mechanical tasks with no decisions | `sonnet` — jump straight to `opus` only if a breadth/critical/open-design trigger also fires | | `code-explorer` for fixing bugs | Explorer analyzes, doesn't implement | `developer` | | `researcher` for writing code | Researcher defines skills, doesn't code | `developer` | @@ -877,7 +879,7 @@ Write each step to its own file using this template. It is the step template — **Task File:** `.specs/tasks/todo/.md` **Phase:** Phase N -**Model:** [Model type - haiku/sonnet/opus] +**Model:** [Model type - haiku/sonnet/opus/fable] **Agent:** [Agent type - see Agent Selection Guide] **Depends on:** [List of step names, or "None"] **Parallel with:** [List of step names that share same dependencies, or "None"] @@ -1046,7 +1048,7 @@ Step 02a-... Step 02b-... Step 02c-... #### Phase 1 Steps: ``, ``, ... -Reviewer model: `` +Reviewer model: `` Acceptance Criteria that should be fulfiled: Checklist items: - `` @@ -1061,7 +1063,7 @@ Rubrics: #### Phase 2 Steps: ``, ``, ... -Reviewer model: `` +Reviewer model: `` Acceptance Criteria that should be fulfiled: Checklist items: - `` @@ -1078,7 +1080,7 @@ Rubrics: - The phase identifier is `Phase N`. You MAY append a short title after it (`#### Phase 1: Foundation`); the identifier must remain parseable as `Phase N`. - `Steps:` lists step names — the sub-task file basenames without `.md` — in execution order, backtick-quoted and comma-separated. -- `Reviewer model:` is exactly one of `haiku`, `sonnet`, `opus`. +- `Reviewer model:` is exactly one of `haiku`, `sonnet`, `opus`, `fable`. - Checklist items are cited by ID plus a short quote of the question, e.g. ``- `CK-3` — Does every public endpoint reject unauthenticated requests?`` - Rubrics are cited by criterion name exactly as written in the `**Rubric:**` table, e.g. ``- `Project Guidelines Alignment` ``. - If a phase has no rubric criteria due yet, write `Rubrics:` followed by `- None`. Never omit the heading. diff --git a/plugins/sdd/skills/implement-task/SKILL.md b/plugins/sdd/skills/implement-task/SKILL.md index 61dbfba..69583b4 100644 --- a/plugins/sdd/skills/implement-task/SKILL.md +++ b/plugins/sdd/skills/implement-task/SKILL.md @@ -1,7 +1,7 @@ --- name: implement-task description: Implement a task step by step with automated LLM-as-Judge verification at the end of each phase -argument-hint: Task file [--continue] [--refine] [--human-in-the-loop] [--target-quality] [--max-iterations] [--skip-reviews] [--model opus|sonnet|haiku] [--strict] +argument-hint: Task file [--continue] [--refine] [--human-in-the-loop] [--target-quality] [--max-iterations] [--skip-reviews] [--model fable|opus|sonnet|haiku] [--strict] --- # Implement Task with Verification @@ -43,7 +43,7 @@ Parse the following arguments from `$ARGUMENTS`: | `--target-quality` | `--target-quality X.X` | `4.0` | Single target threshold value (out of 5.0) applied to every implementation phase review. | | `--max-iterations` | `--max-iterations N` | `3` | Maximum fix→re-review cycles per implementation phase. Default is 3 iterations. Set to `unlimited` for no limit. | | `--skip-reviews` | `--skip-reviews` | `false` | Skip all phase reviews - steps proceed without quality gates. | -| `--model` | `opus\|sonnet\|haiku` | Unset | Model for **all** sub-agents (implementation agents AND `sdd:code-reviewer`) that **overrides** every model in the task file; when omitted, step models come from the Parallelization Overview and reviewer models from the Phase Overview. | +| `--model` | `fable\|opus\|sonnet\|haiku` | Unset | Model for **all** sub-agents (implementation agents AND `sdd:code-reviewer`) that **overrides** every model in the task file; when omitted, step models come from the Parallelization Overview and reviewer models from the Phase Overview. | | `--strict` | `--strict` | `false` | Disable the [Iteration Discretion Rule](#iteration-discretion-rule) - a phase is marked PASS ONLY when `combined_score >= THRESHOLD`, otherwise iterate until `MAX_ITERATIONS` is reached. | ### Configuration Resolution @@ -58,7 +58,7 @@ TASK_FILE = first argument that is a file path or filename THRESHOLD = --target-quality value || 4.0 # Initialize other defaults -MODEL_OVERRIDE = --model value (opus|sonnet|haiku) || none # none = no override; models come from the task file +MODEL_OVERRIDE = --model value (fable|opus|sonnet|haiku) || none # none = no override; models come from the task file MAX_ITERATIONS = --max-iterations || 3 # default is 3 iterations HUMAN_IN_THE_LOOP_PHASES = --human-in-the-loop || [] (empty = none, "*" = all implementation phases) SKIP_REVIEWS = --skip-reviews || false @@ -785,7 +785,7 @@ Before dispatching a single fix, reason **explicitly and in writing** through: 2. **Depth** — is this a local defect inside a step, or did the phase come out structurally wrong (`blast_radius.requires_phase_rework`)? 3. **Coupling** — does fixing the affected steps force rewriting the unaffected ones? If yes, the unit of repair is the phase, not the step. 4. **Severity** — High/Critical findings that break an acceptance criterion the phase owns, or Low/Medium nitpicks? -5. **Ceiling** — does the failure look like the implementing model ran out of capability? If a model already failed once on the same finding, dispatching it again at the same tier will fail again. Escalate. +5. **Ceiling** — does the failure look like the implementing model ran out of capability? If a model already failed once on the same finding, dispatching it again at the same tier will fail again. Escalate. The ladder is `haiku` → `sonnet` → `opus` → `fable`; `fable` is the last rung, so work that has already failed at `fable` goes back to the user, not to another dispatch. Then decide three things: @@ -1636,7 +1636,7 @@ Rubrics: ``` - The **phase identifier** is `Phase N` (a title may follow: `#### Phase 1: Foundation`). This exact identifier is what you pass to the reviewer. -- `Reviewer model:` is one of `haiku`, `sonnet`, `opus`. It is the model of that phase's single review dispatch. +- `Reviewer model:` is one of `haiku`, `sonnet`, `opus`, `fable`. It is the model of that phase's single review dispatch. - The `Checklist items:` and `Rubrics:` lists scope the reviewer's scoring. **They are the reviewer's input, not yours** — it reads them from the task file itself. Never paste them into a prompt. ### Sub-Task Files @@ -1648,7 +1648,7 @@ One per step, at `.specs/sub-tasks//-.md`, where `.md` **Phase:** Phase N -**Model:** haiku | sonnet | opus +**Model:** haiku | sonnet | opus | fable **Agent:** [agent type] **Depends on:** [step names or None] **Parallel with:** [step names or None] diff --git a/plugins/sdd/skills/plan-task/SKILL.md b/plugins/sdd/skills/plan-task/SKILL.md index e9265be..d1e7db0 100644 --- a/plugins/sdd/skills/plan-task/SKILL.md +++ b/plugins/sdd/skills/plan-task/SKILL.md @@ -1,7 +1,7 @@ --- name: plan-task description: Refine a draft task specification into a fully planned, implementation-ready task with acceptance criteria, architecture, per-step sub-task files and verifiable phases -argument-hint: Path to draft task file (e.g., ".specs/tasks/draft/add-validation.feature.md") [--continue] [--refine] [--target-quality] [--max-iterations] [--included-stages] [--skip] [--fast] [--one-shot] [--human-in-the-loop] [--skip-judges] [--strict] [--model haiku|sonnet|opus] +argument-hint: Path to draft task file (e.g., ".specs/tasks/draft/add-validation.feature.md") [--continue] [--refine] [--target-quality] [--max-iterations] [--included-stages] [--skip] [--fast] [--one-shot] [--human-in-the-loop] [--skip-judges] [--strict] [--model haiku|sonnet|opus|fable] --- # Refine Task Workflow @@ -48,7 +48,7 @@ Parse the following arguments from `$ARGUMENTS`: | `--human-in-the-loop` | `--human-in-the-loop phase1,phase2,...` | None | Phases after which to pause for human verification. | | `--skip-judges` | `--skip-judges` | `false` | Skip all judge validation checks - phases proceed without quality gates. | | `--refine` | `--refine` | `false` | Incremental refinement mode - detect changes against git and re-run only affected stages (top-to-bottom propagation). | -| `--model` | `haiku\|sonnet\|opus` | *auto-selected per the policy* | Explicit user override for all sub-agents. When omitted, resolve each phase's tier per the [Model Selection Policy](#model-selection-policy). See [Role Pairing](#role-pairing) for the override's effect and the [Escalation Rule](#escalation-rule) for how escalation interacts with it. | +| `--model` | `haiku\|sonnet\|opus\|fable` | *auto-selected per the policy* | Explicit user override for all sub-agents. When omitted, resolve each phase's tier per the [Model Selection Policy](#model-selection-policy). See [Role Pairing](#role-pairing) for the override's effect and the [Escalation Rule](#escalation-rule) for how escalation interacts with it. | | `--strict` | `--strict` | `false` | Disable the [Iteration Discretion Rule](#iteration-discretion-rule) - a phase passes ONLY when `score >= THRESHOLD`, otherwise retry until `MAX_ITERATIONS` is reached. | ### Stage Names (for `--included-stages` / `--skip`) @@ -373,7 +373,7 @@ This rule governs the `**Decision Logic:**` block of every phase: Picking the model is the **single highest-leverage decision** you make — more than any prompt wording, it decides whether the plan comes back correct and how long the run takes. You MUST NOT treat it as a formality: name the tier and give a one-line justification before dispatching **each** phase agent. Reaching for the strongest model because you did not want to think is a failure, not caution. -**Tier default:** `sonnet` is the working default, and `sonnet`/`haiku` cover the majority of runs. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure. +**Tier default:** `sonnet` is the working default, and `sonnet`/`haiku` cover the majority of runs. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure. `fable` sits above `opus` and is never selected by the table: it is reached only through the [Escalation Rule](#escalation-rule) after `opus` has failed, or through an explicit `--model fable`. ### Selection Rules @@ -398,7 +398,7 @@ Assess the **overall task being planned** — the draft task file's title and ty | Phase 3: Architecture Synthesis | **Heavy** — the only phase that makes open design decisions rather than applying settled ones; three inputs are synthesized here and every later phase, plus the implementation itself, inherits the result | **one tier above `BASELINE_TIER`**, capped at `opus` | | Phases 2a, 2b, 2c, 4 | Standard | `BASELINE_TIER` | -Every model-assigned phase appears in exactly ONE row, so each resolves to exactly ONE tier. The cap means an `opus` baseline leaves all phases at `opus`. [Promotion](#promote-task) is a file move you perform yourself — no sub-agent, no tier. See [Role Pairing](#role-pairing) for the `--model` override. +Every model-assigned phase appears in exactly ONE row, so each resolves to exactly ONE tier. The cap means an `opus` baseline leaves all phases at `opus`. `fable` is deliberately outside the cap: it is spent only after `opus` has failed (Escalation Rule) or on explicit request (`--model fable`), never pre-emptively. [Promotion](#promote-task) is a file move you perform yourself — no sub-agent, no tier. See [Role Pairing](#role-pairing) for the `--model` override. **Not to be confused with the per-step tiers inside the plan.** The tiers above govern the *planning* agents you launch. The `Model:` recorded in each sub-task file and the `Reviewer model:` recorded for each phase are decided by Phase 4 for the *implementation* run, from the per-step policy Phase 4's launch prompt carries — they are independent of `BASELINE_TIER`. @@ -415,7 +415,7 @@ Bump **BOTH the phase agent and its judge** one tier for the next iteration of t 1. **Low first-iteration quality** — a low score, or judge issues showing the model misunderstood the phase rather than merely missing details. 2. **The user complains** that quality is too low or the results are wrong — at any point, including after a reported PASS or a finished run. -Ladder: `haiku` → `sonnet` → `opus`. `opus` is the **ceiling** — there is no further tier. If `opus`-tier work still fails, report it and escalate to the **user**; never loop. +Ladder: `haiku` → `sonnet` → `opus` → `fable`. `fable` is the **ceiling** — there is no further tier, and escalation is the only automatic path onto it. If `fable`-tier work still fails, report it and escalate to the **user**; never loop. - **Sole exception — hold the tier (the ONLY statement of this rule, trigger (1) only):** when trigger (1) fires but the judge's issues are a specific, fixable defect rather than a capability gap (narrow, precisely specified problems the model clearly understood), you MAY hold the tier and re-launch the phase at the SAME tier with the judge's exact feedback instead of bumping. This is the ONLY circumstance in which the bump under trigger (1) is not mandatory; in every other case trigger (1) bumps. Trigger (2) has NO such exception — it always bumps immediately, per the carve-out below. - **Explicit `--model` carve-out (the ONLY statement of this rule):** an explicit `--model` is a user override, so trigger (1) MUST NOT silently overrule it — report the low-quality evidence, *propose* the bump, and re-launch at the user's tier unless they approve. Trigger (2) IS that approval, so it bumps immediately. @@ -434,6 +434,7 @@ When this skill runs outside the Anthropic model context, map the tier to the ne | `haiku` | Fast and cheap; mechanical work | `gemini-flash-lite`, `gemma` class, `gpt-oss` class, small open-weight models | | `sonnet` | Balanced workhorse; most planning phases | `gemini-pro` class and full `gemini-flash` (**not** the `-lite` variant, which is `haiku`-tier), `GPT-5-mini` class, large `Qwen` / `DeepSeek` class | | `opus` | Frontier reasoning; critical or complex work | whatever the provider sells as its extended / deliberate-reasoning tier — currently `GPT-5.5`, deep-think modes, `Kimi K3` class, any model whose advantage is longer deliberation rather than throughput | +| `fable` | Ceiling; reached only by escalation or explicit request | Anthropic's Claude Fable, the tier above Opus. On another provider, the deliberate-reasoning edition it sells *above* its `opus`-class model (`-pro`, `-ultra`, deep-think variants); if the provider has no such tier, map `fable` to the same model as `opus` and the ladder ends there | The mapping is by **capability tier, not by name** — exact names drift as vendors ship new models. Every rule above is expressed in tiers, so on another provider: map tier → your model of that class, then apply the selection, weighting, pairing and escalation rules unchanged. @@ -928,7 +929,7 @@ Launch agent: Task File: - Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: opus, sonnet, haiku} + Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: fable, opus, sonnet, haiku} Assign each step's model tier per this policy: {paste the Selection Rules table plus its Precedence and Tie-breaker paragraphs from the orchestrator's Model Selection Policy verbatim, applied per implementation step; drop the cross-reference links, which do not resolve outside that file} @@ -993,7 +994,7 @@ Launch judge: `## Acceptance Criteria`, written by an earlier phase). Verification is PHASE-level: each phase names one reviewer model; there are no per-step verification sections. - Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: opus, sonnet, haiku} + Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: fable, opus, sonnet, haiku} ### Rubric 1. Step Quality (weight: 0.15) @@ -1035,7 +1036,7 @@ Launch judge: 7. Agent/Model Selection Correctness (weight: 0.08) - Are agent types appropriate for what each step OUTPUTS, and drawn only from the provided available agents list? - - Does each step's `**Model:**` follow the per-step model policy — `opus` earned by a breadth, critical-domain or open-design trigger rather than picked to be safe, `haiku` only for mechanical work? + - Does each step's `**Model:**` follow the per-step model policy — `opus` earned by a breadth, critical-domain or open-design trigger rather than picked to be safe, `haiku` only for mechanical work, `fable` never pre-assigned (it is the implementation-time escalation ceiling, not a planning tier)? - 1=Wrong agents/tiers, 2=Mostly appropriate, 3=Acceptable, 4=Optimal selection, 5=Perfect selection 8. Phase Design (weight: 0.15) From 915eb7eae1a84e78954e20a42d8f43713c0795ef Mon Sep 17 00:00:00 2001 From: adthoms Date: Tue, 1 Sep 2026 17:43:05 -0700 Subject: [PATCH 2/2] chore: sync provider formats (gemini/antigravity bundle) Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_011j7h5Ytw56h4D198aHUKG6 --- agents/tech-lead.md | 16 +++++++++------- antigravity/agents/tech-lead.md | 16 +++++++++------- antigravity/skills/implement-task/SKILL.md | 10 +++++----- antigravity/skills/plan-task/SKILL.md | 15 ++++++++------- gemini-extension.json | 2 +- skills/implement-task/SKILL.md | 10 +++++----- skills/plan-task/SKILL.md | 15 ++++++++------- 7 files changed, 45 insertions(+), 39 deletions(-) diff --git a/agents/tech-lead.md b/agents/tech-lead.md index ea4b33e..088b4ef 100644 --- a/agents/tech-lead.md +++ b/agents/tech-lead.md @@ -27,7 +27,7 @@ Use a scratchpad-first approach: think deeply and analyze everything in a scratc - **Task File**: Path to the task file (e.g., `.specs/tasks/draft/.md`) - Contains: Initial User Prompt, Description, Acceptance Criteria, Architecture Overview -- **Available agents** (optional): the launch prompt MAY list the agents available in this project (e.g. `sdd:developer`, `review:bug-hunter`, plus the general agents `opus`, `sonnet`, `haiku`). If it does, you MUST use ONLY agents from that list. If it does not, use the [Agent Selection Guide](#agent-selection-guide) below. +- **Available agents** (optional): the launch prompt MAY list the agents available in this project (e.g. `sdd:developer`, `review:bug-hunter`, plus the general agents `fable`, `opus`, `sonnet`, `haiku`). If it does, you MUST use ONLY agents from that list. If it does not, use the [Agent Selection Guide](#agent-selection-guide) below. - **Model Selection Policy** (optional): the launch prompt MAY paste a per-step model tier policy. If it does, apply it. If it does not, use the [Model Selection Guide](#model-selection-guide) below. ## CRITICAL: Load Context @@ -741,7 +741,7 @@ Model choice is not a formality — it is the single biggest factor in whether a **Selection Rules** -**Tier default:** `sonnet`/`haiku` cover the majority of steps. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure or "to be safe." +**Tier default:** `sonnet`/`haiku` cover the majority of steps. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure or "to be safe." `fable` sits above `opus` and is never pre-assigned to a step or a reviewer: no row below selects it. It is reserved for implementation-time escalation after `opus` has failed, or for an explicit `--model fable`. | Step shape | Tier | Examples | |---|---|---| @@ -762,6 +762,7 @@ When this skill runs outside the Anthropic model context, map the tier to the ne | `haiku` | Fast and cheap; mechanical work | `gemini-flash-lite`, `gemma` class, `gpt-oss` class, small open-weight models | | `sonnet` | Balanced workhorse; most planning phases | `gemini-pro` class and full `gemini-flash` (**not** the `-lite` variant, which is `haiku`-tier), `GPT-5-mini` class, large `Qwen` / `DeepSeek` class | | `opus` | Frontier reasoning; critical or complex work | whatever the provider sells as its extended / deliberate-reasoning tier — currently `GPT-5.5`, deep-think modes, `Kimi K3` class, any model whose advantage is longer deliberation rather than throughput | +| `fable` | Ceiling; reached only by escalation or explicit request | Anthropic's Claude Fable, the tier above Opus. On another provider, the deliberate-reasoning edition it sells *above* its `opus`-class model (`-pro`, `-ultra`, deep-think variants); if the provider has no such tier, map `fable` to the same model as `opus` and the ladder ends there | The mapping is by **capability tier, not by name** — exact names drift as vendors ship new models. Every rule above is expressed in tiers, so on another provider: map tier → your model of that class, then apply the selection, weighting, pairing and escalation rules unchanged. @@ -783,7 +784,7 @@ Each step has an implementation model. Each **phase** additionally has a **revie - Take the HIGHEST implementation tier in the phase as the baseline, then decide whether to go one tier up. - Go one tier up (the usual case) when the phase mixes concerns, crosses a contract, or its checklist items are the essential ones. - Stay at the same tier when the phase is small, uniform and mechanical and the higher tier would add nothing — e.g. a phase of two `sonnet` steps that both apply one established pattern may keep `sonnet`. -- `opus` is the ceiling; a phase containing an `opus` step is reviewed by `opus`. +- `opus` is the highest tier this rule assigns; a phase containing an `opus` step is reviewed by `opus`. `fable` is not pre-assigned as a reviewer — implementation-time escalation reaches it when an `opus` review lets a structural defect through. - Never review below the highest implementation tier used in the phase. ##### Common Mistakes to AVOID @@ -794,6 +795,7 @@ Each step has an implementation model. Each **phase** additionally has a **revie | `developer` for writing README | README is documentation | `tech-writer` | | `opus` "to be safe" when unsure | `opus` must be EARNED by a breadth/critical/open-design trigger — uncertainty is not a trigger | `sonnet` (the tie-breaker default); escalate later if the step turns out to need it | | `opus` for ordinary feature/fix/refactor work | Local design choices on an established pattern are exactly what `sonnet` is for | `sonnet` | +| `fable` pre-assigned to a step or reviewer | `fable` is the escalation ceiling, not a planning tier — a plan never spends it before `opus` has failed | `opus` (if earned); implementation escalates to `fable` when an `opus` attempt fails | | `haiku` for anything requiring judgment | Haiku is for mechanical tasks with no decisions | `sonnet` — jump straight to `opus` only if a breadth/critical/open-design trigger also fires | | `code-explorer` for fixing bugs | Explorer analyzes, doesn't implement | `developer` | | `researcher` for writing code | Researcher defines skills, doesn't code | `developer` | @@ -876,7 +878,7 @@ Write each step to its own file using this template. It is the step template — **Task File:** `.specs/tasks/todo/.md` **Phase:** Phase N -**Model:** [Model type - haiku/sonnet/opus] +**Model:** [Model type - haiku/sonnet/opus/fable] **Agent:** [Agent type - see Agent Selection Guide] **Depends on:** [List of step names, or "None"] **Parallel with:** [List of step names that share same dependencies, or "None"] @@ -1045,7 +1047,7 @@ Step 02a-... Step 02b-... Step 02c-... #### Phase 1 Steps: ``, ``, ... -Reviewer model: `` +Reviewer model: `` Acceptance Criteria that should be fulfiled: Checklist items: - `` @@ -1060,7 +1062,7 @@ Rubrics: #### Phase 2 Steps: ``, ``, ... -Reviewer model: `` +Reviewer model: `` Acceptance Criteria that should be fulfiled: Checklist items: - `` @@ -1077,7 +1079,7 @@ Rubrics: - The phase identifier is `Phase N`. You MAY append a short title after it (`#### Phase 1: Foundation`); the identifier must remain parseable as `Phase N`. - `Steps:` lists step names — the sub-task file basenames without `.md` — in execution order, backtick-quoted and comma-separated. -- `Reviewer model:` is exactly one of `haiku`, `sonnet`, `opus`. +- `Reviewer model:` is exactly one of `haiku`, `sonnet`, `opus`, `fable`. - Checklist items are cited by ID plus a short quote of the question, e.g. ``- `CK-3` — Does every public endpoint reject unauthenticated requests?`` - Rubrics are cited by criterion name exactly as written in the `**Rubric:**` table, e.g. ``- `Project Guidelines Alignment` ``. - If a phase has no rubric criteria due yet, write `Rubrics:` followed by `- None`. Never omit the heading. diff --git a/antigravity/agents/tech-lead.md b/antigravity/agents/tech-lead.md index 21d4a0a..2644b48 100644 --- a/antigravity/agents/tech-lead.md +++ b/antigravity/agents/tech-lead.md @@ -31,7 +31,7 @@ Use a scratchpad-first approach: think deeply and analyze everything in a scratc - **Task File**: Path to the task file (e.g., `.specs/tasks/draft/.md`) - Contains: Initial User Prompt, Description, Acceptance Criteria, Architecture Overview -- **Available agents** (optional): the launch prompt MAY list the agents available in this project (e.g. `sdd:developer`, `review:bug-hunter`, plus the general agents `opus`, `sonnet`, `haiku`). If it does, you MUST use ONLY agents from that list. If it does not, use the [Agent Selection Guide](#agent-selection-guide) below. +- **Available agents** (optional): the launch prompt MAY list the agents available in this project (e.g. `sdd:developer`, `review:bug-hunter`, plus the general agents `fable`, `opus`, `sonnet`, `haiku`). If it does, you MUST use ONLY agents from that list. If it does not, use the [Agent Selection Guide](#agent-selection-guide) below. - **Model Selection Policy** (optional): the launch prompt MAY paste a per-step model tier policy. If it does, apply it. If it does not, use the [Model Selection Guide](#model-selection-guide) below. ## CRITICAL: Load Context @@ -745,7 +745,7 @@ Model choice is not a formality — it is the single biggest factor in whether a **Selection Rules** -**Tier default:** `sonnet`/`haiku` cover the majority of steps. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure or "to be safe." +**Tier default:** `sonnet`/`haiku` cover the majority of steps. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure or "to be safe." `fable` sits above `opus` and is never pre-assigned to a step or a reviewer: no row below selects it. It is reserved for implementation-time escalation after `opus` has failed, or for an explicit `--model fable`. | Step shape | Tier | Examples | |---|---|---| @@ -766,6 +766,7 @@ When this skill runs outside the Anthropic model context, map the tier to the ne | `haiku` | Fast and cheap; mechanical work | `gemini-flash-lite`, `gemma` class, `gpt-oss` class, small open-weight models | | `sonnet` | Balanced workhorse; most planning phases | `gemini-pro` class and full `gemini-flash` (**not** the `-lite` variant, which is `haiku`-tier), `GPT-5-mini` class, large `Qwen` / `DeepSeek` class | | `opus` | Frontier reasoning; critical or complex work | whatever the provider sells as its extended / deliberate-reasoning tier — currently `GPT-5.5`, deep-think modes, `Kimi K3` class, any model whose advantage is longer deliberation rather than throughput | +| `fable` | Ceiling; reached only by escalation or explicit request | Anthropic's Claude Fable, the tier above Opus. On another provider, the deliberate-reasoning edition it sells *above* its `opus`-class model (`-pro`, `-ultra`, deep-think variants); if the provider has no such tier, map `fable` to the same model as `opus` and the ladder ends there | The mapping is by **capability tier, not by name** — exact names drift as vendors ship new models. Every rule above is expressed in tiers, so on another provider: map tier → your model of that class, then apply the selection, weighting, pairing and escalation rules unchanged. @@ -787,7 +788,7 @@ Each step has an implementation model. Each **phase** additionally has a **revie - Take the HIGHEST implementation tier in the phase as the baseline, then decide whether to go one tier up. - Go one tier up (the usual case) when the phase mixes concerns, crosses a contract, or its checklist items are the essential ones. - Stay at the same tier when the phase is small, uniform and mechanical and the higher tier would add nothing — e.g. a phase of two `sonnet` steps that both apply one established pattern may keep `sonnet`. -- `opus` is the ceiling; a phase containing an `opus` step is reviewed by `opus`. +- `opus` is the highest tier this rule assigns; a phase containing an `opus` step is reviewed by `opus`. `fable` is not pre-assigned as a reviewer — implementation-time escalation reaches it when an `opus` review lets a structural defect through. - Never review below the highest implementation tier used in the phase. ##### Common Mistakes to AVOID @@ -798,6 +799,7 @@ Each step has an implementation model. Each **phase** additionally has a **revie | `developer` for writing README | README is documentation | `tech-writer` | | `opus` "to be safe" when unsure | `opus` must be EARNED by a breadth/critical/open-design trigger — uncertainty is not a trigger | `sonnet` (the tie-breaker default); escalate later if the step turns out to need it | | `opus` for ordinary feature/fix/refactor work | Local design choices on an established pattern are exactly what `sonnet` is for | `sonnet` | +| `fable` pre-assigned to a step or reviewer | `fable` is the escalation ceiling, not a planning tier — a plan never spends it before `opus` has failed | `opus` (if earned); implementation escalates to `fable` when an `opus` attempt fails | | `haiku` for anything requiring judgment | Haiku is for mechanical tasks with no decisions | `sonnet` — jump straight to `opus` only if a breadth/critical/open-design trigger also fires | | `code-explorer` for fixing bugs | Explorer analyzes, doesn't implement | `developer` | | `researcher` for writing code | Researcher defines skills, doesn't code | `developer` | @@ -880,7 +882,7 @@ Write each step to its own file using this template. It is the step template — **Task File:** `.specs/tasks/todo/.md` **Phase:** Phase N -**Model:** [Model type - haiku/sonnet/opus] +**Model:** [Model type - haiku/sonnet/opus/fable] **Agent:** [Agent type - see Agent Selection Guide] **Depends on:** [List of step names, or "None"] **Parallel with:** [List of step names that share same dependencies, or "None"] @@ -1049,7 +1051,7 @@ Step 02a-... Step 02b-... Step 02c-... #### Phase 1 Steps: ``, ``, ... -Reviewer model: `` +Reviewer model: `` Acceptance Criteria that should be fulfiled: Checklist items: - `` @@ -1064,7 +1066,7 @@ Rubrics: #### Phase 2 Steps: ``, ``, ... -Reviewer model: `` +Reviewer model: `` Acceptance Criteria that should be fulfiled: Checklist items: - `` @@ -1081,7 +1083,7 @@ Rubrics: - The phase identifier is `Phase N`. You MAY append a short title after it (`#### Phase 1: Foundation`); the identifier must remain parseable as `Phase N`. - `Steps:` lists step names — the sub-task file basenames without `.md` — in execution order, backtick-quoted and comma-separated. -- `Reviewer model:` is exactly one of `haiku`, `sonnet`, `opus`. +- `Reviewer model:` is exactly one of `haiku`, `sonnet`, `opus`, `fable`. - Checklist items are cited by ID plus a short quote of the question, e.g. ``- `CK-3` — Does every public endpoint reject unauthenticated requests?`` - Rubrics are cited by criterion name exactly as written in the `**Rubric:**` table, e.g. ``- `Project Guidelines Alignment` ``. - If a phase has no rubric criteria due yet, write `Rubrics:` followed by `- None`. Never omit the heading. diff --git a/antigravity/skills/implement-task/SKILL.md b/antigravity/skills/implement-task/SKILL.md index 548f14c..c13f482 100644 --- a/antigravity/skills/implement-task/SKILL.md +++ b/antigravity/skills/implement-task/SKILL.md @@ -42,7 +42,7 @@ Parse the following arguments from `$ARGUMENTS`: | `--target-quality` | `--target-quality X.X` | `4.0` | Single target threshold value (out of 5.0) applied to every implementation phase review. | | `--max-iterations` | `--max-iterations N` | `3` | Maximum fix→re-review cycles per implementation phase. Default is 3 iterations. Set to `unlimited` for no limit. | | `--skip-reviews` | `--skip-reviews` | `false` | Skip all phase reviews - steps proceed without quality gates. | -| `--model` | `opus\|sonnet\|haiku` | Unset | Model for **all** sub-agents (implementation agents AND `sdd:code-reviewer`) that **overrides** every model in the task file; when omitted, step models come from the Parallelization Overview and reviewer models from the Phase Overview. | +| `--model` | `fable\|opus\|sonnet\|haiku` | Unset | Model for **all** sub-agents (implementation agents AND `sdd:code-reviewer`) that **overrides** every model in the task file; when omitted, step models come from the Parallelization Overview and reviewer models from the Phase Overview. | | `--strict` | `--strict` | `false` | Disable the [Iteration Discretion Rule](#iteration-discretion-rule) - a phase is marked PASS ONLY when `combined_score >= THRESHOLD`, otherwise iterate until `MAX_ITERATIONS` is reached. | ### Configuration Resolution @@ -57,7 +57,7 @@ TASK_FILE = first argument that is a file path or filename THRESHOLD = --target-quality value || 4.0 # Initialize other defaults -MODEL_OVERRIDE = --model value (opus|sonnet|haiku) || none # none = no override; models come from the task file +MODEL_OVERRIDE = --model value (fable|opus|sonnet|haiku) || none # none = no override; models come from the task file MAX_ITERATIONS = --max-iterations || 3 # default is 3 iterations HUMAN_IN_THE_LOOP_PHASES = --human-in-the-loop || [] (empty = none, "*" = all implementation phases) SKIP_REVIEWS = --skip-reviews || false @@ -784,7 +784,7 @@ Before dispatching a single fix, reason **explicitly and in writing** through: 2. **Depth** — is this a local defect inside a step, or did the phase come out structurally wrong (`blast_radius.requires_phase_rework`)? 3. **Coupling** — does fixing the affected steps force rewriting the unaffected ones? If yes, the unit of repair is the phase, not the step. 4. **Severity** — High/Critical findings that break an acceptance criterion the phase owns, or Low/Medium nitpicks? -5. **Ceiling** — does the failure look like the implementing model ran out of capability? If a model already failed once on the same finding, dispatching it again at the same tier will fail again. Escalate. +5. **Ceiling** — does the failure look like the implementing model ran out of capability? If a model already failed once on the same finding, dispatching it again at the same tier will fail again. Escalate. The ladder is `haiku` → `sonnet` → `opus` → `fable`; `fable` is the last rung, so work that has already failed at `fable` goes back to the user, not to another dispatch. Then decide three things: @@ -1635,7 +1635,7 @@ Rubrics: ``` - The **phase identifier** is `Phase N` (a title may follow: `#### Phase 1: Foundation`). This exact identifier is what you pass to the reviewer. -- `Reviewer model:` is one of `haiku`, `sonnet`, `opus`. It is the model of that phase's single review dispatch. +- `Reviewer model:` is one of `haiku`, `sonnet`, `opus`, `fable`. It is the model of that phase's single review dispatch. - The `Checklist items:` and `Rubrics:` lists scope the reviewer's scoring. **They are the reviewer's input, not yours** — it reads them from the task file itself. Never paste them into a prompt. ### Sub-Task Files @@ -1647,7 +1647,7 @@ One per step, at `.specs/sub-tasks//-.md`, where `.md` **Phase:** Phase N -**Model:** haiku | sonnet | opus +**Model:** haiku | sonnet | opus | fable **Agent:** [agent type] **Depends on:** [step names or None] **Parallel with:** [step names or None] diff --git a/antigravity/skills/plan-task/SKILL.md b/antigravity/skills/plan-task/SKILL.md index 259af23..b2f8e88 100644 --- a/antigravity/skills/plan-task/SKILL.md +++ b/antigravity/skills/plan-task/SKILL.md @@ -47,7 +47,7 @@ Parse the following arguments from `$ARGUMENTS`: | `--human-in-the-loop` | `--human-in-the-loop phase1,phase2,...` | None | Phases after which to pause for human verification. | | `--skip-judges` | `--skip-judges` | `false` | Skip all judge validation checks - phases proceed without quality gates. | | `--refine` | `--refine` | `false` | Incremental refinement mode - detect changes against git and re-run only affected stages (top-to-bottom propagation). | -| `--model` | `haiku\|sonnet\|opus` | *auto-selected per the policy* | Explicit user override for all sub-agents. When omitted, resolve each phase's tier per the [Model Selection Policy](#model-selection-policy). See [Role Pairing](#role-pairing) for the override's effect and the [Escalation Rule](#escalation-rule) for how escalation interacts with it. | +| `--model` | `haiku\|sonnet\|opus\|fable` | *auto-selected per the policy* | Explicit user override for all sub-agents. When omitted, resolve each phase's tier per the [Model Selection Policy](#model-selection-policy). See [Role Pairing](#role-pairing) for the override's effect and the [Escalation Rule](#escalation-rule) for how escalation interacts with it. | | `--strict` | `--strict` | `false` | Disable the [Iteration Discretion Rule](#iteration-discretion-rule) - a phase passes ONLY when `score >= THRESHOLD`, otherwise retry until `MAX_ITERATIONS` is reached. | ### Stage Names (for `--included-stages` / `--skip`) @@ -372,7 +372,7 @@ This rule governs the `**Decision Logic:**` block of every phase: Picking the model is the **single highest-leverage decision** you make — more than any prompt wording, it decides whether the plan comes back correct and how long the run takes. You MUST NOT treat it as a formality: name the tier and give a one-line justification before dispatching **each** phase agent. Reaching for the strongest model because you did not want to think is a failure, not caution. -**Tier default:** `sonnet` is the working default, and `sonnet`/`haiku` cover the majority of runs. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure. +**Tier default:** `sonnet` is the working default, and `sonnet`/`haiku` cover the majority of runs. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure. `fable` sits above `opus` and is never selected by the table: it is reached only through the [Escalation Rule](#escalation-rule) after `opus` has failed, or through an explicit `--model fable`. ### Selection Rules @@ -397,7 +397,7 @@ Assess the **overall task being planned** — the draft task file's title and ty | Phase 3: Architecture Synthesis | **Heavy** — the only phase that makes open design decisions rather than applying settled ones; three inputs are synthesized here and every later phase, plus the implementation itself, inherits the result | **one tier above `BASELINE_TIER`**, capped at `opus` | | Phases 2a, 2b, 2c, 4 | Standard | `BASELINE_TIER` | -Every model-assigned phase appears in exactly ONE row, so each resolves to exactly ONE tier. The cap means an `opus` baseline leaves all phases at `opus`. [Promotion](#promote-task) is a file move you perform yourself — no sub-agent, no tier. See [Role Pairing](#role-pairing) for the `--model` override. +Every model-assigned phase appears in exactly ONE row, so each resolves to exactly ONE tier. The cap means an `opus` baseline leaves all phases at `opus`. `fable` is deliberately outside the cap: it is spent only after `opus` has failed (Escalation Rule) or on explicit request (`--model fable`), never pre-emptively. [Promotion](#promote-task) is a file move you perform yourself — no sub-agent, no tier. See [Role Pairing](#role-pairing) for the `--model` override. **Not to be confused with the per-step tiers inside the plan.** The tiers above govern the *planning* agents you launch. The `Model:` recorded in each sub-task file and the `Reviewer model:` recorded for each phase are decided by Phase 4 for the *implementation* run, from the per-step policy Phase 4's launch prompt carries — they are independent of `BASELINE_TIER`. @@ -414,7 +414,7 @@ Bump **BOTH the phase agent and its judge** one tier for the next iteration of t 1. **Low first-iteration quality** — a low score, or judge issues showing the model misunderstood the phase rather than merely missing details. 2. **The user complains** that quality is too low or the results are wrong — at any point, including after a reported PASS or a finished run. -Ladder: `haiku` → `sonnet` → `opus`. `opus` is the **ceiling** — there is no further tier. If `opus`-tier work still fails, report it and escalate to the **user**; never loop. +Ladder: `haiku` → `sonnet` → `opus` → `fable`. `fable` is the **ceiling** — there is no further tier, and escalation is the only automatic path onto it. If `fable`-tier work still fails, report it and escalate to the **user**; never loop. - **Sole exception — hold the tier (the ONLY statement of this rule, trigger (1) only):** when trigger (1) fires but the judge's issues are a specific, fixable defect rather than a capability gap (narrow, precisely specified problems the model clearly understood), you MAY hold the tier and re-launch the phase at the SAME tier with the judge's exact feedback instead of bumping. This is the ONLY circumstance in which the bump under trigger (1) is not mandatory; in every other case trigger (1) bumps. Trigger (2) has NO such exception — it always bumps immediately, per the carve-out below. - **Explicit `--model` carve-out (the ONLY statement of this rule):** an explicit `--model` is a user override, so trigger (1) MUST NOT silently overrule it — report the low-quality evidence, *propose* the bump, and re-launch at the user's tier unless they approve. Trigger (2) IS that approval, so it bumps immediately. @@ -433,6 +433,7 @@ When this skill runs outside the Anthropic model context, map the tier to the ne | `haiku` | Fast and cheap; mechanical work | `gemini-flash-lite`, `gemma` class, `gpt-oss` class, small open-weight models | | `sonnet` | Balanced workhorse; most planning phases | `gemini-pro` class and full `gemini-flash` (**not** the `-lite` variant, which is `haiku`-tier), `GPT-5-mini` class, large `Qwen` / `DeepSeek` class | | `opus` | Frontier reasoning; critical or complex work | whatever the provider sells as its extended / deliberate-reasoning tier — currently `GPT-5.5`, deep-think modes, `Kimi K3` class, any model whose advantage is longer deliberation rather than throughput | +| `fable` | Ceiling; reached only by escalation or explicit request | Anthropic's Claude Fable, the tier above Opus. On another provider, the deliberate-reasoning edition it sells *above* its `opus`-class model (`-pro`, `-ultra`, deep-think variants); if the provider has no such tier, map `fable` to the same model as `opus` and the ladder ends there | The mapping is by **capability tier, not by name** — exact names drift as vendors ship new models. Every rule above is expressed in tiers, so on another provider: map tier → your model of that class, then apply the selection, weighting, pairing and escalation rules unchanged. @@ -927,7 +928,7 @@ Launch agent: Task File: - Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: opus, sonnet, haiku} + Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: fable, opus, sonnet, haiku} Assign each step's model tier per this policy: {paste the Selection Rules table plus its Precedence and Tie-breaker paragraphs from the orchestrator's Model Selection Policy verbatim, applied per implementation step; drop the cross-reference links, which do not resolve outside that file} @@ -992,7 +993,7 @@ Launch judge: `## Acceptance Criteria`, written by an earlier phase). Verification is PHASE-level: each phase names one reviewer model; there are no per-step verification sections. - Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: opus, sonnet, haiku} + Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: fable, opus, sonnet, haiku} ### Rubric 1. Step Quality (weight: 0.15) @@ -1034,7 +1035,7 @@ Launch judge: 7. Agent/Model Selection Correctness (weight: 0.08) - Are agent types appropriate for what each step OUTPUTS, and drawn only from the provided available agents list? - - Does each step's `**Model:**` follow the per-step model policy — `opus` earned by a breadth, critical-domain or open-design trigger rather than picked to be safe, `haiku` only for mechanical work? + - Does each step's `**Model:**` follow the per-step model policy — `opus` earned by a breadth, critical-domain or open-design trigger rather than picked to be safe, `haiku` only for mechanical work, `fable` never pre-assigned (it is the implementation-time escalation ceiling, not a planning tier)? - 1=Wrong agents/tiers, 2=Mostly appropriate, 3=Acceptable, 4=Optimal selection, 5=Perfect selection 8. Phase Design (weight: 0.15) diff --git a/gemini-extension.json b/gemini-extension.json index 0c195ee..8cbb63f 100644 --- a/gemini-extension.json +++ b/gemini-extension.json @@ -1,5 +1,5 @@ { "name": "context-engineering-kit", - "version": "3.10.0", + "version": "3.11.0", "description": "Hand-crafted collection of advanced context engineering techniques and patterns with minimal token footprint focused on improving agent result quality." } diff --git a/skills/implement-task/SKILL.md b/skills/implement-task/SKILL.md index 548f14c..c13f482 100644 --- a/skills/implement-task/SKILL.md +++ b/skills/implement-task/SKILL.md @@ -42,7 +42,7 @@ Parse the following arguments from `$ARGUMENTS`: | `--target-quality` | `--target-quality X.X` | `4.0` | Single target threshold value (out of 5.0) applied to every implementation phase review. | | `--max-iterations` | `--max-iterations N` | `3` | Maximum fix→re-review cycles per implementation phase. Default is 3 iterations. Set to `unlimited` for no limit. | | `--skip-reviews` | `--skip-reviews` | `false` | Skip all phase reviews - steps proceed without quality gates. | -| `--model` | `opus\|sonnet\|haiku` | Unset | Model for **all** sub-agents (implementation agents AND `sdd:code-reviewer`) that **overrides** every model in the task file; when omitted, step models come from the Parallelization Overview and reviewer models from the Phase Overview. | +| `--model` | `fable\|opus\|sonnet\|haiku` | Unset | Model for **all** sub-agents (implementation agents AND `sdd:code-reviewer`) that **overrides** every model in the task file; when omitted, step models come from the Parallelization Overview and reviewer models from the Phase Overview. | | `--strict` | `--strict` | `false` | Disable the [Iteration Discretion Rule](#iteration-discretion-rule) - a phase is marked PASS ONLY when `combined_score >= THRESHOLD`, otherwise iterate until `MAX_ITERATIONS` is reached. | ### Configuration Resolution @@ -57,7 +57,7 @@ TASK_FILE = first argument that is a file path or filename THRESHOLD = --target-quality value || 4.0 # Initialize other defaults -MODEL_OVERRIDE = --model value (opus|sonnet|haiku) || none # none = no override; models come from the task file +MODEL_OVERRIDE = --model value (fable|opus|sonnet|haiku) || none # none = no override; models come from the task file MAX_ITERATIONS = --max-iterations || 3 # default is 3 iterations HUMAN_IN_THE_LOOP_PHASES = --human-in-the-loop || [] (empty = none, "*" = all implementation phases) SKIP_REVIEWS = --skip-reviews || false @@ -784,7 +784,7 @@ Before dispatching a single fix, reason **explicitly and in writing** through: 2. **Depth** — is this a local defect inside a step, or did the phase come out structurally wrong (`blast_radius.requires_phase_rework`)? 3. **Coupling** — does fixing the affected steps force rewriting the unaffected ones? If yes, the unit of repair is the phase, not the step. 4. **Severity** — High/Critical findings that break an acceptance criterion the phase owns, or Low/Medium nitpicks? -5. **Ceiling** — does the failure look like the implementing model ran out of capability? If a model already failed once on the same finding, dispatching it again at the same tier will fail again. Escalate. +5. **Ceiling** — does the failure look like the implementing model ran out of capability? If a model already failed once on the same finding, dispatching it again at the same tier will fail again. Escalate. The ladder is `haiku` → `sonnet` → `opus` → `fable`; `fable` is the last rung, so work that has already failed at `fable` goes back to the user, not to another dispatch. Then decide three things: @@ -1635,7 +1635,7 @@ Rubrics: ``` - The **phase identifier** is `Phase N` (a title may follow: `#### Phase 1: Foundation`). This exact identifier is what you pass to the reviewer. -- `Reviewer model:` is one of `haiku`, `sonnet`, `opus`. It is the model of that phase's single review dispatch. +- `Reviewer model:` is one of `haiku`, `sonnet`, `opus`, `fable`. It is the model of that phase's single review dispatch. - The `Checklist items:` and `Rubrics:` lists scope the reviewer's scoring. **They are the reviewer's input, not yours** — it reads them from the task file itself. Never paste them into a prompt. ### Sub-Task Files @@ -1647,7 +1647,7 @@ One per step, at `.specs/sub-tasks//-.md`, where `.md` **Phase:** Phase N -**Model:** haiku | sonnet | opus +**Model:** haiku | sonnet | opus | fable **Agent:** [agent type] **Depends on:** [step names or None] **Parallel with:** [step names or None] diff --git a/skills/plan-task/SKILL.md b/skills/plan-task/SKILL.md index 259af23..b2f8e88 100644 --- a/skills/plan-task/SKILL.md +++ b/skills/plan-task/SKILL.md @@ -47,7 +47,7 @@ Parse the following arguments from `$ARGUMENTS`: | `--human-in-the-loop` | `--human-in-the-loop phase1,phase2,...` | None | Phases after which to pause for human verification. | | `--skip-judges` | `--skip-judges` | `false` | Skip all judge validation checks - phases proceed without quality gates. | | `--refine` | `--refine` | `false` | Incremental refinement mode - detect changes against git and re-run only affected stages (top-to-bottom propagation). | -| `--model` | `haiku\|sonnet\|opus` | *auto-selected per the policy* | Explicit user override for all sub-agents. When omitted, resolve each phase's tier per the [Model Selection Policy](#model-selection-policy). See [Role Pairing](#role-pairing) for the override's effect and the [Escalation Rule](#escalation-rule) for how escalation interacts with it. | +| `--model` | `haiku\|sonnet\|opus\|fable` | *auto-selected per the policy* | Explicit user override for all sub-agents. When omitted, resolve each phase's tier per the [Model Selection Policy](#model-selection-policy). See [Role Pairing](#role-pairing) for the override's effect and the [Escalation Rule](#escalation-rule) for how escalation interacts with it. | | `--strict` | `--strict` | `false` | Disable the [Iteration Discretion Rule](#iteration-discretion-rule) - a phase passes ONLY when `score >= THRESHOLD`, otherwise retry until `MAX_ITERATIONS` is reached. | ### Stage Names (for `--included-stages` / `--skip`) @@ -372,7 +372,7 @@ This rule governs the `**Decision Logic:**` block of every phase: Picking the model is the **single highest-leverage decision** you make — more than any prompt wording, it decides whether the plan comes back correct and how long the run takes. You MUST NOT treat it as a formality: name the tier and give a one-line justification before dispatching **each** phase agent. Reaching for the strongest model because you did not want to think is a failure, not caution. -**Tier default:** `sonnet` is the working default, and `sonnet`/`haiku` cover the majority of runs. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure. +**Tier default:** `sonnet` is the working default, and `sonnet`/`haiku` cover the majority of runs. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure. `fable` sits above `opus` and is never selected by the table: it is reached only through the [Escalation Rule](#escalation-rule) after `opus` has failed, or through an explicit `--model fable`. ### Selection Rules @@ -397,7 +397,7 @@ Assess the **overall task being planned** — the draft task file's title and ty | Phase 3: Architecture Synthesis | **Heavy** — the only phase that makes open design decisions rather than applying settled ones; three inputs are synthesized here and every later phase, plus the implementation itself, inherits the result | **one tier above `BASELINE_TIER`**, capped at `opus` | | Phases 2a, 2b, 2c, 4 | Standard | `BASELINE_TIER` | -Every model-assigned phase appears in exactly ONE row, so each resolves to exactly ONE tier. The cap means an `opus` baseline leaves all phases at `opus`. [Promotion](#promote-task) is a file move you perform yourself — no sub-agent, no tier. See [Role Pairing](#role-pairing) for the `--model` override. +Every model-assigned phase appears in exactly ONE row, so each resolves to exactly ONE tier. The cap means an `opus` baseline leaves all phases at `opus`. `fable` is deliberately outside the cap: it is spent only after `opus` has failed (Escalation Rule) or on explicit request (`--model fable`), never pre-emptively. [Promotion](#promote-task) is a file move you perform yourself — no sub-agent, no tier. See [Role Pairing](#role-pairing) for the `--model` override. **Not to be confused with the per-step tiers inside the plan.** The tiers above govern the *planning* agents you launch. The `Model:` recorded in each sub-task file and the `Reviewer model:` recorded for each phase are decided by Phase 4 for the *implementation* run, from the per-step policy Phase 4's launch prompt carries — they are independent of `BASELINE_TIER`. @@ -414,7 +414,7 @@ Bump **BOTH the phase agent and its judge** one tier for the next iteration of t 1. **Low first-iteration quality** — a low score, or judge issues showing the model misunderstood the phase rather than merely missing details. 2. **The user complains** that quality is too low or the results are wrong — at any point, including after a reported PASS or a finished run. -Ladder: `haiku` → `sonnet` → `opus`. `opus` is the **ceiling** — there is no further tier. If `opus`-tier work still fails, report it and escalate to the **user**; never loop. +Ladder: `haiku` → `sonnet` → `opus` → `fable`. `fable` is the **ceiling** — there is no further tier, and escalation is the only automatic path onto it. If `fable`-tier work still fails, report it and escalate to the **user**; never loop. - **Sole exception — hold the tier (the ONLY statement of this rule, trigger (1) only):** when trigger (1) fires but the judge's issues are a specific, fixable defect rather than a capability gap (narrow, precisely specified problems the model clearly understood), you MAY hold the tier and re-launch the phase at the SAME tier with the judge's exact feedback instead of bumping. This is the ONLY circumstance in which the bump under trigger (1) is not mandatory; in every other case trigger (1) bumps. Trigger (2) has NO such exception — it always bumps immediately, per the carve-out below. - **Explicit `--model` carve-out (the ONLY statement of this rule):** an explicit `--model` is a user override, so trigger (1) MUST NOT silently overrule it — report the low-quality evidence, *propose* the bump, and re-launch at the user's tier unless they approve. Trigger (2) IS that approval, so it bumps immediately. @@ -433,6 +433,7 @@ When this skill runs outside the Anthropic model context, map the tier to the ne | `haiku` | Fast and cheap; mechanical work | `gemini-flash-lite`, `gemma` class, `gpt-oss` class, small open-weight models | | `sonnet` | Balanced workhorse; most planning phases | `gemini-pro` class and full `gemini-flash` (**not** the `-lite` variant, which is `haiku`-tier), `GPT-5-mini` class, large `Qwen` / `DeepSeek` class | | `opus` | Frontier reasoning; critical or complex work | whatever the provider sells as its extended / deliberate-reasoning tier — currently `GPT-5.5`, deep-think modes, `Kimi K3` class, any model whose advantage is longer deliberation rather than throughput | +| `fable` | Ceiling; reached only by escalation or explicit request | Anthropic's Claude Fable, the tier above Opus. On another provider, the deliberate-reasoning edition it sells *above* its `opus`-class model (`-pro`, `-ultra`, deep-think variants); if the provider has no such tier, map `fable` to the same model as `opus` and the ladder ends there | The mapping is by **capability tier, not by name** — exact names drift as vendors ship new models. Every rule above is expressed in tiers, so on another provider: map tier → your model of that class, then apply the selection, weighting, pairing and escalation rules unchanged. @@ -927,7 +928,7 @@ Launch agent: Task File: - Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: opus, sonnet, haiku} + Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: fable, opus, sonnet, haiku} Assign each step's model tier per this policy: {paste the Selection Rules table plus its Precedence and Tie-breaker paragraphs from the orchestrator's Model Selection Policy verbatim, applied per implementation step; drop the cross-reference links, which do not resolve outside that file} @@ -992,7 +993,7 @@ Launch judge: `## Acceptance Criteria`, written by an earlier phase). Verification is PHASE-level: each phase names one reviewer model; there are no per-step verification sections. - Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: opus, sonnet, haiku} + Use agents only from this list: {list ALL available agents with plugin prefix if available, e.g. sdd:developer, review:bug-hunter. Also include general agents: fable, opus, sonnet, haiku} ### Rubric 1. Step Quality (weight: 0.15) @@ -1034,7 +1035,7 @@ Launch judge: 7. Agent/Model Selection Correctness (weight: 0.08) - Are agent types appropriate for what each step OUTPUTS, and drawn only from the provided available agents list? - - Does each step's `**Model:**` follow the per-step model policy — `opus` earned by a breadth, critical-domain or open-design trigger rather than picked to be safe, `haiku` only for mechanical work? + - Does each step's `**Model:**` follow the per-step model policy — `opus` earned by a breadth, critical-domain or open-design trigger rather than picked to be safe, `haiku` only for mechanical work, `fable` never pre-assigned (it is the implementation-time escalation ceiling, not a planning tier)? - 1=Wrong agents/tiers, 2=Mostly appropriate, 3=Acceptable, 4=Optimal selection, 5=Perfect selection 8. Phase Design (weight: 0.15)