gstack Part 3: How to Divide Responsibilities Among the Four Plan Review Skills

Four pre‑implementation skills in gstack

After /office-hours defines the problem, gstack provides four distinct skills that operate before any code is written. Each skill reviews a different object and answers a specific question. /plan-ceo-review – Should we build this? (product‑level evaluation) /plan-eng-review – Can we implement it reliably? (architecture, testing, performance) /plan-design-review – Are the UI/UX details fully specified? (interaction, states, accessibility) /design-consultation – What should the overall product look like? (build a design system)

1. /plan-ceo-review

Focus is not "can we do it?" but "should we do it?"

Runs after /office-hours and asks whether the request hides a better product version. The documentation highlights the phrase find the 10‑star product hidden inside the request . It does not annotate the plan; it questions the plan itself.

Internal modes

SCOPE EXPANSION

SELECTIVE EXPANSION

HOLD SCOPE

SCOPE REDUCTION

These modes let the user decide whether to broaden, narrow, or keep the scope and why.

Typical situations where it adds value

Direction feels roughly right but may not be optimal.

A clear user‑side feature is ready but the scope is uncertain.

A design doc exists and the author wants to verify it is the most valuable version.

It is not useful for pure bug fixes, technical debt, infrastructure changes, or small localized code changes, which require engineering rigor rather than product re‑evaluation.

2. /plan-eng-review

Focus is not "has an idea" but "can this idea be implemented reliably"

Answers the question “does the architecture hold up?” and operates in engineering manager mode . It forces hidden assumptions to surface and produces a concrete test plan.

Checklist

Architecture boundaries

Data flow

State changes

Failure modes

Test coverage

Performance risks

Existing code reuse

Explicit out‑of‑scope items

Four concrete reviews required by the repo

Architecture review

Code‑quality review

Test review – draw new UX, data flow, code paths, and branch results, then map each to a test.

Performance review

After the test review, the skill writes a test plan artifact to ~/.gstack/projects/, which later /qa and /qa-only consume.

When to run it

Multi‑step data flows or state machines

External integrations, async tasks, caching, retries

Clearly defined failure paths and boundary conditions

User interaction exists but the test plan is vague

The team feels the plan is almost ready but wants to surface potential break points

In most cases, once a plan moves toward implementation, /plan-eng-review should be applied.

3. /plan-design-review

It supplements not aesthetics but the UI/UX decisions that are often omitted.

Typical design docs only say “build a dashboard” or “add a settings page” without specifying loading, empty, error states, success feedback, mobile layout, accessibility, or AI‑slop fallback. This skill checks whether those details are clearly described.

Boundaries

If there is no UI scope, the skill exits immediately.

If a DESIGN.md exists, it is used as the baseline; otherwise the skill advises running /design-consultation first.

Scoring dimensions (0‑10)

Information architecture

Interaction states

User journey and emotional experience

AI‑slop risk

Design‑system alignment

Responsiveness and accessibility

Undecided design decisions

Any score below 10 requires an explanation of the gap and a concrete remedy.

4. /design-consultation

It is not a review; it builds a design system from scratch.

When no design system exists, this skill answers “what should the whole product look like?” It produces a complete design proposal, a preview page, and writes the result to DESIGN.md at the repository root.

Workflow

Read README, existing code, and the output of /office-hours for context.

Conduct competitive and space research.

Generate a full design proposal and preview page.

Write the design system (typography, color palette, layout, spacing, motion rhythm, component style) into DESIGN.md.

If a design system already exists, /plan-design-review will use it as the reference; otherwise the skill advises creating one first.

Choosing the right skill

Question “should we do this?” → /plan-ceo-review Question “can we implement this reliably?” → /plan-eng-review Question “are the UI/UX details fully defined?” → /plan-design-review Question “what should the overall product look like, what design language?” →

/design-consultation

Recommended sequencing

Path A – Design doc already exists

/office-hours

/plan-ceo-review

/plan-eng-review

/plan-design-review

(if UI scope exists)

Path B – UI product without a design system

/office-hours

/design-consultation

/plan-ceo-review

/plan-eng-review

/plan-design-review

Path C – Pure backend or infrastructure change

Usually only /plan-eng-review (and optionally /plan-ceo-review if product direction is involved).

Common pitfalls

Treating /plan-eng-review as a fancy code review – it evaluates the plan, not diffs, and surfaces failure modes early.

Running /plan-design-review without an existing design system – the review can only apply generic principles and loses alignment.

Skipping product/design reviews and jumping straight to coding – the code may be technically sound but solves the wrong problem or lacks UI details.

Assuming any review skill will automatically start implementation – they only mature the plan.

Why the four skills illustrate gstack’s value

They decompose the “pre‑implementation” phase, which is often collapsed into a vague “let’s start coding”. By separating product direction, engineering feasibility, UI/UX completeness, and design‑system creation, gstack prevents the “almost there” illusion and pushes high‑value work to the appropriate stage.

Future articles will cover post‑implementation phases such as /review and /investigate.