instructions/claude-code-model-selection.md (added in 1.7.0, linked from CLAUDE.md) tells
a Claude Code session which model (Sonnet vs. Opus) and effort level to run at. Since 4.3.3 it
routes by what catches a mistake in the current phase rather than by skill name: routine wiki-status/wiki-lint at Sonnet default, judgment-heavy ingest/manage at Sonnet high, and
stack development split across three rows - design/version-part/boundary judgment at Opus high,
the mechanical code-and-tests middle at Sonnet high, the unchecked closing phase at Opus high
again. It also covers how to pick a /code-review effort level and a subagent model: override.
It is deliberately Claude-Code-only: its model names, /code-review effort dial, and Agent tool model: parameter have no direct equivalent in the other harnesses this repo supports (Codex CLI,
GitHub Copilot CLI, Mistral Vibe).
Whether those harnesses should get equivalent guidance, and if so what it would even mean for
each of them (they may not expose a comparable model/effort choice at all, or may expose a
different one), was explicitly left undecided - see the "Deliberately out of scope" paragraph in
the 1.7.0CHANGES.md entry.
Why it matters
The operator uses Claude, Codex, GitHub Copilot, Mistral and Perplexity in parallel depending on
the task. If a non-Claude harness session ever drives stack-dev work or a heavy ingest on this
repo, it currently has no guidance at all on right-sizing whatever model/effort choice its own
CLI exposes - the gap the Claude-Code file just closed for Claude Code specifically remains open
for the other three.
Open design questions (why this isn't just "copy the file")
Do Codex CLI / GitHub Copilot CLI / Mistral Vibe each expose a comparable model/effort choice
at all? Needs checking per harness before writing anything - do not assume symmetry with
Claude Code's Sonnet/Opus/effort dial.
If yes, where would harness-specific instructions like this even be linked from? Unlike
Claude Code (which has its own auto-loaded CLAUDE.md to hang a harness-only link off), the
other three all read AGENTS.md directly and natively - there is no equivalent per-harness
bridge file for them today. A link from AGENTS.md would load into all three at once, which
may or may not be the right scope.
One shared "non-Claude" instruction, or one per harness? Depends on how much the answer
actually differs harness to harness.
Since 4.6.0 there is a second Claude-Code-shaped mechanism to consider: the stack-dev / stack-close skill split, which exists precisely because a prose model-switch break was
skipped twice. A harness with no model choice at all still inherits the split (skills are
published to .agents/skills/ too) but not its reason - worth deciding whether that is
harmless or confusing.
Acceptance criteria
A decision (even "not worth it, here's why") recorded in the issue body before closing, per instructions/dev/issue-tracking.md's
closing rule.
If guidance is written: an instruction file (or files), correctly referenced so tools/wikitool instructions verify treats it as linked/loaded rather than orphaned, and a CHANGES.md entry.
Trigger
Revisit when a non-Claude-Code harness session is actually doing meaningful work on this repo
(a stack-dev change or a real ingest driven from Codex/Copilot/Vibe), not before - no data on
what those harnesses actually need until then.
Nachgezogen 2026-09-04 (#29): der relative Markdown-Link auf issue-tracking.md löste aus der
Issue-Ansicht nicht auf und zeigt jetzt auf src/branch/main/. Die Beschreibung von claude-code-model-selection.md beschrieb den Stand vor 4.3.3 („stack-dev at Opus high") und
ist auf die tatsächlichen drei Zeilen korrigiert; der Verweis auf die Schließregel nennt jetzt den
Body-Rewrite statt eines Close-Kommentars, wie die Regel es seit 4.0.1 fordert. Pfadseitig sonst
sauber. Neue offene Frage zum stack-dev/stack-close-Schnitt (4.6.0) ergänzt.
## What
`instructions/claude-code-model-selection.md` (added in `1.7.0`, linked from `CLAUDE.md`) tells
a Claude Code session which model (Sonnet vs. Opus) and effort level to run at. Since `4.3.3` it
routes by **what catches a mistake in the current phase** rather than by skill name: routine
`wiki-status`/`wiki-lint` at Sonnet default, judgment-heavy ingest/manage at Sonnet high, and
stack development split across three rows - design/version-part/boundary judgment at Opus high,
the mechanical code-and-tests middle at Sonnet high, the unchecked closing phase at Opus high
again. It also covers how to pick a `/code-review` effort level and a subagent `model:` override.
It is deliberately Claude-Code-only: its model names, `/code-review` effort dial, and `Agent` tool
`model:` parameter have no direct equivalent in the other harnesses this repo supports (Codex CLI,
GitHub Copilot CLI, Mistral Vibe).
Whether those harnesses should get equivalent guidance, and if so what it would even mean for
each of them (they may not expose a comparable model/effort choice at all, or may expose a
different one), was explicitly left undecided - see the "Deliberately out of scope" paragraph in
the `1.7.0` `CHANGES.md` entry.
## Why it matters
The operator uses Claude, Codex, GitHub Copilot, Mistral and Perplexity in parallel depending on
the task. If a non-Claude harness session ever drives `stack-dev` work or a heavy ingest on this
repo, it currently has no guidance at all on right-sizing whatever model/effort choice its own
CLI exposes - the gap the Claude-Code file just closed for Claude Code specifically remains open
for the other three.
## Open design questions (why this isn't just "copy the file")
- Do Codex CLI / GitHub Copilot CLI / Mistral Vibe each expose a comparable model/effort choice
at all? Needs checking per harness before writing anything - do not assume symmetry with
Claude Code's Sonnet/Opus/effort dial.
- If yes, where would harness-specific instructions like this even be *linked from*? Unlike
Claude Code (which has its own auto-loaded `CLAUDE.md` to hang a harness-only link off), the
other three all read `AGENTS.md` directly and natively - there is no equivalent per-harness
bridge file for them today. A link from `AGENTS.md` would load into all three at once, which
may or may not be the right scope.
- One shared "non-Claude" instruction, or one per harness? Depends on how much the answer
actually differs harness to harness.
- Since `4.6.0` there is a second Claude-Code-shaped mechanism to consider: the `stack-dev` /
`stack-close` skill split, which exists precisely because a prose model-switch break was
skipped twice. A harness with no model choice at all still inherits the split (skills are
published to `.agents/skills/` too) but not its reason - worth deciding whether that is
harmless or confusing.
## Acceptance criteria
- A decision (even "not worth it, here's why") recorded in the issue body before closing, per
[instructions/dev/issue-tracking.md](https://gitea.nehmer.net/torben/chemenu/src/branch/main/instructions/dev/issue-tracking.md)'s
closing rule.
- If guidance is written: an instruction file (or files), correctly referenced so
`tools/wikitool instructions verify` treats it as linked/loaded rather than orphaned, and a
`CHANGES.md` entry.
## Trigger
Revisit when a non-Claude-Code harness session is actually doing meaningful work on this repo
(a `stack-dev` change or a real ingest driven from Codex/Copilot/Vibe), not before - no data on
what those harnesses actually need until then.
---
*Nachgezogen 2026-09-04 (#29): der relative Markdown-Link auf `issue-tracking.md` löste aus der
Issue-Ansicht nicht auf und zeigt jetzt auf `src/branch/main/`. Die Beschreibung von
`claude-code-model-selection.md` beschrieb den Stand vor `4.3.3` („`stack-dev` at Opus high") und
ist auf die tatsächlichen drei Zeilen korrigiert; der Verweis auf die Schließregel nennt jetzt den
Body-Rewrite statt eines Close-Kommentars, wie die Regel es seit `4.0.1` fordert. Pfadseitig sonst
sauber. Neue offene Frage zum `stack-dev`/`stack-close`-Schnitt (`4.6.0`) ergänzt.*
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
instructions/claude-code-model-selection.md(added in1.7.0, linked fromCLAUDE.md) tellsa Claude Code session which model (Sonnet vs. Opus) and effort level to run at. Since
4.3.3itroutes by what catches a mistake in the current phase rather than by skill name: routine
wiki-status/wiki-lintat Sonnet default, judgment-heavy ingest/manage at Sonnet high, andstack development split across three rows - design/version-part/boundary judgment at Opus high,
the mechanical code-and-tests middle at Sonnet high, the unchecked closing phase at Opus high
again. It also covers how to pick a
/code-revieweffort level and a subagentmodel:override.It is deliberately Claude-Code-only: its model names,
/code-revieweffort dial, andAgenttoolmodel:parameter have no direct equivalent in the other harnesses this repo supports (Codex CLI,GitHub Copilot CLI, Mistral Vibe).
Whether those harnesses should get equivalent guidance, and if so what it would even mean for
each of them (they may not expose a comparable model/effort choice at all, or may expose a
different one), was explicitly left undecided - see the "Deliberately out of scope" paragraph in
the
1.7.0CHANGES.mdentry.Why it matters
The operator uses Claude, Codex, GitHub Copilot, Mistral and Perplexity in parallel depending on
the task. If a non-Claude harness session ever drives
stack-devwork or a heavy ingest on thisrepo, it currently has no guidance at all on right-sizing whatever model/effort choice its own
CLI exposes - the gap the Claude-Code file just closed for Claude Code specifically remains open
for the other three.
Open design questions (why this isn't just "copy the file")
at all? Needs checking per harness before writing anything - do not assume symmetry with
Claude Code's Sonnet/Opus/effort dial.
Claude Code (which has its own auto-loaded
CLAUDE.mdto hang a harness-only link off), theother three all read
AGENTS.mddirectly and natively - there is no equivalent per-harnessbridge file for them today. A link from
AGENTS.mdwould load into all three at once, whichmay or may not be the right scope.
actually differs harness to harness.
4.6.0there is a second Claude-Code-shaped mechanism to consider: thestack-dev/stack-closeskill split, which exists precisely because a prose model-switch break wasskipped twice. A harness with no model choice at all still inherits the split (skills are
published to
.agents/skills/too) but not its reason - worth deciding whether that isharmless or confusing.
Acceptance criteria
instructions/dev/issue-tracking.md's
closing rule.
tools/wikitool instructions verifytreats it as linked/loaded rather than orphaned, and aCHANGES.mdentry.Trigger
Revisit when a non-Claude-Code harness session is actually doing meaningful work on this repo
(a
stack-devchange or a real ingest driven from Codex/Copilot/Vibe), not before - no data onwhat those harnesses actually need until then.
Nachgezogen 2026-09-04 (#29): der relative Markdown-Link auf
issue-tracking.mdlöste aus derIssue-Ansicht nicht auf und zeigt jetzt auf
src/branch/main/. Die Beschreibung vonclaude-code-model-selection.mdbeschrieb den Stand vor4.3.3(„stack-devat Opus high") undist auf die tatsächlichen drei Zeilen korrigiert; der Verweis auf die Schließregel nennt jetzt den
Body-Rewrite statt eines Close-Kommentars, wie die Regel es seit
4.0.1fordert. Pfadseitig sonstsauber. Neue offene Frage zum
stack-dev/stack-close-Schnitt (4.6.0) ergänzt.