feat(skills): add /hotfix, /bugfix, and /feat lightweight skills
Fill the gap between direct editing and the full /ship-feature orchestrator. Three new skills for common everyday tasks: - /hotfix: superficial bugs (typo, CSS, config), 1-2 files, no plan - /bugfix: deeper bugs with root cause investigation + fix plan - /feat: small features 1-5 files, light planning, no subagents Each skill documents its escalation path to the next level. Updated plugin-advisor with skill routing table and references. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
bastien
parent
e0e466c857
commit
ed81d13d76
@ -155,14 +155,28 @@ After presenting RECOMMENDATIONS, if any plugin has ⚡ ENABLE status:
|
||||
| `fast-libs` | context7 | — | Doc freshness critical |
|
||||
| `multi-agent` + `complex-arch` | gsd v2 CLI | ruflo (unless explicitly requested) | GSD v2 preferred; ruflo only on explicit user request |
|
||||
| `simple` / single-session | — | gsd, gstack, ruflo, ui-ux-pro-max | Saves ~3000-5000t |
|
||||
| `embedded` / firmware | — | all toggles; superpowers optional | workflow: /analyze → edit or /ship-feature |
|
||||
| `embedded` / firmware | — | all toggles; superpowers optional | workflow: /analyze → /hotfix or /bugfix or /ship-feature |
|
||||
| backend/lib/CLI only | — | frontend-design, ui-ux-pro-max, gstack | ~3100t saved |
|
||||
| small project / hotfix | — | gstack, ruflo, gsd | Overhead exceeds value |
|
||||
| small project / hotfix | — | gstack, ruflo, gsd | Use /hotfix, /bugfix, or /feat |
|
||||
|
||||
**GSD v2 note:** `gsd-pi` is a standalone CLI (Pi SDK), not a Claude Code plugin. Zero passive token cost in CC sessions. Recommend when: feature > 1 day, multiple isolated context windows needed, crash recovery, cost tracking, or parallel workers. Usage: `gsd` in terminal → `/gsd auto`.
|
||||
|
||||
**Ruflo note:** `ruflo` is a heavy CLI tool (310+ tools, ~500-1500t passive when hooks active). Only recommend when the project explicitly requires coordinating 5+ specialized agents simultaneously or swarm/parallel-orchestration architecture. For standard multi-session work, GSD v2 is sufficient and lighter. Install: `npm install -g ruflo@latest --omit=optional`. Init: `ruflo init --wizard`.
|
||||
|
||||
### Skill routing by task size
|
||||
|
||||
When the plugin-advisor detects a `simple` or `hotfix` signal, suggest the appropriate lightweight skill instead of heavy orchestrators:
|
||||
|
||||
| Task | Skill | When to use | Overhead |
|
||||
|---|---|---|---|
|
||||
| Typo, CSS fix, wrong value, missing import | `/hotfix` | Root cause obvious, 1-2 files max | ~30s |
|
||||
| Bug with unclear root cause, multi-file | `/bugfix` | Needs investigation before fixing, up to ~5 files | ~3 min |
|
||||
| Small feature, 1-5 files | `/feat` | Well-scoped addition, no design needed | ~2 min |
|
||||
| Large feature, design decisions needed | `/ship-feature` | Multi-file, needs brainstorm + plan + review | ~10 min |
|
||||
| New project from scratch | `/init-project` | Full project setup with scaffolding | ~15 min |
|
||||
|
||||
**Escalation path:** `/hotfix` → `/bugfix` → `/ship-feature` (bugs), `/feat` → `/ship-feature` (features). Each skill documents when to escalate to the next level.
|
||||
|
||||
---
|
||||
|
||||
## COMPATIBILITY MATRIX
|
||||
@ -245,7 +259,7 @@ RULE: IF "embedded" signal (firmware, bare-metal, microcontroller, or Makefile+C
|
||||
→ superpowers OPTIONAL: useful for initial design brainstorm on complex drivers,
|
||||
but unnecessary for single-function patches — user decides
|
||||
→ GSD v2 CLI: not recommended (sessions are short, tasks are atomic)
|
||||
→ Recommend workflow: /analyze <file> → Edit direct (hotfix) or /ship-feature (multi-file)
|
||||
→ Recommend workflow: /analyze <file> → /hotfix (patch) or /bugfix (investigation) or /ship-feature (multi-file)
|
||||
→ NOTE: print "embedded project detected — minimal plugin footprint recommended"
|
||||
|
||||
RULE: IF gstack ON AND ruflo ON:
|
||||
|
||||
147
skills/bugfix/SKILL.md
Normal file
147
skills/bugfix/SKILL.md
Normal file
@ -0,0 +1,147 @@
|
||||
---
|
||||
name: bugfix
|
||||
description: |
|
||||
Structured bug fix with root cause investigation. For bugs where
|
||||
the cause isn't immediately obvious, spans multiple files, or
|
||||
requires careful analysis before fixing. Includes hypothesis-driven
|
||||
investigation and a fix plan.
|
||||
Trigger: "bugfix", "debug this", "fix this bug", "pourquoi ca marche pas",
|
||||
"investigate and fix", "find and fix", "root cause + fix".
|
||||
For obvious 1-2 file fixes → use /hotfix instead.
|
||||
For bugs that need investigation only (no fix) → use /analyze.
|
||||
argument-hint: <bug description, error message, or stack trace>
|
||||
disable-model-invocation: false
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Edit
|
||||
- Write
|
||||
- Bash
|
||||
- Grep
|
||||
- Glob
|
||||
- Agent
|
||||
---
|
||||
|
||||
# BUGFIX — Structured Bug Fix
|
||||
|
||||
Investigate, understand, plan, fix. No guessing. The iron law:
|
||||
understand the root cause before writing a single fix.
|
||||
|
||||
## REQUEST
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## STEP 1 — GATHER CONTEXT
|
||||
|
||||
Understand the current state:
|
||||
|
||||
```bash
|
||||
git status
|
||||
git log --oneline -5
|
||||
```
|
||||
|
||||
Read the error message, stack trace, or bug description.
|
||||
Identify:
|
||||
- **What** is broken (symptom)
|
||||
- **Where** it manifests (file, line, endpoint, UI element)
|
||||
- **When** it started (recent commit? always? after a deploy?)
|
||||
|
||||
```bash
|
||||
# If the user mentions "it was working before":
|
||||
git log --oneline -20 --all -- <suspected files>
|
||||
```
|
||||
|
||||
## STEP 2 — INVESTIGATE
|
||||
|
||||
Trace the bug from symptom to root cause:
|
||||
|
||||
1. Read the code path involved (follow the data flow).
|
||||
2. Check recent changes to the affected files:
|
||||
```bash
|
||||
git log --oneline -10 -- <file>
|
||||
git diff HEAD~5 -- <file> # if recent regression suspected
|
||||
```
|
||||
3. Look for related tests — do they pass? Do they cover
|
||||
the broken case?
|
||||
4. Search for similar patterns elsewhere that might have
|
||||
the same bug:
|
||||
```bash
|
||||
# grep for the same pattern to assess blast radius
|
||||
```
|
||||
|
||||
## STEP 3 — HYPOTHESIZE + PLAN
|
||||
|
||||
Present findings before fixing:
|
||||
|
||||
```
|
||||
BUGFIX — DIAGNOSIS
|
||||
BUG : <one-line symptom>
|
||||
ROOT CAUSE: <what is actually wrong and why>
|
||||
EVIDENCE: <what confirmed it — test, trace, diff>
|
||||
BLAST RADIUS: <other places affected, or "isolated">
|
||||
|
||||
FIX PLAN:
|
||||
1. <file:line> — <what to change>
|
||||
2. <file:line> — <what to change>
|
||||
[3. <test file> — add/update test for this case]
|
||||
|
||||
RISK: <low/medium — what could go wrong>
|
||||
```
|
||||
|
||||
- If the root cause is still unclear after investigation,
|
||||
say so explicitly. List remaining hypotheses ranked by
|
||||
probability. Ask the user before proceeding.
|
||||
- If the fix is trivial after investigation (1-2 lines):
|
||||
proceed directly — no need to wait for approval on an
|
||||
obvious fix.
|
||||
- If the fix is significant (>10 lines, multiple files,
|
||||
behavior change): wait for user approval.
|
||||
|
||||
## STEP 4 — FIX
|
||||
|
||||
Apply the fix following the plan:
|
||||
|
||||
- Fix the root cause, not the symptom.
|
||||
- Add or update tests to cover the bug case (regression test).
|
||||
- If no test framework exists: document what you verified.
|
||||
- Keep changes minimal — fix the bug, nothing else.
|
||||
|
||||
## STEP 5 — VERIFY + COMMIT
|
||||
|
||||
1. Run the full relevant test suite:
|
||||
```bash
|
||||
# detect and run tests
|
||||
```
|
||||
2. If a build step exists, verify it passes.
|
||||
3. Check for regressions in related functionality.
|
||||
4. Commit using conventional format:
|
||||
```
|
||||
fix(<scope>): <root cause description>
|
||||
|
||||
<what was wrong and why>
|
||||
<what the fix does>
|
||||
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||
```
|
||||
5. Print summary:
|
||||
```
|
||||
BUGFIX COMPLETE
|
||||
BUG : <symptom>
|
||||
ROOT CAUSE : <one-line>
|
||||
FILE(S) : <changed files>
|
||||
TEST(S) : <added/updated tests, or "none — verified manually">
|
||||
REGRESSION : <checked areas>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## RULES
|
||||
- No fix without understanding the root cause first.
|
||||
- No plugin check (lightweight skill, not an orchestrator).
|
||||
- If investigation reveals a design flaw requiring significant
|
||||
refactoring → stop, explain, suggest `/ship-feature` for the
|
||||
proper fix.
|
||||
- Always add a regression test when possible.
|
||||
- Keep the fix scoped. No "while we're here" cleanups.
|
||||
- If >5 files need changes → reconsider if `/ship-feature`
|
||||
is more appropriate.
|
||||
136
skills/feat/SKILL.md
Normal file
136
skills/feat/SKILL.md
Normal file
@ -0,0 +1,136 @@
|
||||
---
|
||||
name: feat
|
||||
description: |
|
||||
Small feature implementation (1-5 files). Light planning, direct
|
||||
implementation, no heavy orchestration. For features that don't
|
||||
need the full /ship-feature pipeline (no design brainstorm, no
|
||||
subagents, no plugin check gate).
|
||||
Trigger: "feat", "small feature", "add this", "petite feature",
|
||||
"quick feature", "ajoute ca", "implement this small thing".
|
||||
For multi-file features needing design → use /ship-feature.
|
||||
For bug fixes → use /hotfix or /bugfix.
|
||||
argument-hint: <feature description>
|
||||
disable-model-invocation: false
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Edit
|
||||
- Write
|
||||
- Bash
|
||||
- Grep
|
||||
- Glob
|
||||
- Agent
|
||||
---
|
||||
|
||||
# FEAT — Small Feature, Fast Track
|
||||
|
||||
Implement a small, well-scoped feature without the overhead of a
|
||||
full orchestrator. Direct work, light planning, quick delivery.
|
||||
|
||||
## REQUEST
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## STEP 0 — SCOPE CHECK
|
||||
|
||||
Before starting, verify this is actually a small feature:
|
||||
|
||||
```bash
|
||||
git status
|
||||
git log --oneline -3
|
||||
```
|
||||
|
||||
Read the relevant existing code to understand the context.
|
||||
|
||||
**Escalate to `/ship-feature` if:**
|
||||
- The feature needs >5 files of new/modified code
|
||||
- It requires architectural decisions or design tradeoffs
|
||||
- It involves new dependencies or infrastructure changes
|
||||
- The user isn't sure what they want (needs brainstorming)
|
||||
|
||||
**Downgrade to `/hotfix` if:**
|
||||
- It's really just adding a missing field, config value, etc.
|
||||
|
||||
Print a one-line scope confirmation:
|
||||
```
|
||||
FEAT: <feature name> — ~<N> files, <brief approach>
|
||||
```
|
||||
|
||||
## STEP 1 — MINI-PLAN
|
||||
|
||||
Quick mental model, not a formal plan document:
|
||||
|
||||
1. List the files to create or modify (with line references).
|
||||
2. Describe the approach in 2-5 bullet points.
|
||||
3. Note any edge cases to handle.
|
||||
4. If tests exist for the area, note which tests to add/update.
|
||||
|
||||
Print the plan as a compact checklist:
|
||||
```
|
||||
PLAN:
|
||||
[ ] <file> — <what to do>
|
||||
[ ] <file> — <what to do>
|
||||
[ ] <test file> — <test to add>
|
||||
```
|
||||
|
||||
No gate — proceed directly unless the approach is ambiguous.
|
||||
If ambiguous: ask the user one focused question, then proceed.
|
||||
|
||||
## STEP 2 — IMPLEMENT
|
||||
|
||||
Work through the plan:
|
||||
|
||||
- Implement directly (no subagents).
|
||||
- Write tests alongside the code (not after).
|
||||
- Follow existing patterns in the codebase.
|
||||
- Run tests incrementally as you go.
|
||||
|
||||
## STEP 3 — VERIFY
|
||||
|
||||
1. Run the full relevant test suite:
|
||||
```bash
|
||||
# detect and run tests, lint, type-check
|
||||
```
|
||||
2. If a dev server is relevant, mention what the user should
|
||||
check visually.
|
||||
3. Quick self-review: scan your diff for obvious issues:
|
||||
```bash
|
||||
git diff --stat
|
||||
git diff
|
||||
```
|
||||
|
||||
## STEP 4 — COMMIT
|
||||
|
||||
Commit using conventional format:
|
||||
```
|
||||
feat(<scope>): <what was added>
|
||||
|
||||
<brief description of the feature>
|
||||
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||
```
|
||||
|
||||
If the feature touched multiple concerns (e.g., feature + config +
|
||||
test), consider splitting into 2-3 atomic commits using the same
|
||||
logic as `/commit-change`.
|
||||
|
||||
Print summary:
|
||||
```
|
||||
FEAT COMPLETE
|
||||
FEATURE : <name>
|
||||
FILE(S) : <created/modified files>
|
||||
TEST(S) : <added tests>
|
||||
VERIFIED : <what was checked>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## RULES
|
||||
- Max 5 files. If more needed → `/ship-feature`.
|
||||
- No plugin check (not an orchestrator).
|
||||
- No brainstorm/design phase (if needed → `/ship-feature`).
|
||||
- No subagents — direct implementation.
|
||||
- Keep scope tight. If scope creep happens mid-work, stop
|
||||
and suggest splitting into `/feat` + follow-up task.
|
||||
- Follow existing code patterns. Don't introduce new patterns
|
||||
for a small feature.
|
||||
86
skills/hotfix/SKILL.md
Normal file
86
skills/hotfix/SKILL.md
Normal file
@ -0,0 +1,86 @@
|
||||
---
|
||||
name: hotfix
|
||||
description: |
|
||||
Quick fix for superficial bugs: typos, CSS issues, config errors,
|
||||
off-by-one, wrong variable name, missing import, broken link.
|
||||
Use when the root cause is obvious and the fix is 1-2 files max.
|
||||
Trigger: "hotfix", "quick fix", "typo", "fix this small thing",
|
||||
"c'est juste un petit bug", "patch rapide".
|
||||
Do NOT use for bugs requiring investigation — use /bugfix instead.
|
||||
argument-hint: <bug description or error message>
|
||||
disable-model-invocation: false
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Edit
|
||||
- Write
|
||||
- Bash
|
||||
- Grep
|
||||
- Glob
|
||||
---
|
||||
|
||||
# HOTFIX — Quick Superficial Fix
|
||||
|
||||
Fast-track fix for obvious bugs. No planning overhead, no plugin
|
||||
check, no subagents. Get in, fix, verify, get out.
|
||||
|
||||
## REQUEST
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## STEP 1 — LOCATE
|
||||
|
||||
Find the bug. Use the description and any error message to go
|
||||
straight to the source:
|
||||
|
||||
```bash
|
||||
git status
|
||||
git log --oneline -3
|
||||
```
|
||||
|
||||
- Read the relevant file(s). Confirm the root cause is obvious
|
||||
and superficial (typo, wrong value, missing import, etc.).
|
||||
- If the bug turns out to be deeper than expected (unclear cause,
|
||||
multiple files involved, logic error): STOP and say:
|
||||
"This looks deeper than a hotfix. Run `/bugfix <description>`
|
||||
for a structured investigation."
|
||||
|
||||
## STEP 2 — FIX
|
||||
|
||||
Apply the minimal change that fixes the bug:
|
||||
|
||||
- Edit only what is necessary. No refactoring, no cleanup.
|
||||
- If tests exist for the affected code, run them:
|
||||
```bash
|
||||
# detect and run relevant tests
|
||||
```
|
||||
- If a build step exists, verify it still passes.
|
||||
|
||||
## STEP 3 — VERIFY + COMMIT
|
||||
|
||||
1. Verify the fix:
|
||||
- Run the test suite or the specific test if available.
|
||||
- If no tests: explain what you verified manually.
|
||||
2. Commit using conventional format:
|
||||
```
|
||||
fix(<scope>): <what was wrong>
|
||||
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||
```
|
||||
3. Print summary:
|
||||
```
|
||||
HOTFIX APPLIED
|
||||
FILE(S) : <changed files>
|
||||
FIX : <one-line description>
|
||||
VERIFIED: <test name or manual check>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## RULES
|
||||
- Max 2 files changed. If more needed → `/bugfix`.
|
||||
- No refactoring. No "while we're here" improvements.
|
||||
- No plugin check (overhead > value for a hotfix).
|
||||
- If root cause is unclear → escalate to `/bugfix`.
|
||||
- If fix touches >5 lines of logic → reconsider if this is
|
||||
truly a hotfix.
|
||||
Loading…
Reference in New Issue
Block a user