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: ...

Más de este repositorio

mismo repositorio

ponytail

watany-dev/ptuf

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).

2026-07-063

wrapup

watany-dev/ptuf

タスク完了時に simplify と update-docs を順に実行し、最後に /compact のリマインドを出す。Stop hook の block reason から起動されるか、user が「タスク完了」「/wrapup」と言ったときに発動する。

2026-05-093

grill-me

watany-dev/ptuf

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".

2026-05-063

update-docs

watany-dev/ptuf

ptuf のドキュメント (README.md, docs/design/, CLAUDE.md) を最新の `src/` に追従させる更新スキル。

2026-05-033

update-plan

watany-dev/ptuf

プランモード完了直前に、プランファイルの品質を `update-design` 同等の基準で検証・改善し、合格してから `ExitPlanMode` を呼ぶ統合スキル。

2026-05-033

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: ...