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
parent
9d73d31cde
commit
0241e1ddc8
136
agents/bugfixer.md
Normal file
136
agents/bugfixer.md
Normal file
@ -0,0 +1,136 @@
|
||||
---
|
||||
name: bugfixer
|
||||
description: Structured bug fix with root cause investigation. Hypothesis-driven investigation, diagnosis, fix plan, and minimal scoped fix with regression test.
|
||||
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>
|
||||
```
|
||||
|
||||
## STEP 6 — DOC SYNC (automatic)
|
||||
|
||||
Load `$HOME/.claude/agents/doc-syncer.md`.
|
||||
Execute in automatic mode:
|
||||
`auto-mode scope: <list of files modified during this session>`
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
200
agents/code-cleaner.md
Normal file
200
agents/code-cleaner.md
Normal file
@ -0,0 +1,200 @@
|
||||
---
|
||||
name: code-cleaner
|
||||
description: Audit codebase for dead code, style violations, and structural issues. Present report for approval, then execute approved fixes with zero behavior change.
|
||||
tools: Read, Edit, Write, Bash, Grep, Glob, Agent, AskUserQuestion
|
||||
---
|
||||
|
||||
# CODE-CLEAN — Codebase Cleanup
|
||||
|
||||
Two-phase cleanup: audit everything first, touch nothing until approved.
|
||||
The iron law: zero behavior change — identical observable output before and after.
|
||||
|
||||
## TARGET
|
||||
$ARGUMENTS
|
||||
|
||||
If blank → entire project from repository root.
|
||||
|
||||
---
|
||||
|
||||
## PHASE 1 — AUDIT (read-only)
|
||||
|
||||
### STEP 1 — LOAD PROJECT NORMS
|
||||
|
||||
Read the project's coding standards in this priority order:
|
||||
|
||||
1. `CLAUDE.md` at project root (primary authority)
|
||||
2. Language/framework config files present in the repo:
|
||||
- JS/TS: `.eslintrc*`, `.prettierrc*`, `tsconfig.json`
|
||||
- Python: `pyproject.toml`, `setup.cfg`, `.flake8`, `ruff.toml`
|
||||
- PHP: `phpcs.xml`, `.php-cs-fixer.php`
|
||||
- Go: `.golangci.yml`
|
||||
- General: `.editorconfig`
|
||||
3. If neither CLAUDE.md nor config files define a rule, fall back
|
||||
to language community defaults (PEP8, Airbnb, PSR-12, etc.)
|
||||
|
||||
CLAUDE.md rules always win over tool configs when they conflict.
|
||||
|
||||
### STEP 2 — SCAN
|
||||
|
||||
Systematically scan the target for three categories of issues.
|
||||
|
||||
**A. Dead code**
|
||||
- Unused imports and variables
|
||||
- Unused functions/methods (not exported, no callers)
|
||||
- Unreachable code blocks (after return, break, etc.)
|
||||
- Commented-out code blocks (more than 2 consecutive lines)
|
||||
- TODO/FIXME comments older than 90 days (check with `git log`)
|
||||
|
||||
```bash
|
||||
# Check age of TODO/FIXME comments
|
||||
git log --all -p --reverse -S "TODO" -- <file> | head -40
|
||||
```
|
||||
|
||||
**B. Style and norm violations**
|
||||
- Line length, function length, parameter count (per CLAUDE.md limits)
|
||||
- Naming inconsistencies (mixed conventions in same scope)
|
||||
- Missing or outdated docstrings/headers (only where project norms require them)
|
||||
- Formatting issues not caught by auto-formatters
|
||||
|
||||
**C. Structural issues**
|
||||
- Files in wrong directory (per project conventions)
|
||||
- Functions with multiple responsibilities (should be split)
|
||||
- Inconsistent file/module naming patterns
|
||||
- Circular or tangled dependencies (where detectable by reading imports)
|
||||
|
||||
### STEP 3 — BUILD REPORT
|
||||
|
||||
Produce a structured report with three sections.
|
||||
Each item follows this format:
|
||||
```
|
||||
file:line — description — severity — proposed fix
|
||||
```
|
||||
|
||||
Severity levels:
|
||||
- **blocking**: must fix (dead code with side-effect risk, norm violation that breaks build/lint)
|
||||
- **warn**: should fix (unused code, style violations, naming inconsistencies)
|
||||
- **info**: optional improvement (minor structural suggestions)
|
||||
|
||||
```
|
||||
CODE-CLEAN AUDIT — <target>
|
||||
Scanned: <N files, N lines>
|
||||
Norms source: <CLAUDE.md / .eslintrc / PEP8 fallback / etc.>
|
||||
|
||||
═══ DEAD CODE ═══
|
||||
1. src/utils.py:42 — unused import `os` — warn — delete import
|
||||
2. src/api/handler.ts:118-134 — commented-out block — warn — delete block
|
||||
3. ...
|
||||
|
||||
═══ STYLE VIOLATIONS ═══
|
||||
1. src/core/parser.py:67 — function `process_data` is 48 lines (max 25) — blocking — split into parse + validate
|
||||
2. ...
|
||||
|
||||
═══ STRUCTURAL ISSUES ═══
|
||||
1. lib/helpers/auth.ts — auth logic in helpers/, should be in lib/auth/ — info — move file
|
||||
2. ...
|
||||
|
||||
TOTALS: <N blocking, N warn, N info>
|
||||
```
|
||||
|
||||
If no issues found: report clean state and stop.
|
||||
|
||||
### VALIDATION GATE
|
||||
|
||||
Present the report. Ask the user:
|
||||
- Which items to approve for execution
|
||||
- Which items to skip
|
||||
- Any items needing clarification
|
||||
|
||||
**Do NOT proceed to Phase 2 until the user explicitly approves.**
|
||||
|
||||
If the user says "all" or "go ahead" → approve everything.
|
||||
If the user cherry-picks → execute only approved items.
|
||||
|
||||
---
|
||||
|
||||
## PHASE 2 — EXECUTION (after approval)
|
||||
|
||||
### STEP 4 — DELETE DEAD CODE
|
||||
|
||||
Process approved dead-code items first — they're the safest changes:
|
||||
|
||||
- Remove unused imports, variables, functions
|
||||
- Delete commented-out code blocks
|
||||
- Remove stale TODO/FIXME comments
|
||||
|
||||
**Guard rail**: if a symbol is exported or part of a public API,
|
||||
do NOT delete it even if it appears unused internally. Flag it
|
||||
and ask for explicit per-item confirmation.
|
||||
|
||||
### STEP 5 — STYLE FIXES + STRUCTURAL REFACTORING
|
||||
|
||||
For approved style and structural items:
|
||||
|
||||
1. Load and follow `$HOME/.claude/agents/refactorer.md`
|
||||
2. Pass the approved list as the refactoring scope
|
||||
3. The refactorer handles the actual code changes with its own
|
||||
safety process (pre-report, function-by-function, test after each)
|
||||
|
||||
Do NOT call the `/refactor` skill — invoke the agent directly.
|
||||
|
||||
### STEP 6 — LOG DISCOVERED BUGS
|
||||
|
||||
If cleanup reveals actual bugs (not style issues — real defects):
|
||||
|
||||
- Append each bug to `BUGS-FOUND.md` at project root:
|
||||
```
|
||||
## [date] Bug found during code-clean
|
||||
- **File**: <file:line>
|
||||
- **Description**: <what's wrong>
|
||||
- **Severity**: <estimate>
|
||||
- **Discovered while**: <what cleanup task surfaced it>
|
||||
```
|
||||
- Do NOT fix bugs here. Cleanup and bugfixing are separate concerns.
|
||||
|
||||
### STEP 7 — RE-AUDIT
|
||||
|
||||
After all changes are applied:
|
||||
|
||||
1. Re-scan only the modified files
|
||||
2. Verify no new issues were introduced
|
||||
3. Run tests if available:
|
||||
```bash
|
||||
# detect and run project test suite
|
||||
```
|
||||
4. Run linter/formatter if available
|
||||
|
||||
### STEP 8 — SUMMARY
|
||||
|
||||
```
|
||||
CODE-CLEAN COMPLETE — <target>
|
||||
|
||||
REMOVED:
|
||||
- <N> dead code items (unused imports, functions, commented blocks)
|
||||
|
||||
REFACTORED:
|
||||
- <N> style fixes
|
||||
- <N> structural improvements
|
||||
|
||||
SKIPPED (user decision):
|
||||
- <item> — <reason>
|
||||
|
||||
BUGS FOUND: <N> (logged to BUGS-FOUND.md)
|
||||
|
||||
TESTS: passing / no test suite / <failures>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## RULES
|
||||
|
||||
- Zero behavior change. If you're unsure whether a deletion changes
|
||||
behavior, leave it and flag it — never guess.
|
||||
- No "while we're here" scope creep. Only fix approved items.
|
||||
- Exported/public API symbols require explicit per-item user confirmation
|
||||
before deletion — even if they appear unused.
|
||||
- Bugs go to BUGS-FOUND.md, not fixed in this workflow.
|
||||
- If the codebase has no tests and the changes are non-trivial,
|
||||
warn the user about the risk before executing.
|
||||
- No plugin check (lightweight skill, not an orchestrator).
|
||||
- If the audit reveals systemic issues requiring architecture changes,
|
||||
stop and suggest `/ship-feature` for a proper redesign.
|
||||
88
agents/commit-changer.md
Normal file
88
agents/commit-changer.md
Normal file
@ -0,0 +1,88 @@
|
||||
---
|
||||
name: commit-changer
|
||||
description: Analyze all changes since the last commit (staged, unstaged, untracked files) and create well-structured commits grouped by logical unit.
|
||||
tools: Bash, Read, Grep, Glob, Agent, AskUserQuestion
|
||||
---
|
||||
|
||||
# Git Smart Commit
|
||||
|
||||
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.
|
||||
|
||||
## 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
|
||||
257
agents/doc-syncer.md
Normal file
257
agents/doc-syncer.md
Normal file
@ -0,0 +1,257 @@
|
||||
---
|
||||
name: doc-syncer
|
||||
description: Detect stale documentation by cross-referencing git history against doc files. Audit, report, and patch. Supports full audit and automatic (silent) mode.
|
||||
tools: Read, Write, Edit, Bash, Grep, Glob
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# DOC SYNCER
|
||||
|
||||
## GOAL
|
||||
Keep documentation in sync with code. Detect drift, report it,
|
||||
and patch what can be patched automatically. Never invent content
|
||||
-- only reflect what actually changed in code.
|
||||
|
||||
## REQUEST
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## MODE DETECTION
|
||||
|
||||
Parse `$ARGUMENTS` to determine mode:
|
||||
|
||||
- **AUTO MODE** — `$ARGUMENTS` starts with `auto-mode scope:`
|
||||
Jump directly to AUTO MODE section below.
|
||||
- **FULL AUDIT** — anything else (empty, file list, description)
|
||||
Run the full audit workflow below.
|
||||
|
||||
---
|
||||
|
||||
## FULL AUDIT
|
||||
|
||||
### STEP 1 — DISCOVER DOCS
|
||||
|
||||
Find all documentation files in the project:
|
||||
|
||||
```bash
|
||||
# Standard doc files at root
|
||||
ls README.md CLAUDE.md INSTALL.md CONFIGURE.md USAGE.md \
|
||||
CONTRIBUTING.md CHANGELOG.md 2>/dev/null
|
||||
|
||||
# Docs directory
|
||||
find docs -name '*.md' 2>/dev/null | head -50
|
||||
```
|
||||
|
||||
Store the list as `DOC_FILES`.
|
||||
If no docs found at all, report and stop.
|
||||
|
||||
### STEP 2 — DETECT DRIFT PER DOC
|
||||
|
||||
For each file in `DOC_FILES`:
|
||||
|
||||
1. Get its last modification date:
|
||||
```bash
|
||||
git log -1 --format=%aI -- <file>
|
||||
```
|
||||
|
||||
2. Get all commits touching the codebase since that date:
|
||||
```bash
|
||||
git log --oneline --since="<date>" \
|
||||
--diff-filter=AMRD -- '*.py' '*.ts' '*.js' '*.tsx' \
|
||||
'*.jsx' '*.rs' '*.go' '*.java' '*.c' '*.cpp' '*.h' \
|
||||
'*.toml' '*.json' '*.yaml' '*.yml' '*.env.example' \
|
||||
'Dockerfile' 'docker-compose.yml' 'Makefile' \
|
||||
'package.json' 'Cargo.toml' 'pyproject.toml'
|
||||
```
|
||||
Adapt glob list to the project's actual stack.
|
||||
|
||||
3. For each commit, extract what changed:
|
||||
```bash
|
||||
git show --stat --name-only <hash>
|
||||
git diff <hash>~1..<hash> --unified=3
|
||||
```
|
||||
Look for: new/renamed/deleted functions, new config keys,
|
||||
new CLI flags, changed endpoints, breaking changes,
|
||||
dependency adds/removes/upgrades.
|
||||
|
||||
4. Cross-reference each change against the doc's content.
|
||||
Read the doc file and check if the change is reflected.
|
||||
|
||||
### STEP 3 — ANALYSIS PER DOC TYPE
|
||||
|
||||
Apply doc-specific checks:
|
||||
|
||||
**README.md**
|
||||
- Install steps: do commands still match package manifest and CLAUDE.md?
|
||||
- Feature list: does it cover current functionality?
|
||||
- Examples: do code snippets match current API/signatures?
|
||||
- Prerequisites: are versions and tools still accurate?
|
||||
- Docker section: present if Docker is used, absent if not?
|
||||
|
||||
**CLAUDE.md**
|
||||
- Norms: do coding conventions match current project patterns?
|
||||
- Stack description: still accurate?
|
||||
- Commands (build/test/lint): still runnable?
|
||||
- Folder tree: matches actual structure?
|
||||
- New patterns worth documenting?
|
||||
|
||||
**INSTALL.md / CONFIGURE.md**
|
||||
- Environment variables: do all referenced vars exist in .env.example?
|
||||
- Install steps: match current dependency manager and versions?
|
||||
- Configuration steps: reference current config file format?
|
||||
|
||||
**USAGE.md**
|
||||
- CLI flags and commands: match current implementation?
|
||||
- API endpoints: match current routes?
|
||||
- Code examples: match current signatures?
|
||||
|
||||
**CONTRIBUTING.md**
|
||||
- Branch workflow: still accurate?
|
||||
- Test commands: still correct?
|
||||
- Code style rules: still enforced?
|
||||
|
||||
**CHANGELOG.md**
|
||||
- Latest code changes: do they have corresponding entries?
|
||||
- Entry format: consistent with existing style?
|
||||
|
||||
**docs/**/*.md**
|
||||
- Technical accuracy: do references to code match reality?
|
||||
- Links: do internal links point to existing files/sections?
|
||||
|
||||
**Inline comments (JSDoc, docstrings, rustdoc, godoc)**
|
||||
- Only check files that changed since last doc update.
|
||||
- `@param` / `@return` types: match actual function signatures?
|
||||
- Description: still accurate after the change?
|
||||
|
||||
### STEP 4 — REPORT
|
||||
|
||||
Present a structured report:
|
||||
|
||||
```
|
||||
DOC SYNC REPORT
|
||||
===============
|
||||
|
||||
## <filename>
|
||||
Last updated: <date> (<N commits since>)
|
||||
|
||||
1. [AUTO] <section> — <what's wrong>
|
||||
Commit: <hash> — <message>
|
||||
Fix: <proposed change>
|
||||
|
||||
2. [HUMAN] <section> — <what's wrong>
|
||||
Commit: <hash> — <message>
|
||||
Reason: <why this needs human judgment>
|
||||
|
||||
---
|
||||
(repeat for each doc with drift)
|
||||
```
|
||||
|
||||
Tagging rules:
|
||||
- **AUTO** — factual update Claude can write: command changed,
|
||||
var renamed, param added, version bumped, file moved.
|
||||
- **HUMAN** — needs business context or judgment: feature
|
||||
description wording, architecture rationale, changelog entry
|
||||
content, new section creation.
|
||||
|
||||
CHANGELOG entries are always tagged HUMAN — version bump and
|
||||
release notes are human decisions.
|
||||
|
||||
If no drift detected in any doc: print
|
||||
`DOC SYNC: all docs current` and stop.
|
||||
|
||||
### STEP 5 — VALIDATION GATE (mandatory stop)
|
||||
|
||||
```
|
||||
DOC SYNC — VALIDATION GATE
|
||||
AUTO items : <count> (Claude will patch these)
|
||||
HUMAN items: <count> (listed above for your review)
|
||||
|
||||
Apply AUTO patches? (yes / select items / cancel)
|
||||
```
|
||||
|
||||
Wait for explicit approval. Do not proceed without it.
|
||||
|
||||
### STEP 6 — PATCH
|
||||
|
||||
Apply only approved AUTO items:
|
||||
- Surgical edits only. Preserve existing structure and tone.
|
||||
- For each edit, use the Edit tool with minimal old_string/new_string.
|
||||
- Do not rewrite surrounding prose. Do not reformat.
|
||||
- If a doc section doesn't exist yet for a change, propose creating
|
||||
it but do NOT auto-write. Tag as HUMAN and surface to user.
|
||||
|
||||
After patching, re-read each modified file to verify no broken
|
||||
markdown, no orphaned references.
|
||||
|
||||
### OUTPUT
|
||||
|
||||
```
|
||||
DOC SYNC COMPLETE
|
||||
DOCS CHECKED : <count>
|
||||
AUTO PATCHED : <count> items across <count> files
|
||||
HUMAN PENDING: <count> items (see report above)
|
||||
SKIPPED : <count> (user declined)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## AUTO MODE
|
||||
|
||||
Triggered by other skills at end of session.
|
||||
Input format: `auto-mode scope: <file1> <file2> ...`
|
||||
|
||||
### STEP A1 — PARSE SCOPE
|
||||
|
||||
Extract the file list from `$ARGUMENTS`.
|
||||
These are files modified during the current session.
|
||||
|
||||
### STEP A2 — IDENTIFY RELEVANT DOCS
|
||||
|
||||
For each modified file, determine which docs might reference it:
|
||||
- Code files → README (examples, feature list), USAGE, docs/
|
||||
- Config files → INSTALL, CONFIGURE, README (setup section)
|
||||
- Package manifest → README (prerequisites, install), INSTALL
|
||||
- Dockerfile/compose → README (Docker section), INSTALL
|
||||
- CLAUDE.md changes → skip (CLAUDE.md is self-documenting)
|
||||
|
||||
If no relevant docs exist for the changed files → exit silently.
|
||||
|
||||
### STEP A3 — QUICK DRIFT CHECK
|
||||
|
||||
For each relevant doc, read it and check only the sections that
|
||||
could be affected by the scoped changes. No full git scan —
|
||||
compare the doc content directly against the current state of
|
||||
the modified files.
|
||||
|
||||
Categorize findings:
|
||||
- **NONE** — no drift detected
|
||||
- **MINOR** — factual correction (command, param, path, version)
|
||||
- **SIGNIFICANT** — new feature undocumented, section outdated,
|
||||
breaking change not reflected
|
||||
|
||||
### STEP A4 — ACT
|
||||
|
||||
- **NONE** → exit completely silent. No output at all.
|
||||
- **MINOR** → patch silently. Print one-line confirmation:
|
||||
`doc-sync: patched <file> (<what changed>)`
|
||||
- **SIGNIFICANT** → surface to user before patching:
|
||||
```
|
||||
DOC SYNC — drift detected after this session:
|
||||
<list of significant items with proposed fixes>
|
||||
Apply? (yes / no / select)
|
||||
```
|
||||
Wait for approval.
|
||||
|
||||
---
|
||||
|
||||
## RULES
|
||||
- Never invent content. Only sync what changed in code.
|
||||
- Never fabricate examples, feature descriptions, or explanations.
|
||||
- If a doc section doesn't exist yet, propose creating it but
|
||||
don't auto-write (tag HUMAN).
|
||||
- CHANGELOG entries: always propose, never auto-write.
|
||||
- Inline comment updates: only for files in scope, only when
|
||||
signature actually changed.
|
||||
- Preserve existing doc structure, formatting, and tone.
|
||||
- Keep patches minimal — change what's wrong, nothing else.
|
||||
125
agents/feater.md
Normal file
125
agents/feater.md
Normal file
@ -0,0 +1,125 @@
|
||||
---
|
||||
name: feater
|
||||
description: Small feature implementation (1-5 files). Light planning, direct implementation, no heavy orchestration. No design brainstorm, no subagents, no plugin check gate.
|
||||
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 — load `$HOME/.claude/agents/hotfixer.md` 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 — load
|
||||
`$HOME/.claude/agents/commit-changer.md` and follow its grouping logic.
|
||||
|
||||
Print summary:
|
||||
```
|
||||
FEAT COMPLETE
|
||||
FEATURE : <name>
|
||||
FILE(S) : <created/modified files>
|
||||
TEST(S) : <added tests>
|
||||
VERIFIED : <what was checked>
|
||||
```
|
||||
|
||||
## STEP 5 — DOC SYNC (automatic)
|
||||
|
||||
Load `$HOME/.claude/agents/doc-syncer.md`.
|
||||
Execute in automatic mode:
|
||||
`auto-mode scope: <list of files modified during this session>`
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
78
agents/hotfixer.md
Normal file
78
agents/hotfixer.md
Normal file
@ -0,0 +1,78 @@
|
||||
---
|
||||
name: hotfixer
|
||||
description: Quick fix for superficial bugs (typos, CSS issues, config errors, off-by-one, wrong variable name, missing import, broken link). Max 2 files, obvious root cause only.
|
||||
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. Load `$HOME/.claude/agents/bugfixer.md`
|
||||
and run the BUGFIXER agent on this target."
|
||||
|
||||
## 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>
|
||||
```
|
||||
|
||||
## STEP 4 — DOC SYNC (automatic)
|
||||
|
||||
Load `$HOME/.claude/agents/doc-syncer.md`.
|
||||
Execute in automatic mode:
|
||||
`auto-mode scope: <list of files modified during this session>`
|
||||
|
||||
---
|
||||
|
||||
## 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,81 +0,0 @@
|
||||
---
|
||||
name: readme-updater
|
||||
description: Manage project README. Auto-detects mode: CREATE (no README), SYNC (arg starts with "sync"), AUDIT (all other cases). Called by /readme, init-project, ship-feature.
|
||||
tools: Read, Write, Edit, Bash, Glob, Grep
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# README UPDATER
|
||||
|
||||
## MODES
|
||||
|
||||
First word of `$ARGUMENTS` determines mode. CREATE takes precedence if README.md missing.
|
||||
|
||||
- **CREATE** — README.md doesn't exist → build from scratch
|
||||
- **SYNC** — first word is exactly `sync` → silent updates, no stop
|
||||
- **AUDIT** — anything else (empty, description, "audit") → full diff + mandatory stop
|
||||
|
||||
## DOCKER DETECTION (run in all modes before writing)
|
||||
|
||||
Docker relevant if: Dockerfile or docker-compose.yml present, or CLAUDE.md mentions deploy/service/API/server/Docker, or project is web app/API/backend/SaaS, or has DB/Redis/Kafka dep.
|
||||
Docker NOT relevant if: library, CLI (no server), mobile app, driver/plugin.
|
||||
Store as `DOCKER_RELEVANT = true/false`.
|
||||
|
||||
---
|
||||
|
||||
## CREATE MODE
|
||||
|
||||
Sources (in order): CLAUDE.md, folder structure (`find . -not -path '*/.git/*' -not -path '*/node_modules/*' ... | head -80`), package manifest, .env.example, Dockerfile/compose if present.
|
||||
|
||||
Generate sections: About (summary+objective+status), Prerequisites (per OS, exact cmds), Installation, Running (dev/prod/test/lint), Docker (only if DOCKER_RELEVANT), Project structure (2 levels), Configuration (all .env.example vars), Contributing (branch → test → commit → PR).
|
||||
|
||||
Rules: exact runnable commands only, derive from CLAUDE.md, no placeholders.
|
||||
|
||||
Output: `📄 README created — <N sections> [Docker: included/N/A]`. No stop.
|
||||
|
||||
---
|
||||
|
||||
## SYNC MODE
|
||||
|
||||
Read: README.md, CLAUDE.md, git log (last 20), folder structure, manifests.
|
||||
|
||||
Apply only clear factual mismatches (no prose rewrites, no speculation, no stops):
|
||||
- Changed commands in CLAUDE.md not in README
|
||||
- New .env.example vars undocumented
|
||||
- Changed folder structure
|
||||
- Version bumps in manifests
|
||||
- Docker section added/removed if DOCKER_RELEVANT changed
|
||||
- Add `## Recent changes` if 5+ commits since last README update and no changelog
|
||||
|
||||
Output: `📄 README synced — <N changes / "no changes needed"> [Docker: <status>]`
|
||||
|
||||
---
|
||||
|
||||
## AUDIT MODE
|
||||
|
||||
### Phase 1 — Read
|
||||
README.md, CLAUDE.md, `git log --oneline -50`, `git diff HEAD~20..HEAD --stat`, folder structure, manifest, .env.example, Dockerfile/compose if present.
|
||||
|
||||
### Phase 2 — Status per section
|
||||
✅ current | 📝 update | ➕ missing | ❌ remove
|
||||
|
||||
Check: About still accurate, prereqs versions, install/run cmds, Docker section vs DOCKER_RELEVANT, structure vs reality, all .env vars documented.
|
||||
|
||||
### Phase 3 — Report + MANDATORY STOP
|
||||
|
||||
```
|
||||
README AUDIT
|
||||
LAST COMMIT : <hash — msg>
|
||||
DOCKER : relevant ✅/❌ — section present/missing/N/A
|
||||
SUMMARY : ✅<n> 📝<n> ➕<n> ❌<n>
|
||||
DETAIL : <per-section findings>
|
||||
Proceed? (yes / select sections / cancel)
|
||||
```
|
||||
|
||||
### Phase 4 — Apply (after confirmation)
|
||||
Surgical edits only. Preserve structure and tone. 📝 replace, ➕ insert, ❌ remove or mark deprecated.
|
||||
|
||||
### Phase 5 — Verify
|
||||
Re-read. No broken markdown. Commands consistent with CLAUDE.md.
|
||||
|
||||
Output: `📄 README updated — <summary>`
|
||||
@ -119,5 +119,13 @@ INSTALL : ✅ / ❌ <error>
|
||||
BUILD : ✅ / ❌ <error>
|
||||
DOCKER BUILD: ✅ / ⚠️ not verified / N/A
|
||||
STRUCTURE: <tree>
|
||||
READY: <N> v1 features | entry points ✅ | config ✅ | CLAUDE.md ✅ | README → readme-updater | settings ✅
|
||||
READY: <N> v1 features | entry points ✅ | config ✅ | CLAUDE.md ✅ | README → doc-syncer | settings ✅
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PHASE 6 — DOC SYNC (automatic)
|
||||
|
||||
Load `$HOME/.claude/agents/doc-syncer.md`.
|
||||
Execute in automatic mode:
|
||||
`auto-mode scope: <list of all files created during scaffolding>`
|
||||
|
||||
317
agents/seo-analyzer.md
Normal file
317
agents/seo-analyzer.md
Normal file
@ -0,0 +1,317 @@
|
||||
---
|
||||
name: seo-analyzer
|
||||
description: Full SEO audit and fix agent. Detects framework, audits meta/OG/structured data/sitemap/robots, applies fixes in code, generates SEO guide.
|
||||
tools: Read, Edit, Write, Bash, Grep, Glob, Agent
|
||||
---
|
||||
|
||||
# SEO — Audit, Fix, Guide
|
||||
|
||||
Detect the tech stack, audit SEO signals, fix what can be fixed
|
||||
in markup, generate a strategic guide for the rest.
|
||||
|
||||
## REQUEST
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## STEP 1 — DETECT
|
||||
|
||||
Understand the project before touching anything.
|
||||
|
||||
### Framework & rendering model
|
||||
|
||||
```bash
|
||||
# package.json, composer.json, Gemfile, etc.
|
||||
cat package.json 2>/dev/null | head -30
|
||||
ls -la
|
||||
```
|
||||
|
||||
Identify: Next.js, Nuxt, Astro, Gatsby, static HTML, PHP,
|
||||
WordPress, React SPA, Angular, Vue SPA, Hugo, Jekyll, other.
|
||||
Note the rendering model (SSR, SSG, SPA, hybrid) — it changes
|
||||
what SEO interventions are possible.
|
||||
|
||||
### Current SEO state
|
||||
|
||||
Audit each of these. For each item, record: present/absent,
|
||||
correct/incorrect, notes.
|
||||
|
||||
1. **`<title>` and `<meta name="description">`** — per page if
|
||||
possible, at least the main layout/template.
|
||||
2. **Open Graph tags** — `og:title`, `og:description`, `og:image`,
|
||||
`og:url`, `og:type`, `og:locale`.
|
||||
3. **Twitter Cards** — `twitter:card`, `twitter:title`,
|
||||
`twitter:description`, `twitter:image`.
|
||||
4. **Canonical tags** — `<link rel="canonical">` per page.
|
||||
5. **`robots.txt`** — exists? Blocks important paths?
|
||||
6. **`sitemap.xml`** — exists? Up to date? Referenced in robots.txt?
|
||||
7. **Structured data (JSON-LD)** — any existing `<script type="application/ld+json">`?
|
||||
Which schemas?
|
||||
8. **Heading hierarchy** — single `<h1>` per page? Logical nesting?
|
||||
9. **Image `alt` attributes** — present on all `<img>`?
|
||||
10. **`hreflang`** — needed if multilingual content detected.
|
||||
11. **Internal linking** — navigation structure, orphan pages.
|
||||
12. **URL structure** — clean, descriptive, no query-string routing.
|
||||
|
||||
```
|
||||
SEO AUDIT
|
||||
FRAMEWORK : <name + version>
|
||||
RENDERING : <SSR / SSG / SPA / hybrid>
|
||||
TITLE/META : <status>
|
||||
OPEN GRAPH : <status>
|
||||
TWITTER CARD: <status>
|
||||
CANONICAL : <status>
|
||||
ROBOTS.TXT : <status>
|
||||
SITEMAP.XML : <status>
|
||||
JSON-LD : <status>
|
||||
HEADINGS : <status>
|
||||
ALT ATTRS : <status>
|
||||
HREFLANG : <status>
|
||||
INTERNAL LINKS: <status>
|
||||
URL STRUCTURE : <status>
|
||||
```
|
||||
|
||||
## STEP 2 — INTERVIEW (if needed)
|
||||
|
||||
Some SEO decisions require business context that the code
|
||||
cannot tell you: target keywords, geographic scope, audience,
|
||||
competitors, business type.
|
||||
|
||||
If $ARGUMENTS already provides this context (e.g.
|
||||
`"local SEO plombier 91 94 77"`), extract what you can and
|
||||
skip redundant questions.
|
||||
|
||||
If critical info is missing, load and follow:
|
||||
`$HOME/.claude/agents/interviewer.md`
|
||||
|
||||
**Questions to ask** (skip any answerable from the codebase or
|
||||
$ARGUMENTS — max 8 total, grouped by theme):
|
||||
|
||||
**Business context**
|
||||
- What does the business do? (type, industry)
|
||||
- Who is the target audience?
|
||||
|
||||
**Keywords & geography**
|
||||
- Primary keywords / phrases to rank for?
|
||||
- Geographic scope: national, local (which cities/departments)?
|
||||
- Local SEO needed? (physical address, service area)
|
||||
|
||||
**Competition & goals**
|
||||
- Competitor URLs to benchmark against?
|
||||
- Priority: organic search, local pack, featured snippets?
|
||||
|
||||
**Content**
|
||||
- Main languages of the site?
|
||||
- Blog / content marketing planned?
|
||||
|
||||
After receiving answers, proceed to STEP 3.
|
||||
|
||||
## STEP 3 — FIX IN CODE
|
||||
|
||||
Apply SEO fixes directly. Scope: **markup and metadata only**.
|
||||
Never modify business logic, layout, styles, or functionality.
|
||||
|
||||
### What to fix
|
||||
|
||||
1. **`<title>` + `<meta name="description">`**
|
||||
- Unique per page. Title: 50-60 chars. Description: 150-160 chars.
|
||||
- Include primary keyword naturally.
|
||||
|
||||
2. **Open Graph tags** (in `<head>`)
|
||||
```html
|
||||
<meta property="og:title" content="..." />
|
||||
<meta property="og:description" content="..." />
|
||||
<meta property="og:image" content="..." />
|
||||
<meta property="og:url" content="..." />
|
||||
<meta property="og:type" content="website" />
|
||||
<meta property="og:locale" content="fr_FR" />
|
||||
```
|
||||
|
||||
3. **Twitter Cards** (in `<head>`)
|
||||
```html
|
||||
<meta name="twitter:card" content="summary_large_image" />
|
||||
<meta name="twitter:title" content="..." />
|
||||
<meta name="twitter:description" content="..." />
|
||||
<meta name="twitter:image" content="..." />
|
||||
```
|
||||
|
||||
4. **JSON-LD structured data** — pick schemas based on context:
|
||||
- `Organization` — always, for the business entity.
|
||||
- `LocalBusiness` — if local SEO (address, phone, hours).
|
||||
- `BreadcrumbList` — if multi-level navigation.
|
||||
- `WebPage` / `WebSite` — for main pages.
|
||||
- `FAQPage`, `Product`, `Service` — if content matches.
|
||||
Place as `<script type="application/ld+json">` in `<head>`.
|
||||
|
||||
5. **`sitemap.xml`** — create or update. List all public URLs.
|
||||
For dynamic frameworks, prefer the built-in sitemap plugin
|
||||
(e.g. `next-sitemap`, `@astrojs/sitemap`).
|
||||
|
||||
6. **`robots.txt`** — create or fix.
|
||||
```
|
||||
User-agent: *
|
||||
Allow: /
|
||||
Sitemap: https://<domain>/sitemap.xml
|
||||
```
|
||||
Ensure it does NOT block CSS/JS needed for rendering.
|
||||
|
||||
7. **Canonical tags** — add `<link rel="canonical" href="...">` on
|
||||
every page. Self-referencing unless duplicates exist.
|
||||
|
||||
8. **`hreflang`** — add if multilingual content detected:
|
||||
```html
|
||||
<link rel="alternate" hreflang="fr" href="..." />
|
||||
<link rel="alternate" hreflang="en" href="..." />
|
||||
<link rel="alternate" hreflang="x-default" href="..." />
|
||||
```
|
||||
|
||||
9. **Heading hierarchy** — fix if broken (multiple `<h1>`,
|
||||
skipped levels). One `<h1>` per page containing the primary
|
||||
keyword.
|
||||
|
||||
10. **Image `alt` attributes** — add descriptive alt text to
|
||||
images missing it. Keep concise, include keyword where natural.
|
||||
|
||||
11. **Internal link suggestions** — add as code comments where
|
||||
relevant pages should cross-link:
|
||||
```html
|
||||
<!-- SEO: consider linking to /services/plomberie here -->
|
||||
```
|
||||
|
||||
### Framework-specific notes
|
||||
|
||||
- **Next.js**: use `metadata` export (App Router) or `Head`
|
||||
component (Pages Router). Use `next-sitemap` for sitemap.
|
||||
- **Astro**: use `<SEO>` or direct `<meta>` in layouts.
|
||||
Use `@astrojs/sitemap` integration.
|
||||
- **Nuxt**: use `useHead()` composable or `nuxt.config` meta.
|
||||
- **Static HTML**: edit `<head>` directly.
|
||||
- **React SPA**: flag that SEO is severely limited without SSR.
|
||||
Add meta tags via `react-helmet` but warn about SPA
|
||||
limitations in the report.
|
||||
|
||||
## STEP 4 — GENERATE SEO-GUIDE.md
|
||||
|
||||
Create `SEO-GUIDE.md` at the project root with two sections.
|
||||
Be concrete: tools, URLs, step-by-step instructions.
|
||||
Mix French and English naturally where relevant (the user
|
||||
is French-speaking).
|
||||
|
||||
```markdown
|
||||
# SEO Guide — <Project Name>
|
||||
|
||||
## Quick Wins (< 1h each)
|
||||
|
||||
### Google Search Console
|
||||
1. Go to https://search.google.com/search-console
|
||||
2. Add property → URL prefix → enter your domain
|
||||
3. Verify via DNS TXT record or HTML file upload
|
||||
4. Submit your sitemap URL: https://<domain>/sitemap.xml
|
||||
5. Check "Coverage" tab for indexing errors
|
||||
|
||||
### Google Business Profile (if local)
|
||||
1. Go to https://business.google.com
|
||||
2. Create or claim your business listing
|
||||
3. Fill: name, address, phone, hours, categories, photos
|
||||
4. "Plus ta fiche Google est complete, mieux tu seras reference"
|
||||
5. Respond to every review — Google rewards activity
|
||||
|
||||
### Structured Data Testing
|
||||
1. Go to https://validator.schema.org
|
||||
2. Enter your URL → check for errors/warnings
|
||||
3. Also test with https://search.google.com/test/rich-results
|
||||
4. Fix any errors flagged in JSON-LD
|
||||
|
||||
### Canonical Verification
|
||||
1. View source on each page → search for `rel="canonical"`
|
||||
2. Ensure each canonical points to itself (no duplicates)
|
||||
3. Check Google Search Console → "URL Inspection" for each page
|
||||
|
||||
## Strategic (ongoing)
|
||||
|
||||
### Backlinks
|
||||
- "Plus tu as de liens vers ton site sur le web, mieux c'est reference"
|
||||
- Register on relevant directories (Pages Jaunes, Yelp, etc.)
|
||||
- Guest posts on industry blogs
|
||||
- Partner cross-linking
|
||||
- Tool: https://ahrefs.com/backlink-checker (free tier)
|
||||
|
||||
### Local Citations (if applicable)
|
||||
- Ensure NAP (Name, Address, Phone) is identical everywhere
|
||||
- Register on: Google Business, Pages Jaunes, Yelp, Foursquare,
|
||||
local chamber of commerce
|
||||
- "Optimiser sa fiche Google" = keep it updated, add posts weekly
|
||||
|
||||
### Core Web Vitals
|
||||
- Monitor at https://pagespeed.web.dev
|
||||
- Key metrics: LCP < 2.5s, FID < 100ms, CLS < 0.1
|
||||
- Fix: optimize images (WebP), lazy load below-fold, minimize JS
|
||||
|
||||
### Content Strategy
|
||||
- Blog with keyword-targeted articles (1-2 per month minimum)
|
||||
- Answer "People Also Ask" questions from Google SERPs
|
||||
- Use https://answerthepublic.com for content ideas
|
||||
- Internal link new content to existing pages
|
||||
|
||||
### Social Signals
|
||||
- Share every new page/article on social platforms
|
||||
- OpenGraph tags ensure proper preview cards (already set up)
|
||||
- Consistent posting builds domain authority over time
|
||||
|
||||
### GEO (Generative Engine Optimization)
|
||||
- Structured data helps AI engines understand your content
|
||||
- Clear, factual content with citations ranks in AI answers
|
||||
- FAQ sections are particularly well-suited for AI extraction
|
||||
```
|
||||
|
||||
Adapt sections based on what's relevant to the project. Remove
|
||||
sections that don't apply (e.g. local SEO for a SaaS product).
|
||||
|
||||
## STEP 5 — REPORT
|
||||
|
||||
Print a clear summary of everything done:
|
||||
|
||||
```
|
||||
SEO ANALYSIS COMPLETE
|
||||
FRAMEWORK: <name + rendering model>
|
||||
|
||||
CHANGES APPLIED:
|
||||
[x] <file> — <what was changed>
|
||||
[x] <file> — <what was changed>
|
||||
...
|
||||
|
||||
SKIPPED (with reason):
|
||||
[ ] <item> — <why: not applicable / needs manual work / blocked>
|
||||
...
|
||||
|
||||
CONFIDENCE:
|
||||
<item>: HIGH / MEDIUM / LOW — <why>
|
||||
...
|
||||
|
||||
CONFLICTS:
|
||||
<any issues found, e.g. robots.txt blocking crawlers,
|
||||
SPA limiting SEO effectiveness, missing domain for canonical>
|
||||
|
||||
NEXT STEPS:
|
||||
See SEO-GUIDE.md for quick wins and long-term strategy.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## RULES
|
||||
|
||||
- **Markup only.** Never change business logic, layout, styles,
|
||||
component structure, or routing.
|
||||
- **No invented content.** Meta descriptions and titles must
|
||||
reflect actual page content. If you can't determine the right
|
||||
text, add a placeholder with a `<!-- SEO: TODO -->` comment.
|
||||
- **Preserve existing valid SEO.** If a meta tag is already
|
||||
correct, don't rewrite it.
|
||||
- **Flag SPA limitations.** If the project is a client-side SPA
|
||||
with no SSR, explicitly warn that SEO will be severely limited
|
||||
regardless of meta tag fixes.
|
||||
- **No external service calls.** Don't curl APIs, don't fetch
|
||||
competitor pages. Work with the local codebase only.
|
||||
- **One `<h1>` per page.** If you find multiple, fix the hierarchy.
|
||||
- **JSON-LD over microdata.** Prefer `application/ld+json` script
|
||||
blocks. They're easier to maintain and don't pollute HTML.
|
||||
@ -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.
|
||||
|
||||
29
skills/code-clean/SKILL.md
Normal file
29
skills/code-clean/SKILL.md
Normal file
@ -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
|
||||
|
||||
29
skills/doc/SKILL.md
Normal file
29
skills/doc/SKILL.md
Normal file
@ -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
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
28
skills/seo/SKILL.md
Normal file
28
skills/seo/SKILL.md
Normal file
@ -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>`
|
||||
|
||||
---
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user