hyperflow-trace
Hyperflow debugging. Use for bugs, test failures, runtime errors, broken builds, or "this doesn't work" reports — verbs like debug, "fix it", solve, "why is X failing", "Y is broken", or a pasted stack trace. Systematic root-cause analysis before any patch — never blind-patch symptoms.
git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/hyperflow-trace && cp -r /tmp/hyperflow-trace/plugins/ai-agency/hyperflow/templates/antigravity/skills/hyperflow-trace ~/.claude/skills/hyperflow-traceSKILL.md
# hyperflow-trace — root-cause phase (Antigravity single-agent) Find the root cause before changing anything. Follow the `hyperflow` doctrine. ## Steps 1. **Reproduce / locate.** Read the error, stack trace, or failing test. Identify the exact failing line and the observed-vs-expected behavior. 2. **5 Whys.** Trace the causal chain backward — keep asking "why" until you reach the true cause, not a symptom. 3. **Hypotheses.** List the 2-4 most plausible causes. For each, state a cheap test (read a file, add a log, run one test) that confirms or rules it out. Test them — narrow to the real cause. 4. **Confirm** the root cause with evidence (a failing assertion, a value print, a reproduced path). Do not patch on a guess. 5. **Fix** the root cause minimally. Add or update a test that would have caught it (characterization test before behavior change). 6. **Verify**: re-run the failing case + the surrounding suite. Self-review the diff (L1-L3). Commit as `fix(<scope>): <root cause>` (conventional, lowercase). ## Rules - Never blind-patch a symptom to make an error message disappear. - No behavior change beyond the fix unless asked. - If the root cause is unclear after hypothesis testing, surface what you found and what's still unknown — don't ship a speculative patch.
|
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.