mirror of
https://github.com/alexbelgium/hassio-addons.git
synced 2026-09-15 14:19:09 +02:00
9443356b36
* docs(skill): ask "is this the simplest way possible" before implementing Every question the loop asks — of me and of Codex — is about what could go wrong, and each answer argues for more code. Nothing pushed the other way until the maintainer asked, and by then the code existed. On PR #3061 that cost a 309-line Python registry client to read one OCI label, in a script whose neighbouring branch does the same kind of job in inline curl and jq. The plan review and the code review both passed it. Asked outright, Codex said to delete all 309 lines; the inline version came to 21 and returned byte-identical output on every image tested. It is the second time the question has had to come from the maintainer. Step 3 now asks it before any code exists, of myself in writing and of Codex as a question of its own with the smaller alternative sketched out to argue for. Step 5 gains an Idiom check, on whether a hunk looks like the code it sits beside. Adding a new file or a new mechanism now means the full loop however small the diff looks, and codex-review.md records that Codex will never raise proportionality unprompted but answers it bluntly when asked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(skill): give the proportionality self-question a home on the light path Three independent reviewers on #3062 (CodeRabbit, Codex, Copilot) all caught the same gap: the self-question and its written answer lived only inside step 3, marked full-loop-only, while the light path went straight from scope to implement. A light task following the documented sequence never reached the instruction telling it to ask "is this the simplest way?" at all. Moved the self-question (and the written answer it requires) into the shared triage section, before the light/full-loop split, so both paths ask it before implementing. Step 3 now only adds Codex to that question, for full loop. Also: clarified that a version bump plus its CHANGELOG entry is release bookkeeping, not a "new file", so it does not trigger the light-to-full-loop escalation on its own (Codex's second finding on #3062, which read the one-file threshold as counting every file the PR touches rather than whether a new mechanism was added). Fixed step 5's stale "six questions" to seven, after Idiom was added in the prior commit. Fixed simplify.md's case study to say the 309-line client was "initially proposed", not shipped, matching the prior PR's own body. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * docs(skill): split "test the smaller candidate" by whether the diff exists yet CodeRabbit on #3062 caught that step 3's "build the smaller one and run it" never says to compare it against the larger candidate, only to run it. As written it applied at plan time, before either candidate has code — where the larger candidate is a plan, not a diff, so there is nothing to compare against without building both in full, which defeats the point of picking the cheaper one first. Testing the smaller sketch against the actual requirement is the correct and complete check there. The comparison CodeRabbit is describing is real, but it happens at step 6, not step 3: by the time code review runs, the larger candidate already exists as the diff, so sketching the smaller one and diffing its output against the shipped code costs nothing extra and is exactly what settled #3061. Moved the build-and-compare instruction there instead of applying it, unchanged, to a step where nothing exists to compare against yet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
53 lines
3.3 KiB
Markdown
53 lines
3.3 KiB
Markdown
# Codex review — invocation and prompt guidance
|
|
|
|
Used for step 3 (plan review) and step 6 (code review), full loop only. Codex is a genuinely
|
|
different model reading the files itself; on this workload it has repeatedly been worth the
|
|
minutes. Run it through a subagent, per SKILL.md's delegation note.
|
|
|
|
## Invocation
|
|
|
|
**Use the CLI, not the MCP tool, for prompts of this size.** The `codex` MCP tool timed out twice
|
|
on ~4 KB prompts (2026-08-03); the CLI with the same content succeeded. The MCP tool is still fine
|
|
for short questions.
|
|
|
|
`--sandbox read-only` blocks writes, not reads, and `approval_policy=never` stops it asking for
|
|
permission rather than stopping it acting — so it can still run read-only commands and often
|
|
falls back to fetching the repo from GitHub instead of reading your worktree. Paste every number
|
|
into the prompt rather than expecting it to gather them, and treat what it reports about *local*
|
|
state as unverified. `- <` feeds the prompt file on stdin. Run it in the background so you are not
|
|
blocked for the several minutes it takes (`&` here, or your harness's background-task mechanism):
|
|
|
|
```bash
|
|
codex exec --model gpt-5.6-sol --sandbox read-only --skip-git-repo-check \
|
|
-c approval_policy='"never"' - < prompt.md > codex_out.txt 2>&1 &
|
|
```
|
|
|
|
## Writing the prompt
|
|
|
|
- **Plan review (step 3):** include the files to read, your measurements **with numbers**, the
|
|
proposed changes, and explicit instructions to challenge you. Ask direct questions ("is this
|
|
really add-on-fixable?", "give the precise flag set") rather than "review this".
|
|
- **The proportionality question, in both reviews, as a numbered question of its own:** "is this
|
|
the simplest way possible, and what exactly would you delete?" Sketch the smaller alternative in
|
|
the prompt and ask it to argue for that, and quote the repo's standing simplicity rule so it has
|
|
the bar to hold you to. Ask for lines and functions to delete, not a direction.
|
|
- **Code review (step 6):** point it at `git diff origin/master...HEAD` plus the reasoning behind
|
|
each hunk. Ask specifically what breaks: upgrade paths, hosts unlike this one, users who
|
|
configured things by hand. Ask directly whether a simpler mechanism would achieve the same
|
|
thing — an outside reader spots one-level-too-deep framing far more easily than the person who
|
|
just built it.
|
|
- Codex's sandbox often cannot run local commands and falls back to reading GitHub, so paste the
|
|
evidence in rather than assuming it will find it.
|
|
|
|
**Codex agrees with confident premises.** It has confirmed a wrong conclusion stated too
|
|
confidently, and separately caught a genuine methodology error in the same review. Treat its
|
|
confirmations with the same scepticism as its objections — especially about the build.
|
|
|
|
**Its objections only ever argue for more code** — it is asked what could go wrong, never whether
|
|
the branch it wants is reachable. Sort them before writing anything; SKILL.md step 6 is that pass.
|
|
|
|
**Unprompted it will never say "this is too much".** Asked outright it will, bluntly and usefully:
|
|
on PR #3061 it answered "delete all 309 lines" of a helper both its earlier reviews had passed
|
|
without comment. Expect it to reverse an earlier position when you ask it to re-examine one — a
|
|
stance it drops that easily was never strongly held, which is itself the answer.
|