skills/consiliency/post-impl-docs/SKILL.md
Update repository documentation after code implementation. Maintains README, CHANGELOG, docs/ folder, and inline docstrings based on changes made. Triggered by lane-executor after task completion.
npx skillsauth add aiskillstore/marketplace post-impl-docsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Automatically update repository documentation to reflect code changes. This skill ensures that when code is implemented, the documentation stays in sync with the actual codebase.
| Variable | Default | Description |
|----------|---------|-------------|
| UPDATE_README | true | Update README.md for new features/APIs |
| UPDATE_CHANGELOG | true | Add entries to CHANGELOG.md |
| UPDATE_DOCS_FOLDER | true | Update files in docs/ that reference changed code |
| UPDATE_DOCSTRINGS | true | Update inline docstrings for changed functions/classes |
| CHANGELOG_FORMAT | conventional | conventional, keep-a-changelog, simple |
| COMMIT_DOCS | true | Commit documentation changes with code |
MANDATORY - Follow the Workflow steps below in order. Do not skip steps.
If you're about to:
STOP -> Review the diff -> Understand the impact -> Then document
Analyze what was changed in the current implementation:
# Get changed files
git diff --name-only HEAD~1 HEAD
# Get change summary
git diff --stat HEAD~1 HEAD
# Get detailed changes for documentation
git diff HEAD~1 HEAD -- "*.py" "*.ts" "*.js" "*.go" "*.rs"
Determine the type and scope of changes:
| Change Type | README Impact | CHANGELOG Entry | Docs Update |
|-------------|---------------|-----------------|-------------|
| New feature | Add to Features section | feat: entry | If documented |
| Bug fix | No change | fix: entry | If affects behavior |
| Breaking change | Update usage examples | BREAKING: entry | Update all refs |
| API addition | Add to API section | feat: entry | Add API docs |
| Deprecation | Add deprecation note | deprecate: entry | Update examples |
| Performance | No change | perf: entry | No |
| Refactor | No change | refactor: entry | No |
| Docs only | N/A | No entry | N/A |
| Tests only | No change | test: entry | No |
Only update README for significant changes:
Add new feature to Features section:
## Features
- **New Feature Name** - Brief description of what it does
Add new API to API/Usage section:
## API
### `newFunction(param: Type): ReturnType`
Description of the function and its purpose.
Update usage examples if API changed:
## Usage
```python
# Updated example reflecting new API
result = module.new_function(param="value")
Add entry following the project's format:
Conventional Changelog:
## [Unreleased]
### Added
- Add user authentication endpoint (#123)
### Changed
- Update database connection pool size for better performance
### Fixed
- Fix race condition in async queue processor (#124)
### Deprecated
- Deprecate `old_function()` in favor of `new_function()`
### Removed
- Remove support for Python 3.8
### Security
- Fix XSS vulnerability in user input handling
Keep a Changelog format:
## [Unreleased]
### Added
- New feature description
### Changed
- Change description
Scan documentation files for references to changed symbols:
# Find docs that reference changed functions/classes
grep -r "changed_function\|ChangedClass" docs/
For each match:
For each modified function/class with docstrings:
Python:
def function(param: str) -> bool:
"""Updated description reflecting new behavior.
Args:
param: Updated parameter description.
Returns:
Updated return value description.
Raises:
ValueError: If param is invalid (new error case).
"""
TypeScript/JavaScript:
/**
* Updated description reflecting new behavior.
*
* @param param - Updated parameter description
* @returns Updated return value description
* @throws {Error} If param is invalid (new error case)
*/
function func(param: string): boolean {
cookbook/readme-updates.mdcookbook/changelog-formats.mdcookbook/docstring-standards.md| Change | README | CHANGELOG | docs/ | Docstrings | |--------|--------|-----------|-------|------------| | New public API | Yes | Yes | Yes | Yes | | New internal function | No | Maybe | No | Yes | | Bug fix | No | Yes | If behavior docs exist | If signature changed | | Performance improvement | No | Yes | No | No | | Breaking change | Yes | Yes | Yes | Yes | | Deprecation | Yes | Yes | Yes | Yes |
| Commit Type | CHANGELOG Section |
|-------------|-------------------|
| feat: | Added |
| fix: | Fixed |
| perf: | Changed |
| refactor: | Changed |
| deprecate: | Deprecated |
| BREAKING CHANGE: | Changed (with breaking note) |
| security: | Security |
| docs: | (skip) |
| test: | (skip) |
| chore: | (skip) |
This skill is invoked:
## Post-Implementation Steps
After completing implementation:
1. Run `dependency-sync` skill to update manifests
2. Run `post-impl-docs` skill to update documentation
3. Verify build/tests still pass
4. Commit all changes together
{
"status": "success",
"updates": {
"readme": {
"updated": true,
"sections_modified": ["Features", "API"]
},
"changelog": {
"updated": true,
"entries_added": [
{"type": "feat", "description": "Add user authentication endpoint"}
]
},
"docs_folder": {
"files_updated": ["docs/api.md", "docs/getting-started.md"],
"references_fixed": 3
},
"docstrings": {
"functions_updated": 5,
"classes_updated": 2
}
},
"commit_sha": "abc123"
}
{
"status": "no_changes",
"reason": "Changes are internal implementation only",
"analysis": {
"change_type": "refactor",
"public_api_affected": false,
"documentation_impact": "none"
}
}
development
Apple Human Interface Guidelines for content display components. Use this skill when the user asks about charts component, collection view, image view, web view, color well, image well, activity view, lockup, data visualization, content display, displaying images, rendering web content, color pickers, or presenting collections of items in Apple apps. Also use when the user says how should I display charts, what's the best way to show images, should I use a web view, how do I build a grid of items, what component shows media, or how do I present a share sheet. Cross-references: hig-foundations for color/typography/accessibility, hig-patterns for data visualization patterns, hig-components-layout for structural containers, hig-platforms for platform-specific component behavior.
tools
Automate HelpDesk tasks via Rube MCP (Composio): list tickets, manage views, use canned responses, and configure custom fields. Always search tools first for current schemas.
testing
Expert Haskell engineer specializing in advanced type systems, pure functional design, and high-reliability software. Use PROACTIVELY for type-level programming, concurrency, and architecture guidance.
tools
GraphQL gives clients exactly the data they need - no more, no less. One endpoint, typed schema, introspection. But the flexibility that makes it powerful also makes it dangerous. Without proper controls, clients can craft queries that bring down your server. This skill covers schema design, resolvers, DataLoader for N+1 prevention, federation for microservices, and client integration with Apollo/urql. Key insight: GraphQL is a contract. The schema is the API documentation. Design it carefully.