Create Oo Component Documentation
Generate standardized architecture and API documentation for object-oriented codebases so maintainers and future-you can onboard without spelunking classes.
Overview
create-oo-component-documentation is an agent skill most often used in Build (also Ship, Operate) that analyzes OOP source and produces standardized component documentation using C4, Arc42, and IEEE 1016–aligned structur
Install
npx skills add https://github.com/github/awesome-copilot --skill create-oo-component-documentationWhat is this skill?
- Applies five documented standards: DOC-001 through DOC-005 (C4, Arc42, IEEE 1016, agile just-enough docs)
- Eight-step analysis checklist: ANA-001 through ANA-008 from path detection through NFR qualities
- Works from a folder or single file and expands to related sources in the directory
- Captures inheritance, design patterns, public APIs, parameters, returns, and exceptions
- Targets developers and maintainers as the primary audience
- 5 documentation standards (DOC-001 through DOC-005)
- 8 analysis steps (ANA-001 through ANA-008)
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 OO module works in production but lacks consistent architecture and API documentation that new contributors—or you in six months—can trust.
Who is it for?
Solo builders documenting services, SDKs, or domain layers after a refactor or before sharing a repo.
Skip if: Teams that only need end-user guides, OpenAPI-only REST catalogs with no class model, or paths with no meaningful OO structure to analyze.
When should I use this skill?
User provides a component path and wants comprehensive standardized OO component documentation.
What do I get? / Deliverables
You get a structured OO component document covering structure, patterns, public surface, dependencies, and quality notes grounded in the code at the given path.
- Standardized OO component documentation (C4/Arc42/IEEE-aligned sections)
- Documented public APIs, patterns, dependencies, and inferred quality attributes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Documentation is authored while the product exists in code; Build → docs is the canonical shelf for generator skills that turn source into maintainer-facing artifacts. Subphase docs covers architecture descriptions, design decisions, and reference material—not ship-time review or launch copy.
Where it fits
Document a new domain service folder before merging a large PR.
Capture inheritance and interface contracts for a shared library package.
Attach standardized component docs to a release review checklist.
Refresh architecture notes after a refactor without rewriting from scratch.
How it compares
Use instead of asking the agent for ad-hoc “explain this folder” without C4/Arc42/IEEE-aligned sections.
Common Questions / FAQ
Who is create-oo-component-documentation for?
Indie and solo developers who ship OO backends, libraries, or agent tools and need maintainer-grade docs without hiring a technical writer.
When should I use create-oo-component-documentation?
During Build when finishing a feature package, during Ship when preparing review packets, or during Operate when updating docs after structural changes—anytime `${input:ComponentPath}` points at real OOP code.
Is create-oo-component-documentation safe to install?
It is a documentation generator that reads your codebase; review the Security Audits panel on this page and avoid pointing it at paths with secrets you do not want echoed into generated text.
SKILL.md
READMESKILL.md - Create Oo Component Documentation
# Generate Standard OO Component Documentation Create comprehensive documentation for the object-oriented component(s) at: `${input:ComponentPath}`. Analyze the component by examining code in the provided path. If folder, analyze all source files. If single file, treat as main component and analyze related files in same directory. ## 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: Determine path type (folder vs single file) and identify primary component - ANA-002: Examine source code files for class structures and inheritance - ANA-003: Identify design patterns and architectural decisions - ANA-004: Document public APIs, interfaces, and dependencies - ANA-005: Recognize creational/structural/behavioral patterns - ANA-006: Document method parameters, return values, exceptions - ANA-007: Assess performance, security, reliability, maintainability - ANA-008: Infer 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 ## Error Handling - ERR-001: Path doesn't exist - provide correct format guidance - ERR-002: No source files found - suggest alternative locations - ERR-003: Unclear structure - document findings and request clarification - ERR-004: Non-standard patterns - document custom approaches - ERR-005: Insufficient code - focus on available information, highlight gaps ## Output Format Generate well-structured Markdown with clear heading hierarchy, code blocks, tables, bullet points, and proper formatting for readability and maintainability. ## File Location The documentation should be saved in the `/docs/components/` directory and named according to the convention: `[component-name]-documentation.md`. ## Required Documentation Structure The documentation file must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following: ```md --- title: [Component Name] - Technical Documentation component_path: `${input:ComponentPath}` version: [Optional: e.g., 1.0, Date] date_created: [YYYY-MM-DD] last_updated: [Optional: YYYY-MM-DD] owner: [Optional: Team/Individual responsible for this component] tags: [Optional: List of relevant tags or categories, e.g., `component`,`service`,`tool`,`infrastructure`,`documentation`,`architecture` etc] --- # [Component Name] Documentation [A short concise introduction to the component and its purpose within the system.] ## 1. Component Overview ### Purpose/Responsibility - OVR-001: State component's primary responsibility - OVR-002: Define scope (included/excluded functionality) - OVR-003: Describe system context and relationships ## 2. Architecture Section - ARC-001: Document design patterns used (Repository, Factory, Observer, etc.) - ARC-002: List internal and external dependencies with purposes - ARC-003: Document component interactions and relationships - ARC-004: Include visual diagrams (UML class, sequence, component) - ARC-005: Create mermaid diagram showing component structure, relationships, and dependencies ### Compon