hyperflow-deploy

What it does and when to use it

Hyperflow ship phase. Use when the user is ready to release — verbs like ship, push, release, deploy, "cut a release", "ready to push". Runs pre-push gates (lint + typecheck + build + tests + security sweep), then asks before pushing. Never --no-verify, never force-push to main.

Triggers from the description

How it works

1. Steps
2. Hard rules

---
name: hyperflow-deploy
description: Hyperflow ship phase. Use when the user is ready to release — verbs like ship, push, release, deploy, "cut a release", "ready to push". Runs pre-push gates (lint + typecheck + build + tests + security sweep), then asks before pushing. Never --no-verify, never force-push to main.
---

# hyperflow-deploy — ship phase (Antigravity single-agent)

Gate, then ship. Follow the `hyperflow` doctrine. Pushing is always an explicit, confirmed step.

## Steps

1. **Pre-push gates** — run in order, fix or halt on failure:
   - lint · typecheck · build · tests · a quick security sweep (no secrets in the diff, no blocked files committed).
2. **Report** the gate results in one short block (pass/fail per gate).
3. **Push gate** via AskUserQuestion — binary `Push / Hold` (no recommended marker). State the branch, ahead/behind vs the remote, and any caveat (e.g. red gate from someone else's files).
4. On **Push**: `git push` the branch (never `--force` to `main`/`master`). On **Hold**: leave commits local and say so.

## Hard rules

- **Never** `git push --no-verify`. If a pre-push hook fails — even on files you don't own — surface it and hold; do not bypass.
- **Never** force-push to `main`/`master`.
- If a gate is red because of a concurrent session's uncommitted/untracked files, report that the push is held on external failure — your commits stay clean and local until the tree is green.

Versions

The database has no other skills named hyperflow-deploy.

Database snapshot: 13.11.2026 · package version 161c87b6fea7 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

• 100deploy
  Use when ready to ship — runs pre-push gates (lint, typecheck, build, tests, security sweep), commits, releases, and pushes. Standalone, never auto-invoked. Push always requires explicit confirmation. Trigger with /hyperflow:deploy, "ship it", "ready to push", "release", "cut a release", "deploy".
• 100deploy
  Use when the user says "ship it", "ready to push", "release", "deploy", or wants pre-push gates (lint, typecheck, build, tests) plus commit/release/push in one flow. Standalone — never auto-invoked; push always requires explicit confirmation.
• 90hyperflow-dispatch
  Hyperflow execution phase. Use when a task file exists in .hyperflow/tasks/ and the work needs building — verbs like build, implement, add, refactor, "wire up", "run the plan", "execute the task". Works batches sequentially with self-review and per-task commits. In Antigravity…
• 100ci-before-push
  Run Make It Ezy's GitHub CI gates locally before any git push or PR update. Use whenever the user asks to push, open/update a PR, merge to main, or "check CI" / "run gates" / "before push" on this repo — even if they did not name this skill. Do not push until check:ci is green.
• 100ship
  Take a completed phase to production - verify the readiness gates, then release. Use when the user wants to deploy, ship, release, cut a version, go live, or asks whether the project is ready to ship. Also use to check readiness without releasing.
• 100pre-publish
  Use when about to push, tag, release or publish code other people will run — 'ready to release', 'cut a release', 'before I push', 'pre-publish', 'is this safe to ship'. The ordered gate sequence: scope the diff, deterministic gates, an independent read-only sweep with every…