Model/effort-selection guidance for non-Claude-Code harnesses #21

New Issue

2026-08-31T14:04:56Z

torben commented

2026-08-31 14:04:56 +00:00

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'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.*

torben added the prio/waiting size/S labels 2026-08-31 14:05:00 +00:00

torben referenced this issue from a commit

2026-08-31 14:38:48 +00:00

feat: CLAUDE.md erreicht Claude-Code-eigene Instructions, Modellwahl-Instruction importiert (1.7.0, #21)

torben referenced this issue

2026-09-01 15:22:23 +00:00

Issue-Texte aus der Zeit vor dem Chemenu-Rename tragen veraltete Pfade und Repo-Namen #29

torben added the area/process kind/decision labels 2026-09-02 21:24:55 +00:00

torben referenced this issue

2026-09-02 21:26:08 +00:00

Issue-Management: Label-Schema und Body-als-Wahrheit-Konvention #41

torben referenced this issue