Skill2.9k estrellas del repoactualizado 6d ago

hyperflow-deploy

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.

Ver fuente Repositorio: tons-of-skills-marketplace

Instalar en Claude Code

Copiar

git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/hyperflow-deploy && cp -r /tmp/hyperflow-deploy/plugins/ai-agency/hyperflow/templates/antigravity/skills/hyperflow-deploy ~/.claude/skills/hyperflow-deploy

Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

Definición

SKILL.md

# 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.

Del mismo repositorio

agency-osSkill

apexSkill

Engineering lead — hand Apex any task and it routes internally. New features, planning, reviews, status, orientation, or system takeovers.

apex-planSkill

Plan and scope a project — discovery, challenge assumptions, present S/M/L options with token and cost estimates. Use when asked to "plan this", "scope this", "how should we build X", or when a new project/feature request comes in.

apex-reconSkill

Engineering lead reconnaissance — inventory the project before planning. Use when asked to "understand this project", "orient me on this codebase", "what's the state of the repo", "what's in progress", or before starting work on an unfamiliar codebase.

apex-reviewSkill

Cross-cutting review of recent work — catches gaps between specialists. Use when asked to "review what we built", "check the work", "pre-launch review", or after completing a significant chunk of work.

apex-statusSkill

CTO-level project status from git and codebase state. Use when asked "where are we", "project status", "what's done", or at the start of a work session.

apex-takeoverSkill

System takeover — take ownership of an existing codebase or inherited system. Use when "we acquired this", "previous team left", "take over this system", "inherited this codebase".

atlasSkill

Knowledge engineer — architecture docs, ADRs, diagrams, changelogs, onboarding, and reports.