review

name	review
description	Analyze the available skill set and recommend candidate groups that could be consolidated into sub-skill bundles. Read-only — proposes a plan, does not move files.
disable-model-invocation	true

Review sub-skills (sub-skill.review)

Analyze the current skill inventory and identify candidate groups that could be consolidated into sub-skill bundles. This sub-skill is read-only: it produces a proposal for the user to review before any file changes are made by sub-skill.consolidate.

When to use

• The user asks to review, reorganize, or audit the skill inventory.
• There are many loosely-related skills that might benefit from hierarchical grouping.
• The user wants to evaluate whether a new skill should be a sub-skill of an existing parent.

Process

1. List the current inventory. Use the skill registry (or scan the configured skill roots) to get a full list of skill names, descriptions, and source scopes.
2. Categorize by domain. Group skills by functional domain — e.g. file operations, web tools, collaboration, observability.
3. Detect coupling. Identify skills that are frequently used together or share similar whenToUse conditions.
4. Flag granularity issues. Call out skills that are too fine-grained (e.g. one skill per CLI flag) or too broad to land in any single domain.
5. Propose sub-skill structures. For each candidate group, list:
   • The parent skill name and a one-line description.
   • The children that should move under it.
   • Any documentation, reference, example, asset, or template directories that must move with each child so the final directory layout stays aligned.
   • Whether the parent needs has-sub-skill: true (it does, if children should be discovered).
6. Output a summary report. Present findings as a concise grouped list with rationale, and stop. Do not edit any file — that's sub-skill.consolidate's job.

Criteria for a good sub-skill grouping

• Shared context. Children operate within the same domain or workflow.
• Composable entry point. The parent gives a natural top-level handle; children handle specifics.
• Shallow nesting. Prefer 2 levels (parent → child). Avoid 3+ unless strictly necessary.
• Backward compatibility. Existing skill names should ideally remain discoverable.

Example output format

Proposed sub-skill: web-research
  - Parent: web-research (has-sub-skill: true)
  - Children:
    - web-search    → move under web-research/search
    - fetch-url     → move under web-research/fetch
  - Documentation alignment: move each child's references/examples/assets with that child.
  - Rationale: Both deal with online information retrieval and are often chained together.