Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 29 additions & 3 deletions .agents/skills/backlog-burndown/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -326,12 +326,13 @@ A worker still live, a promotion fix included, keeps its worktree until the next

### Choosing the Worker's Model Tier

`AGENTS.md` "Delegation" owns the model-tier rule and names the tiers. Read it there. This is only
what it leaves to judgment here. The tier is chosen per group rather than defaulted, since a
`AGENTS.md` "Model Tiers" owns the model-tier rule and names the tiers, carried under "Model Tiers"
below. This is only what it leaves to judgment here. The tier is chosen per group rather than defaulted, since a
stronger tier produces better work and takes fewer review rounds to land it. That often
costs less than a cheaper worker looping. The tier is `frontier` or `standard`, never `bulk`, since
every worker judges its pull request's review findings. It is `highest` only where the maintainer
named it for this run. Groups of these kinds are never tiered
named it for this run and launched the session with it allowed, per "Model Tiers" below. Where a
dispatch at it is refused, ask the maintainer rather than dispatching lower. Groups of these kinds are never tiered
below `frontier`:

- One touching **carried canonical content**, as `GOVERNANCE.md` "Verification Discipline" bounds
Expand Down Expand Up @@ -536,6 +537,31 @@ Report at every round boundary and at each ending: what merged to develop, what
request carries, what was newly filed, what is stopped and on which question, what was held back and
on which blocker, and what the next round would pick.

## Model Tiers

`AGENTS.md` "Model Tiers" keeps the tier rule, carried here whole as a generated include. A tier
this skill names then resolves to its model even where a carried `AGENTS.md` predates the table.

<!-- include: AGENTS.md > Model Tiers -->

A rule, a Skill, or a brief names a model tier, never a model. A model release is then an edit to the table below and to the hub's `spec/model-tiers.json`. That file states the same mapping as data, and the hub's spec gate holds the two equal. Reasoning effort is a separate axis stated beside the tier, such as `bulk` at low effort.

- **`frontier`** is the fleet's default reasoning tier, for orchestrating, rule text, design, spec logic, and adversarial review. It is not the most capable model available, which is `highest`.
- **`standard`** is ordinary implementation and driving a pull request. Judging a review finding is never mechanical, however often it repeats, so it runs at `standard` or above. A `standard` driver's evidence-backed decline of a finding raised on its pull request stands, since that pull request's reviewers and its merge gate check it.
- **`bulk`** is the cheapest model that does the work correctly. It is for high fan-out mechanical work, such as an extraction or a status check.
- **`highest`** is the most capable model available, and only the maintainer selects it. The maintainer chooses it for the session itself, or allows it for the session's subagents at launch. The host's agent-safety kit reads that launch setting, `FLEET_ALLOW_HIGHEST=1` on Claude Code. Naming the tier in a prompt does not set it. A maintainer naming it partway through a session restarts the session with it allowed, and an agent never sets it. Without that setting, the kit refuses a dispatch that names it. A dispatch naming no model runs at its agent definition's model where one is set, and otherwise at the session's own. A fork always runs at the session's model, whatever it names. So a session launched on `highest` names a tier on every dispatch meant to run below it, and uses no fork for such work. A session never reaches for it because a task looks hard.

| Tool | `highest` | `frontier` | `standard` | `bulk` |
| --- | --- | --- | --- | --- |
| Claude Code | `fable` | `opus` | `sonnet` | `haiku` |

Each cell is the name that tool's subagent dispatch takes, which follows the latest model of its family. A tool with no row here, or one that cannot name a model per subagent, runs every tier at the session's own model.

- **A tier resolves only through this table.** A word such as "frontier", "strongest", or "most capable" never resolves to `highest`. The industry's "frontier model" is the opposite of what this tier means here. A session that cannot see this table names no model rather than guessing one, so the subagent runs at the session's own model.
- **An orchestrating seat runs at `frontier` and names a tier on every dispatch.** It defaults a subagent to `frontier`, and picks `standard` or `bulk` deliberately for execution or mechanical work. A dispatch that names no model inherits whatever the session runs on, which is a choice nobody made.

<!-- /include -->

## Mechanics Live Elsewhere

- The review loop, the Merge Gate, the finding outcomes, and when a finding is a question:
Expand Down
27 changes: 26 additions & 1 deletion .agents/skills/local-strict-review/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ Bounds: read-only. No edit, no stage, no commit, no push, no PR-hosted write of

Before dispatching, grep the tree for other statements of each rule the diff adds or changes, and add each file holding one to the `Paths:` floor, so a statement the diff has put in disagreement is read rather than missed.

**Model tier:** `frontier`, the tier `AGENTS.md` "Delegation" names for adversarial review, which this pass is. Where `frontier` is not reachable, run the pass on the strongest tier below it that is, even the one that authored the change. A second, adversarially-prompted look still catches what the authoring pass's own "looks ready" judgment did not.
**Model tier:** `frontier`, the tier "Model Tiers" below names for adversarial review, which this pass is. Where `frontier` is not reachable, run the pass on the strongest tier below it that is, even the one that authored the change. A second, adversarially-prompted look still catches what the authoring pass's own "looks ready" judgment did not.

Reachable means the tier this session can name when it dispatches the reviewer, rather than the tier this session is itself running on. A session deliberately tiered down for execution work, a worker dispatched by an orchestrator being the ordinary case, names `frontier` for the reviewer where its harness lets it, since tiering down the author is the reason the reviewer must not follow it down. What a given harness and account actually permit varies, so treat this as the tier to ask for rather than one to assume. Where a dispatch exposes no way to name a tier, take what it gives and run the pass, for the reason the fallback above states. A seat that cannot dispatch a subagent hands the pass to whoever dispatched it. The seat commits, runs `python3 <hub-checkout>/scripts/local_review.py status --target <target>` in its worktree, and hands back its worktree path, target, and `contentDigest`. The dispatcher fills the brief's `<worktree>` slot and runs the reviewer. It then runs the record command from "Recording the Pass" in that worktree, with `--reviewer agent-skill --target <target> --expect-digest <digest>`. It returns the findings. Each fix commit repeats this cycle, and the seat pushes only when a record matches its content. The brief dispatching the seat states whether the dispatcher can continue that seat. Where the dispatcher cannot, or under `unattended-handoff`, the seat stops, reports, and does not push. Where nobody dispatched the seat, it reports to the maintainer that it could not run the pass, and does not push. Either way the push waits rather than the pass being quietly skipped. The headless `run --backend` route under "Recording the Pass" is not the substitute: it runs a vendor CLI against its own review, which never carries the brief above, so it satisfies the rule this section states only where that separate route is what a capture point asked for.

Expand Down Expand Up @@ -176,6 +176,31 @@ In the hub, `.husky/pre-push` checks the receipt at the push itself, so the mome

This table is the fleet's one enumeration of these, and every other surface states the principle and routes here rather than listing the shapes. That is deliberate: every review round that added a shape also left a restatement of it somewhere else, and keeping one table is what stops the next round doing the same.

## Model Tiers

`AGENTS.md` "Model Tiers" keeps the tier rule, carried here whole as a generated include. A tier
this skill names then resolves to its model even where a carried `AGENTS.md` predates the table.

<!-- include: AGENTS.md > Model Tiers -->

A rule, a Skill, or a brief names a model tier, never a model. A model release is then an edit to the table below and to the hub's `spec/model-tiers.json`. That file states the same mapping as data, and the hub's spec gate holds the two equal. Reasoning effort is a separate axis stated beside the tier, such as `bulk` at low effort.

- **`frontier`** is the fleet's default reasoning tier, for orchestrating, rule text, design, spec logic, and adversarial review. It is not the most capable model available, which is `highest`.
- **`standard`** is ordinary implementation and driving a pull request. Judging a review finding is never mechanical, however often it repeats, so it runs at `standard` or above. A `standard` driver's evidence-backed decline of a finding raised on its pull request stands, since that pull request's reviewers and its merge gate check it.
- **`bulk`** is the cheapest model that does the work correctly. It is for high fan-out mechanical work, such as an extraction or a status check.
- **`highest`** is the most capable model available, and only the maintainer selects it. The maintainer chooses it for the session itself, or allows it for the session's subagents at launch. The host's agent-safety kit reads that launch setting, `FLEET_ALLOW_HIGHEST=1` on Claude Code. Naming the tier in a prompt does not set it. A maintainer naming it partway through a session restarts the session with it allowed, and an agent never sets it. Without that setting, the kit refuses a dispatch that names it. A dispatch naming no model runs at its agent definition's model where one is set, and otherwise at the session's own. A fork always runs at the session's model, whatever it names. So a session launched on `highest` names a tier on every dispatch meant to run below it, and uses no fork for such work. A session never reaches for it because a task looks hard.

| Tool | `highest` | `frontier` | `standard` | `bulk` |
| --- | --- | --- | --- | --- |
| Claude Code | `fable` | `opus` | `sonnet` | `haiku` |

Each cell is the name that tool's subagent dispatch takes, which follows the latest model of its family. A tool with no row here, or one that cannot name a model per subagent, runs every tier at the session's own model.

- **A tier resolves only through this table.** A word such as "frontier", "strongest", or "most capable" never resolves to `highest`. The industry's "frontier model" is the opposite of what this tier means here. A session that cannot see this table names no model rather than guessing one, so the subagent runs at the session's own model.
- **An orchestrating seat runs at `frontier` and names a tier on every dispatch.** It defaults a subagent to `frontier`, and picks `standard` or `bulk` deliberately for execution or mechanical work. A dispatch that names no model inherits whatever the session runs on, which is a choice nobody made.

<!-- /include -->

## Mechanics Live Elsewhere

- Review criteria: `fleet-code-review`.
Expand Down
38 changes: 33 additions & 5 deletions .agents/skills/unattended-handoff/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -90,22 +90,25 @@ maintainer starts a second run on a repository only once the first has ended.

The orchestrator first resolves `<owner>/<repo>` from the checkout's `origin`, or takes it from the
invocation. Apart from the timer "A Dispatch That Fails" names, that is the one command it runs.
From then on it holds only the scope and any `highest` the invocation named, the round count, and
From then on it holds only the scope and any allowed `highest` the invocation named, the round count, and
the dispatched handoff numbers. It also holds each round's one-line outcome and the waits spent on
a dispatch being retried.
Each round runs:

1. **Dispatch the picker** at `frontier` with the brief below, or at `highest` where the
maintainer's invocation named that tier or its model. Its ranking, decision, and worker-tier
1. **Dispatch the picker** at `frontier` with the brief below. Use `highest` only where the
invocation named that tier or its model and the session was launched with it allowed, per
"Model Tiers" below. A refusal there ends the run the way step 3's does. Its ranking, decision, and worker-tier
calls are the ones `backlog-burndown` keeps in its orchestrator, and here no maintainer reviews
them. Wait on the dispatch mechanism's own completion signal rather than polling.
2. **Read its one line.** `NONE` or `STOP` ends the run, and so does any reply that is not a
picker line below. A handoff number already dispatched in this run ends it too, since a handoff
a worker neither closed nor parked means the worker failed in a way this seat must not
investigate.
3. **Dispatch the worker** on that handoff and track, at the model `AGENTS.md` "Delegation" names
3. **Dispatch the worker** on that handoff and track, at the model "Model Tiers" below names
for the tier in the picker's line. Wait the same way. Dispatch at `highest` instead only where
the maintainer's invocation named that tier or its model.
the invocation named that tier or its model and the session was launched with it allowed, per
"Model Tiers" below. Without that allowance every such dispatch is refused. The run then ends
and reports the refusal rather than continuing at a tier nobody chose.
4. **Record its one line** and start the next round. `STOP` ends the run, and so does a reply that
is not one of the lines below, rather than being read further.

Expand Down Expand Up @@ -180,6 +183,31 @@ Under `main` or `release` every unblocked round promotes, so each promotion ordi
fix. A change another session merged to develop meanwhile rides along with it. Naming the scope
accepts that.

## Model Tiers

`AGENTS.md` "Model Tiers" keeps the tier rule, carried here whole as a generated include. A tier
this skill names then resolves to its model even where a carried `AGENTS.md` predates the table.

<!-- include: AGENTS.md > Model Tiers -->

A rule, a Skill, or a brief names a model tier, never a model. A model release is then an edit to the table below and to the hub's `spec/model-tiers.json`. That file states the same mapping as data, and the hub's spec gate holds the two equal. Reasoning effort is a separate axis stated beside the tier, such as `bulk` at low effort.

- **`frontier`** is the fleet's default reasoning tier, for orchestrating, rule text, design, spec logic, and adversarial review. It is not the most capable model available, which is `highest`.
- **`standard`** is ordinary implementation and driving a pull request. Judging a review finding is never mechanical, however often it repeats, so it runs at `standard` or above. A `standard` driver's evidence-backed decline of a finding raised on its pull request stands, since that pull request's reviewers and its merge gate check it.
- **`bulk`** is the cheapest model that does the work correctly. It is for high fan-out mechanical work, such as an extraction or a status check.
- **`highest`** is the most capable model available, and only the maintainer selects it. The maintainer chooses it for the session itself, or allows it for the session's subagents at launch. The host's agent-safety kit reads that launch setting, `FLEET_ALLOW_HIGHEST=1` on Claude Code. Naming the tier in a prompt does not set it. A maintainer naming it partway through a session restarts the session with it allowed, and an agent never sets it. Without that setting, the kit refuses a dispatch that names it. A dispatch naming no model runs at its agent definition's model where one is set, and otherwise at the session's own. A fork always runs at the session's model, whatever it names. So a session launched on `highest` names a tier on every dispatch meant to run below it, and uses no fork for such work. A session never reaches for it because a task looks hard.

| Tool | `highest` | `frontier` | `standard` | `bulk` |
| --- | --- | --- | --- | --- |
| Claude Code | `fable` | `opus` | `sonnet` | `haiku` |

Each cell is the name that tool's subagent dispatch takes, which follows the latest model of its family. A tool with no row here, or one that cannot name a model per subagent, runs every tier at the session's own model.

- **A tier resolves only through this table.** A word such as "frontier", "strongest", or "most capable" never resolves to `highest`. The industry's "frontier model" is the opposite of what this tier means here. A session that cannot see this table names no model rather than guessing one, so the subagent runs at the session's own model.
- **An orchestrating seat runs at `frontier` and names a tier on every dispatch.** It defaults a subagent to `frontier`, and picks `standard` or `bulk` deliberately for execution or mechanical work. A dispatch that names no model inherits whatever the session runs on, which is a choice nobody made.

<!-- /include -->

## Auto-Resolvable

An issue needs no maintainer decision when every one of these holds. Where any is unclear, it
Expand Down
Original file line number Diff line number Diff line change
@@ -1 +1 @@
1bee0d96e7d55aac
e1af7dadfb2070a2
Original file line number Diff line number Diff line change
@@ -1 +1 @@
6da3e35f478872a6
9dc270f21b0302cd
Original file line number Diff line number Diff line change
@@ -1 +1 @@
151cf349b4115615
eddb00a5222e6b31
Loading
Loading