crew-providers

Files (2)

• SKILL.md
• alternative-providers.md

SKILL.md (first lines)

# Providers

Two external roles, deliberately different in what they are allowed to see.

| Role | Provider | Sees your code? | Why |
|---|---|---|---|
| QA review | Codex, Kimi Code **or** Copilot | Yes — the diff | Review is worthless without the actual change |
| Design opinion | Gemini | **No** — brief only | Free tiers train on prompts |

That asymmetry is the whole design. Do not collapse it for convenience.

## The one rule that decides every QA provider question

**A reviewer is only worth having if it is a different model family from the
author.** Crew's code is written by Claude. A Claude reviewer shares its blind
spots, so it agrees with itself and the gate goes green on defects nobody saw.

This is why `qa.order` exists and why every provider block carries its own
`model` key read at call time. It is also why a provider that *can* be pointed at
Claude — Copilot — is refused unless you pin it away from Claude. The danger is
not that such a review is bad; it is that it looks exactly like a good one.

| Family | Reached via |
|---|---|
| Anthropic | the `reviewer` fallback, or Copilot pinned to `claude-*` |
| OpenAI | Codex, or Copilot pinned to `gpt-*` |
| **Google** | Copilot pinned to `gemini-*` |
| **Microsoft MAI** | Copilot pinned to `mai-*` |
| **Moonshot (`kimi`)** | the Kimi Code CLI (`kimi`), or Copilot pinned to `kimi-*` |

---

## Role pins for this project

**This table is a configuration to adopt, not what crew ships.** A fresh
install has `dev.provider: "claude"` and an empty `dev.roles`, and each
agent file's frontmatter pins a Claude tier, so every role below runs on
Claude until someone writes these pins. `/crew:init` and `/crew:config`
offer the table; neither applies it unasked.

Crew fills every role with Claude except these:

| Role | Config key | Provider | Model |
|---|---|---|---|
| `developer` (senior) | `dev.roles.developer` | codex | `gpt-6-astra` |
| `security` | `dev.roles.security` | codex | `gpt-6-astra` |
| QA phase-1 review, and the smoke test | `qa.roles.phase1`, `qa.roles.smoke` | codex | `gpt-5.6-sol` |
| QA review, and gating | `qa.roles.review`, `qa.roles.gate` | codex | `gpt-5.6-luna` |

Two rows carry the word "review" against two different models, so read the key
and not the label: `qa.roles.phase1` is Sol, `qa.roles.review` is Luna.

**Every role not named above runs on claude.** An absent `roles` entry is not an
error state — it is the claude default, and that is how most of the roster is
filled.

Copilot's **Kimi 2.7 (`kimi-k2.7-code`)** must also be selectable as a `dev`
provider, pinned the same way any other `dev.roles.<role>` model is pinned:

```json
"dev": { "roles": { "developer": { "provider": "copilot", "model": "kimi-k2.7-code" } } }
```

"Kimi 2.7 (`kimi-k2.7-code`)" above is the only place this document pairs the
display name with the wire id, deliberately: the id is a debugging detail, not
a name. Everywhere else, say "Kimi 2.7" to a person and write `kimi-k2.7-code`
into config. See "Pin the model, always" in the Copilot section below for why
the suffix is not optional.

### Fallback: configurable, and announced when it fires

Every pin above shares the same fallback, `claude-sonnet-5`. It lives in
config (`qa.fallback` / `dev.fallback`, set via `/crew:model`), not as a
hardcoded string, because model names retire — `gemini-3.1-pro-preview` and
`mai-code-1-flash` were both recommended by an earlier revision of this file
and both now fail outright. See "Pin the model, always" below.

A fallback that fires must be **announced**, never silent. A review that
quietly ran on the fallback is indistinguishable from one that ran on the
pin, and the difference matters most exactly when the pin was chosen to get
a different model family onto the diff.

The fallback runs on its family's provider (L-0712, `provider_for_model`):
`gpt-*` on codex, `kimi-*`/`k3` on kimi, `claude-*` on claude. One in the
author's family is skipped for the next `qa.order` (or `dev.order`) provider
whose family did not write the diff and which answers its probe. When none
answers, the round is INCOMPLETE and refunded; a same-family read runs only
when the operator asks for one, labelled.

### The family guard beats every pin above

Evaluation happens in this order, and the order is the whole interlock:

1. **The family guard runs first.** The family that wrote the diff is struck
   from the QA walk. `family()` is the model's leading letters after any
   `vendor/` prefix, lowercased, so `gpt-6-astra`, `gpt-5.6-sol` and
   `gpt-5.6-luna` are all `gpt`, and `kimi-k2.7-code` and `kimi-k3` are both
   `kimi`. `claude` and `kimi` are decided by provider instead: the Kimi Code
   CLI is `kimi` whatever it is pinned to, because its id `k3` reads as `k`.
2. **The pin applies second**, to whatever families survive step 1.

A pin that beat the guard would let a model review its own family's diff, which
is the single thing this interlock exists to prevent. Never document it, or
build it, the other way round.

The consequence is concrete. `gpt-5.6-sol` and `gpt-5.6-luna` are the same `gpt`
family as `gpt-6-astra`, so when `developer` or `security` are pinned to
`gpt-6-astra` and codex writes the
diff, the guard bars **all** `gpt` models from reviewing it — including both QA
pins above. QA falls to `claude` or to Copilot pinned to Kimi 2.7. **The Sol and
Luna pins therefore apply to work codex did not write.**

State this plainly whenever these pins are discussed: pinning the senior
developer to codex means most dev work is codex-authored, so the Sol and Luna
QA pins fire on the claude-authored work and comparatively rarely on codex's
own diffs. A doc that lists the QA pins without this promises a review the
guard correctly refuses to run. `/crew:model` step 3 applies this exclusion
at review time and reports it per role — see that command for how it decides
which family authored the diff.

From mbadali25/useful-claude-add-ons, GPL-2.0.

More from mbadali25/useful-claude-add-ons