refactor: extract skills from commands across 8 plugins

Refactored commands to extract reusable skills following the
Commands → Skills separation pattern. Each command is now <50 lines
and references skill files for detailed knowledge.

Plugins refactored:
- claude-config-maintainer: 5 commands → 7 skills
- code-sentinel: 3 commands → 2 skills
- contract-validator: 5 commands → 6 skills
- data-platform: 10 commands → 6 skills
- doc-guardian: 5 commands → 6 skills (replaced nested dir)
- git-flow: 8 commands → 7 skills

Skills contain: workflows, validation rules, conventions,
reference data, tool documentation

Commands now contain: YAML frontmatter, agent assignment,
skills list, brief workflow steps, parameters

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
2026-01-30 17:32:24 -05:00
parent aad02ef2d9
commit 7c8a20c804
71 changed files with 3896 additions and 3690 deletions

View File

@@ -0,0 +1,121 @@
---
name: changelog-format
description: Keep a Changelog format and Conventional Commits parsing
---
# Changelog Format
## Purpose
Defines Keep a Changelog format and how to parse Conventional Commits.
## When to Use
- **changelog-gen**: Generating changelog entries from commits
- **git-flow integration**: Validating commit message format
---
## Conventional Commits Pattern
```
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
```
---
## Type to Section Mapping
| Commit Type | Changelog Section |
|-------------|------------------|
| `feat` | Added |
| `fix` | Fixed |
| `docs` | Documentation |
| `perf` | Performance |
| `refactor` | Changed |
| `style` | Changed |
| `test` | Testing |
| `build` | Build |
| `ci` | CI/CD |
| `chore` | Maintenance |
| `BREAKING CHANGE` | Breaking Changes |
---
## Keep a Changelog Sections
Standard order (only include non-empty):
1. Breaking Changes
2. Added
3. Changed
4. Deprecated
5. Removed
6. Fixed
7. Security
---
## Breaking Changes Detection
Detected by:
- `!` suffix on type: `feat!: new auth system`
- `BREAKING CHANGE` in footer
- `BREAKING-CHANGE` in footer
---
## Entry Formatting
For each commit:
1. Extract scope (if present) as bold prefix: `**scope**: `
2. Use description as entry text
3. Link to commit hash if repository URL available
4. Include PR/issue references from footer
### Example Output
```markdown
## [Unreleased]
### Breaking Changes
- **auth**: Remove deprecated OAuth1 support
### Added
- **api**: New batch processing endpoint
- User preference saving feature
### Changed
- **core**: Improve error message clarity
### Fixed
- **api**: Handle null values in response
```
---
## Non-Conventional Handling
Commits not following format:
- List under "Other" section
- Flag for manual categorization
- Skip if `--strict` flag used
---
## Commit Range Detection
1. Default: commits since last tag
2. First release: all commits from initial
3. Explicit: `--from <tag> --to <ref>`
```bash
# Find last tag
git describe --tags --abbrev=0
# Commits since tag
git log v1.0.0..HEAD --oneline
```

View File

@@ -0,0 +1,131 @@
---
name: coverage-calculation
description: Documentation coverage metrics, language patterns, and thresholds
---
# Coverage Calculation
## Purpose
Defines how to calculate documentation coverage and thresholds.
## When to Use
- **doc-coverage**: Full coverage analysis
- **doc-audit**: Completeness checks
---
## Coverage Formula
```
Coverage = (Documented Items / Total Items) * 100
```
---
## Documentable Items by Language
### Python
- Functions (`def`)
- Classes
- Methods
- Module-level docstrings
### JavaScript/TypeScript
- Functions (`function`, arrow functions)
- Classes
- Methods
- JSDoc comments (`/** */`)
### Go
- Functions
- Types
- Methods
- Package comments (`//` above declaration)
### Rust
- Functions
- Structs/Enums
- Impl blocks
- Doc comments (`///`)
---
## Language Detection
| Extension | Language | Doc Format |
|-----------|----------|------------|
| .py | Python | Docstrings (`"""`) |
| .js, .ts | JavaScript/TypeScript | JSDoc (`/** */`) |
| .go | Go | `//` comments above |
| .rs | Rust | `///` doc comments |
| .rb | Ruby | `#` comments, YARD |
| .java | Java | Javadoc (`/** */`) |
---
## Coverage Levels
### Basic
- Item has any docstring/comment
- Not empty or placeholder
### Standard
- Docstring describes purpose
- Non-trivial content (not just `pass` or `TODO`)
### Complete
- All parameters documented
- Return type documented
- Raises/throws documented
---
## Coverage Thresholds
| Level | Coverage | Description |
|-------|----------|-------------|
| Minimal | 60% | Basic documentation exists |
| Good | 80% | Most public APIs documented |
| Excellent | 95% | Comprehensive documentation |
---
## Output Format
```
## Documentation Coverage Report
### Summary
- Total documentable items: 156
- Documented: 142
- Coverage: 91.0%
### By Type
| Type | Total | Documented | Coverage |
|------|-------|------------|----------|
| Functions | 89 | 85 | 95.5% |
| Classes | 23 | 21 | 91.3% |
| Methods | 44 | 36 | 81.8% |
### By Directory
| Path | Total | Documented | Coverage |
|------|-------|------------|----------|
| src/api/ | 34 | 32 | 94.1% |
| src/utils/ | 28 | 28 | 100.0% |
### Undocumented Items
- [ ] src/api/handlers.py:45 `create_order()`
- [ ] src/models/user.py:23 `UserModel.validate()`
```
---
## Exclusion Patterns
Default exclusions:
- `**/test_*` - Test files
- `**/*_test.*` - Test files
- Private members (`_prefixed`) unless `--include-private`
- Generated code (`**/generated/**`)

View File

@@ -0,0 +1,67 @@
---
name: doc-patterns
description: Common documentation structures and patterns
---
# Documentation Patterns
## Purpose
Defines common documentation file structures and their contents.
## When to Use
- **doc-audit**: Understanding what to check in each doc type
- **doc-coverage**: Identifying documentation locations
---
## README.md Patterns
Typical sections:
- **Installation**: Version requirements, dependencies
- **Usage**: Function calls, CLI commands
- **Configuration**: Environment vars, config files
- **API**: Endpoint references
---
## CLAUDE.md Patterns
Typical sections:
- **Project Context**: Tech stack versions
- **File Structure**: Directory layout
- **Commands**: Available operations
- **Workflows**: Process descriptions
---
## Code Documentation
### Docstrings
- Function signatures
- Parameters and types
- Return values
- Raised exceptions
### Type Hints
- Should match docstring types
- Verify consistency
### Inline Comments
- References to other code
- TODO markers
- Warning notes
---
## File Inventory
Standard documentation files to check:
- `README.md` (root and subdirectories)
- `CLAUDE.md`
- `CONTRIBUTING.md`
- `CHANGELOG.md`
- `docs/**/*.md`
- API documentation
- Configuration references

View File

@@ -1,39 +0,0 @@
---
description: Knowledge of documentation patterns and structures for drift detection
---
# Documentation Patterns Skill
## Common Documentation Structures
### README.md Patterns
- Installation section: version requirements, dependencies
- Usage section: function calls, CLI commands
- Configuration section: env vars, config files
- API section: endpoint references
### CLAUDE.md Patterns
- Project context: tech stack versions
- File structure: directory layout
- Commands: available operations
- Workflows: process descriptions
### Code Documentation
- Docstrings: function signatures, parameters, returns
- Type hints: should match docstring types
- Comments: inline references to other code
## Drift Detection Rules
1. **Version Mismatch**: Any hardcoded version in docs must match package.json, pyproject.toml, requirements.txt
2. **Function References**: Function names in docs must exist in codebase with matching signatures
3. **Path References**: File paths in docs must exist in current directory structure
4. **Config Keys**: Environment variables and config keys in docs must be used in code
5. **Command Examples**: CLI examples in docs should be valid commands
## Priority Levels
- **P0 (Critical)**: Broken references that would cause user errors
- **P1 (High)**: Outdated information that misleads users
- **P2 (Medium)**: Missing documentation for public interfaces
- **P3 (Low)**: Style inconsistencies, minor wording issues

View File

@@ -0,0 +1,102 @@
---
name: drift-detection
description: Core drift detection rules, cross-reference analysis, and priority levels
---
# Drift Detection
## Purpose
Defines how to detect documentation drift through cross-reference analysis.
## When to Use
- **doc-audit**: Full cross-reference analysis
- **stale-docs**: Commit-based staleness detection
- **SessionStart hook**: Real-time drift detection
---
## Cross-Reference Analysis
For each documentation file:
1. Extract referenced functions, classes, endpoints, configs
2. Verify each reference exists in codebase
3. Check signatures/types match documentation
4. Flag deprecated or renamed items still in docs
---
## Drift Detection Rules
| Rule | Check | Priority |
|------|-------|----------|
| Version Mismatch | Hardcoded versions must match package.json, pyproject.toml, requirements.txt | P0 |
| Function References | Function names must exist with matching signatures | P0 |
| Path References | File paths must exist in directory structure | P0 |
| Config Keys | Env vars and config keys must be used in code | P1 |
| Command Examples | CLI examples must be valid commands | P1 |
---
## Priority Levels
| Level | Description | Action |
|-------|-------------|--------|
| **P0 (Critical)** | Broken references causing user errors | Immediate fix |
| **P1 (High)** | Outdated information misleading users | Fix in current session |
| **P2 (Medium)** | Missing documentation for public interfaces | Add to backlog |
| **P3 (Low)** | Style inconsistencies, minor wording | Optional |
---
## Drift Categories
### Critical (Broken References)
- Function/class renamed but docs not updated
- File moved/deleted but docs still reference old path
- API endpoint changed but docs show old URL
### Stale (Outdated Info)
- Version numbers not matching actual
- Configuration examples using deprecated keys
- Screenshots of old UI
### Missing (Undocumented)
- Public functions without docstrings
- New features not in README
- Environment variables used but not documented
---
## Documentation File Mapping
| Doc File | Related Code |
|----------|--------------|
| README.md | All files in same directory |
| API.md | src/api/**/* |
| CLAUDE.md | Configuration files, scripts |
| docs/module.md | src/module/**/* |
| Component.md | Component.tsx, Component.css |
---
## Output Format
```
## Documentation Drift Report
### Critical (Broken References)
- [ ] README.md:45 references `calculate_total()` - function renamed to `compute_total()`
### Stale (Outdated Info)
- [ ] CLAUDE.md:23 lists Python 3.9 - project uses 3.11
### Missing (Undocumented)
- [ ] api/handlers.py:`create_order()` - no docstring
### Summary
- Critical: X items
- Stale: X items
- Missing: X items
```

View File

@@ -0,0 +1,127 @@
---
name: staleness-metrics
description: Documentation staleness levels, thresholds, and relationship detection
---
# Staleness Metrics
## Purpose
Defines how to measure documentation staleness relative to code changes.
## When to Use
- **stale-docs**: Commit-based staleness detection
- **doc-audit**: Age-based analysis
---
## Staleness Calculation
```
Commits Behind = Code Commits Since Doc Update
Days Behind = Days Since Doc Update - Days Since Code Update
```
---
## Staleness Levels
| Commits Behind | Level | Action |
|----------------|-------|--------|
| 0-5 | Fresh | No action needed |
| 6-10 | Aging | Review recommended |
| 11-20 | Stale | Update needed |
| 20+ | Critical | Immediate attention |
---
## Relationship Detection
### 1. Same Directory
`src/api/README.md` relates to `src/api/**/*`
### 2. Name Matching
`docs/auth.md` relates to `**/auth.*`, `**/auth/**`
### 3. Explicit Links
Parse `[link](path)` in docs to find related files
### 4. Import Analysis
Track which modules are referenced in code examples
---
## Git Commands
```bash
# Last doc commit
git log -1 --format="%H %ai" -- docs/api.md
# Last code commit for related files
git log -1 --format="%H %ai" -- src/api/
# Commits to code since doc update
git rev-list <doc-commit>..HEAD -- src/api/ | wc -l
```
---
## Configuration
`.doc-guardian.yml`:
```yaml
stale-docs:
threshold: 10
mappings:
- doc: docs/deployment.md
code:
- Dockerfile
- docker-compose.yml
- .github/workflows/deploy.yml
- doc: ARCHITECTURE.md
code:
- src/**/*
ignore:
- CHANGELOG.md
- LICENSE
- vendor/**
```
---
## Output Format
```
## Stale Documentation Report
### Critical (20+ commits behind)
| File | Last Updated | Commits Behind | Related Code |
|------|--------------|----------------|--------------|
| docs/api.md | 2024-01-15 | 34 | src/api/**/* |
### Stale (11-20 commits behind)
| File | Last Updated | Commits Behind | Related Code |
|------|--------------|----------------|--------------|
| README.md | 2024-02-20 | 15 | package.json, src/index.ts |
### Aging (6-10 commits behind)
| File | Last Updated | Commits Behind | Related Code |
|------|--------------|----------------|--------------|
| CONTRIBUTING.md | 2024-03-01 | 8 | .github/*, scripts/* |
### Summary
- Critical: 1 file
- Stale: 1 file
- Aging: 1 file
- Fresh: 12 files
- Total documentation files: 15
```
---
## Exit Codes
- 0: No critical or stale documentation
- 1: Stale documentation found (for CI)
- 2: Critical documentation found

View File

@@ -0,0 +1,109 @@
---
name: sync-workflow
description: Documentation synchronization process and queue management
---
# Sync Workflow
## Purpose
Defines how to synchronize documentation with code changes.
## When to Use
- **doc-sync**: Apply pending documentation updates
- **PostToolUse hook**: Queue drift for later sync
---
## Queue File
Location: `.doc-guardian-queue` in project root
Format:
```
# Doc Guardian Queue
# Generated: YYYY-MM-DD HH:MM:SS
## Pending Updates
- README.md:45 | reference | calculate_total -> compute_total
- CLAUDE.md:23 | version | Python 3.9 -> 3.11
- src/api/README.md:12 | path | old/path.py -> new/path.py
```
---
## Update Types
### Reference Fixes
- Renamed function/class: update all doc references
- Changed signature: update parameter documentation
- Removed item: remove or mark deprecated in docs
### Content Sync
- Version numbers (Python, Node, dependencies)
- Configuration keys/values
- File paths and directory structures
- Command examples and outputs
### Structural
- Add missing sections for new features
- Remove sections for deleted features
- Reorder to match current code organization
---
## Sync Process
1. **Review Queue**
- Read `.doc-guardian-queue`
- List all pending items
2. **Batch Updates**
- Apply each update
- Track in change list
3. **Commit Strategy**
- Stage all doc changes together
- Single commit: `docs: sync documentation with code changes`
- Include summary in commit body
4. **Clear Queue**
```bash
echo "# Doc Guardian Queue - cleared after sync on $(date +%Y-%m-%d)" > .doc-guardian-queue
```
---
## Output Format
```
## Documentation Sync Complete
### Files Updated
- README.md (3 changes)
- CLAUDE.md (1 change)
- src/api/README.md (2 changes)
### Changes Applied
- Updated function reference: calculate_total -> compute_total
- Updated Python version: 3.9 -> 3.11
- Added docstring to create_order()
Committed: abc123f
```
---
## Queue Entry Format
```
<file>:<line> | <type> | <old> -> <new>
```
Types:
- `reference` - Function/class name change
- `version` - Version number update
- `path` - File path change
- `config` - Configuration key/value
- `missing` - New documentation needed