chokkin 0.1.0__tar.gz

chokkin-0.1.0/.cargo/audit.toml

@@ -0,0 +1,13 @@
+# cargo-audit configuration — keep in sync with deny.toml [advisories].ignore
+#
+# Transitive via rustpython-parser 0.4 (ADR 0001). Revisit when evaluating Ruff parser.
+
+[advisories]
+ignore = [
+    "RUSTSEC-2025-0075", # unic-char-range
+    "RUSTSEC-2025-0080", # unic-common
+    "RUSTSEC-2025-0081", # unic-char-property
+    "RUSTSEC-2025-0090", # unic-emoji-char
+    "RUSTSEC-2025-0098", # unic-ucd-version
+    "RUSTSEC-2025-0100", # unic-ucd-ident
+]

chokkin-0.1.0/.cargo/config.toml

@@ -0,0 +1,2 @@
+[target.x86_64-unknown-linux-gnu]
+rustflags = ["-C", "link-arg=-fuse-ld=lld"]

chokkin-0.1.0/.claude/hooks/stop-wrapup.sh

@@ -0,0 +1,58 @@
+#!/bin/bash
+# Stop hook: Claude が応答を終了する直前に発火し,wrapup skill が
+# 実行済みかをマーカーファイルで検査する。未実行なら decision:"block" で
+# Claude に wrapup 起動を促す。
+#
+# 設計上の注意:
+#   - `stop_hook_active` は意図的に見ない。user-level git-check hook が
+#     先に block して再帰した場合に短絡してしまい,wrapup が起動しない罠
+#     を回避するため,独自マーカーで状態管理する。
+#   - Q&A 応答での誤発火を避けるため,transcript JSONL の末尾 user turn
+#     以降に Edit/Write/MultiEdit/NotebookEdit の tool_use があったかで判定。
+set -euo pipefail
+
+# jq 必須。無い環境ではフェイルセーフで素通り。
+command -v jq >/dev/null 2>&1 || exit 0
+
+input=$(cat)
+
+# git repo 外なら何もしない (CLAUDE_PROJECT_DIR が想定と違うケース)
+git rev-parse --git-dir >/dev/null 2>&1 || exit 0
+
+session_id=$(echo "$input" | jq -r '.session_id // "default"')
+transcript=$(echo "$input" | jq -r '.transcript_path // ""')
+marker="${TMPDIR:-/tmp}/chokkin-wrapup-$session_id"
+
+# 編集系 tool_use 名のリスト。SKILL.md の手順で「編集」と扱うものと揃える。
+edit_tools_re='"name":"(Edit|Write|MultiEdit|NotebookEdit)"'
+
+# マーカー存在 = wrapup 実行済 → 許可。次の user turn で再ブロックする
+# ためにマーカーを削除する。
+if [ -f "$marker" ]; then
+  rm -f "$marker"
+  exit 0
+fi
+
+# Q&A ターン heuristic: transcript を tac で逆順に流し,最後の user turn
+# と編集系 tool_use のうち先に現れた方を `grep -m1` で検出する。
+# 編集系が先 (= 元の順序では user turn の後) → block。
+# user turn が先 (= 編集系が無かった) → skip。
+# transcript が読めない / 空なら安全側に倒して block する。
+should_block=true
+if [ -n "$transcript" ] && [ -r "$transcript" ]; then
+  first_match=$(tac "$transcript" 2>/dev/null \
+    | grep -m1 -E "(\"type\":\"user\"|$edit_tools_re)" || true)
+  case "$first_match" in
+    *'"type":"user"'*) should_block=false ;;
+  esac
+fi
+
+if [ "$should_block" = false ]; then
+  exit 0
+fi
+
+# block + 指示。skill が拾えるよう reason に marker 絶対パスを埋め込む。
+jq -n --arg marker "$marker" '{
+  decision: "block",
+  reason: ("終了前に wrapup skill を実行してください。Skill ツールで `wrapup` を呼び出すと simplify と update-docs が順に走り,最後に `/compact` のリマインドが出ます。完了したら最後に `touch " + $marker + "` を必ず実行してください (このマーカーが無いと無限にブロックされます)。git-check hook も同時に block している場合は wrapup を先に終えてから commit&push してください。")
+}'

chokkin-0.1.0/.claude/settings.json

@@ -0,0 +1,29 @@
+{
+  "effortLevel": "high",
+  "language": "japanese",
+  "autoMemoryEnabled": false,
+  "env": {
+    "CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
+  },
+  "permissions": {
+    "allow": [
+      "Bash(make:*)",
+      "Bash(cargo:*)",
+      "Bash(git:*)",
+      "Bash(uvx:*)"
+    ]
+  },
+  "hooks": {
+    "Stop": [
+      {
+        "matcher": "",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/stop-wrapup.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

chokkin-0.1.0/.claude/skills/grill-me/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: grill-me
+description: プランや設計について、共通理解に達するまで user を徹底的に問い詰める。決定木の各分岐を 1 つずつ解消する。プランをストレステストしたいとき、設計をレビューさせたいとき、user が「grill me」と言ったときに発動する。
+---
+
+# grill-me
+
+このプランのあらゆる側面について、共通理解に達するまで徹底的に問い詰める。
+設計ツリーの各分岐を辿り、決定間の依存関係を 1 つずつ解消していく。各質問には
+推奨する回答を添える。
+
+質問は 1 度に 1 つずつ行う。
+
+コードベースを探索すれば答えが出る質問は、質問せずに探索で解決する。
+
+共通理解に達したら、決定とその根拠を `docs/adr/` 配下の ADR として記録する
+（ファイル名: `NNNN-<slug>.md`、連番）。`docs/adr/` が無ければ新規作成する。

chokkin-0.1.0/.claude/skills/update-design/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: update-design
+description: docs/dev/spec.ja.md の設計書を 5 カテゴリ×20点で評価・改善し、ソースコードとの齟齬を双方向で検出する。設計レビューや実装着手前の品質確認、user が「/update-design」と言ったときに発動する。
+---
+
+# update-design
+
+chokkin（Python 向け静的到達可能性解析ツール）の設計書 `docs/dev/spec.ja.md` を
+体系的に評価・改善するスキル。4 フェーズで検証する。
+
+## Phase 1: コンテキスト収集
+
+`docs/dev/spec.ja.md`（§1–§21）と `src/` の API を対応付け、モジュール階層
+（cli/config/manifest/parser/resolver/graph/rules/reporters/fix/plugins）の
+依存関係を確認する。`Cargo.toml` の lint 設定（unsafe forbid、unwrap/expect/panic 禁止）
+も前提として押さえる。
+
+## Phase 2: 品質評価（100点満点）
+
+5 カテゴリ × 20点で採点する:
+
+| カテゴリ | 評価観点 |
+| --- | --- |
+| モジュール / struct 設計 | Rust の境界が明確か、`lib.rs` 中心の構成か |
+| 静的解析制約 | Python コードを実行しない設計が貫かれているか（import/exec/spawn 禁止） |
+| ルール / ポリシー | CHK001–CHK010 の判定ロジックと既定挙動が妥当か |
+| エラー処理 | Result/Option 伝播、unwrap 回避、終了コード規約の遵守 |
+| テスト容易性 | カバレッジ維持戦略、parser/graph のテスト設計 |
+
+## Phase 3: 整合性チェック
+
+設計書とソースコード間の齟齬を双方向で検出する:
+- シンボル名・パスが一致するか
+- 現行コードと設計記述が矛盾していないか
+- フェーズ順序（roadmap）が依存関係と整合するか
+
+## Phase 4: 改善提案
+
+- 90点以上で実装準備完了、50点未満は再設計が必要と判定する
+- 指摘を P0 / P1 / P2 の優先度で記述し、設計書へ反映する
+- 採点サマリと主要な所見を末尾に付記する

chokkin-0.1.0/.claude/skills/update-docs/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: update-docs
+description: src/ の実装変更を README.md / README.ja.md / docs/dev/ / CLAUDE.md / AGENTS.md に同期する。コード変更後やドキュメントの陳腐化が疑われるとき、user が「/update-docs」と言ったときに発動する。
+---
+
+# update-docs
+
+chokkin の進化するソースコードと陳腐化しがちなドキュメントの差分を体系的に埋める
+スキル。5 フェーズで実施する。
+
+## Phase 1: コード監査
+
+実装の現状を把握する:
+- `src/lib.rs` の public API（モジュール階層 cli/config/manifest/parser/resolver/
+  graph/rules/reporters/fix/plugins のうち実装済みのもの）
+- `src/main.rs` の CLI 挙動（引数ディスパッチ、ExitStatus → 終了コード）
+- `Cargo.toml` / `pyproject.toml` のメタデータ（バージョン、edition、maturin bin 設定）
+
+## Phase 2: 設計ドキュメント更新
+
+`docs/dev/spec.ja.md`（§1–§21）を実装と突き合わせる:
+- API 変更を反映する
+- ステータスラベル（design phase / pre-alpha / 実装済み）を実態に合わせる
+- ルール CHK001–CHK010 と reporters（default/compact/JSON/Markdown）の記述を整合させる
+
+## Phase 3: README 更新
+
+`README.md`（英）と `README.ja.md`（日）の両方に以下が含まれるか確認・更新する:
+- プロジェクト概要 1 段落（Python 向け到達可能性解析・未使用 files/deps/symbols 検出、
+  Knip 相当）
+- インストール／ビルド手順（maturin wheel、`make` ターゲット）
+- CLI 利用例と終了コード（0 = 問題なし、非 0 = 未使用検出 / エラー）
+- `make` ターゲット一覧
+
+## Phase 4: 整合性チェック
+
+全 Markdown 間で次を揃える:
+- コマンド名・パス・クレート識別子・ルール番号・終了コード・用語
+- 言語規約: `README.md` と `CLAUDE.md` / `AGENTS.md` は英語、`README.ja.md` と
+  `docs/dev/` 配下（`spec.ja.md` 等）は日本語
+- 「Python コードを絶対に実行しない（static parse only）」の制約が崩れていないか
+
+## Phase 5: 報告
+
+構造化レポートを出す:
+- 更新したファイル一覧
+- ドキュメント化候補（実装にあるが未記載の項目）
+- 設計判断が必要な未解決の不整合

chokkin-0.1.0/.claude/skills/update-plan/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: update-plan
+description: プランモード完了直前に、プランファイルの品質を update-design 同等の基準で検証・改善し、合格してから ExitPlanMode を呼ぶ統合スキル。プラン確定前、user が「/update-plan」と言ったときに発動する。
+---
+
+# update-plan
+
+プランモード終了直前にプランファイルの品質を確保し、設計書と同じ基準で合格して
+から `ExitPlanMode` を呼ぶ統合スキル。4 フェーズで進める。
+
+## Phase 1: コンテキスト収集
+
+現在のプランファイルと、関連成果物を集める:
+- 設計書 `docs/dev/spec.ja.md`
+- プロジェクト文書 `README.md` / `README.ja.md` / `CLAUDE.md` / `AGENTS.md`
+- マニフェスト `Cargo.toml` / `pyproject.toml`
+- プランが触れる `src/` 配下のファイル
+
+## Phase 2: 品質評価（100点満点）
+
+`update-design` と同じ 5 カテゴリ × 20点で評価する:
+
+| カテゴリ | 評価観点 |
+| --- | --- |
+| モジュール / struct 設計 | プランが Rust の境界を明確に扱っているか |
+| 静的解析制約 | Python コード非実行の制約を崩さないか、変更スコープが妥当か |
+| ルール / ポリシー | YOK ルールの判定ロジックと既定挙動への影響 |
+| エラー処理 | Result 伝播、unwrap 回避、終了コード規約の遵守 |
+| テスト容易性 | カバレッジ維持戦略と具体的なテスト計画 |
+
+合格には 90点以上が必要。
+
+## Phase 3: 整合性チェック
+
+- プランと既存コードベースの整合（シンボル名・パス）
+- 現行設計書との突き合わせ
+- 手順の論理順序が依存関係を尊重しているか
+
+## Phase 4: 改善と確定
+
+- 検出した課題を P0 / P1 / P2 で分類しプランへ反映する
+- 採点と主要所見の検証サマリをプランに付記する
+- その後 `ExitPlanMode` を呼ぶ

chokkin-0.1.0/.claude/skills/wrapup/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: wrapup
+description: タスク完了時に simplify と update-docs を順に実行し、最後に /compact のリマインドを出す。Stop hook の block reason から起動されるか、user が「タスク完了」「/wrapup」と言ったときに発動する。
+---
+
+# wrapup
+
+chokkin の編集タスク後に手動で行っていた `/simplify` → `/update-docs` → `/compact`
+の連鎖を自動化するスキル。Stop hook (`.claude/hooks/stop-wrapup.sh`) が未実行を
+検知して `decision:"block"` で起動を促すか、user が「タスク完了」「/wrapup」と
+言ったときに発動する。
+
+## 実行手順
+
+1. **simplify** を Skill ツールで呼び出し、変更したコードを再利用性・品質・効率の
+   観点でレビュー／リファクタする。
+2. **update-docs** を Skill ツールで呼び出し、`src/` の変更を `README.md` /
+   `README.ja.md` / `docs/dev/spec.ja.md` / `CLAUDE.md` / `AGENTS.md` に同期する。
+3. ファイルを変更した場合は `make check` を実行し、fmt-check → lint (clippy + doc) →
+   test → deny → machete が通ることを確認する。
+4. **完了マーカーを必ず touch する。** Stop hook の block reason に埋め込まれた
+   絶対パス (例 `/tmp/chokkin-wrapup-<session_id>`) を `touch` する。reason から
+   取得できない場合は `/tmp/chokkin-wrapup-default` をフォールバックに使う。
+5. user に簡潔にリマインドする: 「wrapup 完了。`/compact` でコンテキストを圧縮して
+   ください。」
+
+## 注意
+
+- 手順 4 は **常に実行する**。省くと次回 Stop hook で無限ループに陥る。
+- simplify / update-docs が「変更なし」と報告しても、手順 4 と 5 は実行する。
+- git-check hook が同時に commit を要求している場合は、simplify / update-docs が
+  ドキュメントを変更しうるため、先に wrapup を終えてから commit & push する。
+- chokkin は Python コードを実行しない静的解析ツール。simplify / update-docs が
+  解析対象プロジェクトのコードを実行することは絶対にない。
+
+## ホスト別の注意 (Codex / Cursor)
+
+`.codex/skills` と `.cursor/skills` はこの `.claude/skills` への symlink。
+Codex / Cursor から本スキルを起動した場合、手順 4 のマーカーと手順 5 の
+`/compact` は Claude Code 専用なので省略し、手順 1–3（コード整理 →
+update-docs → `make check`）のコアだけを実行する。`simplify` は Claude Code の
+組込みスキルなので、Codex / Cursor では同等のコード整理を手動で行う。

chokkin-0.1.0/.codex/skills/grill-me/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: grill-me
+description: プランや設計について、共通理解に達するまで user を徹底的に問い詰める。決定木の各分岐を 1 つずつ解消する。プランをストレステストしたいとき、設計をレビューさせたいとき、user が「grill me」と言ったときに発動する。
+---
+
+# grill-me
+
+このプランのあらゆる側面について、共通理解に達するまで徹底的に問い詰める。
+設計ツリーの各分岐を辿り、決定間の依存関係を 1 つずつ解消していく。各質問には
+推奨する回答を添える。
+
+質問は 1 度に 1 つずつ行う。
+
+コードベースを探索すれば答えが出る質問は、質問せずに探索で解決する。
+
+共通理解に達したら、決定とその根拠を `docs/adr/` 配下の ADR として記録する
+（ファイル名: `NNNN-<slug>.md`、連番）。`docs/adr/` が無ければ新規作成する。

chokkin-0.1.0/.codex/skills/update-design/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: update-design
+description: docs/dev/spec.ja.md の設計書を 5 カテゴリ×20点で評価・改善し、ソースコードとの齟齬を双方向で検出する。設計レビューや実装着手前の品質確認、user が「/update-design」と言ったときに発動する。
+---
+
+# update-design
+
+chokkin（Python 向け静的到達可能性解析ツール）の設計書 `docs/dev/spec.ja.md` を
+体系的に評価・改善するスキル。4 フェーズで検証する。
+
+## Phase 1: コンテキスト収集
+
+`docs/dev/spec.ja.md`（§1–§21）と `src/` の API を対応付け、モジュール階層
+（cli/config/manifest/parser/resolver/graph/rules/reporters/fix/plugins）の
+依存関係を確認する。`Cargo.toml` の lint 設定（unsafe forbid、unwrap/expect/panic 禁止）
+も前提として押さえる。
+
+## Phase 2: 品質評価（100点満点）
+
+5 カテゴリ × 20点で採点する:
+
+| カテゴリ | 評価観点 |
+| --- | --- |
+| モジュール / struct 設計 | Rust の境界が明確か、`lib.rs` 中心の構成か |
+| 静的解析制約 | Python コードを実行しない設計が貫かれているか（import/exec/spawn 禁止） |
+| ルール / ポリシー | CHK001–CHK010 の判定ロジックと既定挙動が妥当か |
+| エラー処理 | Result/Option 伝播、unwrap 回避、終了コード規約の遵守 |
+| テスト容易性 | カバレッジ維持戦略、parser/graph のテスト設計 |
+
+## Phase 3: 整合性チェック
+
+設計書とソースコード間の齟齬を双方向で検出する:
+- シンボル名・パスが一致するか
+- 現行コードと設計記述が矛盾していないか
+- フェーズ順序（roadmap）が依存関係と整合するか
+
+## Phase 4: 改善提案
+
+- 90点以上で実装準備完了、50点未満は再設計が必要と判定する
+- 指摘を P0 / P1 / P2 の優先度で記述し、設計書へ反映する
+- 採点サマリと主要な所見を末尾に付記する

chokkin-0.1.0/.codex/skills/update-docs/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: update-docs
+description: src/ の実装変更を README.md / README.ja.md / docs/dev/ / CLAUDE.md / AGENTS.md に同期する。コード変更後やドキュメントの陳腐化が疑われるとき、user が「/update-docs」と言ったときに発動する。
+---
+
+# update-docs
+
+chokkin の進化するソースコードと陳腐化しがちなドキュメントの差分を体系的に埋める
+スキル。5 フェーズで実施する。
+
+## Phase 1: コード監査
+
+実装の現状を把握する:
+- `src/lib.rs` の public API（モジュール階層 cli/config/manifest/parser/resolver/
+  graph/rules/reporters/fix/plugins のうち実装済みのもの）
+- `src/main.rs` の CLI 挙動（引数ディスパッチ、ExitStatus → 終了コード）
+- `Cargo.toml` / `pyproject.toml` のメタデータ（バージョン、edition、maturin bin 設定）
+
+## Phase 2: 設計ドキュメント更新
+
+`docs/dev/spec.ja.md`（§1–§21）を実装と突き合わせる:
+- API 変更を反映する
+- ステータスラベル（design phase / pre-alpha / 実装済み）を実態に合わせる
+- ルール CHK001–CHK010 と reporters（default/compact/JSON/Markdown）の記述を整合させる
+
+## Phase 3: README 更新
+
+`README.md`（英）と `README.ja.md`（日）の両方に以下が含まれるか確認・更新する:
+- プロジェクト概要 1 段落（Python 向け到達可能性解析・未使用 files/deps/symbols 検出、
+  Knip 相当）
+- インストール／ビルド手順（maturin wheel、`make` ターゲット）
+- CLI 利用例と終了コード（0 = 問題なし、非 0 = 未使用検出 / エラー）
+- `make` ターゲット一覧
+
+## Phase 4: 整合性チェック
+
+全 Markdown 間で次を揃える:
+- コマンド名・パス・クレート識別子・ルール番号・終了コード・用語
+- 言語規約: `README.md` と `CLAUDE.md` / `AGENTS.md` は英語、`README.ja.md` と
+  `docs/dev/` 配下（`spec.ja.md` 等）は日本語
+- 「Python コードを絶対に実行しない（static parse only）」の制約が崩れていないか
+
+## Phase 5: 報告
+
+構造化レポートを出す:
+- 更新したファイル一覧
+- ドキュメント化候補（実装にあるが未記載の項目）
+- 設計判断が必要な未解決の不整合

chokkin-0.1.0/.codex/skills/update-plan/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: update-plan
+description: プランモード完了直前に、プランファイルの品質を update-design 同等の基準で検証・改善し、合格してから ExitPlanMode を呼ぶ統合スキル。プラン確定前、user が「/update-plan」と言ったときに発動する。
+---
+
+# update-plan
+
+プランモード終了直前にプランファイルの品質を確保し、設計書と同じ基準で合格して
+から `ExitPlanMode` を呼ぶ統合スキル。4 フェーズで進める。
+
+## Phase 1: コンテキスト収集
+
+現在のプランファイルと、関連成果物を集める:
+- 設計書 `docs/dev/spec.ja.md`
+- プロジェクト文書 `README.md` / `README.ja.md` / `CLAUDE.md` / `AGENTS.md`
+- マニフェスト `Cargo.toml` / `pyproject.toml`
+- プランが触れる `src/` 配下のファイル
+
+## Phase 2: 品質評価（100点満点）
+
+`update-design` と同じ 5 カテゴリ × 20点で評価する:
+
+| カテゴリ | 評価観点 |
+| --- | --- |
+| モジュール / struct 設計 | プランが Rust の境界を明確に扱っているか |
+| 静的解析制約 | Python コード非実行の制約を崩さないか、変更スコープが妥当か |
+| ルール / ポリシー | YOK ルールの判定ロジックと既定挙動への影響 |
+| エラー処理 | Result 伝播、unwrap 回避、終了コード規約の遵守 |
+| テスト容易性 | カバレッジ維持戦略と具体的なテスト計画 |
+
+合格には 90点以上が必要。
+
+## Phase 3: 整合性チェック
+
+- プランと既存コードベースの整合（シンボル名・パス）
+- 現行設計書との突き合わせ
+- 手順の論理順序が依存関係を尊重しているか
+
+## Phase 4: 改善と確定
+
+- 検出した課題を P0 / P1 / P2 で分類しプランへ反映する
+- 採点と主要所見の検証サマリをプランに付記する
+- その後 `ExitPlanMode` を呼ぶ

chokkin-0.1.0/.codex/skills/wrapup/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: wrapup
+description: タスク完了時に simplify と update-docs を順に実行し、最後に /compact のリマインドを出す。Stop hook の block reason から起動されるか、user が「タスク完了」「/wrapup」と言ったときに発動する。
+---
+
+# wrapup
+
+chokkin の編集タスク後に手動で行っていた `/simplify` → `/update-docs` → `/compact`
+の連鎖を自動化するスキル。Stop hook (`.claude/hooks/stop-wrapup.sh`) が未実行を
+検知して `decision:"block"` で起動を促すか、user が「タスク完了」「/wrapup」と
+言ったときに発動する。
+
+## 実行手順
+
+1. **simplify** を Skill ツールで呼び出し、変更したコードを再利用性・品質・効率の
+   観点でレビュー／リファクタする。
+2. **update-docs** を Skill ツールで呼び出し、`src/` の変更を `README.md` /
+   `README.ja.md` / `docs/dev/spec.ja.md` / `CLAUDE.md` / `AGENTS.md` に同期する。
+3. ファイルを変更した場合は `make check` を実行し、fmt-check → lint (clippy + doc) →
+   test → deny → machete が通ることを確認する。
+4. **完了マーカーを必ず touch する。** Stop hook の block reason に埋め込まれた
+   絶対パス (例 `/tmp/chokkin-wrapup-<session_id>`) を `touch` する。reason から
+   取得できない場合は `/tmp/chokkin-wrapup-default` をフォールバックに使う。
+5. user に簡潔にリマインドする: 「wrapup 完了。`/compact` でコンテキストを圧縮して
+   ください。」
+
+## 注意
+
+- 手順 4 は **常に実行する**。省くと次回 Stop hook で無限ループに陥る。
+- simplify / update-docs が「変更なし」と報告しても、手順 4 と 5 は実行する。
+- git-check hook が同時に commit を要求している場合は、simplify / update-docs が
+  ドキュメントを変更しうるため、先に wrapup を終えてから commit & push する。
+- chokkin は Python コードを実行しない静的解析ツール。simplify / update-docs が
+  解析対象プロジェクトのコードを実行することは絶対にない。
+
+## ホスト別の注意 (Codex / Cursor)
+
+`.codex/skills` と `.cursor/skills` はこの `.claude/skills` への symlink。
+Codex / Cursor から本スキルを起動した場合、手順 4 のマーカーと手順 5 の
+`/compact` は Claude Code 専用なので省略し、手順 1–3（コード整理 →
+update-docs → `make check`）のコアだけを実行する。`simplify` は Claude Code の
+組込みスキルなので、Codex / Cursor では同等のコード整理を手動で行う。

chokkin-0.1.0/.cursor/environment.json

@@ -0,0 +1,3 @@
+{
+  "install": "bash scripts/bootstrap-agent.sh"
+}

chokkin-0.1.0/.cursor/hooks.json

@@ -0,0 +1,14 @@
+{
+  "hooks": {
+    "preToolUse": [
+      {
+        "command": "bash .cursor/ptuf-hook.sh",
+        "failClosed": true,
+        "matcher": "Shell|Bash|Read|ReadFile|Write|Edit|MCP|WebFetch|Fetch|mcp__.*",
+        "timeout": 10,
+        "type": "command"
+      }
+    ]
+  },
+  "version": 1
+}

chokkin-0.1.0/.cursor/ptuf-hook.sh

@@ -0,0 +1,13 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+if [ -x "${HOME}/.cargo/bin/ptuf" ]; then
+  PTUF="${HOME}/.cargo/bin/ptuf"
+elif PTUF="$(command -v ptuf 2>/dev/null)"; then
+  :
+else
+  echo "ptuf is not installed. Run 'bash scripts/bootstrap-agent.sh' to install it." >&2
+  exit 1
+fi
+
+exec "${PTUF}" hook cursor

chokkin-0.1.0/.cursor/skills/grill-me/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: grill-me
+description: プランや設計について、共通理解に達するまで user を徹底的に問い詰める。決定木の各分岐を 1 つずつ解消する。プランをストレステストしたいとき、設計をレビューさせたいとき、user が「grill me」と言ったときに発動する。
+---
+
+# grill-me
+
+このプランのあらゆる側面について、共通理解に達するまで徹底的に問い詰める。
+設計ツリーの各分岐を辿り、決定間の依存関係を 1 つずつ解消していく。各質問には
+推奨する回答を添える。
+
+質問は 1 度に 1 つずつ行う。
+
+コードベースを探索すれば答えが出る質問は、質問せずに探索で解決する。
+
+共通理解に達したら、決定とその根拠を `docs/adr/` 配下の ADR として記録する
+（ファイル名: `NNNN-<slug>.md`、連番）。`docs/adr/` が無ければ新規作成する。

chokkin-0.1.0/.cursor/skills/update-design/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: update-design
+description: docs/dev/spec.ja.md の設計書を 5 カテゴリ×20点で評価・改善し、ソースコードとの齟齬を双方向で検出する。設計レビューや実装着手前の品質確認、user が「/update-design」と言ったときに発動する。
+---
+
+# update-design
+
+chokkin（Python 向け静的到達可能性解析ツール）の設計書 `docs/dev/spec.ja.md` を
+体系的に評価・改善するスキル。4 フェーズで検証する。
+
+## Phase 1: コンテキスト収集
+
+`docs/dev/spec.ja.md`（§1–§21）と `src/` の API を対応付け、モジュール階層
+（cli/config/manifest/parser/resolver/graph/rules/reporters/fix/plugins）の
+依存関係を確認する。`Cargo.toml` の lint 設定（unsafe forbid、unwrap/expect/panic 禁止）
+も前提として押さえる。
+
+## Phase 2: 品質評価（100点満点）
+
+5 カテゴリ × 20点で採点する:
+
+| カテゴリ | 評価観点 |
+| --- | --- |
+| モジュール / struct 設計 | Rust の境界が明確か、`lib.rs` 中心の構成か |
+| 静的解析制約 | Python コードを実行しない設計が貫かれているか（import/exec/spawn 禁止） |
+| ルール / ポリシー | CHK001–CHK010 の判定ロジックと既定挙動が妥当か |
+| エラー処理 | Result/Option 伝播、unwrap 回避、終了コード規約の遵守 |
+| テスト容易性 | カバレッジ維持戦略、parser/graph のテスト設計 |
+
+## Phase 3: 整合性チェック
+
+設計書とソースコード間の齟齬を双方向で検出する:
+- シンボル名・パスが一致するか
+- 現行コードと設計記述が矛盾していないか
+- フェーズ順序（roadmap）が依存関係と整合するか
+
+## Phase 4: 改善提案
+
+- 90点以上で実装準備完了、50点未満は再設計が必要と判定する
+- 指摘を P0 / P1 / P2 の優先度で記述し、設計書へ反映する
+- 採点サマリと主要な所見を末尾に付記する

chokkin-0.1.0/.cursor/skills/update-docs/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: update-docs
+description: src/ の実装変更を README.md / README.ja.md / docs/dev/ / CLAUDE.md / AGENTS.md に同期する。コード変更後やドキュメントの陳腐化が疑われるとき、user が「/update-docs」と言ったときに発動する。
+---
+
+# update-docs
+
+chokkin の進化するソースコードと陳腐化しがちなドキュメントの差分を体系的に埋める
+スキル。5 フェーズで実施する。
+
+## Phase 1: コード監査
+
+実装の現状を把握する:
+- `src/lib.rs` の public API（モジュール階層 cli/config/manifest/parser/resolver/
+  graph/rules/reporters/fix/plugins のうち実装済みのもの）
+- `src/main.rs` の CLI 挙動（引数ディスパッチ、ExitStatus → 終了コード）
+- `Cargo.toml` / `pyproject.toml` のメタデータ（バージョン、edition、maturin bin 設定）
+
+## Phase 2: 設計ドキュメント更新
+
+`docs/dev/spec.ja.md`（§1–§21）を実装と突き合わせる:
+- API 変更を反映する
+- ステータスラベル（design phase / pre-alpha / 実装済み）を実態に合わせる
+- ルール CHK001–CHK010 と reporters（default/compact/JSON/Markdown）の記述を整合させる
+
+## Phase 3: README 更新
+
+`README.md`（英）と `README.ja.md`（日）の両方に以下が含まれるか確認・更新する:
+- プロジェクト概要 1 段落（Python 向け到達可能性解析・未使用 files/deps/symbols 検出、
+  Knip 相当）
+- インストール／ビルド手順（maturin wheel、`make` ターゲット）
+- CLI 利用例と終了コード（0 = 問題なし、非 0 = 未使用検出 / エラー）
+- `make` ターゲット一覧
+
+## Phase 4: 整合性チェック
+
+全 Markdown 間で次を揃える:
+- コマンド名・パス・クレート識別子・ルール番号・終了コード・用語
+- 言語規約: `README.md` と `CLAUDE.md` / `AGENTS.md` は英語、`README.ja.md` と
+  `docs/dev/` 配下（`spec.ja.md` 等）は日本語
+- 「Python コードを絶対に実行しない（static parse only）」の制約が崩れていないか
+
+## Phase 5: 報告
+
+構造化レポートを出す:
+- 更新したファイル一覧
+- ドキュメント化候補（実装にあるが未記載の項目）
+- 設計判断が必要な未解決の不整合