mirror of
https://github.com/github/awesome-copilot.git
synced 2026-03-19 23:55:12 +00:00
Combining skills into a single skill with an internal decision tree
This commit is contained in:
32
skills/oo-component-documentation/references/create-mode.md
Normal file
32
skills/oo-component-documentation/references/create-mode.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# 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 boundaries, dependencies, design patterns, and collaboration model.
|
||||
- Build interface tables and usage examples from the actual public surface area.
|
||||
- Create a Mermaid diagram that introduces the component structure, dependencies, and data flow for a reader seeing the documentation for the first time.
|
||||
|
||||
## Create-specific output guidance
|
||||
|
||||
- Use the full section structure from `../assets/documentation-template.md`.
|
||||
- Write the introduction as a fresh overview of what the component does and why it exists.
|
||||
- Prefer complete sections over placeholders; if information is unavailable, mark the section with a short limitation note instead of leaving template text behind.
|
||||
- Include change history or migration notes only if there is evidence of prior versions or migration concerns in the code or repository history.
|
||||
Reference in New Issue
Block a user