ship-setup
Skill2 starsChanged 10 days agoMITView on GitHub
Set up where the product runs — staging and production — for people who have never deployed. Writes docs/deploy.md with a checklist per environment, does every step that needs no credentials or money (Fly.io apps, GitHub environments with production approval, deploy tokens into GitHub secrets), walks the user through the rest, and verifies each step for real. Use when the user says "setup", "infra", "configurá staging", "prepará producción", "deploy guide", "dónde lo publico", after project-new's skeleton, before the first ship-release, or when the dashboard shows an environment not ready.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- letsship/skillstheir own version, first seen Oct 25, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- letsship/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository18 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/CLAUDE.mdCLAUDE.md
- template/CLAUDE.mdCLAUDE.md
- build-storySkill
- check-bugbashSkill
- check-healthSkill
- check-securitySkill
- coordinateSkill
- harness-upgradeSkill
- keelokitSkill
- plan-backlogSkill
- plan-intakeSkill
- project-adoptSkill
- project-dashboardSkill
- project-newSkill
- project-reportSkill
- run-localSkill
- ship-releaseSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 0 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Only for projects the profile marks hosted.
- Very specific: line 24
Write (or update) docs/deploy.md, in the user's language, one section per environment, each a checklist the dashboard reads (- [x] done and …
- Very specific: line 69
Update the URLs in docs/context/environments.md, close the "staging not configured" gap if it was open, commit docs: deploy setup (<env>), …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Ship setup — environments a founder can own
Only for projects the profile marks hosted. A library, CLI or plugin isn't deployed: say so, and
point at /keelokit:ship-release, which publishes it.
The stack deploys the API to Fly.io (staging from every green main, production from a tag with
REL-1) and the web and site to any static host. Environments and owners are in
docs/context/environments.md. This skill turns that into working environments and keeps the
proof in docs/deploy.md.
Never type, print or commit a credential. The user's accounts, logins, card and third-party
API keys are theirs: give them the exact command or screen, and wait. Creating something that costs
money (a Fly app with Postgres, a paid plan, a domain) needs a clear yes first, with the price if
known. Random secrets the app itself needs (a JWT secret) can be generated in place without being
shown: fly secrets set JWT_SECRET="$(openssl rand -hex 32)" --config ….
1. The guide
Write (or update) docs/deploy.md, in the user's language, one section per environment, each a
checklist the dashboard reads (- [x] done and verified, - [ ] pending), with who owns each
step. Plain words first, the command after:
# Deploy
## staging
Where the team tries every change before users see it. Updates itself on every green main.
- [x] Fly.io account — owner: Ana · verified 2026-10-02
- [ ] Logged in on this computer — run `fly auth login` (opens the browser)
- [ ] API app and its database — `fly launch --no-deploy --config apps/api/fly.staging.toml` (about USD 5/month)
- [ ] API settings — every key of the README's API configuration block, set with `fly secrets set`
- [ ] GitHub can deploy it — a deploy token saved as the `staging` environment's `FLY_API_TOKEN`
- [ ] First deploy green, `https://<app>.fly.dev/health` answers 200
- [ ] Web app published — <static host>, pointing at the staging API
## production
Where users are. Only a tagged version gets here, and only after a person approves it.
- [ ] …the same steps with `fly.production.toml`…
- [ ] GitHub environment `production` requires a reviewer (the approval of REL-1)
- [ ] Domain and HTTPS · error reports (Sentry DSN) · database backups on2. Do what can be done
In order, stopping at the first step that needs the user; after each, tick it only once verified:
| Step | Who | How it's verified |
| Accounts (GitHub, Fly.io, static host, Sentry, domain) | user | the login below works |
gh auth login, fly auth login | user, in their terminal | gh auth status, fly auth whoami |
Fly apps + Postgres from the template's fly.*.toml | Claude, after a yes (it costs) | fly status --config … |
| App config that isn't secret, generated app secrets | Claude | fly secrets list --config … shows the names |
| Third-party keys (payments, mail, WhatsApp…) | user types them into fly secrets set | same, names only |
GitHub environments staging and production; required reviewer on production | Claude, via gh api -X PUT repos/<owner>/<repo>/environments/<env> | gh api repos/<owner>/<repo>/environments |
| Deploy tokens | Claude pipes fly tokens create deploy --config … into gh secret set FLY_API_TOKEN --env <env>, never printing it | gh secret list --env <env> |
| First deploy | CI on the next green main (staging) or /keelokit:ship-release (production) | the run is green; curl -fsS <url>/health |
| Domain, HTTPS | user at their registrar; Claude gives the exact DNS records (fly certs add) | fly certs check, curl -I https://<domain> |
| Backups, error reports | Claude enables, user owns the account | fly postgres backup list, a test event in Sentry |
A step that fails is left unticked with what went wrong and the next thing to try.
3. Close
Update the URLs in docs/context/environments.md, close the "staging not configured" gap if
it was open, commit docs: deploy setup (<env>), and refresh the dashboard: its Environments panel
shows each checklist. Report what is ready, what waits for the user and the cost per month so far.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.