refactor(skills): extract skill logic into standalone agent files
Skills now delegate to agent .md files instead of embedding logic inline. Added new agents (bugfixer, code-cleaner, commit-changer, doc-syncer, feater, hotfixer, seo-analyzer) and new skills (code-clean, doc, seo). Replaced /readme with /doc (broader scope). Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
bastien
+3
-121
@@ -21,127 +21,9 @@ allowed-tools:
|
||||
- Agent
|
||||
---
|
||||
|
||||
# BUGFIX — Structured Bug Fix
|
||||
Load and follow strictly:
|
||||
- $HOME/.claude/agents/bugfixer.md
|
||||
|
||||
Investigate, understand, plan, fix. No guessing. The iron law:
|
||||
understand the root cause before writing a single fix.
|
||||
Execute the BUGFIXER agent on the following target:
|
||||
|
||||
## 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.
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: code-clean
|
||||
description: |
|
||||
Full codebase cleanup: dead code removal, style/norm enforcement, structural
|
||||
issues. Two-phase workflow: audit first (read-only report), then execute
|
||||
approved fixes only. Delegates refactoring to the refactorer agent.
|
||||
Trigger: "code-clean", "clean up the code", "remove dead code",
|
||||
"enforce code style", "cleanup", "nettoyage du code", "code hygiene".
|
||||
For targeted refactoring without audit → use /refactor instead.
|
||||
For bug fixes discovered during cleanup → logged to BUGS-FOUND.md, not fixed here.
|
||||
argument-hint: <file, directory, or blank for entire project>
|
||||
disable-model-invocation: false
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Edit
|
||||
- Write
|
||||
- Bash
|
||||
- Grep
|
||||
- Glob
|
||||
- Agent
|
||||
- AskUserQuestion
|
||||
---
|
||||
|
||||
Load and follow strictly:
|
||||
- $HOME/.claude/agents/code-cleaner.md
|
||||
|
||||
Execute the CODE-CLEANER agent on the following target:
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -18,85 +18,9 @@ allowed-tools:
|
||||
- AskUserQuestion
|
||||
---
|
||||
|
||||
# Git Smart Commit
|
||||
Load and follow strictly:
|
||||
- $HOME/.claude/agents/commit-changer.md
|
||||
|
||||
Create clean, atomic commits from a messy working directory. The goal is to
|
||||
turn a pile of mixed changes into a well-organized git history that tells a
|
||||
clear story — each commit focused on one logical change.
|
||||
Execute the COMMIT-CHANGER agent on the current working directory.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Phase 1: Gather context
|
||||
|
||||
Run these commands to understand the full picture:
|
||||
|
||||
```bash
|
||||
git status
|
||||
git diff # unstaged changes
|
||||
git diff --cached # staged changes
|
||||
git diff HEAD --stat # summary of all changes vs last commit
|
||||
git log --oneline -5 # recent commit style
|
||||
```
|
||||
|
||||
Also check for untracked files that should be included. Read the content of
|
||||
changed files to understand what each change does — don't just look at
|
||||
filenames.
|
||||
|
||||
### Phase 2: Analyze and group changes
|
||||
|
||||
Read the actual diffs and file contents to understand the intent behind each
|
||||
change. Group changes into logical commits based on:
|
||||
|
||||
- **Purpose**: what problem does this change solve or what feature does it add?
|
||||
- **Scope**: files that work together toward the same goal belong together
|
||||
- **Type**: separate concerns (a bug fix shouldn't be bundled with a new feature)
|
||||
|
||||
Common groupings:
|
||||
- Feature code + its tests + its docs = one commit
|
||||
- Config/dependency changes = separate commit
|
||||
- Unrelated bug fixes = each gets its own commit
|
||||
- Formatting/style changes = separate from logic changes
|
||||
|
||||
### Phase 3: Execute commits
|
||||
|
||||
Proceed directly — no confirmation needed. For each logical commit group,
|
||||
in order:
|
||||
|
||||
1. Stage only the files for that commit: `git add <specific-files>`
|
||||
- For partially changed files that belong to multiple commits, use
|
||||
`git add -p` is not available (interactive), so if a single file
|
||||
has changes belonging to different logical groups, mention it to
|
||||
the user and ask how they want to handle it (commit together, or
|
||||
split manually).
|
||||
2. Create the commit with the agreed message
|
||||
3. Verify with `git status` that the right files were committed
|
||||
|
||||
### Commit message format
|
||||
|
||||
Follow Conventional Commits and match the repo's existing style:
|
||||
|
||||
```
|
||||
<type>(<scope>): <short description>
|
||||
|
||||
<optional body — what and why, not how>
|
||||
|
||||
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||
```
|
||||
|
||||
Types: `feat`, `fix`, `refactor`, `chore`, `docs`, `test`, `style`, `perf`
|
||||
|
||||
Keep the first line under 72 characters. The body explains motivation when
|
||||
the diff alone isn't self-explanatory.
|
||||
|
||||
### Edge cases
|
||||
|
||||
- **No changes**: tell the user there's nothing to commit
|
||||
- **Only staged changes**: respect what's already staged — ask if the user
|
||||
wants to commit just those, or also include unstaged/untracked changes
|
||||
- **Merge conflicts**: don't try to commit — tell the user to resolve first
|
||||
- **Large number of changes**: still group logically, but warn the user if
|
||||
the working directory looks like it has many unrelated changes mixed together
|
||||
- **Single logical change**: don't force multiple commits — one commit is fine
|
||||
if all changes serve the same purpose
|
||||
- **Sensitive files** (.env, credentials, keys): warn the user and exclude
|
||||
them from commits by default
|
||||
$ARGUMENTS
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: doc
|
||||
description: |
|
||||
Full documentation audit and sync. Detects stale docs by cross-referencing
|
||||
git history against README, CLAUDE.md, INSTALL.md, CONFIGURE.md, USAGE.md,
|
||||
CONTRIBUTING.md, CHANGELOG.md, docs/**/*.md, and inline comments (JSDoc,
|
||||
docstrings, rustdoc, godoc). Reports drift with commit refs, proposes fixes,
|
||||
patches approved items.
|
||||
Trigger: "doc", "sync docs", "audit docs", "update readme", "check documentation",
|
||||
"are docs up to date", "documentation drift", "stale docs".
|
||||
Replaces the old /readme skill with broader scope.
|
||||
argument-hint: [leave empty for full audit, or list specific files/docs to check]
|
||||
disable-model-invocation: false
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Edit
|
||||
- Write
|
||||
- Bash
|
||||
- Grep
|
||||
- Glob
|
||||
---
|
||||
|
||||
Load and follow strictly:
|
||||
- $HOME/.claude/agents/doc-syncer.md
|
||||
|
||||
Execute the DOC SYNCER on this project.
|
||||
|
||||
Context from the user (if any):
|
||||
$ARGUMENTS
|
||||
+3
-110
@@ -21,116 +21,9 @@ allowed-tools:
|
||||
- Agent
|
||||
---
|
||||
|
||||
# FEAT — Small Feature, Fast Track
|
||||
Load and follow strictly:
|
||||
- $HOME/.claude/agents/feater.md
|
||||
|
||||
Implement a small, well-scoped feature without the overhead of a
|
||||
full orchestrator. Direct work, light planning, quick delivery.
|
||||
Execute the FEATER agent on the following target:
|
||||
|
||||
## 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.
|
||||
|
||||
+3
-63
@@ -18,69 +18,9 @@ allowed-tools:
|
||||
- Glob
|
||||
---
|
||||
|
||||
# HOTFIX — Quick Superficial Fix
|
||||
Load and follow strictly:
|
||||
- $HOME/.claude/agents/hotfixer.md
|
||||
|
||||
Fast-track fix for obvious bugs. No planning overhead, no plugin
|
||||
check, no subagents. Get in, fix, verify, get out.
|
||||
Execute the HOTFIXER agent on the following target:
|
||||
|
||||
## 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.
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
---
|
||||
name: readme
|
||||
description: README audit — detect outdated sections, apply surgical updates
|
||||
argument-hint: [what changed, feature name, or leave empty for full audit]
|
||||
disable-model-invocation: true
|
||||
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
|
||||
---
|
||||
|
||||
Load and follow strictly:
|
||||
- $HOME/.claude/agents/readme-updater.md
|
||||
|
||||
Execute the README UPDATER on this project.
|
||||
|
||||
Context from the user (if any):
|
||||
$ARGUMENTS
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
name: seo
|
||||
description: |
|
||||
Full SEO audit and optimization for any web project. Detects framework,
|
||||
audits all SEO signals (meta, OG, structured data, sitemap, robots.txt,
|
||||
headings, alt attrs, canonicals, hreflang), applies fixes directly in code,
|
||||
and generates a strategic SEO guide.
|
||||
Trigger: "seo", "referencement", "optimize for search", "audit SEO",
|
||||
"meta tags", "structured data", "JSON-LD", "sitemap", "robots.txt",
|
||||
"Google ranking", "local SEO", "referencement local", "fiche Google".
|
||||
For code-only bugs → use /bugfix. For feature work → use /feat.
|
||||
argument-hint: optional keywords/scope, e.g. "local SEO plombier 91 94 77"
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Edit
|
||||
- Write
|
||||
- Bash
|
||||
- Grep
|
||||
- Glob
|
||||
- Agent
|
||||
---
|
||||
|
||||
Load and follow strictly:
|
||||
- $HOME/.claude/agents/seo-analyzer.md
|
||||
|
||||
Execute the SEO-ANALYZER agent on the following target:
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -114,8 +114,10 @@ Invoke `superpowers:requesting-code-review`. Fix all CRITICAL before proceeding.
|
||||
## STEP 7 — FINISH
|
||||
Invoke `superpowers:finishing-a-development-branch`. Tests pass, build clean, ready to merge.
|
||||
|
||||
## STEP 8 — SYNC README
|
||||
Load `$HOME/.claude/agents/readme-updater.md` with arg `sync`. Update cmds/vars/structure, add recent changes entry.
|
||||
## STEP 8 — DOC SYNC
|
||||
Load `$HOME/.claude/agents/doc-syncer.md`.
|
||||
Execute in automatic mode:
|
||||
`auto-mode scope: <list of files modified during this session>`
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user