_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_PROACTIVE=$(~/.claude/skills/gstack/bin/gstack-config get proactive 2>/dev/null || echo "true")
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"
echo "PROACTIVE: $_PROACTIVE"
_LAKE_SEEN=$([ -f ~/.gstack/.completeness-intro-seen ] && echo "yes" || echo "no")
echo "LAKE_INTRO: $_LAKE_SEEN"
_TEL=$(~/.claude/skills/gstack/bin/gstack-config get telemetry 2>/dev/null || true)
_TEL_PROMPTED=$([ -f ~/.gstack/.telemetry-prompted ] && echo "yes" || echo "no")
_TEL_START=$(date +%s)
_SESSION_ID="$$-$(date +%s)"
echo "TELEMETRY: ${_TEL:-off}"
echo "TEL_PROMPTED: $_TEL_PROMPTED"
mkdir -p ~/.gstack/analytics
echo '{"skill":"setup-deploy","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","repo":"'$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown")'"}'  >> ~/.gstack/analytics/skill-usage.jsonl 2>/dev/null || true
for _PF in ~/.gstack/analytics/.pending-*; do [ -f "$_PF" ] && ~/.claude/skills/gstack/bin/gstack-telemetry-log --event-type skill_run --skill _pending_finalize --outcome unknown --session-id "$_SESSION_ID" 2>/dev/null || true; break; done

PROACTIVE

"false"

UPGRADE_AVAILABLE <old> <new>

~/.claude/skills/gstack/gstack-upgrade/SKILL.md

JUST_UPGRADED <from> <to>

LAKE_INTRO

no

open https://garryslist.org/posts/boil-the-ocean
touch ~/.gstack/.completeness-intro-seen

open

touch

TEL_PROMPTED

no

LAKE_INTRO

yes

Help gstack get better! Community mode shares usage data (which skills you use, how long they take, crash info) with a stable device ID so we can track trends and fix bugs faster. No code, file paths, or repo names are ever sent. Change anytime with

gstack-config set telemetry off

.

• A) Help gstack get better! (recommended)
• B) No thanks

~/.claude/skills/gstack/bin/gstack-config set telemetry community

How about anonymous mode? We just learn that someone used gstack — no unique ID, no way to connect sessions. Just a counter that helps us know if anyone's out there.

• A) Sure, anonymous is fine
• B) No thanks, fully off

~/.claude/skills/gstack/bin/gstack-config set telemetry anonymous

~/.claude/skills/gstack/bin/gstack-config set telemetry off

touch ~/.gstack/.telemetry-prompted

TEL_PROMPTED

yes

1. Re-ground: State the project, the current branch (use the

   _BRANCH

   value printed by the preamble — NOT any branch from conversation history or gitStatus), and the current plan/task. (1-2 sentences)
2. Simplify: Explain the problem in plain English a smart 16-year-old could follow. No raw function names, no internal jargon, no implementation details. Use concrete examples and analogies. Say what it DOES, not what it's called.
3. Recommend:

   RECOMMENDATION: Choose [X] because [one-line reason]

   — always prefer the complete option over shortcuts (see Completeness Principle). Include

   Completeness: X/10

   for each option. Calibration: 10 = complete implementation (all edge cases, full coverage), 7 = covers happy path but skips some edges, 3 = shortcut that defers significant work. If both options are 8+, pick the higher; if one is ≤5, flag it.
4. Options: Lettered options:

   A) ... B) ... C) ...

   — when an option involves effort, show both scales:

   (human: ~X / CC: ~Y)

• If Option A is the complete implementation (full parity, all edge cases, 100% coverage) and Option B is a shortcut that saves modest effort — always recommend A. The delta between 80 lines and 150 lines is meaningless with CC+gstack. "Good enough" is the wrong instinct when "complete" costs minutes more.
• Lake vs. ocean: A "lake" is boilable — 100% test coverage for a module, full feature implementation, handling all edge cases, complete error paths. An "ocean" is not — rewriting an entire system from scratch, adding features to dependencies you don't control, multi-quarter platform migrations. Recommend boiling lakes. Flag oceans as out of scope.
• When estimating effort, always show both scales: human team time and CC+gstack time. The compression ratio varies by task type — use this reference:

• This principle applies to test coverage, error handling, documentation, edge cases, and feature completeness. Don't skip the last 10% to "save time" — with AI, that 10% costs seconds.

• BAD: "Choose B — it covers 90% of the value with less code." (If A is only 70 lines more, choose A.)
• BAD: "We can skip edge case handling to save time." (Edge case handling costs minutes with CC.)
• BAD: "Let's defer test coverage to a follow-up PR." (Tests are the cheapest lake to boil.)
• BAD: Quoting only human-team effort: "This would take 2 weeks." (Say: "2 weeks human / ~1 hour CC.")

~/.claude/skills/gstack/ETHOS.md

• Layer 1 (tried and true — in distribution). Don't reinvent the wheel. But the cost of checking is near-zero, and once in a while, questioning the tried-and-true is where brilliance occurs.
• Layer 2 (new and popular — search for these). But scrutinize: humans are subject to mania. Search results are inputs to your thinking, not answers.
• Layer 3 (first principles — prize these above all). Original observations derived from reasoning about the specific problem. The most valuable of all.

jq -n --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --arg skill "SKILL_NAME" --arg branch "$(git branch --show-current 2>/dev/null)" --arg insight "ONE_LINE_SUMMARY" '{ts:$ts,skill:$skill,branch:$branch,insight:$insight}' >> ~/.gstack/analytics/eureka.jsonl 2>/dev/null || true

1. {step}

• DONE — All steps completed successfully. Evidence provided for each claim.
• DONE_WITH_CONCERNS — Completed, but with issues the user should know about. List each concern.
• BLOCKED — Cannot proceed. State what is blocking and what was tried.
• NEEDS_CONTEXT — Missing information required to continue. State exactly what you need.

• If you have attempted a task 3 times without success, STOP and escalate.
• If you are uncertain about a security-sensitive change, STOP and escalate.
• If the scope of work exceeds what you can verify, STOP and escalate.

STATUS: BLOCKED | NEEDS_CONTEXT
REASON: [1-2 sentences]
ATTEMPTED: [what you tried]
RECOMMENDATION: [what the user should do next]

grep -A 20 "## Deploy Configuration" CLAUDE.md 2>/dev/null || echo "NO_CONFIG"

• Context: Deploy configuration already exists in CLAUDE.md.
• RECOMMENDATION: Choose A to update if your setup changed.
• A) Reconfigure from scratch (overwrite existing)
• B) Edit specific fields (show current config, let me change one thing)
• C) Done — configuration looks correct

fly.toml

1. Extract app name:

   grep -m1 "^app" fly.toml | sed 's/app = "\(.*\)"/\1/'

2. Check if

   fly

   CLI is installed:

   which fly 2>/dev/null

3. If installed, verify:

   fly status --app {app} 2>/dev/null

4. Infer URL:

   https://{app}.fly.dev

5. Set deploy status command:

   fly status --app {app}

6. Set health check:

   https://{app}.fly.dev

   (or

   /health

   if the app has one)

render.yaml

1. Extract service name and type from render.yaml
2. Check for Render API key:

   echo $RENDER_API_KEY | head -c 4

   (don't expose the full key)
3. Infer URL:

   https://{service-name}.onrender.com

4. Render deploys automatically on push to the connected branch — no deploy workflow needed
5. Set health check: the inferred URL

1. Check for

   vercel

   CLI:

   which vercel 2>/dev/null

2. If installed:

   vercel ls --prod 2>/dev/null | head -3

3. Vercel deploys automatically on push — preview on PR, production on merge to main
4. Set health check: the production URL from vercel project settings

1. Extract site info from netlify.toml
2. Netlify deploys automatically on push
3. Set health check: the production URL

1. Read the workflow file to understand what it does
2. Extract the deploy target (if mentioned)
3. Ask the user for the production URL

1. How are deploys triggered?
   • A) Automatically on push to main (Fly, Render, Vercel, Netlify, etc.)
   • B) Via GitHub Actions workflow
   • C) Via a deploy script or CLI command (describe it)
   • D) Manually (SSH, dashboard, etc.)
   • E) This project doesn't deploy (library, CLI, tool)
2. What's the production URL? (Free text — the URL where the app runs)
3. How can gstack check if a deploy succeeded?
   • A) HTTP health check at a specific URL (e.g., /health, /api/status)
   • B) CLI command (e.g.,

     fly status

     ,

     kubectl rollout status

     )
   • C) Check the GitHub Actions workflow status
   • D) No automated way — just check the URL loads
4. Any pre-merge or post-merge hooks?
   • Commands to run before merging (e.g.,

     bun run build

     )
   • Commands to run after merge but before deploy verification

• Platform: {platform}
• Production URL: {url}
• Deploy workflow: {workflow file or "auto-deploy on push"}
• Deploy status command: {command or "HTTP health check"}
• Merge method: {squash/merge/rebase}
• Project type: {web app / API / CLI / library}
• Post-deploy health check: {health check URL or command}

• Pre-merge: {command or "none"}
• Deploy trigger: {command or "automatic on push to main"}
• Deploy status: {command or "poll production URL"}
• Health check: {URL or command}

undefined

1. If a health check URL was configured, try it:

curl -sf "{health-check-url}" -o /dev/null -w "%{http_code}" 2>/dev/null || echo "UNREACHABLE"

1. If a deploy status command was configured, try it:

{deploy-status-command} 2>/dev/null | head -5 || echo "COMMAND_FAILED"

• Never expose secrets. Don't print full API keys, tokens, or passwords.
• Confirm with the user. Always show the detected config and ask for confirmation before writing.
• CLAUDE.md is the source of truth. All configuration lives there — not in a separate config file.
• Idempotent. Running /setup-deploy multiple times overwrites the previous config cleanly.
• Platform CLIs are optional. If

  fly

  or

  vercel

  CLI isn't installed, fall back to URL-based health checks.