mirror of
https://github.com/garrytan/gstack.git
synced 2026-06-04 00:58:04 +02:00
feat: /setup-deploy skill + platform-specific deploy verification
- New /setup-deploy skill: interactive guided setup for deploy configuration.
Detects Fly.io, Render, Vercel, Netlify, Heroku, Railway, GitHub Actions,
and custom deploy scripts. Writes config to CLAUDE.md with custom hooks
section for non-standard setups.
- Enhanced deploy bootstrap: platform-specific URL resolution (fly.toml app
→ {app}.fly.dev, render.yaml → {service}.onrender.com, etc.), deploy
status commands (fly status, heroku releases), and custom deploy hooks
section in CLAUDE.md for manual/scripted deploys.
- Platform-specific deploy verification in /land-and-deploy Step 6:
Strategy A (GitHub Actions polling), Strategy B (platform CLI: fly/render/heroku),
Strategy C (auto-deploy: vercel/netlify), Strategy D (custom hooks from CLAUDE.md).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,220 @@
|
||||
---
|
||||
name: setup-deploy
|
||||
version: 1.0.0
|
||||
description: |
|
||||
Configure deployment settings for /land-and-deploy. Detects your deploy
|
||||
platform (Fly.io, Render, Vercel, Netlify, Heroku, GitHub Actions, custom),
|
||||
production URL, health check endpoints, and deploy status commands. Writes
|
||||
the configuration to CLAUDE.md so all future deploys are automatic.
|
||||
Use when: "setup deploy", "configure deployment", "set up land-and-deploy",
|
||||
"how do I deploy with gstack", "add deploy config".
|
||||
allowed-tools:
|
||||
- Bash
|
||||
- Read
|
||||
- Write
|
||||
- Edit
|
||||
- Glob
|
||||
- Grep
|
||||
- AskUserQuestion
|
||||
---
|
||||
|
||||
{{PREAMBLE}}
|
||||
|
||||
# /setup-deploy — Configure Deployment for gstack
|
||||
|
||||
You are helping the user configure their deployment so `/land-and-deploy` works
|
||||
automatically. Your job is to detect the deploy platform, production URL, health
|
||||
checks, and deploy status commands — then persist everything to CLAUDE.md.
|
||||
|
||||
After this runs once, `/land-and-deploy` reads CLAUDE.md and skips detection entirely.
|
||||
|
||||
## User-invocable
|
||||
When the user types `/setup-deploy`, run this skill.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Check existing configuration
|
||||
|
||||
```bash
|
||||
grep -A 20 "## Deploy Configuration" CLAUDE.md 2>/dev/null || echo "NO_CONFIG"
|
||||
```
|
||||
|
||||
If configuration already exists, show it and ask:
|
||||
|
||||
- **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
|
||||
|
||||
If the user picks C, stop.
|
||||
|
||||
### Step 2: Detect platform
|
||||
|
||||
Run the platform detection from the deploy bootstrap:
|
||||
|
||||
```bash
|
||||
# Platform config files
|
||||
[ -f fly.toml ] && echo "PLATFORM:fly" && cat fly.toml
|
||||
[ -f render.yaml ] && echo "PLATFORM:render" && cat render.yaml
|
||||
[ -f vercel.json ] || [ -d .vercel ] && echo "PLATFORM:vercel"
|
||||
[ -f netlify.toml ] && echo "PLATFORM:netlify" && cat netlify.toml
|
||||
[ -f Procfile ] && echo "PLATFORM:heroku"
|
||||
[ -f railway.json ] || [ -f railway.toml ] && echo "PLATFORM:railway"
|
||||
|
||||
# GitHub Actions deploy workflows
|
||||
for f in .github/workflows/*.yml .github/workflows/*.yaml; do
|
||||
[ -f "$f" ] && grep -qiE "deploy|release|production|staging|cd" "$f" 2>/dev/null && echo "DEPLOY_WORKFLOW:$f"
|
||||
done
|
||||
|
||||
# Project type
|
||||
[ -f package.json ] && grep -q '"bin"' package.json 2>/dev/null && echo "PROJECT_TYPE:cli"
|
||||
ls *.gemspec 2>/dev/null && echo "PROJECT_TYPE:library"
|
||||
```
|
||||
|
||||
### Step 3: Platform-specific setup
|
||||
|
||||
Based on what was detected, guide the user through platform-specific configuration.
|
||||
|
||||
#### Fly.io
|
||||
|
||||
If `fly.toml` detected:
|
||||
|
||||
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)
|
||||
|
||||
Ask the user to confirm the production URL. Some Fly apps use custom domains.
|
||||
|
||||
#### Render
|
||||
|
||||
If `render.yaml` detected:
|
||||
|
||||
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
|
||||
|
||||
Ask the user to confirm. Render uses auto-deploy from the connected git branch — after
|
||||
merge to main, Render picks it up automatically. The "deploy wait" in /land-and-deploy
|
||||
should poll the Render URL until it responds with the new version.
|
||||
|
||||
#### Vercel
|
||||
|
||||
If vercel.json or .vercel detected:
|
||||
|
||||
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
|
||||
|
||||
#### Netlify
|
||||
|
||||
If netlify.toml detected:
|
||||
|
||||
1. Extract site info from netlify.toml
|
||||
2. Netlify deploys automatically on push
|
||||
3. Set health check: the production URL
|
||||
|
||||
#### GitHub Actions only
|
||||
|
||||
If deploy workflows detected but no platform config:
|
||||
|
||||
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
|
||||
|
||||
#### Custom / Manual
|
||||
|
||||
If nothing detected:
|
||||
|
||||
Use AskUserQuestion to gather the information:
|
||||
|
||||
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
|
||||
|
||||
### Step 4: Write configuration
|
||||
|
||||
Read CLAUDE.md (or create it). Find and replace the `## Deploy Configuration` section
|
||||
if it exists, or append it at the end.
|
||||
|
||||
```markdown
|
||||
## Deploy Configuration (configured by /setup-deploy)
|
||||
- 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}
|
||||
|
||||
### Custom deploy hooks
|
||||
- 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}
|
||||
```
|
||||
|
||||
### Step 5: Verify
|
||||
|
||||
After writing, verify the configuration works:
|
||||
|
||||
1. If a health check URL was configured, try it:
|
||||
```bash
|
||||
curl -sf "{health-check-url}" -o /dev/null -w "%{http_code}" 2>/dev/null || echo "UNREACHABLE"
|
||||
```
|
||||
|
||||
2. If a deploy status command was configured, try it:
|
||||
```bash
|
||||
{deploy-status-command} 2>/dev/null | head -5 || echo "COMMAND_FAILED"
|
||||
```
|
||||
|
||||
Report results. If anything failed, note it but don't block — the config is still
|
||||
useful even if the health check is temporarily unreachable.
|
||||
|
||||
### Step 6: Summary
|
||||
|
||||
```
|
||||
DEPLOY CONFIGURATION — COMPLETE
|
||||
════════════════════════════════
|
||||
Platform: {platform}
|
||||
URL: {url}
|
||||
Health check: {health check}
|
||||
Status cmd: {status command}
|
||||
Merge method: {merge method}
|
||||
|
||||
Saved to CLAUDE.md. /land-and-deploy will use these settings automatically.
|
||||
|
||||
Next steps:
|
||||
- Run /land-and-deploy to merge and deploy your current PR
|
||||
- Edit the "## Deploy Configuration" section in CLAUDE.md to change settings
|
||||
- Run /setup-deploy again to reconfigure
|
||||
```
|
||||
|
||||
## Important Rules
|
||||
|
||||
- **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.
|
||||
Reference in New Issue
Block a user