From vgv-wingspan
Applies minimal targeted fixes for emergency bugs using git hotfix branches. Enforces triage, codebase exploration, testing, and review without planning phases.
npx claudepluginhub verygoodopensource/very_good_claude_code_marketplace --plugin vgv-wingspanThis skill is limited to using the following tools:
Apply a minimal, targeted fix fast. No brainstorm document, no plan document — but tests and review are still non-negotiable.
Guides hotfix workflow for critical production issues like security vulnerabilities or core bugs: branch from latest release tag, minimal fix, fast-track review, pnpm quality gates, patch release with changeset.
Analyzes urgent online defects via root cause analysis (RCA/5 Whys), builds minimal reproduction paths, defines safe fix boundaries, and hands off to implementation without writing code.
Fixes bugs via root cause diagnosis with debugger/gap-analyzer, requirements.md generation, /execute delegation, 3-retry circuit breaker, and QA.
Share bugs, ideas, or general feedback.
Apply a minimal, targeted fix fast. No brainstorm document, no plan document — but tests and review are still non-negotiable.
<bug_description>$ARGUMENTS</bug_description>
If the bug description above is empty, ask the user: "What's the bug? Paste a description, issue link, or error message."
DO NOT proceed until you have a bug description.
Summarize the bug in one sentence. Identify:
Run a focused codebase exploration to find the problem area:
After the agent returns:
If the root cause is unclear after exploration, use AskUserQuestion to ask the user for additional context before proceeding.
Set up a hotfix branch. Unlike normal feature branches, hotfix branches use the hotfix/ prefix.
Run:
git rev-parse --abbrev-ref HEAD
If already on a hotfix/ branch: skip silently.
Otherwise: infer a branch name in the format hotfix/<kebab-slug> where the slug is derived from the bug description (max 60 characters total). Use AskUserQuestion to confirm:
git checkout -b hotfix/<slug>Before writing any code, outline which files and layers the fix touches.
If >5 files, multiple layers, or new abstractions needed: warn the user and use AskUserQuestion: (1) Proceed with hotfix, (2) Switch to /plan.
If contained (≤5 files, single layer): proceed directly.
Write the minimal change that addresses the root cause. Change only what is necessary — no drive-by refactors. If you touch unrelated code, stop and flag scope creep. Leave // TODO(hotfix): <description> comments for out-of-scope issues. Match surrounding code style.
Tests are non-negotiable, even for hotfixes:
Follow the validation and fix procedure.
// TODO(hotfix): <description of known limitation and its severity> comment in the code and note it in the PR description. The goal is to stop the bleeding, not achieve perfection.Run review agents in parallel to validate the fix. Use a reduced set — speed matters, but quality is non-negotiable.
Each agent prompt must include the review agent instructions with REPORT_DIR set to docs/hotfix-review/.
The 2 agents and their report filenames:
| Agent | Report file |
|---|---|
| @vgv-review-agent | docs/hotfix-review/vgv-review.md |
| @test-quality-review-agent | docs/hotfix-review/test-quality-review.md |
Follow the review consolidation procedure: fix critical issues, present important issues to the user, and record suggestions.
Remove review reports after findings are addressed:
rm -rf docs/hotfix-review/
Run the project's formatter, linter, and test runner one last time. Fix any failures before proceeding.
Create a single, cherry-pick-friendly commit. Stage only fix-related files (no unrelated changes). Use this commit format:
fix: <concise description of what was fixed>
<Root cause explanation in 1-2 sentences>
Bug: <original bug description or issue link, truncated if long>
Push the branch and create a PR. Title: fix: <concise description> (under 70 chars). Body: Use the PR template.
Use AskUserQuestion to present options:
/plan → /build.hotfix/ prefix, not fix/. Other skills use fix/ — do not mix them.docs/hotfix-review/ already exists from a previous interrupted hotfix, delete it before running Phase 4 to avoid stale reports contaminating the review./plan → /build.