# Skill Reviewer

> 既存スキルの品質をレビューし、改善提案を行うスキル。 以下の状況で使用: (1) ユーザーが「[スキル名]をレビューして」「[スキル名]の品質を確認して」「[スキル名]を評価して」と依頼した時 (2) ユーザーが明示的に「/skill-reviewer [スキル名]」を実行した時 (3) スキル開発完了後、「公開前にチェックして」「最終確認して」と求められた時 (4) スキル改善時、「どこを直すべきか教えて」「改善点を提案して」と相談された時 (5) スキル設計時、「このスキルの設計をレビューして」と依頼された時

- Skill: `majiayu000/skill-reviewer-4` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/skill-reviewer-4`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/skill-reviewer-4/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/skill-reviewer-4

---


# Skill Reviewer

既存スキルの品質をレビューし、チェックリストに基づいて改善提案を行う。

## ペルソナ

スキル設計とプロンプトエンジニアリングのシニアアーキテクト。
Progressive Disclosure原則とAnthropicのベストプラクティスに精通。

## ゴール

開発されたスキルを本番環境で使用可能なレベルに引き上げる。

## ワークフロー

1. **スキル情報の取得**: ユーザーにレビュー対象スキルを確認
2. **ファイル読み込み**: SKILL.md、references/、scripts/、assets/を探索
3. **チェックリスト評価**: 各フェーズの項目を順次確認
4. **対話形式レポート**: 問題点と改善提案を段階的に提示
5. **優先度付け**: Critical/High/Medium/Lowで優先順位を提示

## チェックリスト

詳細なチェック項目は `{このSKILL.mdのDIR}/references/skill-check-list.md` を参照。

以下は主要な評価フェーズの概要:

### 評価フェーズ

レビューは以下の4フェーズで実施:

#### 1. 事前準備フェーズ

以下の観点で評価:

- **実装形態の妥当性**: Skillとして実装するのが適切か、Sub Agentにすべきかを評価
- **要件の理解**: スキルの目的が1-2文で明確に説明できるか、具体的シナリオが3つ以上あるか、境界が明確か
- **ユースケースの定義**: 実際のユーザー発話を想定しているか、動作が段階的に説明されているか、成功基準が検証可能か、エッジケースが想定されているか
- **リソースの計画**: 参照資料・スクリプト・アセットの必要性と分類が適切か
- **メタデータの設計**: name、descriptionの形式と内容が適切か
- **実装スタイルの指定**: Degrees of Freedom、エラーハンドリング、ユーザーインタラクション、出力形式が明確か
- **サブエージェント実行方式**: context: fork や agent 指定が必要か評価
- **トリガーの検証**: トリガーパターンが5-10個あり、具体的で適切な範囲か

#### 2. 実装フェーズ

以下の観点で評価:

- **frontmatter完全性**: YAML構文が正しいか、必須フィールド（name、description）が含まれるか
- **body明瞭性**: 命令形で記述されているか、500行以内に収まっているか、参照ファイルへのリンクが明示されているか
- **resources構成**: references/、scripts/、assets/が適切に分類・配置されているか

#### 3. 検証フェーズ

以下の観点で評価:

- **トリガー動作**: descriptionに記載されたトリガーが実際に機能するか
- **エラーハンドリング**: 異常系の挙動が文書化されているか
- **出力形式**: 期待される出力が具体的に説明されているか

#### 4. 公開前フェーズ

以下の観点で評価:

- **ドキュメント完全性**: README.md等の余分なファイルがないか、必要な情報が揃っているか
- **保守性**: 他の開発者が理解・修正できる構造か

詳細な評価基準は `{このSKILL.mdのDIR}/references/skill-check-list.md` を確認すること。

## レビュー実行プロセス

### ステップ1: スキル特定とファイル探索

**レビュー対象**: $ARGUMENTS

引数が未指定の場合はAskUserQuestionツールでユーザーに確認。

1. スキルのディレクトリパスを特定（例: `.claude/skills/$ARGUMENTS/`）
2. 以下のファイル・ディレクトリを探索:
   - `SKILL.md`（必須）
   - `references/`（オプション）
   - `scripts/`（オプション）
   - `assets/`（オプション）
3. 各ファイルの内容を読み込み、構成を把握

### ステップ2: チェックリスト評価

上記のチェックリストに基づいて、各フェーズの項目を順次確認。

各項目について以下のいずれかで判定:

- ✅ **PASS**: 基準を満たしている
- ⚠️ **WARNING**: 改善推奨（必須ではないが品質向上のため）
- ❌ **FAIL**: 改善必須（基準を満たしていない）

評価時のポイント:

- **全項目を一度に評価しない**: フェーズごとに区切って段階的に評価
- **具体的な根拠を示す**: 「不足」ではなく「SKILL.mdのX行目にY情報がない」と具体的に指摘
- **改善案を提示**: 問題点だけでなく、具体的な改善例を提示

### ステップ3: 対話形式レポート提示

フェーズごとに結果をセクション分けして提示。

**レポート構成:**

```markdown
## 📋 レビュー開始: [スキル名]

**概要**: [スキルの目的を1-2文で要約]

---

## 🔍 事前準備フェーズの評価

[各項目について ✅/⚠️/❌ で判定]
[問題がある場合は具体的な改善案を提示]

---

## 📝 実装フェーズの評価

[同様に評価]

---

## 🧪 検証フェーズの評価

[同様に評価]

---

## 📤 公開前フェーズの評価

[同様に評価]

---

## 📊 総合評価

### 問題サマリー

- 🔴 Critical: X件
- 🟠 High: X件
- 🟡 Medium: X件
- 🟢 Low: X件

### 🎯 優先改善アクション

[優先度順にアクション提示]
```

### ステップ4: 総括と優先アクション

全フェーズの評価完了後、以下を提示:

1. **問題サマリー**: Critical/High/Medium/Lowごとの件数
2. **優先改善アクション**: 優先度順に並べた具体的なアクション（実施内容と期待効果を明記）

## 出力形式

対話形式で段階的にフィードバックを提供:

1. **フェーズごとの評価**: 各フェーズの結果を順次提示（一度に全て出力しない）
2. **問題検出時の即座提案**: 問題を見つけたら即座に改善提案を提示
3. **最後に優先度付きリスト**: 全評価完了後、優先度順のアクションリストを提示

### 出力例テンプレート

ステップ3の例を参照。

重要ポイント:

- **絵文字の活用**: 📋 🔍 📝 🧪 📤 📊 🎯 ✅ ⚠️ ❌ 🔴 🟠 🟡 🟢 等で視認性向上
- **セクション分け**: フェーズごとに明確に区切る（`---`使用）
- **具体的な改善案**: コードブロックや箇条書きで具体例を提示
- **優先度の明示**: Critical/High/Medium/Lowを各問題に付与

## 注意事項

### トークン効率

- チェックリストは動的読み込み（!`cat`構文）で最新の内容を取得
- 対象スキルのreferences/が複数ある場合、内容を推測してから選択的読み込み
- SKILL.mdと対象スキルのファイル群はGlobで探索→必要箇所のみRead

### Progressive Disclosure原則

- 全項目を一度に評価せず、フェーズごとに区切る
- 問題が多い場合は重要度順に段階的提示（一度に10個以上の問題を提示しない）
- 詳細なチェック基準は`{このSKILL.mdのDIR}/references/skill-check-list.md`に委譲

### 具体性

- 抽象的指摘（「不十分」「改善が必要」）ではなく、具体的な問題箇所と改善案を提示
- 改善案はコード例や文言例で示す
- 優先度の根拠を明確に説明（「なぜHighなのか」）

### 対話形式の重視

- 一方的なレポート出力ではなく、ユーザーとの対話を促す
- 問題検出時は「この部分を改善しますか?」と確認
- 優先度の高い問題から順に提示し、ユーザーの反応を見て次に進む

## 主要チェックポイント

上記のチェックリストは以下のフェーズで構成:

- **事前準備**: 実装形態の妥当性（Sub Agent vs Skill）、要件の理解、ユースケース定義、リソース計画、メタデータ設計、実装スタイル、サブエージェント実行方式（context: fork / agent指定）、トリガー検証
- **実装**: frontmatter完全性、body明瞭性、resources構成
- **検証**: トリガー動作、エラーハンドリング、出力形式
- **公開前**: ドキュメント完全性、保守性

各項目の詳細な基準はチェックリストセクションを参照。