Update Oo Component Documentation
Refresh architecture-grade OO component docs so they match the current code after refactors, new patterns, or API changes.
Overview
Update OO Component Documentation is an agent skill most often used in Build (also Ship, Operate) that reconciles existing C4/Arc42/IEEE-style OO component docs with the current implementation.
Install
npx skills add https://github.com/github/awesome-copilot --skill update-oo-component-documentationWhat is this skill?
- Updates an existing doc at a given path by re-analyzing the linked component implementation.
- Follows five documentation standards: C4 levels, Arc42, IEEE 1016, agile just-enough docs, developer/maintainer audience
- Seven analysis rules (ANA-001–ANA-007) from reading front matter through creational/structural pattern deltas.
- Compares prior documentation to current classes, inheritance, public APIs, interfaces, and dependencies.
- Infers `component_path` from YAML front matter when the file path alone is ambiguous.
- 5 documentation standards (DOC-001–DOC-005)
- 7 analysis instructions (ANA-001–ANA-007)
Adoption & trust: 7k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your component documentation still describes old classes, APIs, or patterns after the code has already moved on.
Who is it for?
Maintainers of modular OO codebases who already keep per-component markdown with `component_path` metadata and want standards-based refresh passes.
Skip if: Greenfield apps with no doc file yet (use a create-doc skill first), pure functional modules with no OO structure, or teams that only need a one-line changelog.
When should I use this skill?
You have an existing OO component documentation file at `${file}` that must be brought in line with the current component code.
What do I get? / Deliverables
You get an updated documentation file whose structure, APIs, dependencies, and pattern descriptions match the analyzed source tree.
- Updated `${file}` documentation aligned to DOC and ANA rule sets
- Revised public API, interface, and dependency sections
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build/docs because the primary artifact is maintained component documentation aligned to living source. Docs subphase captures C4/Arc42/IEEE-style component write-ups—not one-off README edits but structured maintainer documentation.
Where it fits
After extracting a new strategy class, rerun the skill on its component doc so public methods and dependencies match the refactor.
Before tagging a release, update architecture docs so reviewers see current interfaces, not last quarter's diagram.
When a contractor joins, refresh OO component pages so they inherit accurate pattern and API descriptions.
How it compares
Use instead of asking the model to "fix the readme"—this skill enforces C4/Arc42/IEEE checklists and diff-style analysis against `${file}`.
Common Questions / FAQ
Who is update-oo-component-documentation for?
Developers and tech leads maintaining object-oriented services or libraries who treat component docs as first-class architecture artifacts.
When should I use update-oo-component-documentation?
In Build/docs after feature work; in Ship/review before release when auditors read architecture packets; in Operate/iterate when onboarding needs accurate component maps post-refactor.
Is update-oo-component-documentation safe to install?
It guides doc updates from repository files—review the Security Audits panel on this page and ensure the agent only edits intended `${file}` paths in your repo.
SKILL.md
READMESKILL.md - Update Oo Component Documentation
# Update Standard OO Component Documentation Update the existing documentation file at: `${file}` by analyzing the corresponding component code. Extract the component path from the existing documentation's front matter (`component_path` field) or infer it from the documentation content. Analyze the current component implementation and update the documentation accordingly. **Documentation Standards:** - DOC-001: Follow C4 Model documentation levels (Context, Containers, Components, Code) - DOC-002: Align with Arc42 software architecture documentation template - DOC-003: Comply with IEEE 1016 Software Design Description standard - DOC-004: Use Agile Documentation principles (just enough documentation that adds value) - DOC-005: Target developers and maintainers as primary audience **Analysis Instructions:** - ANA-001: Read existing documentation to understand component context and structure - ANA-002: Identify component path from front matter or content analysis - ANA-003: Examine current source code files for class structures and inheritance - ANA-004: Compare existing documentation with current implementation - ANA-005: Identify design patterns and architectural changes - ANA-006: Update public APIs, interfaces, and dependencies - ANA-007: Recognize new/changed creational/structural/behavioral patterns - ANA-008: Update method parameters, return values, exceptions - ANA-009: Reassess performance, security, reliability, maintainability - ANA-010: Update integration patterns and data flow **Language-Specific Optimizations:** - LNG-001: **C#/.NET** - async/await, dependency injection, configuration, disposal - LNG-002: **Java** - Spring framework, annotations, exception handling, packaging - LNG-003: **TypeScript/JavaScript** - modules, async patterns, types, npm - LNG-004: **Python** - packages, virtual environments, type hints, testing **Update Strategy:** - UPD-001: Preserve existing documentation structure and format - UPD-002: Update `last_updated` field to current date - UPD-003: Maintain version history in front matter if present - UPD-004: Add new sections if component has significantly expanded - UPD-005: Mark deprecated features or breaking changes - UPD-006: Update examples to reflect current API - UPD-007: Refresh dependency lists and versions - UPD-008: Update mermaid diagrams to reflect current architecture **Error Handling:** - ERR-001: Documentation file doesn't exist - provide guidance on file location - ERR-002: Component path not found in documentation - request clarification - ERR-003: Source code has moved - suggest updated paths - ERR-004: Major architectural changes - highlight breaking changes - ERR-005: Insufficient access to source - document limitations **Output Format:** Update the existing Markdown file maintaining its structure while refreshing content to match current implementation. Preserve formatting, heading hierarchy, and existing organizational decisions. **Required Documentation Structure:** Update the existing documentation following the same template structure, ensuring all sections reflect current implementation: ```md --- title: [Component Name] - Technical Documentation component_path: [Current component path] version: [Updated version if applicable] date_created: [Original creation date - preserve] last_updated: [YYYY-MM-DD - update to current date] owner: [Preserve existing or update if changed] tags: [Update tags as needed based on current functionality] --- # [Component Name] Documentation [Update introduction to reflect current component purpose and capabilities] ## 1. Component Overview ### Purpose/Responsibility - OVR-001: Update component's primary responsibility - OVR-002: Refresh scope (included/excluded functionality) - OVR-003: Update system context and relation