git:20260321.9fa274a to git:20260321.857d5ca

21 added, 6 removed. Audit A to A.

---

name: skill-ops-planner

description: Create an operating policy and roadmap for a live portfolio of Claude Code skills. Use when the user asks to organize, govern, audit, measure, retire, or scale skills already used by a team or repository. Also trigger on "スキルの運用計画", "スキルポートフォリオ", "スキルロードマップ", "スキルを整理して".

disable-model-invocation: true

allowed-tools: Read, Grep, Glob, Bash

---

## Pattern declaration

Primary pattern: Pipeline

- Secondary patterns: Reviewer

- Why: portfolio planning requires strict phase order (inventory → classify → policy → metrics → roadmap) with review checkpoints at each stage.

+ Secondary patterns: Reviewer, Inversion

+ Why: portfolio planning requires strict phase order (inventory → classify → policy → metrics → roadmap) with review checkpoints at each stage. Inversion is needed at Phase 0 to block progress when inventory data is insufficient.

## Purpose

Plan how a team should operate a set of skills over time.

Your job is to define:

- portfolio structure

- ownership

- lifecycle stages

- evaluation policy

- rollout policy

- retirement policy

- review cadence

## Phase 0: Portfolio gate

Before planning, identify:

- active skills

- target users or teams

- current pain points

- risk level by skill category

- current review process

- current storage layout

- current evaluation maturity

- If the current inventory is missing:

+ If any of the above cannot be determined:

- - create an inventory-first plan

- - do not pretend portfolio governance already exists

+ - stop and ask the user for the missing information

+ - do not proceed to Phase 1 until at least active skills and current storage layout are confirmed

+ - if no inventory exists at all, output an inventory-first plan and stop

## Phase 1: Inventory and pattern segmentation

For each skill, record:

- owner

- purpose

- invocation policy (auto vs manual)

- risk level

- primary pattern (Tool Wrapper / Generator / Reviewer / Inversion / Pipeline)

- secondary patterns

- current eval maturity

- review requirement

- Group the portfolio by:

+ Output each skill as a structured record:

+ ```text

+ skill: <name>

+ owner: <person or team>

+ purpose: <one line>

+ invocation: auto | manual

+ risk: low | medium | high

+ primary_pattern: <pattern>

+ secondary_patterns: <patterns or none>

+ eval_maturity: none | basic | comprehensive

+ review: <cadence>

+ ```

+ Then group the portfolio by:

- responsibility type (knowledge / workflow / investigation / review / operational)

- risk type

- design pattern

## Phase 2: Lifecycle policy

Define lifecycle stages:

1. proposed

2. experimental

3. team-approved

4. production

5. deprecated

6. retired

For each stage, define:

- entry criteria

- required eval coverage

- review requirement

- allowed blast radius

- logging requirement

- retirement signals (when to deprecate or retire)

## Phase 3: Metrics and governance

Define portfolio metrics:

- trigger precision

- task success rate

- review pass rate

- rollback rate

- mean tool count

- failure recurrence

- stale skill count

Pattern portfolio metrics:

- count by primary pattern

- percentage of Inversion usage where ambiguity is common

- percentage of Generator skills with template coverage

- percentage of Reviewer skills with explicit rubric coverage

- percentage of Pipeline skills with checkpoint validation

- percentage of Tool Wrapper skills with maintained references

Also define:

- monthly review cadence

- change approval policy

- emergency disable policy

- documentation freshness policy

## Phase 4: Roadmap

Create a prioritized roadmap:

- fix now

- standardize next

- automate later

- retire soon

Use `${CLAUDE_SKILL_ROOT}/assets/skill-roadmap-template.md` as the output structure.

Prioritize by:

- impact

- risk

- maintenance burden

- adoption level

## Phase 5: Review

Check against:

- `${CLAUDE_SKILL_ROOT}/references/review-default.md`

- `${CLAUDE_SKILL_ROOT}/references/portfolio-policy.md`

Verify:

- policy is concrete enough to operate

- lifecycle stages have entry rules

- metrics are measurable

- ownership is clear

- retirement criteria exist

## Output format

Return exactly these sections:

### Current-state summary

### Skill inventory model

### Lifecycle policy

### Governance rules

### Metrics dashboard definition

### Pattern portfolio

### 30-day roadmap

### 90-day roadmap

### Risks and open decisions

## Anti-patterns

Do not:

- write abstract policy with no operating rules

- ignore ownership

- ignore retirement

- require eval maturity that the team cannot sustain

- assume all skills should be auto-invoked

## Failure handling

If the team has no current inventory:

- provide a lightweight bootstrap policy

- define a minimum viable governance model

- prioritize inventory, naming, and eval basics first