mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-18 02:22:04 +08:00
* fix: extend tilde-in-assignment fix to design resolver + 4 skill templates PR #993 fixed the Claude Code permission prompt for `scripts/resolvers/browse.ts` and `gstack-upgrade/SKILL.md.tmpl`. Same bug lives in three more places that weren't on the contributor's branch: - `scripts/resolvers/design.ts` (3 spots: D=, B=, and _DESIGN_DIR=) - `design-shotgun/SKILL.md.tmpl` (_DESIGN_DIR=) - `plan-design-review/SKILL.md.tmpl` (_DESIGN_DIR=) - `design-consultation/SKILL.md.tmpl` (_DESIGN_DIR=) - `design-review/SKILL.md.tmpl` (REPORT_DIR=) Replaces bare `~/` with quoted `"$HOME/..."` in the source-of-truth files, then regenerates. `grep -rEn '^[A-Za-z_]+=~/' --include="SKILL.md" .` now returns zero hits across all hosts (claude, codex, cursor, gbrain, hermes). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(openclaw): make native skills codex-friendly (#864) Normalizes YAML frontmatter on the 4 hand-authored OpenClaw skills so stricter parsers like Codex can load them. Codex CLI was rejecting these files with "mapping values are not allowed in this context" on colons inside unquoted description scalars. - Drops non-standard `version` and `metadata` fields - Rewrites descriptions into simple "Use when..." form (no inline colons) - Adds a regression test enforcing strict frontmatter (name + description only) Verified live: Codex CLI now loads the skills without errors. Observed during /codex outside-voice run on the eval-community-prs plan review — Codex stderr tripped on these exact files, which was real-world confirmation the fix is needed. Dropped the connect-chrome changes from the original PR (the symlink removal is out of scope for this fix; keeping connect-chrome -> open-gstack-browser). Co-Authored-By: Cathryn Lavery <cathrynlavery@users.noreply.github.com> Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(browse): server persists across Claude Code Bash calls The browse server was dying between Bash tool invocations in Claude Code because: 1. SIGTERM: The Claude Code sandbox sends SIGTERM to all child processes when a Bash command completes. The server received this and called shutdown(), deleting the state file and exiting. 2. Parent watchdog: The server polls BROWSE_PARENT_PID every 15s. When the parent Bash shell exits (killed by sandbox), the watchdog detected it and called shutdown(). Both mechanisms made it impossible to use the browse tool across multiple Bash calls — every new `$B` invocation started a fresh server with no cookies, no page state, and no tabs. Fix: - SIGTERM handler: log and ignore instead of shutdown. Explicit shutdown is still available via the /stop command or SIGINT (Ctrl+C). - Parent watchdog: log once and continue instead of shutdown. The existing idle timeout (30 min) handles eventual cleanup. The /stop command and SIGINT still work for intentional shutdown. Windows behavior is unchanged (uses taskkill /F which bypasses signal handlers). Tested: browse server survives across 5+ separate Bash tool calls in Claude Code, maintaining cookies, page state, and navigation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(browse): gate #994 SIGTERM-ignore to normal mode only PR #994 made browse persist across Claude Code Bash calls by ignoring SIGTERM and parent-PID death, relying on the 30-min idle timeout for eventual cleanup. Codex outside-voice review caught that the idle timeout doesn't apply in two modes: headed mode (/open-gstack-browser) and tunnel mode (/pair-agent). Both early-return from idleCheckInterval. Combined with #994's ignore-SIGTERM, those sessions would leak forever after the user disconnects — a real resource leak on shared machines where multiple /pair-agent sessions come and go. Fix: gate SIGTERM-ignore and parent-PID-watchdog-ignore to normal (headless) mode only. Headed + tunnel modes respect both signals and shutdown cleanly. Idle timeout behavior unchanged. Also documents the deliberate contract change for future contributors — don't re-add global SIGTERM shutdown thinking it's missing; it's intentionally scoped. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix: keep cookie picker alive after cli exits Fixes garrytan/gstack#985 * fix: add opencode setup support * feat(browse): add Windows browser path detection and DPAPI cookie decryption - Extend BrowserPlatform to include win32 - Add windowsDataDir to BrowserInfo; populate for Chrome, Edge, Brave, Chromium - getBaseDir('win32') → ~/AppData/Local - findBrowserMatch checks Network/Cookies first on Windows (Chrome 80+) - Add getWindowsAesKey() reading os_crypt.encrypted_key from Local State JSON - Add dpapiDecrypt() via PowerShell ProtectedData.Unprotect (stdin/stdout) - decryptCookieValue branches on platform: AES-256-GCM (Windows) vs AES-128-CBC (mac/linux) - Fix hardcoded /tmp → TEMP_DIR from platform.ts in openDbFromCopy Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(browse): Windows cookie import — profile discovery, v20 detection, CDP fallback Three bugs fixed in cookie-import-browser.ts: - listProfiles() and findInstalledBrowsers() now check Network/Cookies on Windows (Chrome 80+ moved cookies from profile/Cookies to profile/Network/Cookies) - openDb() always uses copy-then-read on Windows (Chrome holds exclusive locks) - decryptCookieValue() detects v20 App-Bound Encryption with specific error code Added CDP-based extraction fallback (importCookiesViaCdp) for v20 cookies: - Launches Chrome headless with --remote-debugging-port on the real profile - Extracts cookies via Network.getAllCookies over CDP WebSocket - Requires Chrome to be closed (v20 keys are path-bound to user-data-dir) - Both cookie picker UI and CLI direct-import paths auto-fall back to CDP Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(browse): document CDP debug port security + log Chrome version on v20 fallback Follow-up to #892 per Codex outside-voice review. Two small additions to the Windows v20 App-Bound Encryption CDP fallback: 1. Inline comment documenting the deliberate security posture of the --remote-debugging-port. Chrome binds it to 127.0.0.1 by default, so the threat model is local-user-only (which is no worse than baseline — local attackers can already read the cookie DB). Random port 9222-9321 is for collision avoidance, not security. Chrome is always killed in finally. 2. One-time Chrome version log on CDP entry via /json/version. When Chrome inevitably changes v20 key format or /json/list shape in a future major version, logs will show exactly which version users are hitting. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore: v0.18.1.0 — community wave (6 PRs + hardening) VERSION bump + users-first CHANGELOG entry for the wave: - #993 tilde-in-assignment fix (byliu-labs) - #994 browse server persists across Bash calls (joelgreen) - #996 cookie picker alive after cli exits (voidborne-d) - #864 OpenClaw skills codex-friendly (cathrynlavery) - #982 OpenCode native setup (breakneo) - #892 Windows cookie import + DPAPI + v20 CDP fallback (msr-hickory) Plus 3 follow-up hardening commits we own: - Extended tilde fix to design resolver + 4 more skill templates - Gated #994 SIGTERM-ignore to normal mode only (headed/tunnel preserve shutdown) - Documented CDP debug port security + log Chrome version on v20 fallback Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix: review pass — package.json version, import dedup, error context, stale help Findings from /review on the wave PR: - [P1] package.json version was 0.18.0.1 but VERSION is 0.18.1.0, failing test/gen-skill-docs.test.ts:177 "package.json version matches VERSION file". Bumped package.json to 0.18.1.0. - [P2] Duplicate import of cookie-picker-routes in browse/src/server.ts (handleCookiePickerRoute at line 20 + hasActivePicker at line 792). Merged into single import at top. - [P2] cookie-import-browser.ts:494 generic rethrow loses underlying error. Now preserves the message so "ENOENT" vs "JSON parse error" vs "permission denied" are distinguishable in user output. - [P3] setup:46 "Missing value for --host" error message listed an incomplete set of hosts (missing factory, openclaw, hermes, gbrain). Aligned with the "Unknown value" error on line 94. Kept as-is (not real issues): - cookie-import-browser.ts:869 empty catch on Chrome version fetch is the correct pattern for best-effort diagnostics (per slop-scan philosophy in CLAUDE.md — fire-and-forget failures shouldn't throw). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(watchdog): invert test 3 to match merged #994 behavior main #1025 added browse/test/watchdog.test.ts with test 3 expecting the old "watchdog kills server when parent dies" behavior. The merge with this branch's #994 inverted that semantic — the server now STAYS ALIVE on parent death in normal headless mode (multi-step QA across Claude Code Bash calls depends on this). Changes: - Renamed test 3 from "watchdog fires when parent dies" to "server STAYS ALIVE when parent dies (#994)". - Replaced 25s shutdown poll with 20s observation window asserting the server remains alive after the watchdog tick. - Updated docstring to document all 3 watchdog invariants (env-var disable, headed-mode disable, headless persists) and note tunnel-mode coverage gap. Verification: bun test browse/test/watchdog.test.ts → 3 pass, 0 fail (22.7s). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(ci): switch apt mirror to Hetzner to bypass Ubicloud → archive.ubuntu.com timeouts Both build attempts of `.github/docker/Dockerfile.ci` failed at `apt-get update` with persistent connection timeouts to archive.ubuntu.com:80 and security.ubuntu.com:80 — 90+ seconds of "connection timed out" against every Ubuntu IP. Not a transient blip; this PR doesn't touch the Dockerfile, and a re-run reproduced the same failure across all 9 mirror IPs. Root cause: Ubicloud runners (Hetzner FSN1-DC21 per runner output) have unreliable HTTP-port-80 routing to Ubuntu's official archive endpoints. Fix: - Rewrite /etc/apt/sources.list.d/ubuntu.sources (deb822 format in 24.04) to use https://mirror.hetzner.com/ubuntu/packages instead. Hetzner's mirror is publicly accessible from any cloud (not Hetzner-only despite the name) and route-local for Ubicloud's actual host. Solves both reliability and latency. - Add a 3-attempt retry loop around both `apt-get update` calls as belt-and-suspenders. Even Hetzner's mirror can have brief blips, and the retry costs nothing when the first attempt succeeds. Verification: the workflow will rebuild on push. Local `docker build` not practical for a 12-step image with bun + claude + playwright deps + a 10-min cold install. Trusting CI. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(ci): use HTTP for Hetzner apt mirror (base image lacks ca-certificates) Previous commit switched to https://mirror.hetzner.com/... which proved the mirror is reachable and routes correctly (no more 90s timeouts), but exposed a chicken-and-egg: ubuntu:24.04 ships without ca-certificates, and that's exactly the package we're installing. Result: "No system certificates available. Try installing ca-certificates." Fix: use http:// for the Hetzner mirror. Apt's security model verifies package integrity via GPG-signed Release files, not TLS, so HTTP here is no weaker than the upstream defaults (Ubuntu's official sources also default to HTTP for the same reason). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Cathryn Lavery <cathrynlavery@users.noreply.github.com> Co-authored-by: Joel Green <thejoelgreen@gmail.com> Co-authored-by: d 🔹 <258577966+voidborne-d@users.noreply.github.com> Co-authored-by: Break <breakneo@gmail.com> Co-authored-by: Michael Spitzer-Rubenstein <msr.ext@hickory.ai>
306 lines
11 KiB
Cheetah
306 lines
11 KiB
Cheetah
---
|
|
name: design-shotgun
|
|
preamble-tier: 2
|
|
version: 1.0.0
|
|
description: |
|
|
Design shotgun: generate multiple AI design variants, open a comparison board,
|
|
collect structured feedback, and iterate. Standalone design exploration you can
|
|
run anytime. Use when: "explore designs", "show me options", "design variants",
|
|
"visual brainstorm", or "I don't like how this looks".
|
|
Proactively suggest when the user describes a UI feature but hasn't seen
|
|
what it could look like. (gstack)
|
|
triggers:
|
|
- explore design variants
|
|
- show me design options
|
|
- visual design brainstorm
|
|
allowed-tools:
|
|
- Bash
|
|
- Read
|
|
- Glob
|
|
- Grep
|
|
- Agent
|
|
- AskUserQuestion
|
|
---
|
|
|
|
{{PREAMBLE}}
|
|
|
|
# /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.
|
|
|
|
{{DESIGN_SETUP}}
|
|
|
|
{{UX_PRINCIPLES}}
|
|
|
|
## Step 0: Session Detection
|
|
|
|
Check for prior design exploration sessions for this project:
|
|
|
|
```bash
|
|
eval "$(~/.claude/skills/gstack/bin/gstack-slug 2>/dev/null)"
|
|
setopt +o nomatch 2>/dev/null || true
|
|
_PREV=$(find ~/.gstack/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:**
|
|
|
|
```bash
|
|
cat DESIGN.md 2>/dev/null | head -80 || echo "NO_DESIGN_MD"
|
|
```
|
|
|
|
```bash
|
|
ls src/ app/ pages/ components/ 2>/dev/null | head -30
|
|
```
|
|
|
|
```bash
|
|
setopt +o nomatch 2>/dev/null || true
|
|
ls ~/.gstack/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):
|
|
|
|
```bash
|
|
curl -s -o /dev/null -w "%{http_code}" http://localhost:3000 2>/dev/null || echo "NO_LOCAL_SITE"
|
|
```
|
|
|
|
If a local site is running AND the user referenced a URL or said something like "I don't
|
|
like how this looks," screenshot the current page and use `$D evolve` instead of
|
|
`$D variants` to generate improvement variants from the existing design.
|
|
|
|
**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 prior approved designs to bias generation toward the user's demonstrated taste:
|
|
|
|
```bash
|
|
setopt +o nomatch 2>/dev/null || true
|
|
_TASTE=$(find ~/.gstack/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. Include a taste summary in the design brief:
|
|
|
|
"The user previously approved designs with these characteristics: [high contrast,
|
|
generous whitespace, modern sans-serif typography, etc.]. Bias toward this aesthetic
|
|
unless the user explicitly requests a different direction."
|
|
|
|
Limit to last 10 sessions. Try/catch JSON parse on each (skip corrupted files).
|
|
|
|
## Step 3: Generate Variants
|
|
|
|
Set up the output directory:
|
|
|
|
```bash
|
|
eval "$(~/.claude/skills/gstack/bin/gstack-slug 2>/dev/null)"
|
|
_DESIGN_DIR="$HOME/.gstack/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.
|
|
|
|
### Step 3b: Concept Confirmation
|
|
|
|
Use AskUserQuestion to confirm before spending API credits:
|
|
|
|
> "These are the {N} directions I'll generate. Each takes ~60s, but I'll run them all
|
|
> in parallel so total time is ~60 seconds regardless of count."
|
|
|
|
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
|
|
first:
|
|
|
|
```bash
|
|
$B screenshot "$_DESIGN_DIR/current.png"
|
|
```
|
|
|
|
**Launch N Agent subagents in a single message** (parallel execution). Use the Agent
|
|
tool with `subagent_type: "general-purpose"` for each variant. Each agent is independent
|
|
and handles its own generation, quality check, verification, and retry.
|
|
|
|
**Important: $D path propagation.** The `$D` variable from DESIGN SETUP is a shell
|
|
variable that agents do NOT inherit. Substitute the resolved absolute path (from the
|
|
`DESIGN_READY: /path/to/design` output in Step 0) into each agent prompt.
|
|
|
|
**Agent prompt template** (one per variant, substitute all `{...}` values):
|
|
|
|
```
|
|
Generate a design variant and save it.
|
|
|
|
Design binary: {absolute path to $D binary}
|
|
Brief: {the full variant-specific brief for this direction}
|
|
Output: /tmp/variant-{letter}.png
|
|
Final location: {_DESIGN_DIR absolute path}/variant-{letter}.png
|
|
|
|
Steps:
|
|
1. Run: {$D path} generate --brief "{brief}" --output /tmp/variant-{letter}.png
|
|
2. If the command fails with a rate limit error (429 or "rate limit"), wait 5 seconds
|
|
and retry. Up to 3 retries.
|
|
3. If the output file is missing or empty after the command succeeds, retry once.
|
|
4. Copy: cp /tmp/variant-{letter}.png {_DESIGN_DIR}/variant-{letter}.png
|
|
5. Quality check: {$D path} check --image {_DESIGN_DIR}/variant-{letter}.png --brief "{brief}"
|
|
If quality check fails, retry generation once.
|
|
6. Verify: ls -lh {_DESIGN_DIR}/variant-{letter}.png
|
|
7. Report exactly one of:
|
|
VARIANT_{letter}_DONE: {file size}
|
|
VARIANT_{letter}_FAILED: {error description}
|
|
VARIANT_{letter}_RATE_LIMITED: exhausted retries
|
|
```
|
|
|
|
For the evolve path, replace step 1 with:
|
|
```
|
|
{$D path} evolve --screenshot {_DESIGN_DIR}/current.png --brief "{brief}" --output /tmp/variant-{letter}.png
|
|
```
|
|
|
|
**Why /tmp/ then cp?** In observed sessions, `$D generate --output ~/.gstack/...`
|
|
failed with "The operation was aborted" while `--output /tmp/...` succeeded. This is
|
|
a sandbox restriction. Always generate to `/tmp/` first, then `cp`.
|
|
|
|
### Step 3d: Results
|
|
|
|
After all agents complete:
|
|
|
|
1. Read each generated PNG inline (Read tool) so the user sees all variants at once.
|
|
2. Report status: "All {N} variants generated in ~{actual time}. {successes} succeeded,
|
|
{failures} failed."
|
|
3. For any failures: report explicitly with the error. Do NOT silently skip.
|
|
4. If zero variants succeeded: fall back to sequential generation (one at a time with
|
|
`$D generate`, showing each as it lands). Tell the user: "Parallel generation failed
|
|
(likely rate limiting). Falling back to sequential..."
|
|
5. Proceed to Step 4 (comparison board).
|
|
|
|
**Dynamic image list for comparison board:** When proceeding to Step 4, construct the
|
|
image list from whatever variant files actually exist, not a hardcoded A/B/C list:
|
|
|
|
```bash
|
|
setopt +o nomatch 2>/dev/null || true # zsh compat
|
|
_IMAGES=$(ls "$_DESIGN_DIR"/variant-*.png 2>/dev/null | tr '\n' ',' | sed 's/,$//')
|
|
```
|
|
|
|
Use `$_IMAGES` in the `$D compare --images` command.
|
|
|
|
## Step 4: Comparison Board + Feedback Loop
|
|
|
|
{{DESIGN_SHOTGUN_LOOP}}
|
|
|
|
## 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).
|
|
|
|
If invoked from another skill: return the structured feedback for that skill to consume.
|
|
The calling skill reads `approved.json` and the approved variant PNG.
|
|
|
|
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. **Never save to `.context/`, `docs/designs/`, or `/tmp/`.** All design artifacts go
|
|
to `~/.gstack/projects/$SLUG/designs/`. This is enforced. 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.
|