Menu
設計書を作成・更新した後に発動。100点満点で自己評価し、不足点をタスクリストにして設計書を改善。矛盾や収載漏れがないことを最終確認する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | update-design |
| description | 設計書を作成・更新した後に発動。100点満点で自己評価し、不足点をタスクリストにして設計書を改善。矛盾や収載漏れがないことを最終確認する。 |
設計書（docs/design/*.md）を作成・更新した直後に実行する。
設計書の品質を100点満点で自己評価し、不足点を特定・改善し、最終的に矛盾や漏れがないことを確認する。
ultrathink
引数で指定された設計書、または直前に作成・更新した設計書を特定する。
# 引数がない場合、最近変更された設計書を特定
git diff --name-only HEAD~3 -- docs/design/
対象の設計書を全文読み込む。同時に、関連するソースコードも確認する。
確認対象:
docs/design/<feature>.md）docs/requirements.md）との整合性src/ 配下）以下の10カテゴリ × 10点満点で評価する。各カテゴリの採点基準に従い、厳密に採点すること。
| # | カテゴリ | 配点 | 評価観点 |
|---|---|---|---|
| 1 | 基本構造 | 10点 | 必須セクション（概要・変換仕様・実装詳細・テスト・エラー処理）が揃っているか |
| 2 | 目的・スコープの明確性 | 10点 | 何を実装するか、何を実装しないかが明確か。読み手が迷わないか |
| 3 | 変換ロジックの完全性 | 10点 | SKILL.md→POWER.md変換の仕様が網羅されているか。frontmatter→frontmatter、body→steering、resources→resourcesのマッピングが明記されているか |
| 4 | CLI設計 | 10点 | Commanderコマンド・オプション設計（convert、--overwrite、--dry-run、--keywords、--mcp-template、--no-resources）が明記されているか |
| 5 | 内部アーキテクチャ | 10点 | ファイル構成（types/helpers/converter/cli/index）、モジュール間のデータフローが記述されているか |
| 6 | エッジケース・異常系 | 10点 | 境界条件（空SKILL.md、既存出力ディレクトリ、不正frontmatter、日本語ファイル名）への対処が考慮されているか |
| 7 | テスト戦略 | 10点 | ユニットテストの方針と具体的なテストケース（helpers純関数テスト、converter tmpディレクトリテスト）があるか |
| 8 | キーワード抽出設計 | 10点 | 英語トークナイズ（ストップワード除去）、日本語候補抽出、頻度分析、上限制御の仕様が明記されているか |
| 9 | 技術選定の根拠 | 10点 | Commander, gray-matter, fs-extra, YAML等の採用理由が明記されているか |
| 10 | 実装計画 | 10点 | Phase/Iteration分割、ファイル構成、依存関係が具体的か |
| 点数 | 基準 |
|---|---|
| 9-10 | 模範的。実装着手に必要な情報が全て揃っている。追加すべき内容がない |
| 7-8 | 良好。軽微な追記で完成する |
| 5-6 | 普通。重要な情報が一部欠けている |
| 3-4 | 不十分。大幅な追記が必要 |
| 1-2 | 骨格のみ。ほぼ未記述 |
| 0 | セクション自体が存在しない |
各カテゴリを採点し、以下のフォーマットで結果を出力する。
## 自己評価結果
| # | カテゴリ | 点数 | 評価コメント |
|---|---------|------|-------------|
| 1 | 基本構造 | X/10 | ... |
| 2 | 目的・スコープの明確性 | X/10 | ... |
| 3 | 変換ロジックの完全性 | X/10 | ... |
| 4 | CLI設計 | X/10 | ... |
| 5 | 内部アーキテクチャ | X/10 | ... |
| 6 | エッジケース・異常系 | X/10 | ... |
| 7 | テスト戦略 | X/10 | ... |
| 8 | キーワード抽出設計 | X/10 | ... |
| 9 | 技術選定の根拠 | X/10 | ... |
| 10 | 実装計画 | X/10 | ... |
| | **合計** | **XX/100** | |
8点未満のカテゴリを改善対象として抽出し、優先度を付ける:
Phase 2の評価結果からタスクリストを作成する。TodoWriteツールを使用してタスクを管理する。
タスクの粒度:
タスクリストに従い、設計書を更新する。
更新ルール:
タスクを1つ完了するごとに:
設計書の更新が完了したら、全文を再読して以下を検証する。
src/types.ts）と設計書の型名が一致しているかdocs/requirements.md）の機能スコープと、設計書の記述が矛盾していないかsrc/cli.ts）と設計書のオプション定義が一致しているか既に実装が存在する場合:
src/types.ts のソースコードと一致しているかsrc/helpers.ts, src/converter.ts）がソースコードと一致しているか矛盾や漏れが見つかった場合:
問題がなくなるまで繰り返す（最大3回）。
最終的な評価結果をユーザーに報告する。
報告フォーマット:
## 設計書評価レポート: <設計書名>
### 初回評価: XX/100点
### 改善後評価: YY/100点
### 改善内容
- <改善1>
- <改善2>
- ...
### 最終検証結果
- 内部一貫性: ✅ / ⚠️（詳細）
- 収載漏れ: ✅ / ⚠️（詳細）
- ソースコード整合性: ✅ / ⚠️（詳細） / N/A（未実装）
docs/requirements.md）のフォーマットを参考に新規作成を提案する