Teardown
Permanently delete a project's hosted infrastructure — project, environments, database, cache — to stop all billing. Only runs when the user explicitly asks to tear down, delete, remove, shut down, or stop paying for their hosted app. Never triggers on ambient mentions. Irreversible — requires two separate typed confirmations.From its SKILL.md
npx -y skills add rifatshampod/vibeops --skill teardownAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.0 KB, 568 tokens by cl100k_base, as published. Nobody here has run it
Vibeops — Teardown
You are permanently deleting the user's hosted infrastructure. This is the most destructive action vibeops can take — there is no rollback. Treat it as always-prod-locked, regardless of which environments exist.
Required references: references/safety-rules.md Rule 1 (Destructive Blocklist) and Rule 2 (Production Lock).
This skill only runs on explicit request. "I don't need this anymore" is not enough on its own — confirm the user actually wants to tear down and delete, not just stop working on it for now.
Step 1 — Confirm intent in plain language
Before running anything, make sure the user understands what's about to happen:
"This will permanently delete [app name]'s hosting, database, and all its data. This cannot be undone. Are you sure you want to do this?"
If there's any hesitation, stop and clarify rather than proceeding.
Step 2 — Run scripts/teardown.sh
bash "${CLAUDE_PLUGIN_ROOT}/scripts/teardown.sh" .infra/config.yml
The script enforces two separate confirmation gates — relay both verbatim, never pre-confirm on the user's behalf:
- Type the app name — proves the user is targeting the right project
- Type
DELETE EVERYTHING— the final irreversible confirmation
Because the Railway CLI has no command to fully delete a project, the script then walks the user through the exact Dashboard steps (Settings → Danger Zone → Delete Project) and waits for them to type DONE after they've done it. Relay these steps exactly as the script prints them — never invent a faster CLI shortcut that doesn't exist.
Step 3 — Report outcome
Confirmed:
"Done — your project has been removed. One more thing: check your Railway billing page to make sure no further charges show up: https://railway.app/account/billing"
Cancelled at either gate:
"Cancelled — nothing was deleted."
Stopped before confirming dashboard deletion:
"Okay, I've stopped here. Your project hasn't been confirmed as deleted yet. Let me know when you're ready to finish."
What you must never do
- Never run this skill from an ambient mention — only on explicit request to tear down, delete, remove, or stop paying for hosting
- Never skip either confirmation gate
- Never claim deletion succeeded without the user confirming they completed the Dashboard step
- Never fabricate a one-shot CLI delete command — Railway doesn't expose one; always route to honest Dashboard guidance
- Never treat "dev only, no prod" as lower-risk — teardown is irreversible regardless of environment
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most competitive analysis skills give in 568 tokens
Counted across 117 of the 155 authors here whose files we hold, read 2026-09-06
- Identify direct, indirect, and future competitorsin 12 of 117, across 10 files
- Build a feature comparison matrixin 10 of 117
- Cite every number with source and datein 8 of 117, across 4 files
- Track eight dimensions per competitorin 6 of 117, across 4 files
- Produce one-page battlecards for salesin 6 of 117, across 4 files
- Categorize each competitor as direct, adjacent, or substitutein 6 of 117, across 5 files
- Recommend analyzing three to five competitorsin 6 of 117, across 5 files
- Update the threat matrix quarterlyin 5 of 117, across 3 files
- Scope requirements with ask_user_question before any researchin 5 of 117, across 1 file
- Get outline approval before creating any slidesin 5 of 117, across 1 file
- Use source-file values exactly as givenin 5 of 117, across 1 file
- Match user-specified titles, chart types, and values verbatimin 5 of 117, across 1 file
Said here and by no other author read
- Read the required safety rules first
- Confirm the user truly wants teardown before running anything
- State what will be permanently deleted and ask confirmation
- Stop and clarify if the user hesitates
- Treat teardown as always production-locked
- Relay both confirmation gates verbatim
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.