Made by@slashcloneDocument how your app is deployed
@slashclone/deploy-guide
Write a deploy guide so anyone on your team can ship a release, see what is live, and roll back. It reads your repo and fills docs/DEPLOY.md with hosts and domains, env var names per environment, first-time setup, the release pipeline, rollback steps, and a dev versus production differences table. Asks what it cannot see and never records secret values.
SkillDevOpsv0.1.0
- Activity
- New: be the first to try it
- Installs
- 0 installs
- Likes
- 0 likes
- Clones
- 0 clones
- 1---
- 2name: deploy-guide
- 3description: Write or update docs/DEPLOY.md, the one page that says where an app runs, how it gets there, how to tell what is live, and how to undo a bad release. Use when someone asks for a deploy guide, wants to document their release process, or changes hosting, env vars, or the pipeline.
- 4---
- 6# Deploy guide
- 8Goal: one page, `docs/DEPLOY.md`, that a new teammate (or an agent) can follow to understand where the app runs, ship a release, check what is live, and roll back. Keep it true: update it in the same change that alters hosting, env vars, or the pipeline.
- 10## Before you write
- 121. Read what exists: `docs/DEPLOY.md` if present, the README, CI and release workflows, host config files (for example a `Dockerfile` or a platform's `*.toml` or `*.json`), every `.env.example`, and the package scripts.
- 132. Search the code for environment checks (`NODE_ENV`, `process.env.`, `os.environ`, "production", "development") to find where dev and production differ.
- 143. Ask the person for anything the repo cannot show: which hosts and domains they use, who can run a release, and how rollback works on their host. Do not guess hosts or domains.
- 154. If a guide already exists, keep its structure and wording where it is still true. Change only what is stale or missing, and show the diff.
- 17## Sections
- 19Write these, in this order. Skip a section only when it truly does not apply, and say so in one line.
- 211. **Overview table.** Each service: where its code lives, where it runs, and its public URL. One line on how the services talk to each other.
- 222. **Domains.** Which domain serves what, where DNS is managed, and any redirects. Use the real domains the person gives you; never invent them.
- 233. **Environment variables.** One table per service: name, what it is for, which environments need it (dev, preview or staging, production), and where to get it. Names only. Never write a value, even a sample that looks real. Point to `.env.example` as the source of truth and keep it in sync.
- 244. **First-time setup.** Numbered steps to stand the app up from nothing: accounts, projects, databases, storage, DNS, secrets (with the command to set each one, where the person types the value themselves), and a final check that it works.
- 255. **How work reaches main.** Branches, pull requests, which checks must pass before merge, and whether merging ships or a separate release does.
- 266. **Release pipeline.** A short summary, not the workflow file: what starts a release, the steps (for example pick the commit, migrate, deploy, smoke test, roll back on failure), which secrets it needs (names only), and the one command or button that starts it. Note that migrations must stay compatible with the code already running.
- 277. **What production runs.** How to find the exact commit live right now, and how to list what is merged but not released. Prefer a record the pipeline writes (a deployment record, a tag, or a version endpoint) over guessing from the last workflow run. Include the commands, for example `git log --oneline <live-commit>..origin/main`.
- 288. **Rollback.** For each service, the fastest safe way back to the last good release, and what a rollback does not undo (database migrations, sent emails, queued jobs).
- 299. **Dev and production differences.** A table: where in the code, what dev does, what production does, and why. Every row should be a deliberate choice. If you find an undocumented difference, list it and ask whether to keep it (and document it) or remove it.
- 31## Rules
- 33- Never write secrets, tokens, account ids, or personal emails into the guide. Names of env vars and secrets are fine.
- 34- Prefer settings that behave the same everywhere (an env flag) over code that checks which environment it is in. When you see the second kind, suggest the first.
- 35- Plain, short sentences. Commands in code blocks, ready to paste.
- 36- Date decisions that might change ("Decided 2026-01-15: releases run on demand") so readers know how fresh they are.
- 37- Write only `docs/DEPLOY.md`. If `.env.example` or other files are out of date, list the fixes and let the person make them or approve them.
- 38- End by listing anything you could not confirm, so the person can fill the gaps.