hyperflow-plan
Hyperflow planning phase. Use when a request needs shaping before code — a rough prompt to sharpen, an ambiguous idea to design, or a clear-enough task to decompose. Verbs like plan, design, brainstorm, explore, "should we", "what's the best way to", scope, decompose, "plan out", "break down", "enhance this prompt". Thinking, not building. Writes an optional spec to .hyperflow/specs/<slug>.md and a task file to .hyperflow/tasks/<slug>.md, then hands off to hyperflow-dispatch.
git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/hyperflow-plan && cp -r /tmp/hyperflow-plan/plugins/ai-agency/hyperflow/templates/antigravity/skills/hyperflow-plan ~/.claude/skills/hyperflow-planSKILL.md
# hyperflow-plan — planning phase (Antigravity single-agent) Thinking, not building. The only writes are to `.hyperflow/`. Each phase skips itself when the request doesn't need it. Follow the `hyperflow` doctrine (autonomy, file-first, AskUserQuestion gates). ## Steps 1. **Amplify (skippable).** If the prompt is rough, rewrite it into its strongest form — role · task · context · constraints · output spec. Skip when it's already specific. Never inflate a one-line ask into a spec. 2. **Research first.** Read the relevant code, `AGENTS.md`, and `.hyperflow/memory/*`. Map the affected surface yourself — do not ask what the code answers. 3. **Design (skippable).** For an open-ended request: ask ≥2 clarifying questions (what/which/where only), propose 2–3 approaches, then design section-by-section into `.hyperflow/specs/<slug>.md` with approval per section. A clear request bounces straight to decomposition. When a system, UI, motion, or mobile surface is in scope, ground the design in the matching standards (architecture decomposition + a diagram, the design system, the Motion language, the mobile platform/device matrix). 4. **Decompose.** Produce a topologically-ordered batch graph; each sub-task = one conventional-commit-sized change. **Split any sub-task** touching >5 files, >500 LOC, 2+ subsystems, or >10-min review. Write `.hyperflow/tasks/<slug>.md`: status table → Goal → Why → Scope-at-a-glance → Affected files → Execution plan → Batches (role, files, complexity, acceptance criteria, commit stub) → Verification plan. 5. **Print** `Plan ready — .hyperflow/tasks/<slug>.md (N batches, M sub-tasks)`. 6. **Hand off**: invoke the `hyperflow-dispatch` skill with the task slug — or, in two-session mode, write a committed handoff package and stop. ## Rules - No implementation code; no source edits. - Floor of 2 clarifying questions on the design path; 0–3 on the bounce (decompose-only) path. - Single-batch plans for multi-file work are an anti-pattern — decompose. - Always include a concrete verification plan.
|
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.