Skill Ops Planner

---
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, 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 any of the above cannot be determined:

- 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

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