Menü
ptuf の `docs/design/` 配下の設計書を評価・改善するスキル。フィルタ判定ロジックや PreToolUse フック契約の整合性を `src/` と突き合わせて検証する。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests (general knowledge, prose, translation, summaries, recipes).
タスク完了時に simplify と update-docs を順に実行し、最後に /compact のリマインドを出す。Stop hook の block reason から起動されるか、user が「タスク完了」「/wrapup」と言ったときに発動する。
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
ptuf のドキュメント (README.md, docs/design/, CLAUDE.md) を最新の `src/` に追従させる更新スキル。
プランモード完了直前に、プランファイルの品質を `update-design` 同等の基準で検証・改善し、合格してから `ExitPlanMode` を呼ぶ統合スキル。
| name | update-design |
| description | ptuf の `docs/design/` 配下の設計書を評価・改善するスキル。フィルタ判定ロジックや PreToolUse フック契約の整合性を `src/` と突き合わせて検証する。 |
ptuf (PreToolUseFilter) の設計書を 収集 → 評価 → 整合確認 → 改善提案 の 4 フェーズで点検する。
docs/design/ 配下の Markdown ファイルをすべて読むsrc/lib.rs / src/main.rs の公開 API（Decision, HookInput, decide）を読み、設計書との対応を把握するCargo.toml の依存と deny.toml の制約から、設計上利用可能なクレートの範囲を確認する各 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 維持戦略 |
src/ の双方向比較（設計済みだが未実装、実装済みだが未設計の箇所を列挙）README.md / CLAUDE.md のコマンド・I/O 例の突合## 評価サマリ
| カテゴリ | 点数 |
| --- | --- |
| モジュール / 構造体設計 | xx / 20 |
| フック契約 | xx / 20 |
| 判定ルール / ポリシー | xx / 20 |
| エラーハンドリング | xx / 20 |
| テスト容易性 | xx / 20 |
| **合計** | **xx / 100** |
## 主要所見
...
## 設計書 ↔ ソース整合性
...
## 改善提案
- P0: ...
- P1: ...
- P2: ...