Duplicate review (#1001)

* Removing a codex-specific agent (model deprecated) and removing model from blueprint mode

* Combining skills into a single skill with an internal decision tree

* Converting agents to skill with decision tree

Closes #998

* Converting agents to skill with decision tree"
Fixes #999

skills/oo-component-documentation/references/create-mode.md

@@ -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.

skills/oo-component-documentation/references/update-mode.md

@@ -0,0 +1,32 @@
+# Update mode
+
+Use this workflow when the input is an existing documentation Markdown file or the user asks to refresh existing component documentation.
+
+## Input handling
+
+- Read the existing documentation first to understand the current structure, terminology, and any front matter metadata.
+- Extract the component source path from the `component_path` front matter when present.
+- If `component_path` is missing, infer the component path from the documentation content and surrounding repository structure.
+- Use the current implementation as the source of truth when the documentation and code disagree.
+
+## Update-specific requirements
+
+- Preserve the existing documentation file as the output target.
+- Preserve `date_created`.
+- Update `last_updated` to the current date.
+- Preserve version history and ownership metadata when still accurate; refresh them only when the code or repository evidence indicates they have changed.
+- Maintain the existing organization where it is still useful, but ensure the content remains consistent with the shared template expectations.
+
+## Update-specific analysis focus
+
+- Compare the existing documentation with the current code to identify stale APIs, outdated diagrams, renamed dependencies, and changed usage patterns.
+- Highlight breaking changes, deprecated features, or major architectural shifts when they are evident.
+- Refresh method tables, examples, diagrams, dependency lists, and quality attribute notes to match the implementation as it exists today.
+- Add missing sections only when the component has grown or the current documentation omits information now needed for maintainers.
+
+## Update-specific output guidance
+
+- Keep useful editorial choices from the existing document, but remove stale or misleading content.
+- Update examples so they compile conceptually against the current API shape.
+- Refresh Mermaid diagrams rather than replacing them with generic placeholders.
+- Add migration notes or change history when the update reveals important compatibility or behavior changes.