Oo Component Documentation
Generate consistent technical docs for object-oriented components with overview, architecture, and interface sections your agent can fill from the codebase.
Overview
OO Component Documentation is an agent skill most often used in Build (also Ship review, Operate iterate) that fills a structured template for one OO component’s purpose, architecture, and public interfaces.
Install
npx skills add https://github.com/github/awesome-copilot --skill oo-component-documentationWhat is this skill?
- Numbered doc rules across overview (OVR-001–003), architecture (ARC-001–005), and interfaces (INT-001+)
- Mandatory Mermaid diagram for structure, dependencies, and data flow
- YAML frontmatter for component path, version, owner, and tags
- Explicit scope boundaries: included vs excluded responsibilities
- Interface reference tables plus events and callback coverage when applicable
- 3 overview rules (OVR-001–003)
- 5 architecture rules including required Mermaid (ARC-001–005)
- 3+ interface rules starting at INT-001
Adoption & trust: 1.5k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped or refactored a component but stakeholders only have scattered comments and no single doc with scope, dependencies, and API tables.
Who is it for?
Documenting a class, module, or service after implementation when you need architecture diagrams and interface tables for teammates or future agents.
Skip if: End-user product guides, OpenAPI-only reference, or teams that forbid Mermaid in their doc standard.
When should I use this skill?
You need standardized technical documentation for an object-oriented or modular component including architecture diagram and interface tables.
What do I get? / Deliverables
You get a component doc with rule-tagged sections, a Mermaid structure diagram, and interface tables ready to commit beside the source or link from a PR.
- Markdown component doc with frontmatter and numbered sections
- Mermaid diagram of structure, dependencies, and data flow
- Interface or method reference table
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because component documentation is produced while implementing or refactoring code, even though the same artifact supports Ship review and Operate handoffs. Docs subphase matches structured README-style technical documentation rather than API OpenAPI specs or user tutorials.
Where it fits
After extracting a payment service, you generate overview rules and a dependency Mermaid chart before merging.
A reviewer asks how the auth module relates to storage; you attach the architecture section from the generated doc.
Six months later you update external dependencies in ARC-002 before a migration PR.
How it compares
Structured component README template—not an auto-generated API doc crawler or a PR review checker.
Common Questions / FAQ
Who is oo-component-documentation for?
Solo and indie builders maintaining SaaS, APIs, or libraries who want repeatable technical docs per component without hiring a tech writer for every module.
When should I use oo-component-documentation?
During Build when finishing a component; during Ship review when a PR needs architecture context; during Operate iterate when onboarding or debugging requires an up-to-date dependency map.
Is oo-component-documentation safe to install?
It is a documentation template skill with no prescribed shell or network calls; review the Security Audits panel on this page before adding it to your agent workflow.
SKILL.md
READMESKILL.md - Oo Component Documentation
# [Component Name] Documentation [Concise introduction describing the component purpose and role in the system.] ## 1. Component Overview ### Purpose/Responsibility - OVR-001: State the component's primary responsibility - OVR-002: Define scope, including included and excluded responsibilities - OVR-003: Describe system context and major relationships ## 2. Architecture Section - ARC-001: Document design patterns used - ARC-002: List internal and external dependencies with their purpose - ARC-003: Describe component interactions and relationships - ARC-004: Include visual diagrams where they clarify structure or behavior - ARC-005: Provide a Mermaid diagram showing structure, relationships, and dependencies ### Component Structure and Dependencies Diagram Show the current: - Component structure - Internal dependencies - External dependencies - Data flow - Inheritance and composition relationships ```mermaid graph TD A[Primary Component] --> B[Collaborator] A --> C[Dependency] ``` ## 3. Interface Documentation - INT-001: Document public interfaces and usage patterns - INT-002: Provide a method or property reference table - INT-003: Cover events, callbacks, or notification mechanisms when applicable | Method/Property | Purpose | Parameters | Return Type | Usage Notes | |-----------------|---------|------------|-------------|-------------| | [Name] | [Purpose] | [Parameters] | [Type] | [Notes] | ## 4. Implementation Details - IMP-001: Describe main implementation classes and responsibilities - IMP-002: Capture configuration requirements and initialization patterns - IMP-003: Summarize key algorithms or business logic - IMP-004: Note performance characteristics and bottlenecks ## 5. Usage Examples ### Basic Usage ```text [Basic usage example aligned with the component language and API] ``` ### Advanced Usage ```text [Advanced configuration or orchestration example aligned with the current implementation] ``` - USE-001: Provide basic usage examples - USE-002: Show advanced configuration patterns - USE-003: Document best practices and recommended patterns ## 6. Quality Attributes - QUA-001: Security - QUA-002: Performance - QUA-003: Reliability - QUA-004: Maintainability - QUA-005: Extensibility ## 7. Reference Information - REF-001: List dependencies with versions and purposes where available - REF-002: Document configuration options - REF-003: Provide testing guidance and mock setup notes - REF-004: Capture troubleshooting notes and common issues - REF-005: Link related documentation - REF-006: Add change history or migration notes when relevant # Create mode Use this workflow when the input is a component source path or the user asks to generate new documentation from code. ## Input handling - Accept a single file or a folder path representing the component. - If the input is a folder, analyze the relevant source files in that folder and nearby supporting files. - If the input is a single file, treat it as the primary component entry point and inspect adjacent files as needed to understand collaborators and interfaces. ## Create-specific requirements - Save the new documentation in `/docs/components/`. - Name the file `[component-name]-documentation.md`. - Set `component_path` to the source path provided by the user. - Set `date_created` to the current date. - Set `last_updated` only if the repository convention for the target area expects it at creation time. - Populate optional metadata such as `version`, `owner`, and `tags` only when they can be inferred reliably. ## Create-specific analysis focus - Determine the primary component name and responsibilities from the code structure. - Identify the initial system context, scope