mirror of
https://github.com/garrytan/gstack.git
synced 2026-11-08 09:48:20 +01:00
feat: cut standalone /plan-eng-review; /autoplan keeps its eng phase (GST-1698) (#4108)
* feat: cut standalone /plan-eng-review; /autoplan keeps its eng phase (GST-1698) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test: lower shrunk SKILL.md size pins; keep the retired methodology's pins measured beside /autoplan Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix: carry /autoplan's plan-eng-review.md into Kiro installs Kiro's per-skill loop copied only SKILL.md and sections, so ~/.kiro/skills/gstack-autoplan lacked the Phase 3 methodology file its SKILL.md reads. Generated sibling *.md files now travel with SKILL.md under the same ownership guards. Review-Finding: p1/specialist-batched#1 reader=red-team Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * docs: file /plan-eng-review retirement follow-ups; scope the changelog claim to ./setup Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix: route architecture-review requests to /autoplan by its description (journey-plan-eng) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> --------- Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
This commit is contained in:
Garry Tanandcapy-ai[bot] authored and GitHub committed
1 parent
1970da59c4
commit
3742ee9527
88 files changed
+442
-255
No files matched your search
+3
-3
@@ -181,8 +181,8 @@ The agent should:
|
||||
4. Verify with a test spawn
|
||||
|
||||
**Native skills or ACP.** `./setup --host openclaw` (or `./setup` run inside an
|
||||
OpenClaw session) gives OpenClaw's own agent gstack's skills: the five task
|
||||
skills (review, investigate, qa, ship, plan-eng-review) listed directly and one
|
||||
OpenClaw session) gives OpenClaw's own agent gstack's skills: the four task
|
||||
skills (review, investigate, qa, ship) listed directly and one
|
||||
`gstack` router skill for the rest in `$OPENCLAW_STATE_DIR/skills`, rendered
|
||||
with OpenClaw's tool names and pointing at the installed gstack, so the agent runs gstack's
|
||||
workflows and helpers itself. Use ACP when the work should happen in a Claude
|
||||
@@ -190,7 +190,7 @@ Code session with the full install (hooks, Claude tool names); use native
|
||||
skills when the OpenClaw agent should do it. Both can be installed together.
|
||||
OpenClaw serves a registered skill's `SKILL.md` whole or refuses it, and its
|
||||
limit is 32,768 bytes when it does not know the model's context window
|
||||
(32,000 characters with a 100K-200K-token one), so a skill over 32,000 bytes (review, investigate, ship and plan-eng-review among the five) is
|
||||
(32,000 characters with a 100K-200K-token one), so a skill over 32,000 bytes (review, investigate and ship among the four) is
|
||||
registered as a short entry that tells the agent to read the skill's full
|
||||
`SKILL.md` in `gstack/skills/`, a plain copy of every skill that OpenClaw
|
||||
reads in pages (`.gstack-skills/` under `--skills all`).
|
||||
|
||||
@@ -58,7 +58,7 @@ gstack/
|
||||
├── eval-plan/ # Preregistered paid evals: prereg, arms, $0 dry run, priced pilot (bin/gstack-eval-plan)
|
||||
├── captain/ # /captain (also /crew): one controller, many lanes; templates/ holds CREW.md, AGENTS.md, NOTES.md, DIGEST.md, the flaky ledger, the lane report, the READY block, slot call, the lane brief, asks and the daily automation prompt
|
||||
├── plan-ceo-review/ # /plan-ceo-review skill
|
||||
├── plan-eng-review/ # /plan-eng-review skill
|
||||
├── plan-eng-review/ # /autoplan's eng-phase methodology (retired as a skill, GST-1698)
|
||||
├── autoplan/ # /autoplan skill (auto-review pipeline: CEO → design → DX → eng, eng always last)
|
||||
├── benchmark/ # /benchmark skill (performance regression detection)
|
||||
├── runaway-stopper/ # /runaway-stopper skill (runaway thread/subagent detect, stop, rotate, prevent; bin/gstack-runaway, templates/)
|
||||
|
||||
@@ -22,8 +22,7 @@ Each code has one of four dispositions:
|
||||
|
||||
**The fallback** (printed in every fallback denial):
|
||||
|
||||
1. Run the reviews by hand: `/plan-ceo-review`, then `/plan-devex-review`,
|
||||
then `/plan-eng-review`.
|
||||
1. Run the reviews by hand: `/plan-ceo-review`, then `/plan-devex-review`.
|
||||
2. Or move to a fresh session and keep your work: `/context-save`, start a new
|
||||
Claude Code session in the project (not `--resume`), `/context-restore`,
|
||||
then `/autoplan <plan path>`.
|
||||
|
||||
+1
-1
@@ -61,7 +61,7 @@ characters, the part of a description Hermes's skills index shows.
|
||||
|
||||
| Harness | What gstack registers | Install | Verify | Remove |
|
||||
|---|---|---|---|---|
|
||||
| OpenClaw | default `--skills hybrid`: `gstack-review`, `gstack-investigate`, `gstack-qa`, `gstack-ship` and `gstack-plan-eng-review` as top-level skills plus one `gstack` router skill whose body lists every other skill and its path, in `${OPENCLAW_STATE_DIR:-~/.openclaw}/skills`. With OpenClaw 2026.10.6's 19 eligible bundled skills, hybrid's skills section is 10,290 characters, full format, under its 18,000-character budget; `--skills all` (17,971, compact format, descriptions cut) lists every skill as its own folder, `--skills router` (6,701) only the router. OpenClaw serves a registered skill's `SKILL.md` whole or refuses it ("Skill instructions cannot be partially served"), at most 32,768 bytes when its model catalog has no context window for the model and 32,000 characters with a 100K-200K-token window, so any registered skill over 32,000 bytes (four of the five in hybrid, 26 of 63 in `all` today) is a short entry `SKILL.md` with the same name and description that sends the agent to its full `SKILL.md` in a plain copy of every skill (the router's `gstack/skills/`, or `.gstack-skills/` under `--skills all`, a folder OpenClaw's skill scan skips), which OpenClaw reads in pages. A context window under 100K tokens lowers that budget to 16,000 characters, which this limit does not cover | `./setup --host openclaw`, or `./setup` inside OpenClaw | `openclaw skills list --json` shows `gstack` and the five task skills (source `openclaw-managed`, eligible) | `gstack-harness unregister openclaw` |
|
||||
| OpenClaw | default `--skills hybrid`: `gstack-review`, `gstack-investigate`, `gstack-qa` and `gstack-ship` as top-level skills plus one `gstack` router skill whose body lists every other skill and its path, in `${OPENCLAW_STATE_DIR:-~/.openclaw}/skills`. With OpenClaw 2026.10.6's 19 eligible bundled skills, hybrid's skills section stays in full format under its 18,000-character budget; `--skills all` (17,971, compact format, descriptions cut) lists every skill as its own folder, `--skills router` (6,701) only the router. OpenClaw serves a registered skill's `SKILL.md` whole or refuses it ("Skill instructions cannot be partially served"), at most 32,768 bytes when its model catalog has no context window for the model and 32,000 characters with a 100K-200K-token window, so any registered skill over 32,000 bytes (three of the four in hybrid, 25 of 62 in `all` today) is a short entry `SKILL.md` with the same name and description that sends the agent to its full `SKILL.md` in a plain copy of every skill (the router's `gstack/skills/`, or `.gstack-skills/` under `--skills all`, a folder OpenClaw's skill scan skips), which OpenClaw reads in pages. A context window under 100K tokens lowers that budget to 16,000 characters, which this limit does not cover | `./setup --host openclaw`, or `./setup` inside OpenClaw | `openclaw skills list --json` shows `gstack` and the four task skills (source `openclaw-managed`, eligible) | `gstack-harness unregister openclaw` |
|
||||
| Hermes | every skill, as `gstack-<skill>` in one `gstack` category, in `${HERMES_HOME:-~/.hermes}/skills/gstack`. Hermes's skills index lists only skills registered as folders, so a router would leave the rest out of the listing (`skill_view` still loads an unlisted skill by name, but nothing tells the model it exists) | `./setup --host hermes`, or `./setup` inside Hermes | `hermes skills list` shows the `gstack-*` skills in category `gstack` | `gstack-harness unregister hermes` |
|
||||
| dots (feder-cr) | the `gstack` router in `/home/dot/skills/gstack`, which the Dot lists every turn | `./setup` on the Dot's computer, or `gstack-harness register dots` | the Dot's Skills page, or `GET /skills` | `gstack-harness unregister dots` |
|
||||
| QM | three skills (`gstack-investigate`, `gstack-review`, `gstack-plan`) in QM's own skill format, from `qm/sandbox/skills/` ([qm/README.md](../qm/README.md)). `gstack-harness register qm --yes` still stops before sending anything: QM imports a skill pack by cloning the whole repository and caps it at 32 MiB and 5,000 files, and gstack's repository is about 73 MiB ([why](troubleshooting.md#harness-qm-pack-too-large)) | copy `qm/sandbox/skills/gstack-*` into `<deploy dir>/sandbox/skills/` and run `qm up` | ask it for a gstack skill | remove the folders and run `qm up` again |
|
||||
|
||||
+10
-62
@@ -7,7 +7,6 @@ Detailed guides for every gstack skill — philosophy, workflow, and examples.
|
||||
| [`/office-hours`](#office-hours) | **YC Office Hours** | Start here. Six forcing questions that reframe your product before you write code. Pushes back on your framing, challenges premises, generates implementation alternatives. Design doc feeds into every downstream skill. |
|
||||
| [`/spec`](#spec) | **Spec Author** | Turn vague intent into a precise, executable spec in five phases. Backlog-ready output that downstream skills can pick up. Optional agent spawn at the end. |
|
||||
| [`/plan-ceo-review`](#plan-ceo-review) | **CEO / Founder** | Rethink the problem. Find the 10-star product hiding inside the request. Four modes: Expansion, Selective Expansion, Hold Scope, Reduction. |
|
||||
| [`/plan-eng-review`](#plan-eng-review) | **Eng Manager** | Lock in architecture, data flow, diagrams, edge cases, and tests. Forces hidden assumptions into the open. |
|
||||
| [`/plan-design-review`](#plan-design-review) | **Senior Designer** | Interactive plan-mode design review. Rates each dimension 0-10, explains what a 10 looks like, fixes the plan. Works in plan mode. |
|
||||
| [`/design-consultation`](#design-consultation) | **Design Partner** | Build a complete design system from scratch. Knows the landscape, proposes creative risks, generates realistic product mockups. Design at the heart of all other phases. |
|
||||
| [`/review`](#review) | **Staff Engineer** | Find the bugs that pass CI but blow up in production. Auto-fixes the obvious ones. Flags completeness gaps. Advisory simplification lens flags over-built code — never blocks, never auto-applies. |
|
||||
@@ -127,7 +126,7 @@ Recommends A because you learn from real usage. CRM data comes naturally in week
|
||||
|
||||
### The design doc
|
||||
|
||||
Both modes end with a design doc written to `~/.gstack/projects/` — and that doc feeds directly into `/plan-ceo-review` and `/plan-eng-review`. The full lifecycle is now: `office-hours → plan → implement → review → QA → ship → retro`.
|
||||
Both modes end with a design doc written to `~/.gstack/projects/` — and that doc feeds directly into `/plan-ceo-review` and `/autoplan`. The full lifecycle is now: `office-hours → plan → implement → review → QA → ship → retro`.
|
||||
|
||||
After the design doc is approved, `/office-hours` reflects on what it noticed about how you think — not generic praise, but specific callbacks to things you said during the session. The observations appear in the design doc too, so you re-encounter them when you re-read later.
|
||||
|
||||
@@ -185,62 +184,11 @@ Visions and decisions are persisted to `~/.gstack/projects/` so they survive bey
|
||||
|
||||
---
|
||||
|
||||
## `/plan-eng-review`
|
||||
## `/plan-eng-review` (cut)
|
||||
|
||||
This is my **eng manager mode**.
|
||||
`/plan-eng-review` was cut on 2026-11-06 (GST-1698) after two evals found no gain. In the seeded-flaw panel, plain Opus 5.5 with no gstack found the planted engineering flaws in 15 of 16 reviews. In the wave 1 outcome test, plain Opus 5.5 built 22 of 22 planned features correctly, and a session told to use the skill cost 7.1 times a plain one. The evidence is in GST-1218 and gstack-evals#253.
|
||||
|
||||
Once the product direction is right, I want a different kind of intelligence entirely. I do not want more sprawling ideation. I do not want more "wouldn't it be cool if." I want the model to become my best technical lead.
|
||||
|
||||
This mode should nail:
|
||||
|
||||
* architecture
|
||||
* system boundaries
|
||||
* data flow
|
||||
* state transitions
|
||||
* failure modes
|
||||
* edge cases
|
||||
* trust boundaries
|
||||
* test coverage
|
||||
|
||||
And one surprisingly big unlock for me: **diagrams**.
|
||||
|
||||
LLMs get way more complete when you force them to draw the system. Sequence diagrams, state diagrams, component diagrams, data-flow diagrams, even test matrices. Diagrams force hidden assumptions into the open. They make hand-wavy planning much harder.
|
||||
|
||||
So `/plan-eng-review` is where I want the model to build the technical spine that can carry the product vision.
|
||||
|
||||
### Example
|
||||
|
||||
Take the same listing app example.
|
||||
|
||||
Let's say `/plan-ceo-review` already did its job. We decided the real feature is not just photo upload. It is a smart listing flow that:
|
||||
|
||||
* uploads photos
|
||||
* identifies the product
|
||||
* enriches the listing from the web
|
||||
* drafts a strong title and description
|
||||
* suggests the best hero image
|
||||
|
||||
Now `/plan-eng-review` takes over.
|
||||
|
||||
Now I want the model to answer questions like:
|
||||
|
||||
* What is the architecture for upload, classification, enrichment, and draft generation?
|
||||
* Which steps happen synchronously, and which go to background jobs?
|
||||
* Where are the boundaries between app server, object storage, vision model, search/enrichment APIs, and the listing database?
|
||||
* What happens if upload succeeds but enrichment fails?
|
||||
* What happens if product identification is low-confidence?
|
||||
* How do retries work?
|
||||
* How do we prevent duplicate jobs?
|
||||
* What gets persisted when, and what can be safely recomputed?
|
||||
|
||||
And this is where I want diagrams — architecture diagrams, state models, data-flow diagrams, test matrices. Diagrams force hidden assumptions into the open. They make hand-wavy planning much harder.
|
||||
|
||||
That is `/plan-eng-review`.
|
||||
|
||||
Not "make the idea smaller."
|
||||
**Make the idea buildable.**
|
||||
|
||||
One note on invocation: in plan mode, the skill skips the "what should I review?" scope question and reviews your active plan automatically, announcing its pick in one line ("Scope gate: plan mode — auto-selected B") so you can redirect it. Name a target explicitly ("review PLAN.md") and your choice wins in any mode. Outside plan mode with nothing named, it asks first — that gate is a hard stop.
|
||||
The standalone skill no longer installs, and `./setup` removes an existing gstack-owned `/plan-eng-review` entry on every host. Its review methodology stays as `/autoplan`'s eng phase (Phase 3), unchanged. To review a plan's architecture, data flow, edge cases and tests, run `/autoplan`. `/review` covers the diff before `/ship`.
|
||||
|
||||
### Review Readiness Dashboard
|
||||
|
||||
@@ -260,7 +208,7 @@ Every review (CEO, Eng, Design) logs its result. At the end of each review, you
|
||||
+====================================================================+
|
||||
```
|
||||
|
||||
Eng Review is the only required gate (disable with `gstack-config set skip_eng_review true`). CEO and Design are informational — recommended for product and UI changes respectively.
|
||||
Eng Review is the only required gate; `/review` on the diff or `/autoplan`'s eng phase satisfies it (disable with `gstack-config set skip_eng_review true`). CEO and Design are informational — recommended for product and UI changes respectively.
|
||||
|
||||
Diff reviews use the `review_freshness` grade computed by `gstack-review-read`, shared by `/ship` and `/land-and-deploy`. CURRENT requires a clean, reviewer-reported completed and converged pass whose captured start and finish fingerprints match the current working-tree content. Tracked edits and non-ignored untracked source both count; an identical commit hash or zero commits since review is not a fallback.
|
||||
|
||||
@@ -270,7 +218,7 @@ Plan-file reviews retain their existing seven-day freshness handling and optiona
|
||||
|
||||
### Plan-to-QA flow
|
||||
|
||||
When `/plan-eng-review` finishes the test review section, it writes a test plan artifact to `~/.gstack/projects/`. When you later run `/qa`, it picks up that test plan automatically — your engineering review feeds directly into QA testing with no manual copy-paste.
|
||||
When an eng review writes a test plan artifact to `~/.gstack/projects/`, a later `/qa` picks up that test plan automatically — your engineering review feeds directly into QA testing with no manual copy-paste.
|
||||
|
||||
---
|
||||
|
||||
@@ -282,7 +230,7 @@ Most plans describe what the backend does but never specify what the user actual
|
||||
|
||||
`/plan-design-review` catches all of this during planning, when it's cheap to fix.
|
||||
|
||||
It works like `/plan-ceo-review` and `/plan-eng-review` — interactive, one issue at a time, with the **STOP + AskUserQuestion** pattern. It rates each design dimension 0-10, explains what a 10 looks like, then edits the plan to get there. The rating drives the work: rate low = lots of fixes, rate high = quick pass. Like `/plan-eng-review`, it skips the "what should I review?" scope question in plan mode and targets your active plan automatically (announced in one line so you can redirect); an explicitly named target wins in any mode.
|
||||
It works like `/plan-ceo-review` — interactive, one issue at a time, with the **STOP + AskUserQuestion** pattern. It rates each design dimension 0-10, explains what a 10 looks like, then edits the plan to get there. The rating drives the work: rate low = lots of fixes, rate high = quick pass. It skips the "what should I review?" scope question in plan mode and targets your active plan automatically (announced in one line so you can redirect); an explicitly named target wins in any mode.
|
||||
|
||||
Seven passes over the plan: information architecture, interaction state coverage, user journey, AI slop risk, design system alignment, responsive/accessibility, and unresolved design decisions. For each pass, it finds gaps and either fixes them directly (obvious ones) or asks you to make a design choice (genuine tradeoffs).
|
||||
|
||||
@@ -892,7 +840,7 @@ bounded scan and discloses inaccessible history or incomplete coverage. It reads
|
||||
raw uncommitted source without running project hooks or filters. It never edits
|
||||
code, runs project tests, saves a report, or creates issues or PRs.
|
||||
|
||||
`/plan-eng-review` applies the same criteria to the plan and proposed callers.
|
||||
`/autoplan`'s eng phase applies the same criteria to the plan and proposed callers.
|
||||
`/review` checks the diff and related callers even on tiny changes. These scoped
|
||||
checks do not run the history audit. Optional extractions are advisory and require
|
||||
approval; they do not block a clean review or reduce its score. Actual defects
|
||||
@@ -934,7 +882,7 @@ gstack's own templates and for any skill folder you own.
|
||||
## `/test-audit`
|
||||
|
||||
Find existing tests that cost more than they protect. `/review`, `/ship`, `/qa` and
|
||||
`/plan-eng-review` apply the same [test value bar](test-value-bar.md) to tests in a
|
||||
`/autoplan`'s eng phase apply the same [test value bar](test-value-bar.md) to tests in a
|
||||
diff; `/test-audit` sweeps the tests that already exist.
|
||||
|
||||
```text
|
||||
@@ -1290,7 +1238,7 @@ English in, diagram out. Describe the diagram (or paste mermaid source) and you
|
||||
|
||||
This is my **review autopilot mode**.
|
||||
|
||||
Running `/plan-ceo-review`, then `/plan-design-review`, then `/plan-eng-review` individually means answering 15-30 intermediate questions. Each question is valuable, but sometimes you want the gauntlet to run without stopping for every decision.
|
||||
Running `/plan-ceo-review`, `/plan-design-review` and `/plan-devex-review` individually means answering 15-30 intermediate questions. Each question is valuable, but sometimes you want the gauntlet to run without stopping for every decision.
|
||||
|
||||
`/autoplan` reads the review skills from disk and runs them sequentially: CEO → Design (if UI scope) → DX (if developer-facing scope) → Eng, always last — the required shipping gate reviews the final amended plan, not a stale one. It makes decisions automatically: each question resolves to its recommended option by default, with six encoded principles (prefer completeness, match existing patterns, choose reversible options, prefer the option the user chose for similar past decisions, defer ambiguous items, and escalate security) breaking ties and deciding questions that carry no recommendation. Taste decisions (close approaches, borderline scope expansions, cross-model disagreements) get saved and presented at a final approval gate.
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
gstack's test workflows share one rule: a test earns its place by protecting
|
||||
behavior that a real regression would break. Test count is not a goal. The bar is
|
||||
embedded in `/plan-eng-review`, `/review`, `/qa`, `/qa-only` and `/ship`, so every
|
||||
embedded in `/autoplan`'s eng phase, `/review`, `/qa`, `/qa-only` and `/ship`, so every
|
||||
new or changed test in a diff meets it without a separate step. `/test-audit`
|
||||
applies the same bar to tests that already exist.
|
||||
|
||||
|
||||
@@ -709,7 +709,7 @@ plan; the audit is `not run`.
|
||||
<a id="plan-eng-review-not-persisted"></a>
|
||||
### `PERSISTED: no` / `PERSIST: gstack-review-log '{...}'` / `no saved Eng Review: run the PERSIST: line ...`
|
||||
|
||||
**Meaning.** /plan-eng-review ran where the caller forbids writes (for example
|
||||
**Meaning.** The eng review methodology (`/autoplan`'s eng phase) ran where the caller forbids writes (for example
|
||||
a delegating agent keeps the reviewer read-only, so it cannot edit the plan it
|
||||
judges). The review completed: it ends `DONE` with `PERSISTED: no`, records
|
||||
telemetry `success`, and returns the full report and decision ledger in its
|
||||
@@ -727,7 +727,7 @@ review-log command with this review's values.
|
||||
~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"plan-eng-review",...}'
|
||||
```
|
||||
|
||||
Or rerun /plan-eng-review where it may write its report and log.
|
||||
Or rerun /autoplan where it may write its report and log.
|
||||
|
||||
**Expected result.** `gstack-review-read` lists the `plan-eng-review` entry and
|
||||
/ship's dashboard shows the Eng Review row (CLEAR when its status is `clean`).
|
||||
|
||||
+2
-2
@@ -1,8 +1,8 @@
|
||||
# Voice input (AquaVoice, Whisper, etc.)
|
||||
|
||||
Many gstack skills list speech-to-text aliases (`voice-triggers:` in their
|
||||
templates): "security check" for `/cso`, "run QA" or "test the app" for `/qa`,
|
||||
"tech review" for `/plan-eng-review`. Say one of those naturally and the right
|
||||
templates): "security check" for `/cso`, "run QA" or "test the app" for `/qa`.
|
||||
Say one of those naturally and the right
|
||||
skill can be picked without the slash command name. On Claude Code the aliases
|
||||
are routing lines in the root `/gstack` router; on Codex and the other hosts
|
||||
they are appended to each skill's description, which is what those hosts match
|
||||
|
||||
Reference in new issue
Block a user