@amg555/frameforge-mcp 2.7.6 → 2.7.7

package/.agent/skills/gstack-design-html/SKILL.md.tmpl

@@ -1,476 +0,0 @@
----
-name: design-html
-preamble-tier: 2
-version: 1.0.0
-description: |
-  Design finalization: generates production-quality Pretext-native HTML/CSS.
-  Works with approved mockups from /design-shotgun, CEO plans from /plan-ceo-review,
-  design review context from /plan-design-review, or from scratch with a user
-  description. Text actually reflows, heights are computed, layouts are dynamic.
-  30KB overhead, zero deps. Smart API routing: picks the right Pretext patterns
-  for each design type. Use when: "finalize this design", "turn this into HTML",
-  "build me a page", "implement this design", or after any planning skill.
-  Proactively suggest when user has approved a design or has a plan ready. (gstack)
-voice-triggers:
-  - "build the design"
-  - "code the mockup"
-  - "make it real"
-triggers:
-  - build the design
-  - code the mockup
-  - make design real
-allowed-tools:
-  - Bash
-  - Read
-  - Write
-  - Edit
-  - Glob
-  - Grep
-  - Agent
-  - AskUserQuestion
----
-
-{{PREAMBLE}}
-
-# /design-html: Pretext-Native HTML Engine
-
-You generate production-quality HTML where text actually works correctly. Not CSS
-approximations. Computed layout via Pretext. Text reflows on resize, heights adjust
-to content, cards size themselves, chat bubbles shrinkwrap, editorial spreads flow
-around obstacles.
-
----
-
-{{SECTION_INDEX:design-html}}
-
----
-
-{{DESIGN_SETUP}}
-
-{{DESIGN_DETECTOR}}
-
-{{SECTION:doctrine}}
-
----
-
-## Step 0: Input Detection
-
-Detect context with the CEO-plan check and the design-artifact checks below:
-
-```bash
-SLUG=$(~/.claude/skills/gstack/bin/gstack-slug --get SLUG 2>/dev/null)
-GSTACK_STATE_ROOT=$(~/.claude/skills/gstack/bin/gstack-paths --get GSTACK_STATE_ROOT); : "${GSTACK_STATE_ROOT:?gstack-paths failed; reinstall with ./setup or /gstack-upgrade}"
-setopt +o nomatch 2>/dev/null || true
-_CEO=$(ls -t "$GSTACK_STATE_ROOT/projects/$SLUG/ceo-plans/"*.md 2>/dev/null | head -1)
-[ -n "$_CEO" ] && echo "CEO_PLAN: $_CEO" || echo "NO_CEO_PLAN"
-```
-
-```bash
-SLUG=$(~/.claude/skills/gstack/bin/gstack-slug --get SLUG 2>/dev/null)
-GSTACK_STATE_ROOT=$(~/.claude/skills/gstack/bin/gstack-paths --get GSTACK_STATE_ROOT); : "${GSTACK_STATE_ROOT:?gstack-paths failed; reinstall with ./setup or /gstack-upgrade}"
-setopt +o nomatch 2>/dev/null || true
-_APPROVED=$(ls -t "$GSTACK_STATE_ROOT/projects/$SLUG/designs/"*/approved.json 2>/dev/null | head -1)
-[ -n "$_APPROVED" ] && echo "APPROVED: $_APPROVED" || echo "NO_APPROVED"
-_VARIANTS=$(ls -t "$GSTACK_STATE_ROOT/projects/$SLUG/designs/"*/variant-*.png 2>/dev/null | head -1)
-[ -n "$_VARIANTS" ] && echo "VARIANTS: $_VARIANTS" || echo "NO_VARIANTS"
-_FINALIZED=$(ls -t "$GSTACK_STATE_ROOT/projects/$SLUG/designs/"*/finalized.html 2>/dev/null | head -1)
-[ -n "$_FINALIZED" ] && echo "FINALIZED: $_FINALIZED" || echo "NO_FINALIZED"
-[ -f DESIGN.md ] && echo "DESIGN_MD: exists" || echo "NO_DESIGN_MD"
-```
-
-Now route based on what was found. Check these cases in order:
-
-### Case A: approved.json exists (design-shotgun ran)
-
-If `APPROVED` was found, read it for user feedback and screen name, and resolve the
-approved PNG (never guess it from a letter or the newest variant):
-
-```bash
-{{BIN_DIR}}/gstack-design-approved "<APPROVED path>"
-```
-
-It prints the approved image's absolute path. If it prints "approved image ... is
-missing; reselect from the board" instead, tell the user exactly that, offer
-/design-shotgun to reselect, and do not substitute another image. Also read the CEO
-plan if one exists (it adds strategic context).
-
-Read `DESIGN.md` if it exists in the repo root. These tokens take priority for
-system-level values (fonts, brand colors, spacing scale).
-
-Then check for prior finalized.html. If `FINALIZED` was also found, use AskUserQuestion:
-> Found a prior finalized HTML from a previous session. Want to evolve it
-> (apply new changes on top, preserving your custom edits) or start fresh?
-> A) Evolve — iterate on the existing HTML
-> B) Start fresh — regenerate from the approved mockup
-
-If evolve: read the existing HTML. Apply changes on top during Step 3.
-If fresh or no finalized.html: proceed to Step 1 with the approved PNG as the
-visual reference.
-
-### Case B: CEO plan and/or design variants exist, but no approved.json
-
-If `CEO_PLAN` or `VARIANTS` was found but no `APPROVED`:
-
-Read whichever context exists:
-- If CEO plan found: read it and summarize the product vision and design requirements.
-- If variant PNGs found: show them inline using the Read tool.
-- If DESIGN.md found: read it for design tokens and constraints.
-
-Use AskUserQuestion:
-> Found [CEO plan from /plan-ceo-review | design review variants from /plan-design-review | both]
-> but no approved design mockup.
-> A) Run /design-shotgun — explore design variants based on the existing plan context
-> B) Skip mockups — I'll design the HTML directly from the plan context
-> C) I have a PNG — let me provide the path
-
-If A: tell the user to run /design-shotgun, then come back to /design-html.
-If B: proceed to Step 1 in "plan-driven mode." There is no approved PNG, the plan is
-the source of truth. Ask the user for a screen name to use for the output directory
-(e.g., "landing-page", "dashboard", "pricing").
-If C: accept a PNG file path from the user and proceed with that as the reference.
-
-### Case C: Nothing found (clean slate)
-
-If none of the above produced any context:
-
-Use AskUserQuestion:
-> No design context found for this project. How do you want to start?
-> A) Run /plan-ceo-review first — think through the product strategy before designing
-> B) Run /plan-design-review first — design review with visual mockups
-> C) Run /design-shotgun — jump straight to visual design exploration
-> D) Just describe it — tell me what you want and I'll design the HTML live
-
-If A, B, or C: tell the user to run that skill, then come back to /design-html.
-If D: proceed to Step 1 in "freeform mode." Ask the user for a screen name.
-
-### Context summary
-
-After routing, output a brief context summary:
-- **Mode:** approved-mockup | plan-driven | freeform | evolve
-- **Visual reference:** path to approved PNG, or "none (plan-driven)" or "none (freeform)"
-- **CEO plan:** path or "none"
-- **Design tokens:** "DESIGN.md" or "none"
-- **Screen name:** from approved.json, user-provided, or inferred from CEO plan
-
----
-
-## Step 1: Design Analysis
-
-1. If `$D` is available (`DESIGN_READY`), extract a structured implementation spec:
-```bash
-$D prompt --image <approved-variant.png> --output json
-```
-This returns colors, typography, layout structure, and component inventory via an OpenAI vision model (gpt-5.5 by default, `GSTACK_DESIGN_MODEL` overrides).
-
-2. If `$D` is not available, read the approved PNG inline using the Read tool.
-   Describe the visual layout, colors, typography, and component structure yourself.
-
-3. If in plan-driven or freeform mode (no approved PNG), design from context:
-   - **Plan-driven:** read the CEO plan and/or design review notes. Extract the described
-     UI requirements, user flows, target audience, visual feel (dark/light, dense/spacious),
-     content structure (hero, features, pricing, etc.), and design constraints. Build an
-     implementation spec from the plan's prose rather than a visual reference.
-   - **Freeform:** use AskUserQuestion to gather what the user wants to build. Ask about:
-     purpose/audience, visual feel (dark/light, playful/serious, dense/spacious),
-     content structure (hero, features, pricing, etc.), and any reference sites they like.
-   In both cases, describe the intended visual layout, colors, typography, and
-   component structure as your implementation spec. Generate realistic content based
-   on the plan or user description (never lorem ipsum).
-
-4. Read `DESIGN.md` tokens. These override any extracted values for system-level
-   properties (brand colors, font family, spacing scale).
-
-5. Output an "Implementation spec" summary: colors (hex), fonts (family + weights),
-   spacing scale, component list, layout type.
-
----
-
-## Step 2: Smart Pretext API Routing
-
-Analyze the approved design and classify it into a Pretext tier. Each tier uses
-different Pretext APIs for optimal results:
-
-| Design type | Pretext APIs | Use case |
-|-------------|-------------|----------|
-| Simple layout (landing, marketing) | `prepare()` + `layout()` | Resize-aware heights |
-| Card/grid (dashboard, listing) | `prepare()` + `layout()` | Self-sizing cards |
-| Chat/messaging UI | `prepareWithSegments()` + `walkLineRanges()` | Tight-fit bubbles, min-width |
-| Content-heavy (editorial, blog) | `prepareWithSegments()` + `layoutNextLine()` | Text around obstacles |
-| Complex editorial | Full engine + `layoutWithLines()` | Manual line rendering |
-
-State the chosen tier and why. Reference the specific Pretext APIs that will be used.
-
----
-
-## Step 2.5: Framework Detection
-
-Check if the user's project uses a frontend framework:
-
-```bash
-[ -f package.json ] && cat package.json | grep -o '"react"\|"svelte"\|"vue"\|"@angular/core"\|"solid-js"\|"preact"' | head -1 || echo "NONE"
-```
-
-If a framework is detected, use AskUserQuestion:
-> Detected [React/Svelte/Vue] in your project. What format should the output be?
-> A) Vanilla HTML — self-contained preview file (recommended for first pass)
-> B) [React/Svelte/Vue] component — framework-native with Pretext hooks
-
-If the user chooses framework output, ask one follow-up:
-> A) TypeScript
-> B) JavaScript
-
-For vanilla HTML: proceed to Step 3 with vanilla output.
-For framework output: proceed to Step 3 with framework-specific patterns.
-If no framework detected: default to vanilla HTML, no question needed.
-
----
-
-## Step 3: Generate Pretext-Native HTML
-
-{{SECTION:pretext-patterns}}
-
-### Pretext Source Embedding
-
-For **vanilla HTML output**, check for the vendored Pretext bundle:
-```bash
-_PRETEXT_VENDOR=""
-_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
-[ -n "$_ROOT" ] && [ -f "$_ROOT/.claude/skills/gstack/design-html/vendor/pretext.js" ] && _PRETEXT_VENDOR="$_ROOT/.claude/skills/gstack/design-html/vendor/pretext.js"
-[ -z "$_PRETEXT_VENDOR" ] && [ -f ~/.claude/skills/gstack/design-html/vendor/pretext.js ] && _PRETEXT_VENDOR=~/.claude/skills/gstack/design-html/vendor/pretext.js
-[ -n "$_PRETEXT_VENDOR" ] && echo "VENDOR: $_PRETEXT_VENDOR" || echo "VENDOR_MISSING"
-```
-
-- If `VENDOR` found: inline the file in a `<script type="module">` and put the page's
-  Pretext code after it in that same script; the bundle ends in `export {...}` and sets
-  no global. The HTML file is fully self-contained with zero network dependencies.
-- If `VENDOR_MISSING`: use CDN import as fallback:
-  `<script type="module">import { prepare, layout, prepareWithSegments, walkLineRanges, layoutNextLine, layoutWithLines } from 'https://esm.sh/@chenglou/pretext'</script>`
-  Add a comment: `<!-- FALLBACK: vendor/pretext.js missing, using CDN -->`
-
-For **framework output**, add to the project's dependencies instead:
-```bash
-# Detect package manager
-[ -f bun.lockb ] && echo "bun add @chenglou/pretext" || \
-[ -f pnpm-lock.yaml ] && echo "pnpm add @chenglou/pretext" || \
-[ -f yarn.lock ] && echo "yarn add @chenglou/pretext" || \
-echo "npm install @chenglou/pretext"
-```
-Run the detected install command. Then use standard imports in the component.
-
-### HTML Generation
-
-Write a single file using the Write tool. Save to:
-`$GSTACK_STATE_ROOT/projects/$SLUG/designs/<screen-name>-YYYYMMDD/finalized.html`
-
-For framework output, save to:
-`$GSTACK_STATE_ROOT/projects/$SLUG/designs/<screen-name>-YYYYMMDD/finalized.[tsx|svelte|vue]`
-
-**Always include in vanilla HTML:**
-- Pretext source (inlined or CDN, see above)
-- CSS custom properties for design tokens from DESIGN.md / Step 1 extraction
-- Fonts from the source DESIGN.md names (Google Fonts, Fontshare, or self-hosted) via `<link>` tags + `document.fonts.ready` gate before first `prepare()`
-- Semantic HTML5 (`<header>`, `<nav>`, `<main>`, `<section>`, `<footer>`)
-- Responsive behavior via Pretext relayout (not just media queries)
-- Breakpoint-specific adjustments at 375px, 768px, 1024px, 1440px
-- ARIA attributes, heading hierarchy, focus-visible states
-- `contenteditable` on text elements + MutationObserver to re-prepare + re-layout on edit
-- ResizeObserver on containers to re-layout on resize
-- `prefers-color-scheme` media query for dark mode
-- `prefers-reduced-motion` for animation respect
-- Real content extracted from the mockup (never lorem ipsum)
-
-**Never include by default (AI slop blacklist):** an approved mockup that carries one, a DESIGN.md blessing, or an explicit user ask overrides it; say the tradeoff once.
-- Purple/blue gradients as default <!-- ai-color-palette -->
-- Cream-and-serif default palette <!-- cream-palette -->
-- Gradient text <!-- gradient-text -->
-- Generic 3-column feature grids <!-- feature-grid-3col -->
-- Identical card grids, nested cards <!-- identical-cards --> <!-- nested-cards -->
-- Center-everything layouts with no visual hierarchy <!-- centered-everything -->
-- Kickers or icon tiles above headings <!-- kicker-above-heading --> <!-- icon-tile-stack -->
-- Hero metric rows ("10k+ users") <!-- hero-metrics -->
-- Decorative blobs, waves, or geometric patterns not in the mockup <!-- decorative-blobs -->
-- Glowing edges or pulsing status dots <!-- dark-glow --> <!-- pulsing-dot -->
-- Stock photo placeholder divs <!-- stock-photo-hero -->
-- "Get Started" / "Learn More" generic CTAs not from the mockup <!-- generic-cta-copy -->
-- Rounded-corner cards with drop shadows as the default component <!-- card-default-component -->
-- Emoji as visual elements <!-- emoji-decoration -->
-- Generic testimonial sections <!-- generic-testimonials -->
-- Cookie-cutter hero sections with left-text right-image <!-- split-hero-template -->
-
-Each `<!-- id -->` is the pattern's id in `lib/design-catalog.ts`; the design detector reports the same ids.
-
----
-
-## Step 3.5: Live Reload Server
-
-After writing the HTML file, start a simple HTTP server for live preview:
-
-```bash
-# Start a simple HTTP server in the output directory
-_OUTPUT_DIR=$(dirname <path-to-finalized.html>)
-cd "$_OUTPUT_DIR"
-python3 -m http.server 0 --bind 127.0.0.1 &
-_SERVER_PID=$!
-_PORT=$(lsof -i -P -n | grep "$_SERVER_PID" | grep LISTEN | awk '{print $(9)}' | cut -d: -f2 | head -1)
-echo "SERVER: http://localhost:$_PORT/finalized.html"
-echo "PID: $_SERVER_PID"
-```
-
-Remember the printed `SERVER:` URL and `PID:` value; each bash block is a fresh
-shell, so later blocks restate them literally.
-
-If python3 is not available, fall back to:
-```bash
-open <path-to-finalized.html>
-```
-
-Tell the user: "Live preview running at <SERVER URL>.
-After each edit, just refresh the browser (Cmd+R) to see changes."
-
-When the refinement loop ends (Step 4 exits), kill the server:
-```bash
-kill <PID> 2>/dev/null || true
-```
-
----
-
-## Step 4: Preview + Refinement Loop
-
-{{DESIGN_DETECTOR:gate}}
-
-### Verification Screenshots
-
-Take verification screenshots at 3 viewports. One `gstack-render` call serves
-the HTML's directory on 127.0.0.1 (so relative assets resolve), opens the page
-in the Aside browser when it is running — otherwise in gstack's own headless
-browser (the first output line, `ENGINE=aside` or `ENGINE=browse`, says which)
-— and captures each width:
-
-```bash
-bun run ~/.claude/skills/gstack/bin/gstack-render.ts <path-to-finalized.html> \
-  --screenshot /tmp/gstack-verify-mobile.jpg --width 375 --jpeg \
-  --screenshot /tmp/gstack-verify-tablet.jpg --width 768 --jpeg \
-  --screenshot /tmp/gstack-verify-desktop.jpg --width 1440 --jpeg
-```
-
-Show all three screenshots inline using the Read tool. Check for:
-- Text overflow (text cut off or extending beyond containers)
-- Layout collapse (elements overlapping or missing)
-- Responsive breakage (content not adapting to viewport)
-
-If issues are found, note them and fix before presenting to the user.
-
-Only if `gstack-render` prints `NEEDS_ASIDE` or `ASIDE_NOT_RUNNING` followed by
-`ERROR: no browser available` (Aside is not open AND gstack's own browser is not
-built), skip verification and note: "No browser available (open the Aside app,
-or run ./setup in the gstack repo to build gstack's browser). Skipping automated
-viewport verification." Never install either for the user.
-
-### Refinement Loop
-
-```
-LOOP:
-  1. If server is running, tell user to open http://localhost:PORT/finalized.html
-     Otherwise: open <path>/finalized.html
-
-  2. If an approved mockup PNG exists, show it inline (Read tool) for visual comparison.
-     If in plan-driven or freeform mode, skip this step.
-
-  3. AskUserQuestion (adjust wording based on mode):
-     With mockup: "The HTML is live in your browser. Here's the approved mockup for comparison.
-      Try: resize the window (text should reflow dynamically),
-      click any text (it's editable, layout recomputes instantly).
-      What needs to change? Say 'done' when satisfied."
-     Without mockup: "The HTML is live in your browser. Try: resize the window
-      (text should reflow dynamically), click any text (it's editable, layout
-      recomputes instantly). What needs to change? Say 'done' when satisfied."
-
-  4. If "done" / "ship it" / "looks good" / "perfect" → exit loop, go to Step 5
-
-  5. Apply feedback using targeted Edit tool changes on the HTML file
-     (do NOT regenerate the entire file — surgical edits only)
-
-  6. Briefly say what changed
-
-  7. If verification screenshots are available, re-take them to confirm the fix
-
-  8. Go to LOOP
-```
-
-Maximum 10 iterations. If the user hasn't said "done" after 10, use AskUserQuestion:
-"We've done 10 rounds of refinement. Want to continue iterating or call it done?"
-
----
-
-## Step 5: Save & Next Steps
-
-### Design Token Extraction
-
-If no `DESIGN.md` exists in the repo root, offer to create one from the generated HTML:
-
-Extract from the HTML:
-- CSS custom properties (colors, spacing, font sizes)
-- Font families and weights used
-- Color palette (primary, secondary, accent, neutral)
-- Spacing scale
-- Border radius values
-- Shadow values
-
-Use AskUserQuestion:
-> No DESIGN.md found. I can extract the design tokens from the HTML we just built
-> and create a DESIGN.md for your project. This means future /design-shotgun and
-> /design-html runs will be style-consistent automatically.
-> A) Create DESIGN.md from these tokens
-> B) Skip — I'll handle the design system later
-
-If A: write `DESIGN.md` in the open DESIGN.md format (/design-consultation Phase 6 template): extracted values in the front matter's five token groups, line 2 `# gstack: design-md-format=spec`, rationale in the canonical sections. An existing file keeps its persisted format choice; never offer a conversion here.
-
-### Save Metadata
-
-Write `finalized.json` alongside the HTML:
-```json
-{
-  "source_mockup": "<approved variant PNG path or null>",
-  "source_plan": "<CEO plan path or null>",
-  "mode": "<approved-mockup|plan-driven|freeform|evolve>",
-  "html_file": "<path to finalized.html or component file>",
-  "pretext_tier": "<selected tier>",
-  "framework": "<vanilla|react|svelte|vue>",
-  "iterations": <number of refinement iterations>,
-  "date": "<ISO 8601>",
-  "screen": "<screen name>",
-  "branch": "<current branch>"
-}
-```
-
-### Next Steps
-
-Use AskUserQuestion:
-> Design finalized with Pretext-native layout. What's next?
-> A) Copy to project — copy the HTML/component into your codebase
-> B) Iterate more — keep refining
-> C) Done — I'll use this as a reference
-
----
-
-## Important Rules
-
-- **Source of truth fidelity over code elegance.** When an approved mockup exists,
-  pixel-match it. If that requires `width: 312px` instead of a CSS grid class, that's
-  correct. When in plan-driven or freeform mode, the user's feedback during the
-  refinement loop is the source of truth. Code cleanup happens later during
-  component extraction.
-
-- **Always use Pretext for text layout.** Even if the design looks simple, Pretext
-  ensures correct height computation on resize. The overhead is 30KB. Every page benefits.
-
-- **Surgical edits in the refinement loop.** Use the Edit tool to make targeted changes,
-  not the Write tool to regenerate the entire file. The user may have made manual edits
-  via contenteditable that should be preserved.
-
-- **Real content only.** When a mockup exists, extract text from it. In plan-driven mode,
-  use content from the plan. In freeform mode, generate realistic content based on the
-  user's description. Never use "Lorem ipsum", "Your text here", or placeholder content.
-
-- **One page per invocation.** For multi-page designs, run /design-html once per page.
-  Each run produces one HTML file.

package/.agent/skills/gstack-design-html/sections/detector-install-offer.md

@@ -1,40 +0,0 @@
-<!-- AUTO-GENERATED from detector-install-offer.md.tmpl — do not edit directly -->
-<!-- Regenerate: bun run gen:skill-docs -->
-<!-- Derived in part from nothing third-party: gstack's own consent flow for downloading impeccable's engine (Apache-2.0, see NOTICE.md). -->
-# Design detector: the one-time install offer
-
-Read this only when the Setup probe printed `DESIGN_DETECTOR_INSTALL_OFFER`. It is the same question `/design-review` asks; whichever design skill runs first asks it, and the answer is remembered.
-
-**Install offer (one question, asked once).** If the probe printed `DESIGN_DETECTOR_INSTALL_OFFER: version=<v> platform=<p> bytes=<n> dest=<path>`, the user has never answered this. Ask now, before any other step, in an interactive session only: with `SESSION_KIND: spawned` or a headless run, never install and never ask; continue as if the answer were "not now". In Conductor, render the brief as prose and STOP. Use this skill's AskUserQuestion format:
-
-```
-D<N> — Install impeccable's design detector engine?
-Project/branch/task: <one line from the current work>
-ELI10: impeccable is a separate Apache-2.0 tool (Paul Bakaus). Its engine is one <n>-byte program that checks pages and CSS for 61 mechanical design mistakes. gstack can download that one file (version <v>, from github.com/pbakaus/impeccable releases) into <dest>, check it against a checksum recorded in gstack, and log the download in ~/.gstack/security/egress.jsonl. No impeccable skill, no editor hook; the engine never touches the network when gstack runs it. Without it this skill works as it does today.
-Stakes if we pick wrong: yes puts a third-party binary on this machine; no leaves machine-catchable design mistakes to judgment alone.
-Recommendation: A because the download is pinned, logged, and reversible (delete <dest>).
-Note: options differ in kind, not coverage — no completeness score.
-Pros / cons:
-A) Install the engine now (recommended)
-  ✅ Every design review opens with 61 deterministic checks, tagged by rule id
-  ✅ One checksum-verified file under your home directory, logged, removable with rm
-  ❌ A third-party binary you did not build runs over your project files in scans
-B) Not now
-  ✅ Nothing changes on this machine; the question returns next time a design skill runs
-  ❌ Design reviews keep relying on judgment alone for mistakes a machine can catch
-C) Never ask again
-  ✅ Design skills stay silent about impeccable (reversible: gstack-config set design_detector_install_prompted false)
-  ❌ An engine you install later is still used, but gstack never reminds you
-D) Turn the detector off
-  ✅ No probe, scan, or handoff line in any design skill (gstack-config set design_detector off)
-  ❌ An engine installed later is ignored until design_detector is back to auto
-Net: a pinned, logged 16 MB download for machine-checked findings, versus every design check staying a judgment call.
-```
-
-On **A**, run the install and read its first line (`IMPECCABLE_INSTALLED: <path>` then the fresh probe lines, or `IMPECCABLE_INSTALL_REFUSED: <reason>`, after which this skill continues without scans):
-
-```bash
-bun --no-env-file run $HOME/.claude/skills/gstack/bin/gstack-design-detect.ts install --host claude
-```
-
-On **B**, continue without scans. On **C**, run `~/.claude/skills/gstack/bin/gstack-config set design_detector_install_prompted true`. On **D**, run `~/.claude/skills/gstack/bin/gstack-config set design_detector off`. Never pass `--sha256` or `--base` yourself: they exist for maintainers and mirrors. If the user also wants the `/impeccable` skill and its hook, they run `npx impeccable install` themselves; gstack never does.

package/.agent/skills/gstack-design-html/sections/detector-install-offer.md.tmpl

@@ -1,6 +0,0 @@
-<!-- Derived in part from nothing third-party: gstack's own consent flow for downloading impeccable's engine (Apache-2.0, see NOTICE.md). -->
-# Design detector: the one-time install offer
-
-Read this only when the Setup probe printed `DESIGN_DETECTOR_INSTALL_OFFER`. It is the same question `/design-review` asks; whichever design skill runs first asks it, and the answer is remembered.
-
-{{DESIGN_DETECTOR:offer}}

package/.agent/skills/gstack-design-html/sections/doctrine.md

@@ -1,86 +0,0 @@
-<!-- AUTO-GENERATED from doctrine.md.tmpl — do not edit directly -->
-<!-- Regenerate: bun run gen:skill-docs -->
-## UX Principles: How Users Actually Behave
-
-These principles govern how real humans interact with interfaces. They are observed
-behavior, not preferences. Apply them before, during, and after every design decision.
-
-### The Three Laws of Usability
-
-1. **Don't make me think.** Every page should be self-evident. If a user stops
-   to think "What do I click?" or "What does this mean?", the design has failed.
-   Self-evident > self-explanatory > requires explanation.
-
-2. **Clicks don't matter, thinking does.** Three mindless, unambiguous clicks
-   beat one click that requires thought. Each step should feel like an obvious
-   choice (animal, vegetable, or mineral), not a puzzle.
-
-3. **Omit, then omit again.** Get rid of half the words on each page, then get
-   rid of half of what's left. Happy talk (self-congratulatory text) must die.
-   Instructions must die. If they need reading, the design has failed.
-
-### How Users Actually Behave
-
-- **Users scan, they don't read.** Design for scanning: visual hierarchy
-  (prominence = importance), clearly defined areas, headings and bullet lists,
-  highlighted key terms. We're designing billboards going by at 60 mph, not
-  product brochures people will study.
-- **Users satisfice.** They pick the first reasonable option, not the best.
-  Make the right choice the most visible choice.
-- **Users muddle through.** They don't figure out how things work. They wing
-  it. If they accomplish their goal by accident, they won't seek the "right" way.
-  Once they find something that works, no matter how badly, they stick to it.
-- **Users don't read instructions.** They dive in. Guidance must be brief,
-  timely, and unavoidable, or it won't be seen.
-
-### Billboard Design for Interfaces
-
-- **Use conventions.** Logo top-left, nav top/left, search = magnifying glass.
-  Don't innovate on navigation to be clever. Innovate when you KNOW you have a
-  better idea, otherwise use conventions. Even across languages and cultures,
-  web conventions let people identify the logo, nav, search, and main content.
-- **Visual hierarchy is everything.** Related things are visually grouped. Nested
-  things are visually contained. More important = more prominent. If everything
-  shouts, nothing is heard. Start with the assumption everything is visual noise,
-  guilty until proven innocent.
-- **Make clickable things obviously clickable.** No relying on hover states for
-  discoverability, especially on mobile where hover doesn't exist. Shape, location,
-  and formatting (color, underlining) must signal clickability without interaction.
-- **Eliminate noise.** Three sources: too many things shouting for attention
-  (shouting), things not organized logically (disorganization), and too much stuff
-  (clutter). Fix noise by removal, not addition.
-- **Clarity trumps consistency.** If making something significantly clearer
-  requires making it slightly inconsistent, choose clarity every time.
-
-### Navigation as Wayfinding
-
-Users on the web have no sense of scale, direction, or location. Navigation
-must always answer: What site is this? What page am I on? What are the major
-sections? What are my options at this level? Where am I? How can I search?
-
-Persistent navigation on every page. Breadcrumbs for deep hierarchies.
-Current section visually indicated. The "trunk test": cover everything except
-the navigation. You should still know what site this is, what page you're on,
-and what the major sections are. If not, the navigation has failed.
-
-### The Goodwill Reservoir
-
-Users start with a reservoir of goodwill. Every friction point depletes it.
-
-**Deplete faster:** Hiding info users want (pricing, contact, shipping). Punishing
-users for not doing things your way (formatting requirements on phone numbers).
-Asking for unnecessary information. Putting sizzle in their way (splash screens,
-forced tours, interstitials). Unprofessional or sloppy appearance.
-
-**Replenish:** Know what users want to do and make it obvious. Tell them what they
-want to know upfront. Save them steps wherever possible. Make it easy to recover
-from errors. When in doubt, apologize.
-
-### Mobile: Same Rules, Higher Stakes
-
-All the above applies on mobile, just more so. Real estate is scarce, but never
-sacrifice usability for space savings. Affordances must be VISIBLE: no cursor
-means no hover-to-discover. Touch targets must be big enough (44px minimum).
-Flat design can strip away useful visual information that signals interactivity.
-Prioritize ruthlessly: things needed in a hurry go close at hand, everything
-else a few taps away with an obvious path to get there.

package/.agent/skills/gstack-design-html/sections/doctrine.md.tmpl

@@ -1 +0,0 @@
-{{UX_PRINCIPLES}}

package/.agent/skills/gstack-design-html/sections/manifest.json

@@ -1,26 +0,0 @@
-{
-  "$schema": "https://gstack.dev/schemas/section-manifest.json",
-  "skill": "design-html",
-  "version": 1,
-  "note": "PASSIVE registry (v2 plan T9 / CM2). Fields are IDs, file paths, human titles, and human-readable trigger text ONLY. The skeleton's decision-tree prose is the ONLY place that decides WHEN to read a section; required section reads are checked by test/carve-section-loading-design-html.test.ts. No machine predicate here — see docs/designs/v2_PLAN.md:663.",
-  "sections": [
-    {
-      "id": "doctrine",
-      "file": "doctrine.md",
-      "title": "UX principles doctrine (how users actually behave)",
-      "trigger": "analyzing the design or making any layout/visual decision (Step 1 onward) — the UX-principles doctrine governs every design choice"
-    },
-    {
-      "id": "pretext-patterns",
-      "file": "pretext-patterns.md",
-      "title": "Pretext wiring patterns + API reference",
-      "trigger": "writing the finalized HTML in Step 3 — the Pretext wiring patterns and API cheatsheet are the required reference for all text-layout code"
-    },
-    {
-      "id": "detector-install-offer",
-      "file": "detector-install-offer.md",
-      "title": "Design detector install offer (one question, asked once)",
-      "trigger": "the Setup probe printed DESIGN_DETECTOR_INSTALL_OFFER — ask the user once whether gstack may download impeccable's engine (checksum-pinned, receipted) before any other step"
-    }
-  ]
-}