CalvinBackup/gstack
1
0
Fork 0
mirror of https://github.com/garrytan/gstack.git synced 2026-07-07 08:37:52 +02:00
Code Issues Packages Projects Releases Wiki Activity

fix: plan-review right-sized diff counterbalance (not minimal-diff default)

Browse Source 
/plan-ceo-review and /plan-eng-review listed "minimal diff" as an
engineering preference without counterbalancing language. Reviewers
picked up on that and rejected rewrites that should have been approved.

The preference is now framed as "right-sized diff" with explicit
permission to recommend a rewrite when the existing foundation is
broken. Implementation alternatives section in CEO review gets an
equal-weight clarification: don't default to minimal viable just
because it is smaller. Recommend whichever best serves the user's
goal; if the right answer is a rewrite, say so.

Three-line tone edit per template, no voice / ETHOS / YC / promotional
content change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Garry Tan
2026-04-18 12:10:33 +08:00
parent 4bf5ae12c0
commit 5ca4ac48ab
4 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plan-eng-review/SKILL.md
+2 -2
View File
@@ -589,7 +589,7 @@ If the user asks you to compress or the system triggers context compaction: Step
* I want code that's "engineered enough" — not under-engineered (fragile, hacky) and not over-engineered (premature abstraction, unnecessary complexity).
* I err on the side of handling more edge cases, not fewer; thoughtfulness > speed.
* Bias toward explicit over clever.
* Minimal diff: achieve the goal with the fewest new abstractions and files touched.
* Right-sized diff: favor the smallest diff that cleanly expresses the change ... but don't compress a necessary rewrite into a minimal patch. If the existing foundation is broken, say "scrap it and do this instead."
## Cognitive Patterns — How Great Eng Managers Think
@@ -1075,7 +1075,7 @@ THE PLAN:
```bash
TMPERR_PV=$(mktemp /tmp/codex-planreview-XXXXXXXX)
_REPO_ROOT=$(git rev-parse --show-toplevel) || { echo "ERROR: not in a git repo" >&2; exit 1; }
codex exec "<prompt>" -C "$_REPO_ROOT" -s read-only -c 'model_reasoning_effort="high"' --enable web_search_cached 2>"$TMPERR_PV"
codex exec "<prompt>" -C "$_REPO_ROOT" -s read-only -c 'model_reasoning_effort="high"' --enable web_search_cached < /dev/null 2>"$TMPERR_PV"
```
Use a 5-minute timeout (`timeout: 300000`). After the command completes, read stderr:
plan-eng-review/SKILL.md.tmpl
+1 -1
View File
@@ -45,7 +45,7 @@ If the user asks you to compress or the system triggers context compaction: Step
* I want code that's "engineered enough" — not under-engineered (fragile, hacky) and not over-engineered (premature abstraction, unnecessary complexity).
* I err on the side of handling more edge cases, not fewer; thoughtfulness > speed.
* Bias toward explicit over clever.
* Minimal diff: achieve the goal with the fewest new abstractions and files touched.
* Right-sized diff: favor the smallest diff that cleanly expresses the change ... but don't compress a necessary rewrite into a minimal patch. If the existing foundation is broken, say "scrap it and do this instead."
## Cognitive Patterns — How Great Eng Managers Think