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>
2026-04-15 20:18:34 +02:00
parent 9d73d31cde
commit 0241e1ddc8
18 changed files with 1313 additions and 473 deletions
@@ -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