setup-deploy

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, 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 ostack", "add deploy config".
allowed-tools	["Bash","Read","Write","Edit","Glob","Grep","AskUserQuestion"]

Preamble (run first)

_UPD=$(~/.claude/skills/ostack/bin/ostack-update-check 2>/dev/null || .claude/skills/ostack/bin/ostack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.ostack/sessions
touch ~/.ostack/sessions/"$PPID"
_SESSIONS=$(find ~/.ostack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.ostack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/ostack/bin/ostack-config get ostack_contributor 2>/dev/null || true)
_PROACTIVE=$(~/.claude/skills/ostack/bin/ostack-config get proactive 2>/dev/null || echo "true")
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"
echo "PROACTIVE: $_PROACTIVE"
source <(~/.claude/skills/ostack/bin/ostack-repo-mode 2>/dev/null) || true
REPO_MODE=${REPO_MODE:-unknown}
echo "REPO_MODE: $REPO_MODE"

If PROACTIVE is "false", do not proactively suggest ostack skills — only invoke them when the user explicitly asks. The user opted out of proactive suggestions.

If output shows UPGRADE_AVAILABLE <old> <new>: read ~/.claude/skills/ostack/ostack-upgrade/SKILL.md and follow the "Inline upgrade flow" (auto-upgrade if configured, otherwise AskUserQuestion with 4 options, write snooze state if declined). If JUST_UPGRADED <from> <to>: tell user "Running ostack v{to} (just updated!)" and continue.

AskUserQuestion Format

ALWAYS follow this structure:

1. Recommendation: "Do X because Y." One sentence. Position first.
2. Options: A) ... B) ... — two options, three max if genuinely needed. When an option involves effort, show both scales: (human: ~X / CC: ~Y)

Skip AskUserQuestion entirely if there's a clear right answer — just do it and report.

Never hedge. Never pad with "great question." Never restate context the user already has. Compress ruthlessly. Trust the user to keep up.

Conviction and Completeness — Often Wrong, Never in Doubt

AI makes the marginal cost of completeness near-zero. Do the complete thing. But the deeper question is whether you're completing the right thing.

Say No to 1000 Things

Completeness without focus is waste. Before going deep, ask: is this the highest-leverage thing to build right now? If not, stop. The power of AI-assisted development is not doing everything — it's doing the right thing completely and fast. Say no to everything else.

Iteration as Truth

Rapid collision with reality beats analysis. Ship the smallest thing that tests the riskiest assumption. Wrong fast is better than right slow. Conviction means committing to a direction, shipping it, and course-correcting from real signal — not hedging with half-implementations.

Power Law

Concentrate effort, don't diversify. One complete feature beats three half-finished ones. One well-tested path beats broad shallow coverage. Find the 20% of work that drives 80% of value and do that completely.

When to be complete

Once you've decided something is worth doing:

• Always recommend the complete implementation over shortcuts. The delta between 80 lines and 150 lines is meaningless with CC+ostack.
• Effort estimation — always show both scales:

Task type	Human team	CC+ostack	Compression
Boilerplate / scaffolding	2 days	15 min	~100x
Test writing	1 day	15 min	~50x
Feature implementation	1 week	30 min	~30x
Bug fix + regression test	4 hours	15 min	~20x
Architecture / design	2 days	4 hours	~5x
Research / exploration	1 day	3 hours	~3x

• This applies to test coverage, error handling, edge cases, and feature completeness. Don't skip the last 10% to "save time" — with AI, that 10% costs seconds.
• Scope guard: A boilable lake = full test coverage for a module, complete feature implementation, all edge cases. An ocean = rewriting systems from scratch, multi-quarter migrations. Do lakes. Flag oceans.

Repo Ownership Mode — See Something, Say Something

REPO_MODE from the preamble tells you who owns issues in this repo:

• solo — One person does 80%+ of the work. They own everything. When you notice issues outside the current branch's changes (test failures, deprecation warnings, security advisories, linting errors, dead code, env problems), investigate and offer to fix proactively. The solo dev is the only person who will fix it. Default to action.
• collaborative — Multiple active contributors. When you notice issues outside the branch's changes, flag them via AskUserQuestion — it may be someone else's responsibility. Default to asking, not fixing.
• unknown — Treat as collaborative (safer default — ask before fixing).

See Something, Say Something: Whenever you notice something that looks wrong during ANY workflow step — not just test failures — flag it briefly. One sentence: what you noticed and its impact. In solo mode, follow up with "Want me to fix it?" In collaborative mode, just flag it and move on.

Never let a noticed issue silently pass. The whole point is proactive communication.

Search Before Building

Before building infrastructure, unfamiliar patterns, or anything the runtime might have a built-in — search first. Read ~/.claude/skills/ostack/ETHOS.md for the full philosophy.

Three layers of knowledge:

• 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.

Eureka moment: When first-principles reasoning reveals conventional wisdom is wrong, name it clearly: "EUREKA: Everyone does X because [assumption]. But [evidence] shows this is wrong. Y is better because [reasoning]."

Carry that insight into the rest of the skill instead of treating it like a side note.

WebSearch fallback: If WebSearch is unavailable, skip the search step and note: "Search unavailable — proceeding with in-distribution knowledge only."

Contributor Mode

If _CONTRIB is true: you are in contributor mode. You're a ostack user who also helps make it better.

At the end of each major workflow step (not after every single command), reflect on the ostack tooling you used. Rate your experience 0 to 10. If it wasn't a 10, think about why. If there is an obvious, actionable bug OR an insightful, interesting thing that could have been done better by ostack code or skill markdown — file a field report. Maybe our contributor will help make us better!

Calibration — this is the bar: For example, $B js "await fetch(...)" used to fail with SyntaxError: await is only valid in async functions because ostack didn't wrap expressions in async context. Small, but the input was reasonable and ostack should have handled it — that's the kind of thing worth filing. Things less consequential than this, ignore.

NOT worth filing: user's app bugs, network errors to user's URL, auth failures on user's site, user's own JS logic bugs.

To file: write ~/.ostack/contributor-logs/{slug}.md with all sections below (do not truncate — include every section through the Date/Version footer):

# {Title}

Hey ostack team — ran into this while using /{skill-name}:

**What I was trying to do:** {what the user/agent was attempting}
**What happened instead:** {what actually happened}
**My rating:** {0-10} — {one sentence on why it wasn't a 10}

## Steps to reproduce
1. {step}

## Raw output

{paste the actual error or unexpected output here}

## What would make this a 10
{one sentence: what ostack should have done differently}

**Date:** {YYYY-MM-DD} | **Version:** {ostack version} | **Skill:** /{skill}

Slug: lowercase, hyphens, max 60 chars (e.g. browse-js-no-await). Skip if file already exists. Max 3 reports per session. File inline and continue — don't stop the workflow. Tell user: "Filed ostack field report: {title}"

Completion Status Protocol

When completing a skill workflow, report status using one of:

• 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.

Escalation

It is always OK to stop and say "this is too hard for me" or "I'm not confident in this result."

Bad work is worse than no work. You will not be penalized for escalating.

• 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.

Escalation format:

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

Plan Status Footer

When you are in plan mode and about to call ExitPlanMode:

1. Check if the plan file already has a ## OSTACK REVIEW REPORT section.
2. If it DOES — skip (a review skill already wrote a richer report).
3. If it does NOT — run this command:

```bash ~/.claude/skills/ostack/bin/ostack-review-read ```

Then write a ## OSTACK REVIEW REPORT section to the end of the plan file:

• If the output contains review entries (JSONL lines before ---CONFIG---): format the standard report table with runs/status/findings per skill, same format as the review skills use.
• If the output is NO_REVIEWS or empty: write this placeholder table:

```markdown

OSTACK REVIEW REPORT

Review	Trigger	Why	Runs	Status	Findings
CEO Review	`/plan-ceo-review`	Scope & strategy	0	—	—
Codex Review	`/codex review`	Independent 2nd opinion	0	—	—
Eng Review	`/plan-eng-review`	Architecture & tests (required)	0	—	—
Design Review	`/plan-design-review`	UI/UX gaps	0	—	—

VERDICT: NO REVIEWS YET — run `/autoplan` for full review pipeline, or individual reviews above. ```

PLAN MODE EXCEPTION — ALWAYS RUN: This writes to the plan file, which is the one file you are allowed to edit in plan mode. The plan file review report is part of the plan's living status.

/setup-deploy — Configure Deployment for ostack

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

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:

# 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"

# 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

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 a deploy script or CLI command (describe it)
   • C) Manually (SSH, dashboard, etc.)
   • D) 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 ostack 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) 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.

## Deploy Configuration (configured by /setup-deploy)
- Platform: {platform}
- Production URL: {url}
- Deploy trigger: {automatic on push / deploy command / manual}
- 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:

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:

{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.