Documentation lifecycle management skill. Activates when user mentions documentation, docs, sync, quality, validation, releases, or setup. Routes to appropriate agent (doc-expert for orchestration, doc-writer for content) and provides gentle reminders about documentation health.
Inherits all available tools
Additional assets for this skill
This skill inherits all available tools. When active, it can use any tool Claude has access to.
Documentation lifecycle management through the doc-manager MCP server. This skill routes requests to specialized agents and provides proactive documentation health awareness.
Activate when user mentions:
Documentation terms: "documentation", "docs", "README", "API docs", "guide"
Sync/status: "sync docs", "doc status", "update docs", "docs out of date"
Quality: "doc quality", "validate docs", "check docs", "broken links"
Releases: "release", "deploy", "ship", "merge to main", "v1.0"
Setup: "setup docs", "init docs", "documentation management"
Configuration: "config", "configuration", ".doc-manager", "conventions", "api_coverage", "preset", "strategy", "exclude patterns"
Code changes: "committed", "pushed", "finished implementing" (gentle reminder)
Requires analysis, orchestration, quality, or state management?
YES → doc-expert agent
NO → Straightforward content with clear scope?
YES → doc-writer agent
NO → doc-expert agent (to assess first)
Never automatically run heavy operations. Always suggest and ask:
At appropriate moments, offer (don't command):
On release mention:
Before the release, would you like a documentation health check?
- /doc-status - Quick sync status
- /doc-quality - Full quality assessment
On code change mention:
Code changes may need documentation updates.
Run /doc-status when ready to check.
On docs mention:
I can help with documentation. Options:
- Check status: /doc-status
- Full sync: /doc-sync
- Quality audit: /doc-quality
If .doc-manager/ doesn't exist when user asks about docs:
Documentation management isn't set up for this project.
Would you like me to initialize it? I'll:
1. Detect your documentation platform
2. Create tracking configuration
3. Establish baselines
Say "setup docs" to proceed.
| Command | Purpose |
|---|---|
/doc-status | Quick health check |
/doc-sync | Full sync workflow |
/doc-quality | Quality assessment |
/doc-dashboard | Comprehensive metrics |
Warn before proceeding:
Detected 50+ files with changes. This will be processed in batches.
Estimated time: 10-15 minutes.
Proceed with documentation sync?
If fixing one criterion harms another:
Quality trade-off detected:
- Adding detail improves Clarity
- But increases Uniqueness issues (duplication)
Which should I prioritize?
Always check for .doc-manager/ before assuming setup exists.
Offer initialization if missing.
This skill coordinates with:
When helping with documentation, consider the project type to provide better recommendations.
| Project Type | Recommended Strategy | Doc Focus | Indicators |
|---|---|---|---|
| Library/SDK | all_then_underscore | Public API reference | Has __all__, pip installable |
| MCP Server | all_only | Tool reference, usage | FastMCP, mcp dependency |
| CLI Tool | all_only or underscore_only | Commands, options | argparse, click, typer |
| Application | all_only | User guides, config | Django, FastAPI app |
Look for these indicators:
mcp in dependencies, FastMCP imports, tool definitions__all__ exports, package structure, PyPI metadata__all__When reviewing documentation health, apply these heuristics to provide proactive suggestions.
Detect: Quality assessment shows <50% API coverage AND no api_coverage section in .doc-manager.yml
Suggest:
Coverage is at {X}%. This might include framework symbols that don't need documentation.
Adding an api_coverage preset could help filter these out. For example:
- `pydantic` preset excludes Config, validators, etc.
- `pytest` preset excludes test_*, Test*, fixtures
Would you like me to explain the available presets?
Detect: MCP server project (has mcp dependency) AND strategy is all_then_underscore
Suggest:
This appears to be an MCP server. Users interact via the MCP protocol, not Python imports.
Consider using `all_only` strategy - this will only count symbols explicitly exported via __all__.
For MCP servers, 0% API coverage is often correct since there's no public Python API.
Want me to update the config?
Detect: sources patterns in config don't match any existing files
Suggest:
Some source patterns in .doc-manager.yml don't match any files:
- `{pattern}` → 0 files found
The project structure may have changed. Would you like me to update the source patterns?
Detect: Consistency issues detected (heading case, list markers) AND no doc-conventions.yml exists
Suggest:
Quality assessment found consistency issues:
- {X} files use different heading case styles
- {Y} files use different list markers
A doc-conventions.yml file could help enforce standards.
Would you like me to help set one up?
Detect: Using framework (pydantic, django, etc.) but no matching preset configured
Suggest:
I noticed this project uses {framework} but the `{framework}` preset isn't configured.
This preset would exclude common {framework} symbols from coverage metrics:
{list of excluded symbols}
Add it to improve coverage accuracy?
Provide context-aware suggestions based on project maturity.
Documentation management is now set up!
Recommended next steps:
1. Run /doc-quality to establish a quality baseline
2. Consider adding doc-conventions.yml for consistency
3. Review api_coverage settings if accuracy seems off
I noticed frequent code changes since last sync.
Tip: Run /doc-sync periodically to keep docs in sync.
For CI integration, consider adding doc validation to your pipeline.
Preparing for release? Here's a quick checklist:
1. /doc-sync - Ensure docs match code
2. /doc-quality - Check for issues
3. Review any "poor" quality scores before shipping
Want me to run a full pre-release audit?
I noticed some configuration that might need attention:
- {specific issue from heuristics}
The doc-expert agent can help tune your configuration.
Say "tune config" to start.