CalvinBackup/gstack
1
0
Fork 0
mirror of https://github.com/garrytan/gstack.git synced 2026-09-09 14:38:59 +02:00
Code Issues Packages Projects Releases Wiki Activity
Files
c8f0c4e368fd59ec316c0eb0d1f4ebfa896c2d16
gstack/docs/skills.md
T
Garry TanandClaude Fable 5.1 c8f0c4e368 v1.84.0.0 feat: impeccable interop: detector pre-pass in four design skills, DOM-mode scans, open DESIGN.md format, one typed slop catalog (#2832) 
* chore(design): pin impeccable rule ids and detector JSON shape as fixtures

Real captures from a human-initiated `npx impeccable install` in a scratch
directory (engine 0.1.3, linux-x64), never a runtime download:

- test/fixtures/impeccable-antipatterns.json: upstream
  crates/live/assets/antipatterns.json at 87d8f6d6 (the state engine-v0.1.3
  shipped), 61 rules, source commit recorded in `_source`.
- test/fixtures/impeccable-detect-sample.json: `detect --json` over gstack's
  planted-slop fixture (source mode), paths normalized.
- test/fixtures/review-eval-design-slop.dom.html + impeccable-detect-dom-sample.json:
  the same page served locally, dumped through the browse engine with the
  shared DOM-dump script, then scanned. Pins the load-bearing assumption
  that the static engine reads inline <style> in a .html file: the DOM scan
  yields the same id set as the source scan.
- lib/dom-dump-script.ts: the one dump script both browser engines evaluate
  (IIFE, no single quotes). Folds CSSOM rgb() back to author hex so palette
  rules still fire, and removes inlined <link> nodes so the engine does not
  warn about an unresolvable stylesheet. Both verified against the engine.
- test/fixtures/impeccable-detect-help.txt + impeccable-captures.meta.json:
  the flags, exit codes, finding fields, and re-capture protocol.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* refactor(design): typed slop catalog in lib/; AI_SLOP_BLACKLIST derived

lib/design-catalog.ts is the single source of truth for gstack's design
anti-pattern vocabulary: the 11 legacy blacklist lines (verbatim, flagged
`legacyBlacklist`), every one of impeccable's 61 registry ids with gstack
prose, tier, impact, confidence, grep heuristic, and /impeccable handoff,
plus the gstack-only tells the LLM pass judges (hero metrics, identical
cards, glassmorphism, missing states, unthemed browser surfaces, ...).

`impeccableId` is set only when the id exists in the registry fixture, and
`renderCatalog({style:'ids'})` brackets an id only then, so rendered prose
never shows an id the detector cannot emit. Role-scoped font lists
(OVERUSED_FONTS_DISPLAY, BANNED_FONTS, FONTS_BODY_UI_OK, FONTS_MONO_OK,
FONTS_VERIFIED_FREE) live beside the entries.

scripts/resolvers/constants.ts now derives AI_SLOP_BLACKLIST from the
catalog. Generated output is byte-identical (bun run gen:skill-docs is a
zero diff). Pure module: no I/O, no scripts/ imports, loading prints
nothing, so bin/ can import it at runtime on every host.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(review): generate review/design-checklist.md from the catalog

review/design-checklist.md was hand-written and its own header admitted it
drifted from DESIGN_METHODOLOGY category 9. It is now rendered by
scripts/resolvers/design-checklist.ts from lib/design-catalog.ts: category 1
lists every grep-detectable slop entry plus the legacy blacklist lines,
sorted HIGH/MEDIUM/LOW, each with its heuristic and, where the detector knows
the rule, its bracketed id (27 items, up from 6). The font blacklist renders
from BANNED_FONTS. Categories 2-5, Instructions, Classification, Output
Format, and Suppressions keep their prose. Title and slop heading are
unchanged (test/skill-e2e-review.test.ts and hosts/opencode.ts key on them).

gen-skill-docs writes the file for the Claude host only (a Claude-side
runtime asset; other hosts copy or inline the render), honors --out-dir, and
reports STALE/FRESH under --dry-run like sections do.
test/design-checklist-sync.test.ts pins committed == generated, the
host/out-dir scoping, and the dry-run freshness line.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(design): modes, craft-floor reflexes, calibration, catalog in doctrine

DESIGN_HARD_RULES: the classifier names four visitor modes (Persuade,
Operate, Read, Experience, plus Hybrid per section) and keeps the
MARKETING/LANDING PAGE and APP UI aliases; Read and Experience get three
rules each; a "Reflexes no detector catches" block (browser surfaces, one
authored motion moment, depth has an offset, tinted secondary text, space
above headings, light-or-dark from the use scene) and the three-looks
calibration follow the universal rules. The slop section renders the 11
legacy lines plus the detector rule ids and judgment tells from the catalog;
in design-review, which also renders DESIGN_METHODOLOGY, it becomes a
one-line pointer so the catalog is paid for once. Header counts are
computed, not hardcoded.

DESIGN_METHODOLOGY: category 9 renders the catalog in three registers
(legacy lines verbatim, detector rules that need judgment with bracketed
ids, gstack-only judgment tells as prose, polish-level ids on one line);
categories 5 and 7 carry the browser-surface and one-motion-moment reflexes;
the typography overused-face item points at [overused-font] with the
role-scoped exception. The consultation Codex prompt's anti-slop line reads
from the catalog.

Budget: design-review eager 25.6K -> 27.0K (ceiling 27,984), plan-design-review
unchanged at 17.4K; no carve-guard or context-budget re-baseline needed; ship
goldens unchanged (ship never renders the hard rules).

Derived from pbakaus/impeccable reference/craft-floor.md + new-work.md
(Apache-2.0), rewritten. See NOTICE.md (commit 12).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(design-consultation): font procedure, role-scoped overused list, color strategies

The proposal section stops handing out a font menu. "Choosing faces: a
procedure, not a menu" names the subject's world, shortlists per role,
strikes the overused list for that role, verifies availability in-session,
and states the loading strategy. {{OVERUSED_FONTS}} renders the role-scoped
lists from lib/design-catalog.ts: overused as display (the detector's
overused-font set plus the training-data defaults), fine as body/UI on an
Operate or Read surface, mono for data and code, banned in any role, and a
short verified-free list with its verification date. Color approaches become
Restrained / Committed / Full palette / Drenched. The anti-convergence
directive drops light-vs-dark as a dial (it comes from the use scene) and the
three-looks calibration sits under Your Design Knowledge. The slop list is
{{DESIGN_SLOP_BULLETS}}: prose from the catalog, no rule ids, polish-level
tells omitted.

design-html's "Never include (AI slop blacklist)" list keeps its literal
(carve guard) and each line now carries a trailing <!-- id --> naming a
catalog entry, pinned by test/design-catalog.test.ts so the last surviving
duplicate is derived-by-test. Both resolvers are registered and listed in
ARCHITECTURE.md. No carve-guard or budget re-baseline needed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(bin): gstack-design-detect wrapper + design_detector config key

bin/gstack-design-detect.ts finds and runs an impeccable engine the user
installed; it never installs, downloads, or executes anything that could
download. `probe` reads only: config (design_detector off → DISABLED),
IMPECCABLE_BIN (absolute, realpath outside the repo and cwd), a PATH walk
(absolute entries outside the repo; a #! shim counts as launcher-present,
never READY), the ~/.impeccable/bin/<newest semver>/ cache, and the engine
installed beside a skill launcher (scripts/bin/<os>-<arch>/impeccable, the
layout a real install produced). It reports IMPECCABLE_SKILL, host-aware
IMPECCABLE_HOOK (+ HOOK_OTHER), the ignore lists from .impeccable/config*.json,
IMPECCABLE_ENGINE_UNTESTED for versions outside the fixture set, and a hint
only when a launcher exists without its engine. `scan` re-probes, refuses
URLs and anything outside the repo root or the design-report allow-list
(realpath, so symlinks cannot escape), derives `--changed <base>` targets
NUL-safely through git and lib/frontend-scope.ts, batches 100 absolute paths
per engine call with stdin ignored, a SIGKILL timeout, a 50 MB stdout cap, and
sanitized length-capped fields, then prints one normalized JSON document
(--format gstack) or the engine's bytes (--format raw); DETECT_TOP (fenced as
untrusted content), DETECT_SUMMARY, and DETECT_EXIT go to stderr; exit code
passes through with 1 over 2 over 0; exit 3 is a gstack bug. `rules` prints
the mapped set. Every run appends a content-free line to the local analytics
file.

lib/design-detect-contract.ts owns every sentinel string, the limits, and the
normalized-finding shape (pure module); test/design-detect-contract.test.ts
asserts every sentinel-shaped token the agent can read exists there.
lib/frontend-scope.ts mirrors gstack-diff-scope's frontend arm, pinned by a
parity test that runs the bash script. bin/gstack-config gains
design_detector (auto | off, default auto, invalid values rejected with the
file unchanged). test/fixtures/fake-impeccable.ts is the env-driven engine
stand-in; test/gstack-design-detect.test.ts covers READY/NOT_CACHED/
NOT_AVAILABLE/DISABLED, env trust (.env never loaded, in-repo IMPECCABLE_BIN
ignored), newest-semver cache, hook and ignore detection, refusals, exit
passthrough, raw byte-identity, normalization, the display cap, timeout,
parse errors, diagnostics, --changed, and analytics. The egress scanner test
records the wrapper as a documented non-sink.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(design): {{DESIGN_DETECTOR}} wired into design-review, ship review-lite, review army, design-html

The user-installed impeccable engine becomes a deterministic pre-pass in four
skills, through one resolver with three renders: {{DESIGN_DETECTOR}} (the probe
block and how to read every sentinel), {{DESIGN_DETECTOR:phase0}} (design-
review's mechanical scan), {{DESIGN_DETECTOR:gate}} (design-html's bounded slop
gate). Every rendered invocation is `bun --no-env-file run <bin>/gstack-design-
detect.ts ... --host <host>` and every scan ends with the DETECT_EXIT_CODE echo
so exit 2 (findings) never aborts a block.

design-review: probe in Setup; Phase 0 picks DOM mode (URL target) or source
mode (diff-aware, no URL) once; source mode scans the changed frontend files in
Setup, DOM mode never reads source (Rule 4). Phase 3 gains a DOM-dump step per
page: both browser engines load the shared script from lib/dom-dump.js (Aside
splices it into a double-quoted repl script; the fallback engine copies it into
a temp dir for `$B eval --out --raw`), the dump is size-capped, run through
gstack-redact (a HIGH finding skips the page), and persisted under
$REPORT_DIR/dom/$RUN_ID/; one scan runs after the last page, labeled "static
scan of the rendered DOM; cross-origin CSS not resolved". REPORT_DIR honors
GSTACK_HOME so the wrapper's allow-list and the report dir agree; RUN_ID is set
once in Setup. design-baseline.json is schemaVersion 2 with runId, targetSet,
base, and a detector block (mode, engine, byRule, byPage), written temp+rename
with a per-run copy; Regression Output diffs ids only when mode and target set
match, caveats an engine change, and calls live-page count deltas advisory.
Phase 7 hands deferred detector findings to the `handoff=` command the scan
printed; Phase 9 recomputes the same way and deletes the dumps unless
--keep-dom; Phase 10 reports `Detector: N → M`.

ship review-lite gains step 0 (probe, `scan --changed <base>`, tier buckets,
detector + checklist dedupe, advisory and ignored never count) and a
`detector` count in its log payload; the PR body gets a Detector line (rule
ids and counts only). The Review Army Design specialist runs the mechanical
pass at the top of review/design-checklist.md, which now carries it. design-
html probes after DESIGN_SETUP and runs the one-pass gate before screenshots.

lib/dom-dump.js is generated by gen-skill-docs from lib/dom-dump-script.ts
(Claude host, --out-dir aware, dry-run freshness) and pinned byte-equal, so the
prose never carries the script. The contract gains DETECT_JSON, DOM_DUMP_OK,
and the self-describing set; its test now checks both directions.

Budget: design-review eager 25.6K → 28.5K. The plan's target was +2.5K; after
the levers it named (ids-only detector rules, no inline script, trimmed prose)
it lands at +2.87K, and the remainder is doctrine and detector wiring, so the
ceiling moves to the captured 31,319 for design-review only (the full capture
would also have loosened 21 ceilings this branch never touched; those stay).
design-html skeleton re-baselined to 54,000 (measured 53,592). Codex and
Factory ship goldens refreshed (review-lite step 0 and the PR-body line render
inline there).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(design): catalog never-lines in the mockup prompt

Ten catalog ids carry `mockupNever` (kicker-above-heading, icon-tile-stack,
gradient-text, ai-color-palette, cream-palette, nested-cards, dark-glow,
pulsing-dot, identical-cards, hero-metrics) and lib/design-catalog.ts exports
their deduped plain-English names as MOCKUP_NEVER_NAMES. briefToPrompt() in
the design binary appends "Never: <names>." before its fixed tail, so `$D
generate | variants | evolve` stop reaching for purple gradients, icon tiles,
and cream defaults before the comparison board opens. The binary still
bundles (`bun build --compile design/src/cli.ts`); ./setup rebuilds it.

design-html's Never-include list now covers every mockupNever id (kicker /
icon tile, hero metric rows, gradient text, cream palette, nested and
identical cards, glow and pulsing dots), each line tagged with its catalog
ids; test/design-catalog.test.ts pins the exact ten flags, the deduped names,
and that the template list is a superset. New design/test/brief.test.ts pins
the prompt shape.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(lib): open DESIGN.md reader/writer + gstack-design-md bin

lib/design-md.ts implements the open DESIGN.md format (google-labs-code/
design.md, Apache-2.0): YAML front matter with the five token groups (colors,
typography, rounded, spacing, components) and eight canonical `##` sections
in spec order (Overview, Colors, Typography, Layout, Elevation & Depth,
Shapes, Components, Do's and Don'ts), aliases mapped, extras preserved after
them in their original order. parseDesignMd never throws (unparsable front
matter → `unknown` with a reason); renderDesignMd re-emits the preserved front
matter bytes and only `convert` writes fresh YAML through a small block-style
emitter (Bun.YAML.stringify is flow style); upsertSection splices the body
only; tokensFlat resolves `{path}` references to primitives and reports group,
self, dangling, and cyclic refs as DESIGN_MD_TOKEN_REF_INVALID. convertLegacy
turns gstack's pre-spec DESIGN.md into the open format: Product Context and
Aesthetic Direction fold into Overview, Typography roles become
display/body/label/mono tokens (mono carries fontFeature: tnum), Color hexes
become colors (mode-qualified labels keep their qualifier; strategy lines are
not colors), the Spacing scale and Layout radii become spacing and rounded,
Motion / Grain Texture / Decisions Log survive as extras. The format marker
lives inside the file: a YAML comment on line 2 of a spec file, an HTML
comment on line 1 of a legacy file.

bin/gstack-design-md.ts: `check` (DESIGN_MD_FORMAT + marker), `convert
[--write]` (backup to DESIGN.md.legacy.bak, temp+rename, refuses ambiguous
input with DESIGN_MD_CONVERT_REFUSED), `tokens` (flat JSON), `mark
<spec|legacy-keep>`. Exit 3 + DESIGN_MD_INTERNAL_ERROR is a gstack bug.

design/src/memory.ts: updateDesignMd upserts "Extracted Design Language"
through the lib (front matter bytes untouched, canonical order kept, section
replaced on rerun) and creates a spec skeleton with tokens from the extraction
when no file exists; readDesignConstraints leads with the flat tokens and the
Overview for spec files. The design binary still bundles.

test/design-md.test.ts pins all of it against gstack's own DESIGN.md.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(design): write/read DESIGN.md in the open spec; persisted format choice

gstack's design skills now write DESIGN.md in the open DESIGN.md format and
read tokens from it. {{DESIGN_MD_CHECK}} renders the format check through
bin/gstack-design-md.ts: design-consultation's Phase 0 settles the format once
(spec → update tokens in the front matter; legacy without a marker → one
AskUserQuestion: convert with a .legacy.bak, keep the legacy file, or start
fresh; the answer is written into the file as the format marker so no skill
asks again; a marker already present is obeyed silently; unknown → prose;
missing → Phase 6 writes one). Phase 6's template is the spec form: YAML front
matter with name, description, and exactly the five token groups (colors,
typography.display/body/label/mono with fontFeature: tnum on mono, rounded,
spacing, components with {path} references), then Overview (Creative North
Star, product context, mode per surface, references, key characteristics),
Colors (opening with the Restrained / Committed / Full palette / Drenched
strategy), Typography, Layout, Elevation & Depth, Shapes, Components, Do's and
Don'ts, plus gstack's Motion and Decisions Log as extras; the template ends
with a check that the file parses as `spec`.

design-review runs the `:calibrate` form in Setup: a spec file's flat tokens
are the calibration source (a value present in the tokens is never a finding),
the marker is respected, and conversion is never offered there; its DESIGN.md
export writes the spec form. design-html's token extraction writes the spec
form and respects an existing choice. review/design-checklist.md category 5 and
ship's review-lite step 1 name `gstack-design-md tokens` as the calibration
source; plan-design-review Pass 5 cites tokens by path when front matter
exists.

The contract owns the bin's DESIGN_MD_MARKER / REASON / WRITTEN / BACKUP
lines; the contract test's pending list closes. Carve guard: design-
consultation skeleton 66,500 → 67,500 (measured 67,014; +1,508 B against the
1.5 KB cap). Codex and Factory ship goldens refreshed (review-lite step 1).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(design): PRODUCT.md prefill + /impeccable handoffs

design-consultation's context gathering and design-shotgun's auto-gather read
PRODUCT.md (impeccable's product-context file) when it exists: it counts as
the user's prior answers, gets confirmed in one line, and is never re-asked.
Neither skill opens `.claude/skills/impeccable/**`; PRODUCT.md and DESIGN.md
are the shared surface, and impeccable's prose never loads inside a gstack
skill.

Handoffs: ship's review-lite ends each NEEDS INPUT detector row with the
`handoff=` command the scan printed (`/impeccable <cmd>`) when the probe
reported IMPECCABLE_SKILL: present, recommending the command and never
opening its files; design-review's Phase 7 does the same for deferred
findings, and `design_detector: off` silences handoff lines with the rest.
Codex and Factory ship goldens refreshed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* chore(design): convert gstack's own DESIGN.md to the open spec

`gstack-design-md convert --write` on the repo's DESIGN.md: tokens in YAML
front matter (typography.display/body/label/mono, colors with their light/dark
qualifiers, spacing scale, rounded scale), Overview from Product Context and
Aesthetic Direction, Colors / Typography / Layout as canonical sections, Motion,
Grain Texture, and Decisions Log preserved as extras, format marker on line 2.
Hand-checked; `check` reports spec with no token-reference errors. A Decisions
Log row records the conversion and that DM Sans stays the body face: it is on
the overused-as-display list, and body/UI use on an Operate surface is the
allowed exception under the role-scoped rule.

The pre-conversion file lives on as test/fixtures/design-md-legacy.md, which
test/design-md.test.ts now uses for its legacy cases; the converted root file
is asserted to be spec.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* docs: NOTICE, Apache license text, README interop, project structure

NOTICE.md names what gstack derived from impeccable (rule ids and names in
the catalog and the registry fixture; the visitor modes, craft-floor
reflexes, and calibration in the design resolvers; the font procedure in the
consultation template) and from Google's DESIGN.md specification (the format
lib/design-md.ts implements), states that gstack does not distribute or audit
the impeccable engine, and points at licenses/Apache-2.0.txt (verbatim).

README: the design-consultation, design-review, and design-html rows say what
changes when impeccable or the open DESIGN.md format is in play, and a "Works
with impeccable" paragraph explains the pre-pass, the shared ids, PRODUCT.md
and DESIGN.md as the shared surface, the handoffs, the no-nag posture without
impeccable, and the off switch. docs/skills.md gets the detector paragraph
under /design-review. docs/PROJECT_STRUCTURE.md lists the new lib and bin
files, NOTICE.md, and licenses/. docs/designs/IMPECCABLE_INTEROP.md promotes
the CEO plan (its ~/.gstack copy is flipped to PROMOTED) with a "what
shipped" summary. TODOS.md files the seven deferrals from the reviews: the
design-review Phases 7-11 carve (the budget lever, with the +2.87K vs 2.5K
landing recorded), the Bun .env audit across bin/*.ts, the Kiro bin/lib gap,
the $D check slop rubric, taste-profile interplay, the CEO Section 11
bullets, and the scan cache.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* test: touchfiles, tiers, shim E2E, real-engine fixture

Touchfiles: the catalog, contract, detector bin, checklist resolver, review-
army resolver, and DESIGN.md lib join the dep lists of review-design-lite,
design-review-fix, the design-consultation cases, and plan-design-review-no-
ui-scope, so editing any of them re-selects the tests that read their output.
Three new E2E keys: design-review-detector-shim (gate; source mode on a
feature-branch diff), design-review-detector-shim-dom (gate; DOM mode: the
slop fixture served on loopback, dumped through the browse binary with
lib/dom-dump.js, persisted under a GSTACK_HOME-scoped REPORT_DIR, scanned once;
self-skips when browse/dist/browse is absent), and design-html-slop-gate
(periodic; one fix pass, at most two scans, remaining findings accepted with
reason). Every case reaches the engine through test/fixtures/fake-impeccable.ts
via IMPECCABLE_BIN from outside the temp repo, reads extracted skill sections
(never a whole SKILL.md) with the installed bin path rewritten to this
checkout, and asserts the probe ran, the right scan verb ran, `npx impeccable`
never did, and the output carries FINDING rows tagged [ai-color-palette] and
[low-contrast]. review-design-lite gets the fake engine and an eighth tally
signal for a detector row; its 4-hit threshold is unchanged.

test/gstack-design-detect.test.ts evaluates design-review's REPORT_DIR
expression with GSTACK_HOME set and proves a dump under it is accepted by the
wrapper's allow-list. The sample fixtures were real captures from commit 1
(engine 0.1.3), so there is nothing hand-written left to swap.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design-detect): never execute a repository-controlled engine; allow-list --changed targets; sanitize engine text

Pre-landing review findings (security + checklist), all reproduced before the fix:

- A checked-out branch could commit `.claude/skills/impeccable/scripts/bin/<os>-<arch>/impeccable`
  and the probe would report READY and `scan` would run it, with the agent's full
  environment. Launchers and sibling engines under the repo or cwd now count as
  "skill present" only (IMPECCABLE_NOT_CACHED: repository-local install, and the
  hint never names a repository-local launcher to run); only HOME-rooted installs,
  IMPECCABLE_BIN, the cache, and PATH entries outside the repo qualify, all by
  realpath. The engine now sees a minimal environment (PATH, HOME, TMPDIR, locale,
  IMPECCABLE_*), never the agent's tokens.
- `scan --changed <base>` pushed git-derived paths without the allow-list, so a
  committed symlink with a frontend extension handed a file outside the repo to
  the engine. Derived targets now go through the same allow-list as explicit ones
  and symlinks named by git are refused outright.
- A repo-controlled `scripts/VERSION` with embedded newlines forged probe lines;
  the version is trusted only when it is semver, and every printed version is
  sanitized. Engine text containing the untrusted-content fence or a
  `SENTINEL:` prefix is neutralized with a zero-width space
  (neutralizeSentinels in the contract), so page text cannot close the envelope
  or forge a probe line.
- A failing `git diff <base>...HEAD` (unknown or unfetched base) was swallowed
  and read as "no frontend changes"; it is now DETECT_REFUSED with exit 1.
- The scan allow-list root follows `${GSTACK_HOME:-$HOME/.gstack}` like the
  templates and gstack-slug (config.yaml keeps gstack-config's STATE_ROOT
  precedence); a quoted or commented design_detector value reads correctly.

Smaller: raw engine chunks are kept only in --format raw; diagnostics are
capped (200 kept, 20 echoed); the engine identity hash reads size + 4 MB, not
the whole binary; PROBE_STEP and ENGINE_STDERR are contract sentinels; the
--verbose gate covers every probe step; analytics use one sentinel vocabulary;
bare limits live in DETECT_LIMITS. The fake engine's knobs are IMPECCABLE_FAKE_*
(so they pass the minimal env) and a shared test helper installs it. New tests
cover each item above plus clean runs, `{}` parse errors, missing paths, and the
50 MB stdout cap.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design-md): mark and updateDesignMd never rewrite the user's file; refuse a contradictory mark

renderDesignMd re-sorted canonical section names into spec order on every
render, so `gstack-design-md mark legacy-keep` (the "leave it alone" answer)
and the design binary's mockup extraction reordered a legacy DESIGN.md
(Typography and Layout jumped to the top) and normalized its whitespace, while
the bin promised "body bytes untouched". `mark` now splices only the marker
line (insertMarker) and `updateDesignMd` splices only its own section
(spliceSection); every other byte of an existing file is preserved, and spec
order applies only to files that open with front matter. `mark` refuses a
choice that contradicts the file's format (spec on a non-spec file,
legacy-keep on a spec file) with DESIGN_MD_CONVERT_REFUSED, exit 2, file
unchanged. convertLegacy keeps intro prose under the title instead of
rebuilding the preamble from the title alone. detectFormat returns a
machine-readable `code` beside the prose reason (the bin no longer branches on
reason text); the marker regexes derive from FORMAT_MARKER_PREFIX and
FORMAT_CHOICES; the hop limit and legacy identity headings are named
constants; slug is exported and reused; both writers use lib/fs-atomic.ts.
Tests pin byte identity for mark and updateDesignMd on the legacy fixture,
the refusal paths, and the preserved preamble.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design): run the DOM dump in the page on both engines; align doctrine with the catalog

The DOM-dump script is an arrow function, not a self-calling IIFE: Aside's
`pg.evaluate($_DUMP)` receives the function and runs it in the page (the IIFE
form executed in the repl sandbox, where `document` does not exist), and the
fallback engine calls it with `$B js "($_DUMP)()" --out --raw`. Hygiene widens
to every URL-bearing attribute (src, srcset per candidate, poster, action,
formaction, data, ping, cite lose their query strings and fragments) and to
data: URLs inside existing <style> nodes. The persist and scan blocks restate
REPORT_DIR and RUN_ID literally instead of relying on a shell variable from an
earlier block; the baseline's targetSet is defined per mode (repo-relative
paths in source mode, page slugs in DOM mode) so DOM-mode deltas can match; the
PR-body Detector line lists the states the probe can actually print. The DOM
fixture is re-captured with the new script from outside the repo (the engine
walks up from cwd for DESIGN.md, which the metadata now records).

Doctrine contradictions the design specialist found: the landing-page motion
rule matches the one-authored-moment reflex; the background rule names the
catalog's halo/spotlight/stripe/grid slop instead of asking for gradients; the
universal font rule is scoped to the display voice with the body/UI exceptions;
"two typefaces max" allows the mono; the methodology's banned-font line renders
BANNED_FONTS; Courier New is banned outright; the Brutalist, Retro-Futuristic,
and Playful menu entries stop recommending system stacks, glow, and bounce; the
coherence nudge uses the decoration vocabulary; Path A's gate names the display
voice; font-loading prose points at the source the procedure verified;
centered-everything is MEDIUM (an aggregate heuristic); the mockup guard reads
"Never by default (unless the brief above asks for it)". The checklist's
AUTO-FIX list renders the catalog's auto-fix rules; category 9 and the Hard
Rules pointer count from the same partition helpers (detectorSlopEntries,
judgmentTellEntries); the handoff list renders from HANDOFF_COMMANDS; a missing
catalog id fails gen-skill-docs by name. gstack's own DESIGN.md gains border
tokens and Decisions Log rows for its live-feed pulse and 11px mono labels.
frontend-scope is case-sensitive like the bash arm. gen-skill-docs shares one
emitGenerated helper for sections and lib-derived assets; renderCatalog keeps
the one style with a caller. Tests: shared sliceBetween that fails on a missing
end marker, the slop-gate fixture's real end marker, an isolated browse daemon
for the DOM-mode E2E, the DOM hygiene test gated to CI or opt-in, docs notes
for the two superseded plan sentences.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design-detect): an engine is a file named impeccable outside the project; DOM dumps scan without inline ignores

Second review cycle, security + checklist:

- IMPECCABLE_BIN=/bin/sh (or node) was READY, and `detect` with cwd=repoRoot
  made the interpreter run the repository's own `detect` file. Every engine
  candidate (env override, PATH entry, cache, sibling) is now judged by the
  realpath of the FILE and must be named impeccable[.exe]; PATH and cache
  candidates that resolve into the repository are skipped like the others.
  "Inside the project" means the repository, or cwd when cwd is a project
  directory: HOME and its ancestors are exempt, so a URL-mode review launched
  from HOME still finds the HOME-rooted installs.
- A base for --changed that starts with `-` was spliced into git argv
  (`--output=<file>` made git write a file and report no changes); an option-
  like or missing base is DETECT_REFUSED (not a ref name), exit 1, and the
  parser no longer defaults a missing value to main.
- DOM dumps are the audited page's bytes, so an in-file `impeccable-disable`
  comment there is page-controlled: batches under the designs root run with
  --no-inline-ignores, repository batches keep the project's own ignores.
- neutralizeSentinels covers the shapes it missed (bare sentinels such as
  DETECT_TOP total= and IMPECCABLE_DISABLED, the DETECT_EXIT_CODE= echo, the
  `[rule-id] impact=` group header) in one precompiled alternation instead of
  37 replaceAll passes per field; only kept findings are normalized, and the
  summary's total stays the engine's count.
- The minimal engine environment compares keys case-insensitively on Windows
  (process.env enumerates Path, SystemRoot there) and passes PATHEXT, COMSPEC,
  HOMEDRIVE, HOMEPATH, PROGRAMDATA.
- Bare 64s move into DETECT_LIMITS; the unused SentinelName type is gone; the
  header states the directory-target contract (the engine's own walk).

Tests: an interpreter as IMPECCABLE_BIN never runs the repo's detect file; a
PATH symlink into the repository is never READY; option-like and empty bases
are refused with no file written; the designs-root batch carries
--no-inline-ignores and the repo batch does not; the identity label is
deterministic per binary; the bare-sentinel and header shapes are neutralized;
the installed fake engine works without IMPECCABLE_FAKE_OUTPUT (the helper
copies the sample beside it); two tests clean up in finally.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design-md): text-level edits keep CRLF, one section-boundary rule, control characters quoted

- insertMarker and spliceSection normalized every line ending to LF, so a CRLF
  DESIGN.md came back rewritten beyond the one line they promised to touch.
  Both detect the file's dominant line ending and restore it.
- parseDesignMd and spliceSection each walked headings with their own fence
  tracking; they now share headingLines (and upsertSection shares
  headingMatches). An unclosed ``` is treated as prose for that file: it used
  to swallow every later section on a splice.
- A token value carrying a control character (an LLM-extracted font family
  with an embedded newline) was emitted as a bare multi-line scalar that
  Bun.YAML rejects, turning a freshly written DESIGN.md into
  frontmatter-unparsable; needsQuotes routes it through the quoted form.
- The marker-line regex variants are built once beside YAML_MARKER_RE; the
  dead setMarker export and a no-op ternary are gone; LEGACY_HEADINGS derives
  from the identity list; the header diagram names the text-level editors as
  the write path for user-owned files; the bin validates and prints the mark
  choices from FORMAT_CHOICES.

Tests: CRLF round-trips for both editors, a fenced ## inside a section and an
unclosed fence, and a newline-bearing scalar parsing back.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design): Aside dump script stays single-quoted; redaction gate sized to the dump cap; doctrine made consistent

- The DOM-dump Aside block was the only double-quoted `aside repl` script in
  the tree (to splice the function text), which put the agent-filled <url>
  inside a double-quoted bash string: a same-origin href carrying $(...) would
  run in the reviewer's shell when Phase 3 opened that page. The script is
  single-quoted like every other Aside script and the function text enters
  through a closed-quote segment ('"$_DUMP"'); the fallback line is
  `$B js '('"$_DUMP"')()'`. A free test pins that no rendered Aside script
  opens with a double quote.
- The persist block capped dumps at 10 MiB but ran gstack-redact with its
  1 MiB default, so every real page between the two was deleted as
  DOM_DUMP_REDACTION_BLOCKED; the gate passes --max-bytes at the dump cap and
  blocks on any exit other than clean (0) or MEDIUM (2), so a redaction tool
  that fails to run can no longer fall through to "persist".
- Dump hygiene removes <template> and <noscript> subtrees (invisible to the
  attribute walk), inline on* handlers, and the cross-origin <link> nodes
  already named in the note, so the file handed to the engine references no
  remote stylesheet.
- Doctrine: the Codex design-voice prompts said "2-3 intentional motions"
  against the one-authored-moment rule; the overused-display heading scoped
  its ban to Persuade/Experience while the catalog and hard rules ban it
  everywhere; design-consultation's Important Rule 4 still said "as primary";
  design-html's blacklist header is now "Never include by default" with the
  mockup/DESIGN.md/user-ask override the catalog grants; the slop gate honors
  Decisions Log and Do's and Don'ts blessings like /review does; the landing
  "poster" line says poster in stance, not type size; the design binary's
  variant dials no longer flip light/dark for variety; gstack's DESIGN.md
  rows name data labels (UI labels stay the DM Sans token) and call the
  skill-bar fill and hovers functional transitions.
- design-review names how the base branch is found (gh pr view, then the
  repo default; never main) for the source-mode scan and the diff-aware mode.
- frontend-scope matches the config globs at the repo root only, like the
  bash arm; the parity test carries nested samples.
- Cleanups: renderCatalog's stale style option, an unused import, the
  identity-map bannedFontNames, the checklist header's "same entries" claim,
  the catalog header's consumer list, the orphaned main() docstring, the
  plan doc's IIFE bullet. design-html's skeleton ceiling is re-measured
  (54,184) for the two doctrine sentences.

Tests: AUTO-FIX rendering from the catalog, the E2E slice markers checked in
the free suite, the hygiene cases for templates/noscript/handlers/remote
links, and the review E2E counting detector rows separately from the seven
checklist plants.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design-detect): project means below HOME; only page dumps drop inline ignores; a whole-scan budget; prototype-safe rule counts

Third review cycle + Red Team, all reproduced before the fix:

- With no repository, the wrapper adopted cwd as the repo root, so a review
  launched from HOME (URL mode can run from anywhere) rejected every
  HOME-rooted install as "repository-local", reported the user's own skill
  install with the wrong hint, and, for targets, accepted all of HOME
  (~/.ssh/id_rsa scanned). A project directory is now one strictly below
  HOME: `git init ~` never turns the user's installs into repository files,
  and from HOME only the designs allow-list qualifies as a target.
- --no-inline-ignores keyed on "not inside the repo", which misclassified
  dumps when GSTACK_HOME sits under the repo and stripped the design-html
  gate's own `<!-- impeccable-disable -->` from finalized.html. Targets are
  classified as project / dom-dump (designs/<audit>/dom/**, the page's bytes)
  / artifact (other designs/ files, gstack-authored); only dumps drop inline
  ignores.
- A repository's .impeccable/config.json can hide rules from the review;
  detector.ignoreValues was never surfaced. The probe prints
  IMPECCABLE_IGNORED_VALUES beside the rules, and the prose stops calling
  repo-config ignores "a decision the user made".
- An engine id named `constructor` corrupted byRule through
  Object.prototype and `__proto__` counts vanished; byRule is a null-
  prototype object and an id that fails the shape check is `unmapped` as a
  key too.
- Batches ran with no total budget (10,000 un-ignored files: hours). The
  scan stops at 5x the per-batch timeout with DETECT_TIMEOUT and exit 1.
- The scan JSON carries an `untrusted` list of the engine- and page-derived
  fields, so the agent reading past the fenced DETECT_TOP block is told what
  is evidence.
- The PATH walk keeps launcher-present for a .cmd wrapper or a differently
  named real file (the name gate applies to READY only).

Tests: probe and scan from a fake HOME (cache READY, HOME file refused, dump
scanned without inline ignores), artifact vs dump batches, prototype-member
ids, the whole-scan budget over 11 batches, ignoreValues surfaced, the
`untrusted` field.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design-md): edits follow a symlinked DESIGN.md, keep the BOM and the majority line ending, refuse an unclosed fence

- `mark`, `convert --write`, and the design binary's extraction replaced a
  symlinked DESIGN.md (a docs-site layout) with a regular file and left the
  real target untouched; both writers resolve the link first.
- A single stray CRLF flipped a whole LF file to CRLF: the editors now keep
  the majority ending. A UTF-8 BOM broke format detection and ended up
  mid-file after `mark`; it is recognized and kept at byte 0.
- Re-running `mark` on a marked file deleted the blank line after the marker
  (`\s*$` matched across the newline); the marker regexes use `[ \t]*`.
- Fences: readers follow markdown (an unclosed fence runs to EOF); the
  text-level editors refuse such a file with DesignMdEditRefused
  (DESIGN_MD_EDIT_REFUSED) instead of splicing the wrong section, and the
  design binary reports that and leaves the file alone.
- needsQuotes also quotes a scalar containing ` #` (an inline-comment
  shape parsed back as a truncated value).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design): dump hygiene covers CSS URLs, srcdoc, and handlers; dumps persist owner-only; ignore prose treats repo config as evidence

- The dump script cuts query strings from CSS url() in style attributes,
  <style> nodes, and the inlined stylesheets (signed asset URLs), empties
  srcdoc, and covers background and xlink:href.
- Persisted dumps are chmod 600; MEDIUM redaction findings persist (an
  authenticated page shows emails) and the prose says so; earlier runs'
  dumps are swept before the first dump of a run unless --keep-dom.
- The Aside dump prose asks for `'` in a pasted URL to be percent-encoded
  (a bare single quote would end the script) and never to paste an unread
  URL.
- Repo-config ignores are evidence, not settled decisions, in /review,
  /ship, and design-review's probe prose; the scan JSON's text fields are
  named as untrusted.
- design-html's skeleton ceiling is re-measured (54,545); ship goldens
  refreshed for the checklist prose.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design-detect): audit directories scan as dumps; scans print probe lines on stderr; refused base always exits 1; PATH loses project entries

Adversarial review (Claude subagent):

- A DIRECTORY target under designs/ (the audit dir, which the prose hands the
  agent as REPORT_DIR) classified as an artifact, so the engine walked its
  dom/ subtree WITH inline ignores honored. Any directory under designs/ is
  now scanned as dumps.
- A scan whose probe no longer finds an engine wrote its sentinel lines to
  stdout and exited 0, so `scan > "$_DJ"` captured "IMPECCABLE_NOT_AVAILABLE"
  as the scan result and the rendered bash read a clean scan. Probe lines go
  to stderr on every path; stdout is the JSON document or nothing.
- A refused --changed base exited 0/2 when explicit targets were also given;
  it folds into the exit code (1 over 2 over 0). A trailing --changed no
  longer defaults to main.
- A hand-edited `design_detector: Off` re-enabled the detector; the value is
  compared case-insensitively.
- The engine inherited PATH entries inside the project (a direnv .envrc
  adding node_modules/.bin); those are filtered like every other project path.
- DOM_DUMP_MISSING names the case where the dump script wrote nothing.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design-md): markdown edge cases: rule-opened legacy files, spaced fences, ~~~ blocks, duplicate headings, YAML 1.2 numerics

- insertMarker keyed on "starts with ---", so a legacy file opening with a
  horizontal rule got a `# gstack:` line rendered as a heading that the
  parser then never read back (the conversion question re-asked every run).
  It keys on parsed front matter.
- A closing front-matter fence with trailing spaces (`---  `) made a valid
  spec file `unknown`; the closer is any whole `---` line.
- `~~~` fences hid nothing, so a `## ` inside one was a section boundary and
  a splice corrupted the fence; both fence kinds are tracked and only the
  same kind closes an opener.
- convertLegacy silently kept the first of two `## Layout` bodies (and one
  of `## Color` / `## Colors`); it refuses with DESIGN_MD_CONVERT_REFUSED and
  the bin leaves the file and writes no backup.
- needsQuotes covers 0x / 0o / .inf / .nan (YAML 1.2 numerics that changed
  type on round-trip); emitYamlBlock throws on an object inside an array
  instead of writing "[object Object]".
- The design binary coerces the model's extraction JSON at the parse
  boundary (null names, missing arrays) so the paid call's result survives.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(design): print and alternate stylesheets are not scanned as page CSS; no cross-run dump sweep; probe-state and design-system caveats in prose

- The dump inlined every linked sheet's rules as active CSS, so a print
  sheet's 12pt black text or an alternate theme produced tiny-text and
  palette findings the user never sees; disabled and alternate sheets are
  skipped and a media-scoped sheet is wrapped in its @media block.
- The cross-run dump sweep is gone: two same-day reviews shared REPORT_DIR
  and one run's sweep deleted the other's dumps mid-audit. Dumps stay per
  run, owner-only, deleted after Phase 9 unless --keep-dom (now defined in
  the prose), and an interrupted run's dumps wait for the user.
- Prose: design-system-* rows in DOM mode compare the page to THIS repo's
  DESIGN.md and apply only to the repo's own app; an empty scan JSON with
  exit 0 means the probe state changed since Setup (read stderr); the
  persist block names a missing dump instead of mislabeling it as a
  redaction block.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* v1.82.0.0: impeccable interop, detector pre-pass, open DESIGN.md format

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* docs: update project documentation for v1.82.0.0

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* changelog: name the measure behind the test-count row

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(test): drive the DOM hygiene test through Playwright Chromium directly

Under the six-shard CI free suite the test's private browse daemon never
answered its health probe (two minutes of retries), failed the shard, and
starved two unrelated test files into failing before the runner's timeout.
The test now launches the same Chromium through playwright-core and calls the
dump function with page.evaluate, the way Aside's pg.evaluate does: no state
file, no daemon, no health window. It self-skips when the Playwright Chromium
bundle is absent. Two more hygiene rules are pinned along the way (print
sheets keep their @media, alternate sheets are dropped).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(test): compare gen-skill-docs paths with forward slashes on Windows

gen-skill-docs prints repo-relative paths with the OS separator, so the
checklist render pins (`GENERATED: review/design-checklist.md`) failed on the
Windows lane against `review\design-checklist.md`.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* fix(test): assemble the planted PEM block at runtime

The quality gate scans every added line of the PR diff through gstack-redact;
the redaction test's literal PEM header was a HIGH finding on our own test
file. The block is now built from fragments, so the scanned file never carries
a key-shaped line while the test still plants a HIGH finding.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(design-detect): consent-gated engine install, checksum-pinned and receipted

`gstack-design-detect.ts install` is the one download gstack makes, and only
after a design skill's one-time question got a yes. It fetches the engine
version gstack has tested (0.1.3) for this platform from impeccable's own
GitHub release, verifies it against the checksum pinned in
lib/design-detect-contract.ts (all five platforms, captured from the
release's .sha256 sidecars; linux-x64 equals the fixture engine), writes an
egress receipt before the fetch and refuses to download when the receipt
cannot be written (fail-closed; the sink is registered in the wiring test's
polarity table), caps the download at 32 MB, streams with the cap enforced,
writes the file only after the hash matches, and places it under
~/.impeccable/bin/<version>/ (a trusted IMPECCABLE_HOME is honored; never
inside a project). No skill, no hook, no launcher, no npx. --sha256 accepts a
sidecar checksum for a version gstack has not pinned; --base allows a mirror
(https, or http on loopback for tests). After a successful install the probe
runs and its lines follow, so the skill sees READY at once.

The probe ends with DESIGN_DETECTOR_INSTALL_OFFER (version, platform, bytes,
destination) whenever it found no engine and the user has not answered the
question; once design_detector_install_prompted is true it prints neither the
offer nor the NOT_CACHED hint, which used to repeat on every run. The hint's
npx wording is corrected: `npx impeccable detect --help` caches the engine
for npx only, not where the probe looks.

gstack-config gains design_detector_install_prompted (true|false, typo
rejected, enumerated in list and defaults). Tests: a loopback mirror (async
spawn, so the in-process server can answer) covers install, re-install as a
verified no-op, checksum mismatch, 404, unpinned version, non-https base,
design_detector off, and IMPECCABLE_HOME inside the repo; the offer and the
silenced hint; pin completeness per platform.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* feat(design): ask once before downloading impeccable's engine

When the probe prints DESIGN_DETECTOR_INSTALL_OFFER the design skills ask the
user one AskUserQuestion, in interactive sessions only (spawned or headless
runs never install and never ask; Conductor gets the prose brief), before
any other step: install the engine now, not now, never ask again
(design_detector_install_prompted), or turn the detector off. A yes runs the
receipted, checksum-pinned install and the skill continues with a READY probe.
The brief says what impeccable is, what the one file is, where it goes, how
it is verified and logged, and that no skill or hook comes with it; users who
want the /impeccable skill run npx impeccable install themselves.

design-review carries the brief inline (it is not carved). design-html keeps
its skeleton small: the probe block points at a new read-on-demand section,
sections/detector-install-offer.md, registered in its manifest and carve
guard; its skeleton ceiling is re-measured (55,262) and its eager ceiling
set to the measured 13,767. The review and ship passes state that they never
offer an install. NOTICE.md, README, docs/skills.md, the interop design doc,
and the CHANGELOG describe the new posture: gstack still never runs
impeccable's installer or launcher; the one download is consented, pinned,
and receipted. Ship goldens refreshed for the review-pass wording.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-08 22:40:22 -07:00

1294 lines
78 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Skill Deep Dives
Detailed guides for every gstack skill — philosophy, workflow, and examples.
| Skill | Your specialist | What they do |
|-------|----------------|--------------|
| [`/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. |
| [`/investigate`](#investigate) | **Debugger** | Systematic root-cause debugging. Iron Law: no fixes without investigation. Traces data flow, tests hypotheses, stops after 3 failed fixes. |
| [`/design-review`](#design-review) | **Designer Who Codes** | Live-site visual audit + fix loop. 80-item audit, then fixes what it finds. Atomic commits, before/after screenshots. |
| [`/design-shotgun`](#design-shotgun) | **Design Explorer** | Generate multiple AI design variants, open a comparison board in your browser, and iterate until you approve a direction. Taste memory biases toward your preferences. |
| [`/design-html`](#design-html) | **Design Engineer** | Generates production-quality Pretext-native HTML. Works with approved mockups, CEO plans, design reviews, or from scratch. Text reflows on resize, heights adjust to content. Smart API routing per design type. Framework detection for React/Svelte/Vue. Previews render through your Aside browser. |
| [`/qa`](#qa) | **QA Lead** | Test your app, find bugs, fix them with atomic commits, re-verify. Auto-generates regression tests for every fix. |
| [`/qa-only`](#qa) | **QA Reporter** | Same methodology as /qa but report only. Use when you want a pure bug report without code changes. |
| [`/scrape`](#browse) | **Browser Data Extractor** | Pull structured data off a web page — tables, lists, prices — in your Aside browser with the page's real logged-in state. Same driver contract as `/browse`. On the fallback browser, a codified browser-skill answers a repeat intent in ~200ms. |
| [`/skillify`](#browse) | **Skill Codifier** | Fallback-browser skill: walks back through your conversation, finds the last `/scrape` prototype, synthesizes script + test + fixture, runs the test, asks before committing. On Aside, durable per-site automation belongs to Aside's own skills. |
| [`/ship`](#ship) | **Release Engineer** | Sync main, run tests, audit coverage, push, open PR. Bootstraps test frameworks if you don't have one. One command. |
| [`/land-and-deploy`](#land-and-deploy) | **Release Engineer** | Merge the PR, wait for CI and deploy, verify production health. One command from "approved" to "verified in production." |
| [`/canary`](#canary) | **SRE** | Post-deploy monitoring loop. Watches for console errors, performance regressions, and page failures in your Aside browser. |
| [`/benchmark`](#benchmark) | **Performance Engineer** | Baseline page load times, Core Web Vitals, and resource sizes. Compare before/after on every PR. Track trends over time. |
| [`/cso`](#cso) | **Chief Security Officer** | OWASP Top 10 + STRIDE threat modeling security audit. Scans for injection, auth, crypto, and access control issues. |
| [`/document-release`](#document-release) | **Technical Writer** | Update all project docs to match what you just shipped. Catches stale READMEs automatically. |
| [`/document-generate`](#document-generate) | **Technical Writer** | Generate Diataxis docs (tutorial / how-to / reference / explanation) for a feature from code. |
| [`/retro`](#retro) | **Eng Manager** | Team-aware weekly retro. Per-person breakdowns, shipping streaks, test health trends, growth opportunities. |
| [`/browse`](#browse) | **QA Engineer** | Give the agent eyes. Drives your Aside browser first — real sessions, real clicks, real screenshots — through deterministic `aside repl` scripts, and falls back to gstack's own Chromium (~100ms per command) when Aside isn't there. |
| [`/setup-browser-cookies`](#setup-browser-cookies) | **Session Manager** | Fallback-browser skill: import cookies from your real browser (Chrome, Arc, Brave, Edge) into gstack's headless session to test authenticated pages. Unnecessary on Aside, which already has your sessions. |
| [`/autoplan`](#autoplan) | **Review Pipeline** | One command, fully reviewed plan. Runs CEO → design → DX → eng review automatically (eng always last, so the shipping gate reviews the final amended plan) with encoded decision principles. Surfaces only taste decisions for your approval. |
| [`/plan-devex-review`](#plan-devex-review) | **DX Reviewer** | Plan-stage DX review. TTHW (time-to-hello-world), magical moments, friction points, persona traces. Three modes: Expansion, Polish, Triage. |
| [`/devex-review`](#devex-review) | **DX Reviewer (live)** | Live developer experience audit. Walks the actual onboarding flow, measures TTHW, catches the docs lies. |
| [`/plan-tune`](#plan-tune) | **Question Tuner** | Self-tune AskUserQuestion sensitivity per question. Mark questions as never-ask, always-ask, or only-for-one-way. |
| [`/spec`](#spec) | **Spec Author** | Turn vague intent into a precise, executable spec in five phases. Files a GitHub issue, optionally spawns a Claude Code agent in a fresh worktree, and lets `/ship` close the source issue on merge. |
| [`/learn`](#learn) | **Memory** | Manage what gstack learned across sessions. Review, search, prune, and export project-specific patterns and preferences. |
| [`/context-save`](#context-save) | **Save State** | Save working context (git state, decisions, remaining work) so any future session can resume. |
| [`/context-restore`](#context-restore) | **Restore State** | Resume from a saved context, even across Conductor workspace handoffs. |
| [`/health`](#health) | **Code Quality Dashboard** | Wraps type checker, linter, tests, dead code detection. Computes a weighted 0-10 score; tracks trends over time. |
| [`/landing-report`](#landing-report) | **Ship Queue Dashboard** | Read-only snapshot of the workspace-aware ship queue. Which version slots are claimed, which sibling workspaces have WIP. |
| [`/benchmark-models`](#benchmark-models) | **Model Benchmark** | Side-by-side cross-model benchmark for skills (Claude vs GPT vs Gemini). Latency, tokens, cost, optional LLM-judged quality. |
| | | |
| **Multi-AI** | | |
| [`/codex`](#codex) | **Second Opinion** | Independent review from OpenAI Codex CLI. Three modes: code review (pass/fail gate), adversarial challenge, and open consultation with session continuity. Cross-model analysis when both `/review` and `/codex` have run. |
| [`/pair-agent`](#browse) | **Remote Agent Bridge** | Pair a remote AI agent (OpenClaw, Codex, Cursor, Hermes) with gstack's own browser. Scoped tunnel, locked allowlist, session token. Fallback-browser skill; agents driving Aside open their own tabs. |
| [`/setup-gbrain`](#setup-gbrain) | **Memory Sync** | Set up gbrain for cross-machine session memory sync. One command from zero to live. |
| [`/sync-gbrain`](#sync-gbrain) | **Keep Brain Current** | Refresh gbrain against this repo's code; teach the agent when to use `gbrain search`/`code-def` over Grep. Idempotent; safe to re-run. |
| | | |
| **Safety & Utility** | | |
| [`/careful`](#safety--guardrails) | **Safety Guardrails** | Warns before destructive commands (rm -rf, DROP TABLE, force-push, git reset --hard). Override any MEDIUM warning; root/home recursive deletes and default-branch force-pushes are hard-denied. Common build cleanups whitelisted. |
| [`/freeze`](#safety--guardrails) | **Edit Lock** | Restrict all file edits to a single directory. Blocks Edit and Write outside the boundary. Accident prevention for debugging. |
| [`/guard`](#safety--guardrails) | **Full Safety** | Combines /careful + /freeze in one command. Maximum safety for prod work. |
| [`/unfreeze`](#safety--guardrails) | **Unlock** | Remove the /freeze boundary, allowing edits everywhere again. |
| [`/open-gstack-browser`](#open-gstack-browser) | **GStack Browser** | Launch gstack's own browser headed, with sidebar, anti-bot stealth, auto model routing, cookie import, and Claude Code integration. The visible face of the fallback engine; with Aside open you watch the agent's tabs there. |
| [`/setup-deploy`](#setup-deploy) | **Deploy Configurator** | One-time setup for `/land-and-deploy`. Detects your platform, production URL, and deploy commands. |
| [`/gstack-upgrade`](#gstack-upgrade) | **Self-Updater** | Upgrade gstack to the latest version. Detects global vs vendored install, syncs both, shows what changed. |
| [`/make-pdf`](#make-pdf) | **PDF Generator** | Turn any markdown file into a publication-quality PDF. Proper margins, page numbers, cover pages, clickable TOC. Mermaid/excalidraw fences render as vector diagrams; `--to html\|docx` for other formats. Prints through your Aside browser (macOS 15+), or gstack's bundled browser when Aside is absent. |
| [`/diagram`](#diagram) | **Diagram Maker** | English in, diagram out: mermaid source + editable `.excalidraw` (open it on excalidraw.com, hand-drawn style) + rendered SVG/PNG. Fully offline, rendered through your Aside browser (macOS 15+) or gstack's bundled browser when Aside is absent. |
| [`/ios-qa`](#ios-qa) | **iOS QA Lead** | Live-device iOS QA via USB CoreDevice tunnel + embedded StateServer. Reads Swift source, codegens accessors, drives the real iPhone. Optionally exposes the device over Tailscale for remote agents. |
| [`/ios-fix`](#ios-fix) | **iOS Autonomous Fixer** | Closes the find→fix→verify loop on a real iPhone. Captures a reproducing snapshot, fixes the source, rebuilds, redeploys, verifies. |
| [`/ios-design-review`](#ios-design-review) | **iOS Designer's Eye** | 10-dimension Apple HIG audit on a real iPhone. Rates each screen, says what would make it a 10. |
| [`/ios-clean`](#ios-clean) | **iOS Bridge Cleanup** | Convenience wrapper to strip DebugBridge SPM + `#if DEBUG` wiring. The structural Release-build guard is in Package.swift + CI; this skill is for guided manual removals. |
| [`/ios-sync`](#ios-sync) | **iOS Bridge Resync** | Regenerate accessors and Swift templates against the latest upstream gstack. Run when you add new `@Observable` classes or upgrade gstack. |
---
## `/office-hours`
This is where every project should start.
Before you plan, before you review, before you write code — sit down with a YC-style partner and think about what you're actually building. Not what you think you're building. What you're *actually* building.
### The reframe
Here's what happened on a real project. The user said: "I want to build a daily briefing app for my calendar." Reasonable request. Then it asked about the pain — specific examples, not hypotheticals. They described an assistant missing things, calendar items across multiple Google accounts with stale info, prep docs that were AI slop, events with wrong locations that took forever to track down.
It came back with: *"I'm going to push back on the framing, because I think you've outgrown it. You said 'daily briefing app for multi-Google-Calendar management.' But what you actually described is a personal chief of staff AI."*
Then it extracted five capabilities the user didn't realize they were describing:
1. **Watches your calendar** across all accounts and detects stale info, missing locations, permission gaps
2. **Generates real prep work** — not logistics summaries, but *the intellectual work* of preparing for a board meeting, a podcast, a fundraiser
3. **Manages your CRM** — who are you meeting, what's the relationship, what do they want, what's the history
4. **Prioritizes your time** — flags when prep needs to start early, blocks time proactively, ranks events by importance
5. **Trades money for leverage** — actively looks for ways to delegate or automate
That reframe changed the entire project. They were about to build a calendar app. Now they're building something ten times more valuable — because the skill listened to their pain instead of their feature request.
### Premise challenge
After the reframe, it presents premises for you to validate. Not "does this sound good?" — actual falsifiable claims about the product:
1. The calendar is the anchor data source, but the value is in the intelligence layer on top
2. The assistant doesn't get replaced — they get superpowered
3. The narrowest wedge is a daily briefing that actually works
4. CRM integration is a must-have, not a nice-to-have
You agree, disagree, or adjust. Every premise you accept becomes load-bearing in the design doc.
### Implementation alternatives
Then it generates 2-3 concrete implementation approaches with honest effort estimates:
- **Approach A: Daily Briefing First** — narrowest wedge, ships tomorrow, M effort (human: ~3 weeks / CC: ~2 days)
- **Approach B: CRM-First** — build the relationship graph first, L effort (human: ~6 weeks / CC: ~4 days)
- **Approach C: Full Vision** — everything at once, XL effort (human: ~3 months / CC: ~1.5 weeks)
Recommends A because you learn from real usage. CRM data comes naturally in week two.
### Two modes
**Startup mode** — for founders and intrapreneurs building a business. You get six forcing questions distilled from how YC partners evaluate products: demand reality, status quo, desperate specificity, narrowest wedge, observation & surprise, and future-fit. These questions are uncomfortable on purpose. If you can't name a specific human who needs your product, that's the most important thing to learn before writing any code.
**Builder mode** — for hackathons, side projects, open source, learning, and having fun. You get an enthusiastic collaborator who helps you find the coolest version of your idea. What would make someone say "whoa"? What's the fastest path to something you can share? The questions are generative, not interrogative.
### 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`.
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.
---
## `/plan-ceo-review`
This is my **founder mode**.
This is where I want the model to think with taste, ambition, user empathy, and a long time horizon. I do not want it taking the request literally. I want it asking a more important question first:
**What is this product actually for?**
I think of this as **Brian Chesky mode**.
The point is not to implement the obvious ticket. The point is to rethink the problem from the user's point of view and find the version that feels inevitable, delightful, and maybe even a little magical.
### Example
Say I am building a Craigslist-style listing app and I say:
> "Let sellers upload a photo for their item."
A weak assistant will add a file picker and save an image.
That is not the real product.
In `/plan-ceo-review`, I want the model to ask whether "photo upload" is even the feature. Maybe the real feature is helping someone create a listing that actually sells.
If that is the real job, the whole plan changes.
Now the model should ask:
* Can we identify the product from the photo?
* Can we infer the SKU or model number?
* Can we search the web and draft the title and description automatically?
* Can we pull specs, category, and pricing comps?
* Can we suggest which photo will convert best as the hero image?
* Can we detect when the uploaded photo is ugly, dark, cluttered, or low-trust?
* Can we make the experience feel premium instead of like a dead form from 2007?
That is what `/plan-ceo-review` does for me.
It does not just ask, "how do I add this feature?"
It asks, **"what is the 10-star product hiding inside this request?"**
### Four modes
- **SCOPE EXPANSION** — dream big. The agent proposes the ambitious version. Every expansion is presented as an individual decision you opt into. Recommends enthusiastically.
- **SELECTIVE EXPANSION** — hold your current scope as the baseline, but see what else is possible. The agent surfaces opportunities one by one with neutral recommendations — you cherry-pick the ones worth doing.
- **HOLD SCOPE** — maximum rigor on the existing plan. No expansions surfaced.
- **SCOPE REDUCTION** — find the minimum viable version. Cut everything else.
Visions and decisions are persisted to `~/.gstack/projects/` so they survive beyond the conversation. Exceptional visions can be promoted to `docs/designs/` in your repo for the team.
---
## `/plan-eng-review`
This is my **eng manager mode**.
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.
### Review Readiness Dashboard
Every review (CEO, Eng, Design) logs its result. At the end of each review, you see a dashboard:
```
+====================================================================+
| REVIEW READINESS DASHBOARD |
+====================================================================+
| Review | Runs | Last Run | Status | Required |
|-----------------|------|---------------------|-----------|----------|
| Eng Review | 1 | 2026-03-16 15:00 | CLEAR | YES |
| CEO Review | 1 | 2026-03-16 14:30 | CLEAR | no |
| Design Review | 0 | — | — | no |
+--------------------------------------------------------------------+
| VERDICT: CLEARED — Eng Review passed |
+====================================================================+
```
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.
### 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.
---
## `/plan-design-review`
This is my **senior designer reviewing your plan** — before you write a single line of code.
Most plans describe what the backend does but never specify what the user actually sees. Empty states? Error states? Loading states? Mobile layout? AI slop risk? These decisions get deferred to "figure it out during implementation" — and then an engineer ships "No items found." as the empty state because nobody specified anything better.
`/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.
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).
### Example
```
You: /plan-design-review
Claude: Initial Design Rating: 4/10
"This plan describes a user dashboard but never specifies
what the user sees first. It says 'cards with icons' —
which looks like every SaaS template. It mentions zero
loading states, zero empty states, and no mobile behavior."
Pass 1 (Info Architecture): 3/10
"A 10 would define primary/secondary/tertiary content
hierarchy for every screen."
→ Added information hierarchy section to plan
Pass 2 (Interaction States): 2/10
"The plan has 4 UI features but specifies 0 out of 20
interaction states (4 features × 5 states each)."
→ Added interaction state table to plan
Pass 4 (AI Slop): 4/10
"The plan says 'clean, modern UI with cards and icons'
and 'hero section with gradient'. These are the top 2
AI-generated-looking patterns."
→ Rewrote UI descriptions with specific, intentional alternatives
Overall: 4/10 → 8/10 after fixes
"Plan is design-complete. Run /design-review after
implementation for visual QA."
```
When you re-run it, sections already at 8+ get a quick pass. Sections below 8 get full treatment. For live-site visual audits post-implementation, use `/design-review`.
---
## `/design-consultation`
This is my **design partner mode**.
`/plan-design-review` audits a site that already exists. `/design-consultation` is for when you have nothing yet — no design system, no font choices, no color palette. You are starting from zero and you want a senior designer to sit down with you and build the whole visual identity together.
It is a conversation, not a form. The agent asks about your product, your users, and your audience. It thinks about what your product needs to communicate — trust, speed, craft, warmth, whatever fits — and works backward from that to concrete choices. Then it proposes a complete, coherent design system: aesthetic direction, typography (3+ fonts with specific roles), color palette with hex values, spacing scale, layout approach, and motion strategy. Every recommendation comes with a rationale. Every choice reinforces every other choice.
But coherence is table stakes. Every dev tool dashboard looks the same — clean sans-serif, muted grays, a blue accent. They are all coherent. They are all forgettable. The difference between a product that looks "nice" and one that people actually recognize is the **deliberate creative risks**: the unexpected serif for headings, the bold accent nobody else in your category uses, the tighter spacing that makes your data feel authoritative instead of airy.
That is what `/design-consultation` is really about. It does not just propose a safe system. It proposes safe choices AND risks — and tells you which is which. "Here are the choices that keep you literate in your category. And here is where I think you should break from convention, and why." You pick which risks to take. The agent checks that the whole system still coheres either way.
If you want, the agent will research what's already out there in your space — take screenshots of real sites, analyze their fonts and colors and spacing — so you can see the landscape before you make choices. This is not about copying. It is about getting in the ballpark so you know what the conventions are, and then deciding which ones are worth breaking.
After you agree on the system, it generates an interactive HTML preview page — not just swatches and font samples, but realistic product pages. If you are building a dashboard, you see a dashboard with a sidebar, data tables, and stat cards. If you are building a marketing site, you see a hero section with real copy and a CTA. Everything rendered in your design system, with your product name, in light and dark mode. You see what your product could feel like before a single line of production code is written.
Then it writes `DESIGN.md` to your repo root — your project's design source of truth — and updates `CLAUDE.md` so every future Claude Code session respects the system. From that point on, `/design-review` can audit against it, and any agent working on your frontend knows the rules.
The file is written in the open DESIGN.md format ([google-labs-code/design.md](https://github.com/google-labs-code/design.md)): every token in YAML front matter (`colors`, `typography`, `rounded`, `spacing`, `components`), the rationale in the spec's canonical sections, so impeccable, Google Stitch, and anything else that reads the format share one file. If you already have a legacy gstack `DESIGN.md`, the skill offers a conversion once (a backup is kept) and records your answer in the file so it never asks again. A `PRODUCT.md` in the repo root prefills the product questions instead of re-asking them.
### Example
```
You: /design-consultation
Claude: From the README, this looks like a developer analytics dashboard
for engineering teams. Sound right? Tell me about the feeling
you want — and would you like me to look at what's out there
first so we can see the landscape?
You: Yes, it's for eng managers. Show me what's out there.
Claude: [browses Linear, Vercel, Datadog, Posthog — takes screenshots]
Here's the landscape. They all converge on clean sans-serifs
and muted blue-gray palettes. Linear stands out with dark-first
and tight spacing. The rest feel interchangeable.
Here's my proposal — and where I'd play it safe vs. take risks:
AESTHETIC: Industrial/Utilitarian — data-first, every pixel earns its place
TYPOGRAPHY: Geist (body + UI), Instrument Serif (display), JetBrains Mono (data)
COLOR: Restrained — slate neutrals, single teal accent (#0D9488)
SPACING: 4px base, compact density
LAYOUT: Grid-disciplined, 12-column
MOTION: Minimal-functional — only transitions that aid comprehension
SAFE CHOICES (match category expectations):
Geist for body — your users already know this font from Vercel
Slate neutrals — warm grays feel right for data-heavy UIs
Grid-disciplined layout — dashboards need predictable alignment
RISKS (where you'd stand out):
Instrument Serif for display headings — nobody in dev tools
uses a serif. It creates instant hierarchy contrast and
signals "we care about craft" in a space full of sans-serifs.
Single teal accent instead of blue — everyone else in this space uses blue.
Teal is close enough to feel trustworthy, different enough
to be recognizable.
4px compact density — tighter than Linear, says "we respect
your screen real estate."
The safe choices keep you literate. The risks are where your
product gets its own face. Which risks appeal to you?
You: Love the serif risk. Let's see it.
Claude: Preview opened in your browser.
[/tmp/design-consultation-preview-1710000000.html]
The page shows a realistic dashboard: sidebar nav, header with
avatar, stat cards, data table — all in your design system.
Instrument Serif at hero scale, Geist in body text, JetBrains
Mono in the data table. Teal accent on buttons and active states.
Light and dark mode toggle in the corner.
How does it feel? Want to adjust anything before I write DESIGN.md?
You: Ship it.
Claude: Wrote DESIGN.md (typography, color, spacing, layout, motion).
Updated CLAUDE.md with design system guidelines.
All future sessions will respect these choices.
```
---
## `/design-review`
This is my **designer who codes mode**.
`/plan-design-review` reviews your plan before implementation. `/design-review` audits and fixes the live site after.
It runs an 80-item visual audit on your live site — in your Aside browser, so it sees exactly what a logged-in you sees — then enters a fix loop: for each design finding, it locates the source file, makes the minimal CSS/styling change, commits with `style(design): FINDING-NNN`, re-navigates to verify, and takes before/after screenshots. One commit per fix, fully bisectable.
The self-regulation heuristic is tuned for design work — CSS-only changes get a free pass (they are inherently safe and reversible), but changes to component JSX/TSX files count against the risk budget. Hard cap at 30 fixes. If the risk score exceeds 20%, it stops and asks.
**Design detector.** When you have [impeccable](https://impeccable.style) installed, its engine runs first: on a URL the page's rendered DOM is dumped (linked styles inlined) and scanned; on a feature branch with no URL the changed frontend files are scanned. Every mechanical finding arrives as a `FINDING-NNN` tagged with its rule id (`[nested-cards]`, `[low-contrast]`), and the report closes with `Detector: N → M`. gstack never runs impeccable's installer; when no engine is present it offers, once, to download the engine binary (checksum-pinned, logged in the egress ledger) and remembers the answer; without it the audit is unchanged. `gstack-config set design_detector off` disables the pre-pass.
### Example
```
You: /design-review https://myapp.com
Claude: [Runs full 80-item visual audit on the live site]
Design Score: C | AI Slop Score: D
12 findings (4 high, 5 medium, 3 polish)
Fixing 9 design issues...
style(design): FINDING-001 — replace 3-column icon grid with asymmetric layout
style(design): FINDING-002 — add heading scale 48/32/24/18/16
style(design): FINDING-003 — remove gradient hero, use bold typography
style(design): FINDING-004 — add second font for headings
style(design): FINDING-005 — vary border-radius by element role
style(design): FINDING-006 — left-align body text, reserve center for headings
style(design): FINDING-007 — add hover/focus states to all interactive elements
style(design): FINDING-008 — add prefers-reduced-motion media query
style(design): FINDING-009 — set max content width to 680px for body text
Final audit:
Design Score: C → B+ | AI Slop Score: D → A
9 fixes applied (8 verified, 1 best-effort). 3 deferred.
[Report with before/after screenshots saved to .gstack/design-reports/]
```
Nine commits, each touching one concern. The AI Slop score went from D to A because the three most recognizable patterns (gradient hero, 3-column grid, uniform radius) are gone.
---
## `/design-shotgun`
This is my **design exploration mode**.
You know the feeling. You have a feature, a page, a landing screen... and you're not sure what it should look like. You could describe it to Claude and get one answer. But one answer means one perspective, and design is a taste game. You need to see options.
`/design-shotgun` generates 3 visual design variants using the GPT Image API, opens a comparison board in your browser, and waits for your feedback. You pick a direction, request changes, or ask for entirely new variants. The board supports remix, regenerate, and approval actions.
### The loop
1. You describe what you want (or point at an existing page)
2. The skill reads your `DESIGN.md` for brand constraints (if it exists)
3. It generates 3 distinct design variants as PNGs
4. A comparison board opens in your browser with all 3 side-by-side
5. You click "Approve" on the one you like, or give feedback for another round
6. The approved variant saves to `~/.gstack/projects/$SLUG/designs/` with an `approved.json`
That `approved.json` is one way to feed `/design-html`. The design pipeline chains: shotgun picks the direction, design-html renders it as working code. But `/design-html` also works with CEO plans, design reviews, or just a description.
### Taste memory
The skill remembers your preferences across sessions. If you consistently prefer minimal designs over busy ones, it biases future generations. This isn't a setting you configure... it emerges from your approvals.
### Example
```
You: /design-shotgun — hero section for a developer tools landing page
Claude: [Generates 3 variants]
Variant A: Bold typography, dark background, code snippet hero
Variant B: Split layout, product screenshot left, copy right
Variant C: Minimal, centered headline, gradient accent
[Opens comparison board at localhost:PORT]
You: [Clicks "Approve" on Variant A in the browser]
Claude: Approved Variant A. Saved to ~/.gstack/projects/myapp/designs/
Next: run /design-html to generate production HTML from this mockup.
```
---
## `/design-html`
This is my **design-to-code mode**.
Every AI code generation tool produces static CSS. Hardcoded heights. Text that overflows on resize. Breakpoints that snap instead of flowing. The output looks right at exactly one viewport size and breaks at every other.
`/design-html` fixes this. It generates HTML using [Pretext](https://github.com/chenglou/pretext) by Cheng Lou (ex-React core, Midjourney frontend). Pretext is a 15KB library that computes text layout without DOM measurement. Text reflows. Heights adjust to content. Cards size themselves. Chat bubbles shrinkwrap. All sub-millisecond, all dynamic.
It works with multiple input sources: an approved mockup from `/design-shotgun`, a CEO plan from `/plan-ceo-review`, design review context from `/plan-design-review`, a PNG you provide, or just a description of what you want. It detects what context exists and asks how you want to proceed.
### Smart API routing
Not every page needs the full Pretext engine. The skill reads the design and picks the right tools:
- **Simple layouts** (landing, marketing): `prepare()` + `layout()` for resize-aware heights
- **Card grids** (dashboard, listing): `prepare()` + `layout()` for self-sizing cards
- **Chat UIs**: `walkLineRanges()` for tight-fit bubbles with zero wasted pixels
- **Editorial layouts**: `layoutNextLine()` for text flowing around obstacles
- **Complex editorial**: Full engine with `layoutWithLines()` for manual line rendering
### The refinement loop
1. Reads the approved mockup from `approved.json`
2. Uses GPT-4o vision to extract implementation spec (colors, typography, layout)
3. Generates self-contained HTML with Pretext inlined (15KB, zero network dependency)
4. Spins up a live-reload server so you see changes instantly
5. Screenshots at 3 viewports (mobile, tablet, desktop) to verify layout
6. AskUserQuestion: what needs to change?
7. Surgical edits via the Edit tool (not full regeneration)
8. Repeat until you say "done"
**Slop gate.** If you have [impeccable](https://impeccable.style) installed, the finalized page gets one scan through its engine before the verification screenshots: findings trigger a single surgical fix pass over the non-advisory rules, then one more scan. Whatever remains is presented as accepted-with-reason (the approved mockup contains it, `DESIGN.md` blesses it, or you agreed to an inline `impeccable-disable` comment). One pass, never a loop; without impeccable the step is skipped silently. The skill's never-include list carries the same rule ids the detector reports, from `lib/design-catalog.ts`.
### Framework detection
If your project uses React, Svelte, or Vue (detected from `package.json`), the skill offers to generate a framework component instead of vanilla HTML. Framework output uses `npm install @chenglou/pretext` instead of inline vendoring.
### Example
```
You: /design-html
Claude: Found approved mockup: variant-A.png (hero section)
Design type: simple layout → using prepare() + layout()
[Generates HTML with Pretext, opens live-reload server]
[Screenshots at 375px, 768px, 1440px — all verified]
The HTML is live at localhost:3456. Resize your browser.
Text reflows dynamically. What needs to change?
You: Make the headline bigger and add more spacing below the CTA
Claude: [Edits font-size and margin, browser auto-reloads]
Updated. Two changes applied.
You: Done
Claude: Saved to ~/.gstack/projects/myapp/designs/hero-20260330/finalized.html
```
---
## `/review`
This is my **paranoid staff engineer mode**.
Passing tests do not mean the branch is safe.
`/review` exists because there is a whole class of bugs that can survive CI and still punch you in the face in production. This mode is not about dreaming bigger. It is not about making the plan prettier. It is about asking:
**What can still break?**
This is a structural audit, not a style nitpick pass. I want the model to look for things like:
* N+1 queries
* stale reads
* race conditions
* bad trust boundaries
* missing indexes
* escaping bugs
* broken invariants
* bad retry logic
* tests that pass while missing the real failure mode
* forgotten enum handlers — add a new status or type constant, and `/review` traces it through every switch statement and allowlist in your codebase, not just the files you changed
### Fix-First
Findings get action, not just listed. Obvious mechanical fixes (dead code, stale comments, N+1 queries) are applied automatically — you see `[AUTO-FIXED] file:line Problem → what was done` for each one. Genuinely ambiguous issues (security, race conditions, design decisions) get surfaced for your call.
### Completeness gaps
`/review` now flags shortcut implementations where the complete version costs less than 30 minutes of CC time. If you chose the 80% solution and the 100% solution is a lake, not an ocean, the review will call it out.
One exception: a shortcut you took deliberately and logged. A `gstack-shortcut(dec-<id>)` marker whose decision id resolves in the decision ledger downgrades the finding to acknowledged debt. An orphan marker — one with no ledger entry behind it — doesn't suppress anything; the gap is reported normally and the marker itself gets flagged.
**Design pass.** When the diff touches frontend files, the Design specialist reads `review/design-checklist.md`, which is generated from `lib/design-catalog.ts`, so `/review`, `/ship`, and `/design-review` flag the same patterns under the same rule ids. If you have [impeccable](https://impeccable.style) installed, its engine scans the changed frontend files first: its rows bucket by tier (auto-fix, ask, possible), a detector hit and a checklist hit at the same file:line collapse into one row, and your repo's `.impeccable/config*.json` ignores are read as settled decisions. Without it, the checklist pass runs alone.
### Example
Suppose the smart listing flow is implemented and the tests are green.
`/review` should still ask:
* Did I introduce an N+1 query when rendering listing photos or draft suggestions?
* Am I trusting client-provided file metadata instead of validating the actual file?
* Can two tabs race and overwrite cover-photo selection or item details?
* Do failed uploads leave orphaned files in storage forever?
* Can the "exactly one hero image" rule break under concurrency?
* If enrichment APIs partially fail, do I degrade gracefully or save garbage?
* Did I accidentally create a prompt injection or trust-boundary problem by pulling web data into draft generation?
That is the point of `/review`.
I do not want flattery here.
I want the model imagining the production incident before it happens.
---
## `/investigate`
When something is broken and you don't know why, `/investigate` is your systematic debugger. It follows the Iron Law: **no fixes without root cause investigation first.**
Instead of guessing and patching, it traces data flow, matches against known bug patterns, and tests hypotheses one at a time. If three fix attempts fail, it stops and questions the architecture instead of thrashing. This prevents the "let me try one more thing" spiral that wastes hours.
---
## `/qa`
This is my **QA lead mode**.
`/browse` gives the agent eyes. `/qa` gives it a testing methodology.
The most common use case: you're on a feature branch, you just finished coding, and you want to verify everything works. Just say `/qa` — it reads your git diff, identifies which pages and routes your changes affect, opens them in tabs of your Aside browser, and tests each one. No URL required. No manual test plan.
Four modes:
- **Diff-aware** (automatic on feature branches) — reads `git diff main`, identifies affected pages, tests them specifically
- **Full** — systematic exploration of the entire app. 5-15 minutes. Documents 5-10 well-evidenced issues.
- **Quick** (`--quick`) — 30-second smoke test. Homepage + top 5 nav targets.
- **Regression** (`--regression baseline.json`) — run full mode, then diff against a previous baseline.
### Automatic regression tests
When `/qa` fixes a bug and verifies it, it automatically generates a regression test that catches the exact scenario that broke. Tests include full attribution tracing back to the QA report.
### Example
```
You: /qa https://staging.myapp.com
Claude: [Explores 12 pages, fills 3 forms, tests 2 flows]
QA Report: staging.myapp.com — Health Score: 72/100
Top 3 Issues:
1. CRITICAL: Checkout form submits with empty required fields
2. HIGH: Mobile nav menu doesn't close after selecting an item
3. MEDIUM: Dashboard chart overlaps sidebar below 1024px
[Full report with screenshots saved to .gstack/qa-reports/]
```
**Testing authenticated pages:** with Aside, nothing to set up. Aside is your browser, so `/qa` already has your sessions; if it hits a sign-in wall, sign in inside Aside and tell it you're done — it re-runs the step. It never types a password for you. On the fallback browser, run `/setup-browser-cookies` first to import your real sessions, or log in once in headed mode.
---
## `/ship`
This is my **release machine mode**.
Once I have decided what to build, nailed the technical plan, and run a serious review, I do not want more talking. I want execution.
`/ship` is for the final mile. It is for a ready branch, not for deciding what to build.
This is where the model should stop behaving like a brainstorm partner and start behaving like a disciplined release engineer: sync with main, run the right tests, make sure the branch state is sane, update changelog or versioning if the repo expects it, push, and create or update the PR.
### Test bootstrap
If your project doesn't have a test framework, `/ship` sets one up — detects your runtime, researches the best framework, installs it, writes 3-5 real tests for your actual code, sets up CI/CD (GitHub Actions), and creates TESTING.md. 100% test coverage is the goal — tests make vibe coding safe instead of yolo coding.
### Coverage audit
Every `/ship` run builds a code path map from your diff, searches for corresponding tests, and produces an ASCII coverage diagram with quality stars. Gaps get tests auto-generated. Your PR body shows the coverage: `Tests: 42 → 47 (+5 new)`.
### Review gate
`/ship` checks the [Review Readiness Dashboard](#review-readiness-dashboard) before creating the PR. If the Eng Review is missing, it asks — but won't block you. Decisions are saved per-branch so you're never re-asked.
A lot of branches die when the interesting work is done and only the boring release work is left. Humans procrastinate that part. AI should not.
### Third-party web actions (v1.72.0.0+)
Sometimes the release work leaves the terminal: registering an API key, creating a vendor account, wiring a webhook or OAuth app. Instead of handing you a manual step list, `/ship` (and `/spec`, `/office-hours`, `/land-and-deploy`, `/setup-deploy`) offers to drive the browser for you. Aside first — it acts across your real logged-in sessions, which is exactly what vendor dashboards need. No Aside? gstack's own visible browser (headed `$B` with handoff for sign-in) is the fallback on every platform, with one pointer to aside.com (macOS 15+) per task.
The consent rules are strict and pin-tested: one explicit question per task naming the exact site and actions, no standing permission, no auto-install ever (on a Mac without Aside you get one download pointer — aside.com, macOS 15+ — once per task). Passwords, payment, CAPTCHAs, and identity verification stay yours; Apple credential creation is never a drive target in any skill. A captured secret never appears in chat — it lands in an owner-only file and gets verified with one read-only API call before gstack claims success.
---
## `/land-and-deploy`
This is my **deploy pipeline mode**.
`/ship` creates the PR. `/land-and-deploy` finishes the job: merge, deploy, verify.
It merges the PR, waits for CI, waits for the deploy to finish, then runs canary checks against production. One command from "approved" to "verified in production." If the deploy breaks, it tells you what failed and whether to rollback.
First run on a new project triggers a dry-run walk-through so you can verify the pipeline before it does anything irreversible. After that, it trusts the config and runs straight through.
### Setup
Run `/setup-deploy` first. It detects your platform (Fly.io, Render, Vercel, Netlify, Heroku, GitHub Actions, or custom), discovers your production URL and health check endpoints, and writes the config to CLAUDE.md. One-time, 60 seconds.
### Example
```
You: /land-and-deploy
Claude: Merging PR #42...
CI: 3/3 checks passed
Deploy: Fly.io — deploying v2.1.0...
Health check: https://myapp.fly.dev/health → 200 OK
Canary: 5 pages checked, 0 console errors, p95 < 800ms
Production verified. v2.1.0 is live.
```
---
## `/canary`
This is my **post-deploy monitoring mode**.
After deploy, `/canary` watches the live site for trouble. It loops through your key pages in your Aside browser (one `aside repl` script per page, so every cycle is a fresh load), checking for console errors, performance regressions, page failures, and visual anomalies. Takes periodic screenshots and compares against pre-deploy baselines.
Use it right after `/land-and-deploy`, or schedule it to run periodically after a risky deploy.
```
You: /canary https://myapp.com
Claude: Monitoring 8 pages every 2 minutes...
Cycle 1: ✓ All pages healthy. p95: 340ms. 0 console errors.
Cycle 2: ✓ All pages healthy. p95: 380ms. 0 console errors.
Cycle 3: ⚠ /dashboard — new console error: "TypeError: Cannot read
property 'map' of undefined" at dashboard.js:142
Screenshot saved.
Alert: 1 new console error after 3 monitoring cycles.
```
---
## `/benchmark`
This is my **performance engineer mode**.
`/benchmark` establishes performance baselines for your pages: load time, Core Web Vitals (LCP, CLS, INP), resource counts, and total transfer size. Run it before and after a PR to catch regressions.
It measures in your Aside browser — the page's own `performance` navigation and resource entries from a real load, not synthetic estimates. Multiple runs averaged. Results persist so you can track trends across PRs.
```
You: /benchmark https://myapp.com
Claude: Benchmarking 5 pages (3 runs each)...
/ load: 1.2s LCP: 0.9s CLS: 0.01 resources: 24 (890KB)
/dashboard load: 2.1s LCP: 1.8s CLS: 0.03 resources: 31 (1.4MB)
/settings load: 0.8s LCP: 0.6s CLS: 0.00 resources: 18 (420KB)
Baseline saved. Run again after changes to compare.
```
---
## `/cso`
This is my **Chief Security Officer**.
Run `/cso` on any codebase and it performs an OWASP Top 10 + STRIDE threat model audit. It scans for injection vulnerabilities, broken authentication, sensitive data exposure, XML external entities, broken access control, security misconfiguration, XSS, insecure deserialization, known-vulnerable components, and insufficient logging. Each finding includes severity, evidence, and a recommended fix.
```
You: /cso
Claude: Running OWASP Top 10 + STRIDE security audit...
CRITICAL: SQL injection in user search (app/models/user.rb:47)
HIGH: Session tokens stored in localStorage (app/frontend/auth.ts:12)
MEDIUM: Missing rate limiting on /api/login endpoint
LOW: X-Frame-Options header not set
4 findings across 12 files scanned. 1 critical, 1 high.
```
---
## `/document-release`
This is my **technical writer mode**.
After `/ship` creates the PR but before it merges, `/document-release` reads every documentation file in the project and cross-references it against the diff. It updates file paths, command lists, project structure trees, and anything else that drifted. Risky or subjective changes get surfaced as questions — everything else is handled automatically.
```
You: /document-release
Claude: Analyzing 21 files changed across 3 commits. Found 8 documentation files.
README.md: updated skill count from 9 to 10, added new skill to table
CLAUDE.md: added new directory to project structure
CONTRIBUTING.md: current — no changes needed
TODOS.md: marked 2 items complete, added 1 new item
All docs updated and committed. PR body updated with doc diff.
```
It also polishes CHANGELOG voice (without ever overwriting entries), cleans up completed TODOS, checks cross-doc consistency, and asks about VERSION bumps only when appropriate.
---
## `/retro`
This is my **engineering manager mode**.
At the end of the week I want to know what actually happened. Not vibes — data. `/retro` analyzes commit history, work patterns, and shipping velocity and writes a candid retrospective.
It is team-aware. It identifies who is running the command, gives you the deepest treatment on your own work, then breaks down every contributor with specific praise and growth opportunities. It computes metrics like commits, LOC, test ratio, PR sizes, and fix ratio. It detects coding sessions from commit timestamps, finds hotspot files, tracks shipping streaks, and identifies the biggest ship of the week.
It also tracks test health: total test files, tests added this period, regression test commits, and trend deltas. If test ratio drops below 20%, it flags it as a growth area.
### Example
```
You: /retro
Claude: Week of Mar 1: 47 commits (3 contributors), 3.2k LOC, 38% tests, 12 PRs, peak: 10pm | Streak: 47d
## Your Week
32 commits, +2.4k LOC, 41% tests. Peak hours: 9-11pm.
Biggest ship: one browser contract for every browser skill (Aside).
What you did well: shipped a complete feature with encryption, UI, and
18 unit tests in one focused push...
## Team Breakdown
### Alice
12 commits focused on app/services/. Every PR under 200 LOC — disciplined.
Opportunity: test ratio at 12% — worth investing before payment gets more complex.
### Bob
3 commits — fixed the N+1 query on dashboard. Small but high-impact.
Opportunity: only 1 active day this week — check if blocked on anything.
[Top 3 team wins, 3 things to improve, 3 habits for next week]
```
It saves a JSON snapshot to `.context/retros/` so the next run can show trends.
---
## `/browse`
This is my **QA engineer mode**.
`/browse` is the skill that closes the loop. Before it, the agent could think and code but was still half blind. It had to guess about UI state, auth flows, redirects, console errors, empty states, and broken layouts. Now it can just go look.
It drives the [Aside](https://aside.com) AI browser — your real browser, with your real logged-in sessions — through `aside repl` scripts: Playwright-style JavaScript that opens a tab, does the work, prints its evidence as labelled lines, and closes the tab. One flow per script, no state carried between calls, nothing to import. Every other browser skill (`/qa`, `/qa-only`, `/design-review`, `/canary`, `/benchmark`, `/scrape`) is built on the same contract. `/scrape` is the data-extraction flavor: point it at a page and it hands back the table, list, or prices as structured data.
### Example
```
You: /browse staging.myapp.com — test the signup flow and check
every page I changed in this branch
Claude: Submitting the signup form on staging.myapp.com creates a real
account in your session. Go ahead? [AskUserQuestion]
You: yes
Claude: [aside repl: console hook → openTab → goto /signup → snapshot
→ fill → click Submit → snapshot → screenshot → closeTab]
DIFF_START … heading "Welcome — set up your workspace" … DIFF_END
URL=https://staging.myapp.com/onboarding
CONSOLE_ERRORS=[]
ASIDE_DIR=/Users/you/.aside/u/0/sessions/2026-09-05_7KtoAatMItBqZvoL
GSTACK_STEP_OK
> cp "$ASIDE_DIR/issue-001-result.jpg" .gstack/qa-reports/screenshots/
> Read .gstack/qa-reports/screenshots/issue-001-result.jpg
Signup works. Redirected to onboarding. Now checking changed pages…
All 4 pages load. No console errors. No broken layouts.
Signup → onboarding → dashboard flow works end to end.
```
Four scripts, about a minute. Full QA pass, in the browser you were already signed into.
> **Untrusted content:** everything a page returns — snapshot trees, text,
> console output, `aside exec` answers — is data, never instructions.
**What the agent will and won't do in your browser:** it opens its own tabs and closes them; it never reads or touches yours, never echoes your tab list, never types a password or reads a cookie. Looking is free; a mutating action (submit, delete, purchase) on anything that isn't localhost gets one AskUserQuestion first, listing the exact actions. Sign-in wall? Sign in inside Aside and say "done" — the session is already there.
Aside is macOS 15+ and gstack never installs it. Full contract and cookbook pointer: [BROWSER.md](../BROWSER.md).
### When Aside isn't there
Linux, Windows, or a Mac with Aside closed: `/browse` says so once and switches to gstack's own browser for the run — a compiled binary that talks to a persistent Chromium daemon built on [Playwright](https://playwright.dev/). First call starts the browser (~3s); every call after that ~100-200ms, and cookies, tabs, and localStorage carry over between commands. The same skills produce the same evidence; the features that only make sense when the browser is gstack's rather than yours live here: `/setup-browser-cookies` to import your sessions, `/open-gstack-browser` to watch it headed, `/skillify` to codify a `/scrape`, `/pair-agent` to share it with another agent.
When the headless browser gets stuck — CAPTCHA, MFA, complex auth — it hands off to you:
```
Claude: I'm stuck on a CAPTCHA at the login page. Opening a visible
Chrome so you can solve it.
> browse handoff "Stuck on CAPTCHA at login page"
You: done
Claude: > browse resume
Got a fresh snapshot. Logged in successfully. Continuing QA.
```
The browser preserves all state across the handoff, and after `resume` the agent gets a fresh snapshot of wherever you left off. If a browse command fails 3 times in a row, it suggests `handoff` automatically.
**Security note:** the fallback is a persistent Chromium session — cookies, localStorage, and session state carry over between commands. Do not use it against sensitive production environments unless you intend to. The session auto-shuts down after 30 minutes of idle time. Full `$B` command reference: [BROWSER.md](../BROWSER.md#the-fallback-engine--complete-reference).
---
## `/setup-browser-cookies`
This is my **session manager mode** — for the fallback browser. With Aside open, `/qa` and `/browse` already run in your real sessions and this skill has nothing to do.
Before `/qa` or `/browse` can test authenticated pages on gstack's own browser, they need cookies. Instead of manually logging in through the headless browser every time, `/setup-browser-cookies` imports your real sessions directly from your daily browser.
It auto-detects installed Chromium browsers (Comet, Chrome, Arc, Brave, Edge), decrypts cookies via the macOS Keychain, and loads them into the Playwright session. An interactive picker UI lets you choose exactly which domains to import — no cookie values are ever displayed.
```
You: /setup-browser-cookies
Claude: Cookie picker opened — select the domains you want to import
in your browser, then tell me when you're done.
[You pick github.com, myapp.com in the browser UI]
You: done
Claude: Imported 2 domains (47 cookies). Session is ready.
```
Or skip the UI entirely:
```
You: /setup-browser-cookies github.com
Claude: Imported 12 cookies for github.com from Comet.
```
---
## `/make-pdf`
Turn any markdown file into a publication-quality PDF: proper margins, page numbers, cover page, clickable TOC, mermaid and excalidraw fences rendered as vector diagrams, `--to html|docx` when you need another format. The compiled `pdf` binary does the typesetting; the printing happens in a browser — your Aside browser first. make-pdf serves the finished HTML from your machine on loopback, opens it in a tab Aside closes when it is done, prints through the browser's own PDF engine (tagged PDF, document outline, header and footer templates all intact), and copies the file out. Nothing leaves the box. When Aside is absent (Linux, Windows, or the app closed) the same pipeline prints through gstack's bundled browser instead, so a PDF comes out on every platform. Full guide to fences and formats: [howto-diagrams-and-formats.md](howto-diagrams-and-formats.md).
---
## `/diagram`
English in, diagram out. Describe the diagram (or paste mermaid source) and you get a triplet: the mermaid source, an editable `.excalidraw` file you can open on excalidraw.com in hand-drawn style, and rendered SVG + PNG. The mermaid and excalidraw runtimes are vendored in `lib/diagram-render/` and rendered by `bin/gstack-render.ts`, the same one-script render make-pdf uses — through your Aside browser when it is open, through gstack's bundled browser otherwise — so it is fully offline on every platform.
---
## `/autoplan`
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.
`/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.
One command, fully reviewed plan out.
```
You: /autoplan
Claude: Running CEO review... [4 scope decisions auto-resolved]
Running design review... [3 design dimensions auto-scored]
Running eng review... [2 architecture decisions auto-resolved]
TASTE DECISIONS (need your input):
1. Scope: Codex suggested adding search — borderline expansion. Add?
2. Design: Two approaches scored within 1 point. Which feels right?
[Shows both options with context]
You: 1) Yes, add search. 2) Option A.
Claude: Plan complete. 9 decisions auto-resolved, 2 taste decisions approved.
```
---
## `/learn`
This is my **institutional memory mode**.
gstack learns from every session. Patterns, pitfalls, preferences, architectural decisions... they accumulate in `~/.gstack/projects/$SLUG/learnings.jsonl`. Each learning has a confidence score, source attribution, and the files it references.
`/learn` lets you see what gstack has absorbed, search for specific patterns, prune stale entries (when referenced files no longer exist), and export learnings for team sharing. The real magic is in other skills... they automatically search learnings before making recommendations, and display "Prior learning applied" when a past insight is relevant.
```
You: /learn
Claude: 23 learnings for this project (14 high confidence, 6 medium, 3 low)
Top patterns:
- [9/10] API responses always wrapped in { data, error } envelope
- [8/10] Tests use factory helpers in test/support/factories.ts
- [8/10] All DB queries go through repository pattern, never direct
3 potentially stale (referenced files deleted):
- "auth middleware uses JWT" — auth/middleware.ts was deleted
[Prune these? Y/N]
```
---
## `/open-gstack-browser`
This is my **co-presence mode** — for the fallback browser. With Aside open, you already watch the agent's tabs in Aside; this skill is how you watch it when the browser is gstack's own.
Without Aside, `/browse` runs headless by default. You don't see what the agent sees. `/open-gstack-browser` changes that. It launches GStack Browser (rebranded Chromium with anti-bot stealth) controlled by Playwright, with the sidebar extension auto-loaded. You watch every action in real time.
The sidebar chat is a Claude instance that controls the browser. It auto-routes to the right model: Sonnet for navigation and actions (click, goto, fill, screenshot), Opus for reading and analysis (summarize, find bugs, describe). One-click cookie import from the sidebar footer. The browser stays alive as long as the window is open... no idle timeout in headed mode. The menu bar says "GStack Browser" instead of "Chrome for Testing."
The sidebar agent ships a layered prompt injection defense: a local 22MB ML classifier scans every page and tool output, a Haiku transcript check votes on the full conversation, a canary token catches session-exfil attempts, and a verdict combiner requires two classifiers to agree before blocking. A shield icon in the header shows status (green/amber/red). Details in [ARCHITECTURE.md](../ARCHITECTURE.md#prompt-injection-defense-sidebar-agent).
```
You: /open-gstack-browser
Claude: Launched GStack Browser with sidebar extension.
Anti-bot stealth active. All $B commands run in headed mode.
Type in the sidebar to direct the browser agent.
Sidebar model routing: sonnet for actions, opus for analysis.
```
---
## `/setup-deploy`
One-time deploy configuration. Run this before your first `/land-and-deploy`.
It auto-detects your deploy platform (Fly.io, Render, Vercel, Netlify, Heroku, GitHub Actions, or custom), discovers your production URL, health check endpoints, and deploy status commands. Writes everything to CLAUDE.md so all future deploys are automatic.
```
You: /setup-deploy
Claude: Detected: Fly.io (fly.toml found)
Production URL: https://myapp.fly.dev
Health check: /health → expects 200
Deploy command: fly deploy
Status command: fly status
Written to CLAUDE.md. Run /land-and-deploy when ready.
```
---
## `/codex`
This is my **second opinion mode**.
When `/review` catches bugs from Claude's perspective, `/codex` brings a completely different AI — OpenAI's Codex CLI — to review the same diff. Different training, different blind spots, different strengths. The overlap tells you what's definitely real. The unique findings from each are where you find the bugs neither would catch alone.
### Three modes
**Review** — run `codex review` against the current diff. Codex reads every changed file, classifies findings by severity (P1 critical, P2 high, P3 medium), and returns a PASS/FAIL verdict. Any P1 finding = FAIL. The review is fully independent — Codex doesn't see Claude's review.
**Challenge** — adversarial mode. Codex actively tries to break your code. It looks for edge cases, race conditions, security holes, and assumptions that would fail under load. Uses maximum reasoning effort (`xhigh`). Think of it as a penetration test for your logic.
**Consult** — open conversation with session continuity. Ask Codex anything about the codebase. Follow-up questions reuse the same session, so context carries over. Great for "am I thinking about this correctly?" moments.
### Cross-model analysis
When both `/review` (Claude) and `/codex` (OpenAI) have reviewed the same branch, you get a cross-model comparison: which findings overlap (high confidence), which are unique to Codex (different perspective), and which are unique to Claude. This is the "two doctors, same patient" approach to code review.
```
You: /codex review
Claude: Running independent Codex review...
CODEX REVIEW: PASS (3 findings)
[P2] Race condition in payment handler — concurrent charges
can double-debit without advisory lock
[P3] Missing null check on user.email before downcase
[P3] Token comparison not using constant-time compare
Cross-model analysis (vs /review):
OVERLAP: Race condition in payment handler (both caught it)
UNIQUE TO CODEX: Token comparison timing attack
UNIQUE TO CLAUDE: N+1 query in listing photos
```
---
## Safety & Guardrails
Four skills that add safety rails to any Claude Code session. They work via Claude Code's PreToolUse hooks — transparent, session-scoped, no configuration required.
### `/careful`
Say "be careful" or run `/careful` when you're working near production, running destructive commands, or just want a safety net. Every Bash command gets checked against known-dangerous patterns:
- `rm -rf` / `rm -r` — recursive delete
- `DROP TABLE` / `DROP DATABASE` / `TRUNCATE` — data loss
- `git push --force` / `git push -f` — history rewrite
- `git reset --hard` — discard commits
- `git checkout .` / `git restore .` — discard uncommitted work
- `kubectl delete` — production resource deletion
- `docker rm -f` / `docker system prune` — container/image loss
Common build artifact cleanups (`rm -rf node_modules`, `dist`, `.next`, `__pycache__`, `build`, `coverage`) are whitelisted — no false alarms on routine operations.
You can override any MEDIUM warning. Two catastrophic shapes are hard-denied instead of asked: recursive deletes of the filesystem root or your home directory (including the `/*`, `~/`, and `$HOME/` forms), and force-pushes to the repo's default branch (`--force-with-lease` never triggers the deny; the escape hatch is ending the session-scoped `/careful` session). You can also add your own warn rules — one POSIX ERE per line — in `~/.gstack/careful-patterns.txt` (global) or `~/.gstack/projects/<slug>/careful-patterns.txt` (per-project); custom patterns only ever add warnings, never suppress the built-ins. The guardrails are accident prevention, not access control.
### `/freeze`
Restrict all file edits to a single directory. When you're debugging a billing bug, you don't want Claude accidentally "fixing" unrelated code in `src/auth/`. `/freeze src/billing` blocks all Edit and Write operations outside that path.
`/investigate` activates this automatically — it detects the module being debugged and freezes edits to that directory.
```
You: /freeze src/billing
Claude: Edits restricted to src/billing/. Run /unfreeze to remove.
[Later, Claude tries to edit src/auth/middleware.ts]
Claude: BLOCKED — Edit outside freeze boundary (src/billing/).
Skipping this change.
```
Note: this blocks Edit and Write tools only. Bash commands like `sed` can still modify files outside the boundary — it's accident prevention, not a security sandbox.
### `/guard`
Full safety mode — combines `/careful` + `/freeze` in one command. Destructive command warnings plus directory-scoped edits. Use when touching prod or debugging live systems.
### `/unfreeze`
Remove the `/freeze` boundary, allowing edits everywhere again. The hooks stay registered for the session — they just allow everything. Run `/freeze` again to set a new boundary.
---
## `/gstack-upgrade`
Keep gstack current with one command. It detects your install type (global at `~/.claude/skills/gstack` vs vendored in your project at `.claude/skills/gstack`), runs the upgrade, syncs both copies if you have dual installs, and shows you what changed.
```
You: /gstack-upgrade
Claude: Current version: 0.7.4
Latest version: 0.8.2
What's new:
- Browser skills now drive your Aside browser
- /codex multi-AI second opinion
- /qa always uses browser now
- Safety skills: /careful, /freeze, /guard
- Proactive skill suggestions
Upgraded to 0.8.2. Both global and project installs synced.
```
Set `auto_upgrade: true` in `~/.gstack/config.yaml` to skip the prompt entirely — gstack upgrades silently at the start of each session when a new version is available.
---
## Greptile integration
[Greptile](https://greptile.com) is a YC company that reviews your PRs automatically. It catches real bugs — race conditions, security issues, things that pass CI and blow up in production. It has genuinely saved my ass more than once. I love these guys.
### Setup
Install Greptile on your GitHub repo at [greptile.com](https://greptile.com) — it takes about 30 seconds. Once it's reviewing your PRs, gstack picks up its comments automatically. No additional configuration.
### How it works
The problem with any automated reviewer is triage. Greptile is good, but not every comment is a real issue. Some are false positives. Some flag things you already fixed three commits ago. Without a triage layer, the comments pile up and you start ignoring them — which defeats the purpose.
gstack solves this. `/review` and `/ship` are now Greptile-aware. They read Greptile's comments, classify each one, and take action:
- **Valid issues** get added to the critical findings and fixed before shipping
- **Already-fixed issues** get an auto-reply acknowledging the catch
- **False positives** get pushed back — you confirm, and a reply goes out explaining why it's wrong
The result is a two-layer review: Greptile catches things asynchronously on the PR, then `/review` and `/ship` triage those findings as part of the normal workflow. Nothing falls through the cracks.
### Learning from history
Every false positive you confirm gets saved to `~/.gstack/greptile-history.md`. Future runs auto-skip known FP patterns for your codebase. And `/retro` tracks Greptile's batting average over time — so you can see whether the signal-to-noise ratio is improving.
### Example
```
You: /ship
Claude: [syncs main, runs tests, pre-landing review...]
Greptile found 3 comments on this PR:
[VALID] app/services/payment_service.rb:47 — Race condition:
concurrent charges can double-debit. Recommend DB-level advisory
lock around the charge block.
[ALREADY FIXED] app/models/user.rb:12 — Missing null check
on email before downcase.
→ Already fixed in commit abc1234. Auto-replying.
[FALSE POSITIVE] lib/auth.rb:88 — "Token comparison should
use constant-time comparison." We already use
ActiveSupport::SecurityUtils.secure_compare here.
Fixing the race condition in payment_service.rb...
The auth token comment is a false positive.
Options: A) Reply to Greptile explaining B) Fix anyway C) Ignore
You: A
Claude: Replied to Greptile. All tests pass.
PR: github.com/you/app/pull/42
```
Three Greptile comments. One real fix. One auto-acknowledged. One false positive pushed back with a reply. Total extra time: about 30 seconds.
---
## `/ios-qa`
Live-device iOS QA. The fork's load-bearing insight was: don't simulate, don't run XCTest, don't bring up WebDriverAgent. Embed an HTTP server in the app under test, drive it from a Mac-side daemon over the USB CoreDevice IPv6 tunnel.
The agent reads your Swift source, finds `@Observable` classes with `@Snapshotable`-marked fields, codegens typed accessors, deploys a debug bridge, then runs a closed find→fix→verify loop.
### Architecture in one diagram
```
┌──────────────────────┐ USB CoreDevice (IPv6) ┌──────────────────┐
│ gstack-ios-qa daemon │ ────────────────────────▶ │ iOS app │
│ (Mac, bun/TS) │ bearer + X-Session-Id │ StateServer │
│ - rotates boot token │ │ (loopback only) │
│ - mints session toks │ └──────────────────┘
│ - capability tiers │
│ - audit + redact │
└──────────────────────┘
▲
│ Tailscale (optional, --tailnet)
│
┌──────────────────────┐
│ Remote agent │
│ (OpenClaw, etc.) │
└──────────────────────┘
```
The iOS app's `StateServer` binds loopback only (`::1` + `127.0.0.1`). The Mac daemon owns tailnet identity validation, capability tiers, and the audit trail. Remote agents NEVER see the boot token — only short-lived session tokens (1h default, 24h hard cap) minted via Tailscale identity gating.
### The unlock: USB-tethered + Tailscale = remote iOS QA from any agent
A Mac plus an iPhone you already own plus the Tailscale free tier replaces what most teams pay BrowserStack/Sauce Labs for. Any HTTP-capable agent on your tailnet can drive the iOS app once you've minted them a session token. Tailscale ACLs scope which identities can reach the Mac at which capability tier.
See `ios-qa/docs/tailscale-acl-example.md` for the runnable setup.
### Capability tiers
| Tier | Endpoints |
|------|-----------|
| observe | `/screenshot`, `/elements`, `GET /state/*`, `/state/snapshot`, `/healthz` |
| interact | observe + `/tap`, `/swipe`, `/type`, `/session/*` |
| mutate | interact + `POST /state/<key>` |
| restore | mutate + `POST /state/restore` |
Default minted tokens get `interact`. Higher tiers require explicit owner mint.
---
## `/ios-fix`
Iron Law: no fix without a reproducing snapshot. The agent captures pre-bug state via `GET /state/snapshot`, writes the fix, rebuilds, redeploys, restores the snapshot, and verifies the bug is gone. The snapshot becomes a regression test fixture so the bug can't recur silently.
Mirrors `/qa`'s find-bug → fix → re-verify loop for iOS.
---
## `/ios-design-review`
Designer's-eye QA on a real iPhone. Connects to the same `/ios-qa` daemon in observe-tier mode and screenshots every screen. Scores 10 dimensions 0-10: typography hierarchy, spacing rhythm, color hierarchy, touch targets, loading/empty/error states, accessibility, animation discipline, iOS idiom alignment, information density, AI-slop check.
For each score < 7, uses AskUserQuestion to present the issue with recommended fix.
---
## `/ios-clean`
Convenience wrapper. The structural Release-build guard against shipping DebugBridge is in `Package.swift` (`.when(configuration: .debug)`) plus a CI invariant test. `/ios-clean` is for developers who want a guided removal flow or who manually added the SPM dependency without going through `/ios-qa`.
---
## `/ios-sync`
Run after upgrading gstack or adding new `@Observable` classes. Detects what's installed, runs gen-accessors against the latest upstream templates, refreshes any changed Swift files, verifies the app rebuilds. Cache-key invalidation handles Swift version changes, generator git rev changes, and source changes.
Reference in New Issue View Git Blame Copy Permalink