update-design

name	update-design
description	ptuf の `docs/design/` 配下の設計書を評価・改善するスキル。フィルタ判定ロジックや PreToolUse フック契約の整合性を `src/` と突き合わせて検証する。

update-design スキル

ptuf (PreToolUseFilter) の設計書を 収集 → 評価 → 整合確認 → 改善提案 の 4 フェーズで点検する。

Phase 1: コンテキスト収集

• docs/design/ 配下の Markdown ファイルをすべて読む
• src/lib.rs / src/main.rs の公開 API（Decision, HookInput, decide）を読み、設計書との対応を把握する
• Cargo.toml の依存と deny.toml の制約から、設計上利用可能なクレートの範囲を確認する

Phase 2: 設計書品質評価 (100 点満点 / 5 カテゴリ)

各 20 点で採点し、合計 90 点以上で実装 ready とみなす。50 点未満は再設計を要求する。

カテゴリ	観点
モジュール / 構造体設計	クレート分割、pub 境界、責務分離、Rust 命名規約 (PascalCase / snake_case)
フック契約 (PreToolUse JSON I/O)	Claude Code の hook payload との互換、tool_name / tool_input のフィールド網羅、Decision 出力の JSON スキーマ
判定ルール / ポリシー設計	ルールの記述方式、優先順位、拒否理由 (Decision::Deny.reason) のテンプレート、デフォルト挙動
エラーハンドリング	Result 伝搬、#![forbid(unsafe_code)] 遵守、unwrap/expect 不使用、stdin / JSON parse 失敗時の終了コード
テスト容易性	関数の純粋性、I/O の境界化、フィクスチャ駆動テストの設計、95% coverage 維持戦略

Phase 3: 整合性チェック

• 設計書 ↔ src/ の双方向比較（設計済みだが未実装、実装済みだが未設計の箇所を列挙）
• 設計書 ↔ README.md / CLAUDE.md のコマンド・I/O 例の突合
• 設計書間の用語・データ型・終了コードの不整合検出

Phase 4: 改善提案

• P0 (実装ブロッカー) / P1 (品質低下) / P2 (Nice to have) で優先度分類
• 各指摘は「対象ファイル:行 → 問題 → 推奨修正」の形式で記述
• 具体的な Rust コード断片を添える（PascalCase / snake_case 準拠）

出力テンプレート

## 評価サマリ
| カテゴリ | 点数 |
| --- | --- |
| モジュール / 構造体設計 | xx / 20 |
| フック契約 | xx / 20 |
| 判定ルール / ポリシー | xx / 20 |
| エラーハンドリング | xx / 20 |
| テスト容易性 | xx / 20 |
| **合計** | **xx / 100** |

## 主要所見
...

## 設計書 ↔ ソース整合性
...

## 改善提案
- P0: ...
- P1: ...
- P2: ...