deploy
|
git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/deploy && cp -r /tmp/deploy/plugins/ai-agency/hyperflow/skills/deploy ~/.claude/skills/deploySKILL.md
# Deploy No gate skipped, no failure ignored. If any gate fails, halt and report. Never `--no-verify`. Never bypass. **Failure recovery (rule 14).** Worker errors and Quality Gate failures follow the canonical policy in [`skills/hyperflow/failure-recovery.md`](../hyperflow/failure-recovery.md). Gate failures are user-surfaced, never auto-fixed — print the failing command + full stderr and halt the push. Never `--no-verify`, never force-push to main. ## Per-Step Agent Map | Step | Sub-phase | Workers | Reviewer | Notes | |---|---|---|---|---| | 1a | Repo-state scan | Worker A (git status), Worker B (git log) | Reviewer | — | | 1b | Tool detection | Worker A (profile.md + lockfiles), Worker B (testing.md + devDeps) | Reviewer | — | | 2a | Lint + typecheck (parallel) | Worker A (linter), Worker B (formatter), Worker C (tsc) | Reviewer | Step 3 (Security Sweep) runs in parallel with Step 2 at orchestrator level; 2a halts chain on any failure before 2b | | 2b | Build gate | Worker A (prod build), Worker B (dev build) | Reviewer | Depends on 2a PASS | | 2c | Test gate | Worker A (unit), Worker B (integration/E2E) | Reviewer | Parallel (P1); depends on 2b PASS | | 3a | Secrets scan | Worker A (diff pattern), Worker B (file pattern) | **`security-reviewer`** | Runs in parallel with Step 2 (pre-build; read-only) | | 3b | Dependency audit | Worker A (CVE audit), Worker B (license check) | **`vulnerability-reviewer`** (web-research-first) | — | | 4 | Commit | single Worker | Reviewer | atomic-exempt (DOCTRINE 12.2) | | 5a | Release execution | single Worker | Reviewer | atomic-exempt (DOCTRINE 12.2) | | 5b | Version sync | Worker A (manifests), Worker B (changelog) | Reviewer | — | | 6 | Push gate | AskUserQuestion | — | structural gate; atomic-exempt | | 7 | Output | single print | — | atomic-exempt (§12.1) | ## Step 1 — Survey State Sub-phases run in parallel (P1). ### Step 1a — Repo-state scan Two Workers in parallel: - Worker A — `git status --short` — uncommitted changes, staged files - Worker B — `git log origin/<branch>..HEAD --oneline` — commits ahead of remote; detect branch name Reviewer — verdict on repo state (clean / has uncommitted / ahead by N). If detached HEAD or no remote configured → halt with reason. ### Step 1b — Tool detection Two Workers in parallel: - Worker A — Read `.hyperflow/profile.md` for package manager and project type; fallback: inspect `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod` - Worker B — Check `.hyperflow/testing.md` for test runner; fallback: detect from `package.json` devDependencies (`vitest`, `jest`, `playwright`, `pytest`, etc.) Reviewer — produce a single tool manifest (package manager, test runner, typed-project flag, build script presence). Used by Step 2 gates. ## Step 2 — Quality Gates Step 2 runs in parallel with Step 3 (Security Sweep) at the orchestrator level — both are pre-build, read-only checks. Both must reach `PASS` before Step 4 (Commit) may proceed. Within Step 2, sub-phases 2a → 2b → 2c run sequentially (2b depends on 2a PASS; 2c depends on 2b PASS). Halt at the first `NEEDS_REVISION` verdict. Wall-clock note: default flow runs 3 gates simultaneously (lint + security + typecheck in parallel), then build, then tests — roughly max(lint, security, typecheck) + build + max(unit, integration), versus the old 4× sequential gate duration. Typical saving: ~40% wall-clock reduction. Under `--thorough`, a standalone final-integration review pass is added after all gates complete, and intra-sub-phase Workers serialize (DOCTRINE §12.2/clarification), so the full saving collapses to 2c's unit + integration pair only. Print `Gate <letter> — <name>` before each sub-phase. ### Step 2a — Lint + typecheck (parallel; no build artifact required) Three Workers in parallel (P1). None depend on build output — safe to run alongside Step 3. - Worker A — Detect and run primary linter: `npm run lint` / `pnpm lint` / `bun run lint` / `eslint .`. On failure: auto-fix via `--fix`, re-run once; report final error count. - Worker B — Detect and run formatter check: `prettier --check .` / `biome check .` / equivalent. Report diff count. - Worker C — Root typecheck: `tsc --noEmit` / `npm run typecheck`. Skip if not a typed project (per Step 1b tool manifest). Also run per-package typecheck if workspace detected (pnpm/yarn workspaces): iterate packages with `tsc --noEmit` in each. Reviewer — aggregate verdict across all three Workers: - `PASS` — all clean (or absent/untyped) - `NEEDS_REVISION` — any gate fails → halt before 2b. Report which specific gate(s) failed and why. Do NOT proceed to build. - `ESCALATE` — config errors preventing execution of any gate ### Step 2b — Build gate (sequential; depends on 2a PASS) Two Workers in parallel: - Worker A — Production build: `npm run build` / `pnpm build` / `bun run build`. Capture output; report size or artifact path if printed. - Worker B — Dev/preview build if a separate script exists (`npm run build:dev`, `vite build --mode development`, etc.). Skip if no separate dev-build script. Reviewer — verdict: - `PASS` — production build succeeds - `NEEDS_REVISION` — production build fails → halt with output - `ESCALATE` — build tool absent or script missing (skip silently, not failure) ### Step 2c — Test gate (parallel; depends on 2b PASS) Two Workers in parallel (P1): - Worker A — Unit tests: run full unit suite per runner from Step 1b (vitest, jest, pytest, cargo test, etc.). Full suite — not just affected. Report count. - Worker B — Integration / E2E tests if runner detected separately (playwright, cypress, etc.). Skip if no integration runner found. Reviewer — verdict: - `PASS` — all tests pass (or integration absent) - `NEEDS_REVISION` — failing tests → halt with failing test names. Do NOT skip. Do NOT increase timeout. - `ESCALATE` — runner misconfigured or no tests found and test runner is declared See [quality-gates.md](references/quality-gates.md) for gate details. ## Step 3 — S
|
Engineering lead — hand Apex any task and it routes internally. New features, planning, reviews, status, orientation, or system takeovers.
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.
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.
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.
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.
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".
Knowledge engineer — architecture docs, ADRs, diagrams, changelogs, onboarding, and reports.