deploy-watch-setup

name

deploy-watch-setup

description

Creates a project-scoped deploy-status check for the deploy-watch monitor, tailored to a project's own package scripts, internal commands, deployment wrappers, or custom deploy tooling. Use when setting up or configuring deploy tracking for a project, when provider auto-detect (GitHub Actions, Fly, Vercel) cannot read the deploy stack, or when the user says "set up deploy watching", "scope deploy-watch", or "make deploy-watch work with my deploy".

deploy-watch-setup

Build a project-scoped deploy-status check so the deploy-watch monitor reports accurately for this project's deploy tooling — including internal or custom stacks that provider auto-detect (GitHub Actions, Fly, Vercel) cannot read.

The output is one trackable file, .claude/deploy-status.sh, that deploy-watch auto-detects and prefers over provider guessing. No plugin config changes. Commit it only when the user agrees.

The contract

On a successful status query, .claude/deploy-status.sh MUST print exactly one stdout line, nothing else on stdout:

deploy-status: succeeded
deploy-status: failed
deploy-status: in-progress

One canonical stdout line means deploy-watch's default patterns classify it exactly, and no unrelated output can cause a false match. If the status query itself fails (auth, network, missing tool), the script exits non-zero with no stdout. A short diagnostic on stderr is acceptable; deploy-watch captures it and reports the tooling failure, not a fake deploy result.

Workflow

Copy this checklist and track progress:

- [ ] 1. Survey deploy entrypoints, package scripts, and provider/internal clues
- [ ] 2. Interview the user (status query, signal, environment)
- [ ] 3. Generate .claude/deploy-status.sh from the template
- [ ] 4. Make it executable, run syntax + contract checks, confirm the line
- [ ] 5. Explain the wiring (auto-detected; no config)
- [ ] 6. Offer to commit (handle .claude/ being gitignored)

1. Survey. Detect the deploy surface from package manifests and scripts (package.json, pyproject.toml, workspace files), CI config, Dockerfile, k8s/helm manifests, Makefile/justfile targets, and documented internal packages or CLIs. Report what you found, then ask — do not assume a known provider.

2. Interview. Ask the questions in references/interview.md, one topic at a time. Read that file before starting.

3. Generate from assets/deploy-status.template.sh: adapt the marked regions to the user's answers, holding the contract above. The generated script MUST be macOS/BSD-safe — see references/portability.md.

4. Verify. mkdir -p .claude, chmod +x .claude/deploy-status.sh, and run bash -n on it. Run it once, show the user the single stdout line it printed, confirm it matches the deploy's real state, and verify the line is one of the three canonical states. If the status query fails, confirm stdout is empty and stderr explains the tooling failure.

5. Wiring. Nothing to configure — deploy-watch auto-detects the script and prefers it. /app-deploy now drives this scoped watcher.

6. Commit. .claude/ is often gitignored. If git check-ignore .claude/deploy-status.sh matches, add a negation to the project .gitignore so the file is trackable. Commit only when the user asks or agrees:

   !/.claude/deploy-status.sh