consistency-enforcement
Consistency Enforcement Skill
Layer 4 Defense Against Documentation Drift
Auto-activates to maintain documentation consistency when working on docs, skills, agents, or commands.
See: workflow.md for step-by-step scenarios See: templates.md for checklists and commands
When This Activates
Keywords: "readme", "documentation", "docs", "commit", "sync", "update", "skill", "agent", "command", "count", "marketplace", "consistency", "drift"
Critical Consistency Rules
Rule 1: README.md is Source of Truth
All counts must match reality:
# Count actual resources
ls -d plugins/autonomous-dev/skills/*/ | wc -l # Skills
ls plugins/autonomous-dev/agents/*.md | wc -l # Agents
ls plugins/autonomous-dev/commands/*.md | wc -l # Commands
Rule 2: All Docs Must Match README.md
These files MUST show the same counts:
README.md(primary source)docs/SYNC-STATUS.mddocs/UPDATES.mdINSTALL_TEMPLATE.md.claude-plugin/marketplace.json(metrics)
Rule 3: Never Reference Non-Existent Skills
# Verify skill exists before referencing
ls -1 plugins/autonomous-dev/skills/
Rule 4: marketplace.json Matches Reality
{
"metrics": {
"agents": 8,
"skills": 12,
"commands": 21
}
}
4-Layer Defense System
| Layer | Location | Purpose |
|---|---|---|
| 1 | tests/test_documentation_consistency.py |
Automated CI/CD enforcement |
| 2 | agents/doc-master.md |
Agent memory checklist |
| 3 | hooks/validate_docs_consistency.py |
Pre-commit hook (optional) |
| 4 | This skill | Auto-reminder during work |
Run Tests
pytest tests/test_documentation_consistency.py -v
Quick Workflow
When adding/removing skills, agents, or commands:
- Update README.md count
- Update cross-reference files (SYNC-STATUS.md, UPDATES.md, etc.)
- Update marketplace.json metrics
- Run consistency tests
- Commit
See: workflow.md for detailed scenarios
Why This Matters
Documentation drift causes user confusion:
- README shows "9 Skills" but plugin has 12
- README mentions skill that doesn't exist
- User tries to use non-existent feature
With 4-layer defense:
- Layer 1: Tests fail in CI/CD
- Layer 2: doc-master catches before docs.json
- Layer 3: Pre-commit hook blocks commit
- Layer 4: This skill reminds during work
Result: Documentation always matches reality
Integration
Works with:
- documentation-guide: HOW to write docs
- git-workflow: HOW to commit changes
- project-management: PROJECT.md consistency
Related Files
- workflow.md - Step-by-step scenarios
- templates.md - Checklists and commands
More from akaszubski/autonomous-dev
git-github
Git workflow and GitHub collaboration patterns including conventional commits, branch naming, PR workflow, and gh CLI usage. Use when creating commits, branches, or pull requests. TRIGGER when: git commit, branch, PR, pull request, merge, gh cli. DO NOT TRIGGER when: code implementation, testing, documentation without git operations.
26library-design-patterns
Two-tier design, progressive enhancement, non-blocking patterns, and security-first architecture for Python libraries. Use when creating or refactoring Python libraries. TRIGGER when: library design, module architecture, reusable component, two-tier. DO NOT TRIGGER when: simple scripts, config files, documentation-only changes.
26scientific-validation
Scientific method for validating claims with pre-registration, power analysis, statistical rigor, and Bayesian methods. Use when testing hypotheses, running experiments, or validating claims from papers. TRIGGER when: validate, hypothesis, experiment, backtest, evidence, statistical test. DO NOT TRIGGER when: routine coding, config changes, documentation, non-experimental tasks.
24state-management-patterns
JSON persistence, atomic writes, file locking, crash recovery, and state versioning patterns. Use when implementing stateful libraries or features requiring persistent state. TRIGGER when: state persistence, atomic write, file locking, crash recovery, checkpoint. DO NOT TRIGGER when: stateless utilities, pure functions, config reads, documentation.
22code-review
10-point code review checklist covering correctness, tests, error handling, type hints, naming, security, and performance. Use when reviewing PRs or evaluating code quality. TRIGGER when: code review, PR review, review checklist, code quality check. DO NOT TRIGGER when: writing new code, debugging, refactoring without review context.
22api-design
REST API design best practices covering versioning, error handling, pagination, and OpenAPI documentation. Use when designing or implementing REST APIs or HTTP endpoints. TRIGGER when: API design, REST endpoint, HTTP route, OpenAPI, swagger, pagination. DO NOT TRIGGER when: internal library code, CLI tools, non-HTTP interfaces.
22