<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly --> <!-- Regenerate: bun run gen:skill-docs -->

Telemetry (run last)

After workflow completion, log telemetry with ONE command. OUTCOME is success/error/abort/unknown; SESSION_ID and TEL_START are the values the preamble's skill-start output echoed. It also drains the artifacts-sync queue (the former skill-end sync step — do not run gstack-brain-sync separately).

PLAN MODE EXCEPTION — ALWAYS RUN: This writes telemetry to $GSTACK_STATE_ROOT/analytics/, matching preamble analytics writes.

~/.claude/skills/gstack/bin/gstack-skill-end --skill "design-shotgun" --outcome OUTCOME \
  --session-id "SESSION_ID" --tel-start "TEL_START" --used-browse USED_BROWSE \
  --error-message "ERROR_MESSAGE" --failed-step "FAILED_STEP" 2>/dev/null || true

Replace OUTCOME and USED_BROWSE (yes/no) before running; substitute SESSION_ID/TEL_START from the skill-start echoes. ERROR_MESSAGE/FAILED_STEP are "" unless outcome is error. If the command is missing (stale install), skip telemetry — it never blocks the workflow.

/design-shotgun: Visual Design Exploration

You are a design brainstorming partner. Generate multiple AI design variants, open them side-by-side in the user's browser, and iterate until they approve a direction. This is visual brainstorming, not a review process.

Section index — Read each section when its situation applies

This skill is a decision-tree skeleton. The steps below point to on-demand sections. Read a section in full before doing its step; do not work from memory.

DESIGN SETUP (run this check BEFORE any design mockup command)

_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
D=""
[ -n "$_ROOT" ] && [ -x "$_ROOT/.claude/skills/gstack/design/dist/design" ] && D="$_ROOT/.claude/skills/gstack/design/dist/design"
[ -z "$D" ] && D="$HOME/.claude/skills/gstack/design/dist/design"
_DS=$("$HOME/.claude/skills/gstack/bin/gstack-paths" --get GSTACK_STATE_ROOT 2>/dev/null); _DC=${_DS:+$_DS/design-ready}; _DK=$(ls -diL "$D" 2>/dev/null)
_dt() { if command -v gtimeout >/dev/null; then gtimeout 10 "$@"; elif command -v timeout >/dev/null; then timeout 10 "$@"
elif command -v perl >/dev/null; then perl -e 'alarm(shift);exec(@ARGV)' 10 "$@"; else return 125; fi; }
_RC=0; _F="Fix: cd ${D%/design/dist/design} && ./setup"
if [ ! -x "$D" ]; then _RC=missing
elif [ ! "$_DC" -nt "$D" ] || [ "$(cat "$_DC")" != "$_DK" ]; then _dt "$D" --version >/dev/null 2>&1 </dev/null || _RC=$?
fi
case "$_RC" in
  0) echo "DESIGN_READY: $D"; [ -n "$_DC" ] && echo "$_DK" > "$_DC" 2>/dev/null ;;
  missing) echo "DESIGN_NOT_AVAILABLE: $D is not installed. $_F" ;;
  124|142) echo "DESIGN_NOT_AVAILABLE: $D --version timed out after 10s" ;;
  125) echo "DESIGN_NOT_AVAILABLE: no timeout/gtimeout/perl to bound $D" ;;
  137) echo "DESIGN_NOT_AVAILABLE: $D --version exited 137 (killed at launch; on macOS usually an invalid code signature). $_F" ;;
  *) echo "DESIGN_NOT_AVAILABLE: $D --version exited $_RC" ;;
esac

If DESIGN_NOT_AVAILABLE: skip visual mockup generation and fall back to the existing HTML wireframe approach (DESIGN_SKETCH). Design mockups are a progressive enhancement, not a hard requirement.

Comparison boards are local HTML files: open them with open file://... on macOS (xdg-open elsewhere). The user just needs to see the file in their default browser.

If DESIGN_READY: the design binary is available for visual mockup generation. Commands:

• $D generate --brief "$(cat "$BRIEF_FILE")" --output /path.png — generate a single mockup (prints outputPath)
• $D variants --brief "$(cat "$BRIEF_FILE")" --count 3 --output-dir /path/ — generate N style variants (prints paths)
• $D compare --images-file /path/board-images.json --output /path/board.html --serve — comparison board + HTTP server
• $D serve --html /path/board.html — serve comparison board and collect feedback via HTTP
• $D check --image /path.png --brief "$(cat "$BRIEF_FILE")" — vision quality gate
• $D iterate --session /path/session.json --feedback "$(cat "$FEEDBACK_FILE")" --output /path.png — iterate

Image commands never overwrite (a taken name gets -2) and always print JSON (requested, saved, failures); exit 0 ready, 2 nothing saved, 3 stopped after saving some. Capture without set -e: _OUT=$($D ...); _RC=$?. Briefs and feedback are free text: write each into a private mktemp file under .gstack/tmp and pass "$(cat "$FILE")", never inline.

Path rule: Design artifacts belong in $GSTACK_STATE_ROOT/projects/$SLUG/designs/. Use bin/gstack-paths (docs/state-root.md). Keep it even if temporary; never substitute .context/, docs/designs/ or another directory. These are user files, not application source.

STOP. Before writing variant concepts or design briefs (Step 3 onward) — the UX-principles doctrine governs every design direction, Read ~/.claude/skills/gstack/design-shotgun/sections/doctrine.md and execute it in full. Do not work from memory — that section is the source of truth for this step.

Step 0: Session Detection

Check for prior design exploration sessions for this project:

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
_PREV=$(find "$GSTACK_STATE_ROOT/projects/$SLUG/designs/" -name "approved.json" -maxdepth 2 2>/dev/null | sort -r | head -5)
[ -n "$_PREV" ] && echo "PREVIOUS_SESSIONS_FOUND" || echo "NO_PREVIOUS_SESSIONS"
echo "$_PREV"

**If PREVIOUS_SESSIONS_FOUND:** Read each approved.json, display a summary, then AskUserQuestion:

"Previous design explorations for this project: - [date]: [screen] — chose variant [X], feedback: '[summary]' A) Revisit — reopen the comparison board to adjust your choices B) New exploration — start fresh with new or updated instructions C) Something else"

If A: regenerate the board from existing variant PNGs, reopen, and resume the feedback loop. If B: proceed to Step 1.

**If NO_PREVIOUS_SESSIONS:** Show the first-time message:

"This is /design-shotgun — your visual brainstorming tool. I'll generate multiple AI design directions, open them side-by-side in your browser, and you pick your favorite. You can run /design-shotgun anytime during development to explore design directions for any part of your product. Let's start."

Step 1: Context Gathering

When design-shotgun is invoked from plan-design-review, design-consultation, or another skill, the calling skill has already gathered context. Check for $_DESIGN_BRIEF — if it's set, skip to Step 2.

When run standalone, gather context to build a proper design brief.

Required context (5 dimensions):

1. Who — who is the design for? (persona, audience, expertise level)
2. Job to be done — what is the user trying to accomplish on this screen/page?
3. What exists — what's already in the codebase? (existing components, pages, patterns)
4. User flow — how do users arrive at this screen and where do they go next?
5. Edge cases — long names, zero results, error states, mobile, first-time vs power user

Auto-gather first:

cat DESIGN.md 2>/dev/null | head -80 || echo "NO_DESIGN_MD"
cat PRODUCT.md 2>/dev/null | head -120 || echo "NO_PRODUCT_MD"

A PRODUCT.md (impeccable's product-context file) answers the job-to-be-done and audience questions: confirm, do not re-ask. Never open .claude/skills/impeccable/**.

ls src/ app/ pages/ components/ 2>/dev/null | head -30

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
ls "$GSTACK_STATE_ROOT"/projects/$SLUG/*office-hours* 2>/dev/null | head -5

If DESIGN.md exists, tell the user: "I'll follow your design system in DESIGN.md by default. If you want to go off the reservation on visual direction, just say so — design-shotgun will follow your lead, but won't diverge by default."

Check for a live site to screenshot (for the "I don't like THIS" use case):

curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 2>/dev/null || echo "NO_LOCAL_SITE"

If the user referenced a URL or said something like "I don't like how this looks," screenshot that page with Aside in Step 3c and generate improvement variants from that screenshot instead of from text alone. If they didn't name the URL, ask for it — never guess which page they mean. If the probe above printed 200, offer http://localhost:3000 as the default in the AskUserQuestion below (still ask — never assume).

AskUserQuestion with pre-filled context: Pre-fill what you inferred from the codebase, DESIGN.md, and office-hours output. Then ask for what's missing. Frame as ONE question covering all gaps:

"Here's what I know: [pre-filled context]. I'm missing [gaps]. Tell me: [specific questions about the gaps]. How many variants? (default 3, up to 8 for important screens)"

Two rounds max of context gathering, then proceed with what you have and note assumptions.

Step 2: Taste Memory

Read both the persistent taste profile (cross-session) AND the per-session approved designs to bias generation toward the user's demonstrated taste.

**Persistent taste profile (v1 schema at ~/.gstack/projects/$SLUG/taste-profile.json):**

Read this project's taste profile:

SLUG=$("$HOME/.claude/skills/gstack/bin/gstack-slug" --get SLUG) || SLUG=""
[ -n "${SLUG:-}" ] || { echo "TASTE_PROFILE_UNAVAILABLE: could not resolve the project slug (gstack-slug failed). Fix: run ./setup."; exit 0; }
GSTACK_STATE_ROOT=$("$HOME/.claude/skills/gstack/bin/gstack-paths" --get GSTACK_STATE_ROOT); : "${GSTACK_STATE_ROOT:?gstack-paths failed; reinstall with ./setup or /gstack-upgrade}"
_TASTE_PROFILE="$GSTACK_STATE_ROOT/projects/$SLUG/taste-profile.json"
if [ -f "$_TASTE_PROFILE" ]; then
  # Schema v1: { dimensions: { fonts, colors, layouts, aesthetics }, sessions: [] }
  # Each dimension has approved[] and rejected[] entries with
  # { value, confidence, approved_count, rejected_count, last_seen }
  # Confidence decays 5% per week of inactivity — computed at read time.
  cat "$_TASTE_PROFILE" 2>/dev/null
  echo "TASTE_PROFILE_FOUND"
else
  echo "NO_TASTE_PROFILE"
fi

If TASTE_PROFILE_UNAVAILABLE: say so once; continue without a taste profile.

If TASTE_PROFILE_FOUND: Parse the full JSON; malformed/unreadable uses the legacy fallback. After decay, rank each dimension by confidence * approved_count (or rejected_count); take three per kind. Count retained sessions (at most 50, not lifetime). Include in the brief:

"Based on [number of retained sessions] recorded sessions, this user's taste leans toward: fonts [top-3], colors [top-3], layouts [top-3], aesthetics [top-3]. Bias generation toward these unless the user explicitly requests a different direction. Also avoid their strong rejections: [top-3 rejected per dimension]."

Legacy fallback: Glob $GSTACK_STATE_ROOT/projects/$SLUG/designs/**/approved.json (resolve the root with gstack-paths); Read the five newest. To view an approved image, resolve it with ~/.claude/skills/gstack/bin/gstack-design-approved <approved.json>. Use explicit feedback only, never infer fonts/colors from variant letters. No usable files: continue without a taste profile.

Conflict handling: If the current user request contradicts a strong persistent signal (e.g., "make it playful" when taste profile strongly prefers minimal), flag it: "Note: your taste profile strongly prefers minimal. You're asking for playful this time — I'll proceed, but want me to update the taste profile, or treat this as a one-off?"

Decay: Multiply stored confidence by 0.95 raised to elapsed weeks since last_seen (minimum zero weeks). Skip invalid dates/confidence; do not rewrite the file while reading.

Schema migration: If the file has no version field or version: 0, it's the legacy approved.json aggregate — ~/.claude/skills/gstack/bin/gstack-taste-update will migrate it to schema v1 on the next write.

Per-session approved.json files (legacy, still supported):

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
_TASTE=$(find "$GSTACK_STATE_ROOT/projects/$SLUG/designs/" -name "approved.json" -maxdepth 2 2>/dev/null | sort -r | head -10)

If prior sessions exist, read each approved.json and extract patterns from the approved variants; resolve each approved image with ~/.claude/skills/gstack/bin/gstack-design-approved <approved.json> (an error means that image is gone: skip it, never substitute another). Merge these into the taste-profile.json-derived signal — if the profile already says "user prefers Geist font" (from aggregated history), the approved.json files add the specific recent approval context.

Limit to last 10 sessions. Try/catch JSON parse on each (skip corrupted files).

Updating taste profile after a design-shotgun session: When the user picks a variant, call ~/.claude/skills/gstack/bin/gstack-taste-update approved <approved image path> (the APPROVED_IMAGE printed when approved.json is saved). When they explicitly reject a variant, call ~/.claude/skills/gstack/bin/gstack-taste-update rejected <variant-path>. The CLI handles schema migration from approved.json, decay, and conflict flagging.

Step 3: Generate Variants

Set up the output directory:

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}"
_DESIGN_DIR="$GSTACK_STATE_ROOT/projects/$SLUG/designs/<screen-name>-$(date +%Y%m%d)"
mkdir -p "$_DESIGN_DIR"
echo "DESIGN_DIR: $_DESIGN_DIR"

Replace <screen-name> with a descriptive kebab-case name from the context gathering.

Step 3a: Concept Generation

Before any API calls, generate N text concepts describing each variant's design direction. Each concept should be a distinct creative direction, not a minor variation. Present them as a lettered list:

I'll explore 3 directions:

A) "Name" — one-line visual description of this direction
B) "Name" — one-line visual description of this direction
C) "Name" — one-line visual description of this direction

Draw on DESIGN.md, taste memory, and the user's request to make each concept distinct.

Anti-convergence directive: each concept is a distinct direction. When a DESIGN.md exists, it decides what varies: keep its fonts and palette and vary layout and composition. Without one, vary font family, color palette, and layout approach. If two variants look like siblings, rework the weaker one with a deliberately different direction. For a landing, pricing or campaign screen, also vary the page archetype (classic-hero, long-form-story, minimal-conversion, comparison), keep the one primary action identical, and caption each variant with its archetype id and section outline.

Concrete test: if someone could swap the headline text between two variants without noticing, they're too similar. Variants should feel like separate design teams made them, not one team on different days.

Step 3b: Concept Confirmation

Use AskUserQuestion to confirm before spending API credits:

"These are the {N} directions I'll generate. They run in parallel, so the whole set typically takes about 60 seconds."

Options:

• A) Generate all {N} — looks good
• B) I want to change some concepts (tell me which)
• C) Add more variants (I'll suggest additional directions)
• D) Fewer variants (tell me which to drop)

If B: incorporate feedback, re-present concepts, re-confirm. Max 2 rounds. If C: add concepts, re-present, re-confirm. If D: drop specified concepts, re-present, re-confirm.

Step 3c: Parallel Generation

If evolving from a screenshot (user said "I don't like THIS"), take ONE screenshot of the page the user named, in Aside (PNG, the format the evolve step reads):

aside repl '
const pg = await openTab("<url>");
await pg.screenshot({ path: "current.png", type: "png", fullPage: true });
console.log("ASIDE_DIR=" + pwd);
await closeTab(pg);
console.log("GSTACK_STEP_OK");
'

Then cp "<ASIDE_DIR>/current.png" "$_DESIGN_DIR/current.png" and Read it so the user sees what you're evolving from.

**Generate every variant with one $D variants --briefs-file call.** Write one entry per confirmed concept to $_DESIGN_DIR/briefs.json: a JSON array of {"brief": "<the full variant-specific brief>"} objects, in concept order (A, B, C, ...), at most 7. When evolving, add "screenshot": "<_DESIGN_DIR>/current.png" to every entry. Then run this Bash call with timeout: 600000 and wait for it to return. It stages in a fresh per-run directory: in sandboxed sessions $D output under ~/.gstack/ can abort ("The operation was aborted"), while the temp dir works.

_VARIANT_TMP=$(mktemp -d "${TMPDIR:-/tmp}/gstack-variants-XXXXXXXX")
_VARIANTS_JSON=$("$D" variants --briefs-file "$_DESIGN_DIR/briefs.json" --output-dir "$_VARIANT_TMP"); _RC=$?
echo "$_VARIANTS_JSON"; echo "EXIT: $_RC"

The command starts the variants 1.5s apart, retries rate limits with backoff, regenerates an empty image once, runs the vision check on each image and regenerates once when it fails (both images are kept), and starts no new work after 9 minutes. It never overwrites an image. It prints one VARIANT_<letter>_DONE, _FAILED or _RATE_LIMITED line per variant on stderr and JSON on stdout. Each variants[] entry has saved (every image it saved, in order; the last is its pick), operation, status, error, retryable and check.status (pass, fail or skipped). Exit 0 means at least one variant was generated (read each status), 2 means nothing was saved, and 1 means the briefs file was invalid and nothing was billed (the error names the entry and field; fix it and rerun).

Publish without overwriting. Never cp or mv an image. For each variant, publish every path in its saved list, in order, with FINAL=$(~/.claude/skills/gstack/bin/gstack-design-claim "<saved path>" "$_DESIGN_DIR/variant-{letter}.png"). It never overwrites and prints the final (possibly bumped) path; use FINAL from here on and report every published path. A variant's last FINAL is its pick. If a claim fails, report the error; the staged image stays at its saved path.

Step 3d: Results

After the command returns and its images are published:

<!-- design:round-accounting -->

1. Round accounting first: this round's images are exactly the published paths (never a directory listing; older rounds stay on disk). Tell the user: "{saved} of {N} paid images saved in ~{actual time}", listing every published path. A skipped check is missing automated coverage, not a pass: say so.
2. For any failures: report explicitly with the error. Do NOT silently skip. Rerun each failed variant with retryable: true once, using its own operation and its brief read from briefs.json as data: _BRIEF=$(jq -r --arg v "<letter>" '.[($v | explode[0]) - 65].brief' "$_DESIGN_DIR/briefs.json"), then "$D" generate --brief "$_BRIEF" --output "$_VARIANT_TMP/variant-<letter>.png", or for a screenshot entry "$D" evolve --screenshot "$_DESIGN_DIR/current.png" --brief "$_BRIEF" --output "$_VARIANT_TMP/variant-<letter>.png". Capture its JSON and exit code, then publish its outputPath with the claim helper.
3. If zero variants succeeded: fall back to sequential generation, running $D generate yourself one variant at a time into $_VARIANT_TMP, publishing each with the claim helper and showing each as it lands. Tell the user: "Parallel generation failed (likely rate limiting). Falling back to sequential..." If that also saves nothing, report the failures and stop: no board.
4. Read each published image inline (Read tool, the published paths) so the user sees all variants at once.
5. Proceed to Step 4 with each variant's pick (its last published path), in letter order, as this round's board images.

Step 4: Comparison Board + Feedback Loop

Comparison Board + Feedback Loop

Create the comparison board and serve it over HTTP:

<!-- design:board --> Write this round's board images (printed paths that passed checks, in order) as a JSON array to $_DESIGN_DIR/board-images.json with the Write tool; board letters A, B, C follow that order. Then archive any earlier Submit so it cannot approve these images, and build the board:

[ -f "${_DESIGN_DIR:?set _DESIGN_DIR to the design dir printed above}/feedback.json" ] && mv "${_DESIGN_DIR:?}/feedback.json" "${_DESIGN_DIR:?}/feedback-$(date -u +%Y%m%dT%H%M%SZ).json"
$D compare --images-file "$_DESIGN_DIR/board-images.json" --output "$_DESIGN_DIR/design-board.html" --serve

Creates HTML and opens the board. Run it in the background (host task, or & redirecting stdout/stderr to private files in $_DESIGN_DIR). Read captured stderr for the startup marker; a PID is not readiness. Missing marker: use the failure fallback below.

Default stderr: BOARD_URL: http://127.0.0.1:N/boards/<id>/. Use that full per-board URL for AskUserQuestion and as the reload base. Only explicit legacy --no-daemon emits SERVE_STARTED: port=XXXXX, serving one board at / with reload at /api/reload.

PRIMARY WAIT: AskUserQuestion with board URL

Once serving, wait with AskUserQuestion including the board URL:

"I've opened a comparison board with the design variants: <BOARD_URL> — Rate them, leave comments, remix elements you like, and click Submit when you're done. Let me know when you've submitted your feedback (or paste your preferences here). If you clicked Regenerate or Remix on the board, tell me and I'll generate new variants."

Substitute <BOARD_URL> from the stderr marker above.

The user chooses variants in the board; AskUserQuestion only waits.

After the user responds to AskUserQuestion:

Check for feedback files next to the board HTML:

• $_DESIGN_DIR/feedback.json — written when user clicks Submit (final choice)
• $_DESIGN_DIR/feedback-pending.json — written when user clicks Regenerate/Remix/More Like This

if [ -f "$_DESIGN_DIR/feedback.json" ]; then
  echo "SUBMIT_RECEIVED"
  cat "$_DESIGN_DIR/feedback.json"
elif [ -f "$_DESIGN_DIR/feedback-pending.json" ]; then
  echo "REGENERATE_RECEIVED"
  cat "$_DESIGN_DIR/feedback-pending.json"
  rm "$_DESIGN_DIR/feedback-pending.json"
else
  echo "NO_FEEDBACK_FILE"
fi

The feedback JSON has this shape:

{
  "preferred": "A",
  "ratings": { "A": 4, "B": 3, "C": 2 },
  "comments": { "A": "Love the spacing" },
  "overall": "Go with A, bigger CTA",
  "regenerated": false
}

**If feedback.json found:** The user clicked Submit on the board. Read preferred, ratings, comments, overall from the JSON. Proceed with the approved variant.

**If feedback-pending.json found:** The user clicked Regenerate/Remix on the board.

1. Read regenerateAction from the JSON ("different", "match", "more_like_B", "remix", or custom text)
2. If regenerateAction is "remix", read remixSpec (e.g. {"layout":"A","colors":"B"})
3. Generate new variants with $D iterate or $D variants using updated brief (capture the JSON and do round accounting as for the first round)
4. Rebuild with the board block above (it archives feedback.json and rewrites board-images.json), without --serve
5. Reload the board in the user's browser (same tab) — the URL is per-board under daemon mode, so use <BOARD_URL> (from the BOARD_URL: stderr line) as the base: jq -nc --arg html "$_DESIGN_DIR/design-board.html" '{html: $html}' | curl -sS -X POST "${BOARD_URL}api/reload" -H 'Content-Type: application/json' --data-binary @- Under --no-daemon the reload endpoint is /api/reload at the legacy port; this path only matters if the caller explicitly opted out of the daemon.
6. The board auto-refreshes. AskUserQuestion again with the same board URL to wait for the next round of feedback. Repeat until feedback.json appears.

**If NO_FEEDBACK_FILE:** The user typed their preferences directly in the AskUserQuestion response instead of using the board. Use their text response as the feedback.

Exit 0 with BOARD_URL means the daemon is serving; use the board feedback flow above. SERVER FALLBACK: Nonzero exit or no readiness marker: show each variant inline using the Read tool (so the user can see them), then use AskUserQuestion: "The comparison board server failed to start. I've shown the variants above. Which do you prefer? Any feedback?"

After receiving feedback (any path): Output a clear summary confirming what was understood:

"Here's what I understood from your feedback: PREFERRED: Variant [X] RATINGS: [list] YOUR NOTES: [comments] DIRECTION: [overall]

Is this right?"

Use AskUserQuestion to verify before proceeding.

Save the approved choice. Write the user's feedback (none when they gave none) into a private file:

_GT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)/.gstack/tmp"
mkdir -p "$_GT" && chmod 700 "$_GT" || { echo "Not sent: cannot create $_GT for the text file." >&2; exit 1; }
_EX=$(git rev-parse --git-path info/exclude 2>/dev/null) && mkdir -p "$(dirname "$_EX")" && { grep -qxF '/.gstack/tmp/' "$_EX" 2>/dev/null || echo '/.gstack/tmp/' >> "$_EX"; }
FEEDBACK_FILE=$(mktemp "${_GT:?}/feedback.XXXXXX") || { echo "Not sent: mktemp failed in $_GT." >&2; exit 1; }; echo "FEEDBACK_FILE: $FEEDBACK_FILE (name: ${FEEDBACK_FILE##*/})"

Write the text into each printed file with your file-write tool (Claude Code's Write tool needs a Read of the empty file first), exactly as it should appear. The text never goes into a shell command, heredoc or quoted argument. If a write fails or is refused, do not send: print the cause, the file path and the command below for sending by hand. Then map the confirmed letter through this board's board-images.json (never the directory listing) and save it, substituting the printed name for <feedback-file-name>:

_IMG=$(jq -r --arg v "<VARIANT>" '.[($v | explode[0]) - 65] // empty' "$_DESIGN_DIR/board-images.json")
if [ -n "$_IMG" ]; then
  FEEDBACK_FILE="$(git rev-parse --show-toplevel 2>/dev/null || pwd)/.gstack/tmp/<feedback-file-name>"
  [ -s "$FEEDBACK_FILE" ] || { echo "Not saved: $FEEDBACK_FILE is missing or empty. Write the feedback, then rerun this block." >&2; exit 1; }
  jq -n --arg approved_variant "<VARIANT>" --arg approved_path "$(basename "$_IMG")" --rawfile feedback "$FEEDBACK_FILE" --arg date "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --arg screen "<SCREEN>" --arg branch "$(git branch --show-current 2>/dev/null)" '$ARGS.named | .feedback |= rtrimstr("\n")' > "$_DESIGN_DIR/approved.json" && rm -f "$FEEDBACK_FILE"
  echo "APPROVED_IMAGE: $_IMG"
else
  echo "NO_BOARD_IMAGE: <VARIANT> is not on this board; reselect from the board"
fi

Step 5: Feedback Confirmation

After receiving feedback (via HTTP POST or AskUserQuestion fallback), output a clear summary confirming what was understood:

"Here's what I understood from your feedback:

PREFERRED: Variant [X] RATINGS: A: 4/5, B: 3/5, C: 2/5 YOUR NOTES: [full text of per-variant and overall comments] DIRECTION: [regenerate action if any]

Is this right?"

Use AskUserQuestion to confirm before saving.

Step 6: Save & Next Steps

Write approved.json to $_DESIGN_DIR/ (handled by the loop above). When the variants varied archetype, then add the chosen variant's archetype id and sections (its outline as an array of section names) to it with the Edit tool; /design-html takes them as given.

If invoked from another skill: return the structured feedback for that skill to consume. The calling skill reads approved.json and resolves the approved image with ~/.claude/skills/gstack/bin/gstack-design-approved "$_DESIGN_DIR/approved.json".

If standalone, offer next steps via AskUserQuestion:

"Design direction locked in. What's next? A) Iterate more — refine the approved variant with specific feedback B) Finalize — generate production Pretext-native HTML/CSS with /design-html C) Save to plan — add this as an approved mockup reference in the current plan D) Done — I'll use this later"

Important Rules

1. Use the configured state root. All design artifacts go to $GSTACK_STATE_ROOT/projects/$SLUG/designs/, even when that root is temporary. Do not substitute .context/, docs/designs/, or an arbitrary /tmp/ path. See DESIGN_SETUP above.
2. Show variants inline before opening the board. The user should see designs immediately in their terminal. The browser board is for detailed feedback.
3. Confirm feedback before saving. Always summarize what you understood and verify.
4. Taste memory is automatic. Prior approved designs inform new generations by default.
5. Two rounds max on context gathering. Don't over-interrogate. Proceed with assumptions.
6. DESIGN.md is the default constraint. Unless the user says otherwise.