スキルの整理

.claude/agent-memory/ticket-reviewer/MEMORY.md

@@ -1,5 +0,0 @@
-- [Event broadcast pattern](project_event_broadcast_pattern.md) — Pod は event_tx: Option<broadcast::Sender<Event>> を保持、Controller が attach_notifier と同タイミングで attach
-- [Test-path omission precedent](feedback_test_path_omission.md) — 要件に挙がったテストを「共通ヘルパ経由だから省略」した場合は Approve with follow-up が相場
-- [cargo add workspace pitfall](feedback_cargo_add_workspace_pitfall.md) — ルート Cargo.toml に [workspace.dependencies] が未定義、workspace = true 指定は現状使えない
-- [Out-of-scope diff mixing](feedback_out_of_scope_mixing.md) — スコープ外修正が ticket diff に同居 → [major] Non-blocking で指摘、コミット分割推奨、総合は Approve
-- [Explicit out-of-scope violation](feedback_explicit_out_of_scope_violation.md) — 要件/範囲外に反する変更は Request changes、ticket 先更新 or 戻すの二択

.claude/agent-memory/ticket-reviewer/feedback_cargo_add_workspace_pitfall.md

@@ -1,18 +0,0 @@
----
-name: cargo add workspace pitfall
-description: ルート Cargo.toml に [workspace.dependencies] が未定義なので workspace = true は使えない
-type: feedback
----
-
-ルート `Cargo.toml` は `[workspace.package]` のみを持ち `[workspace.dependencies]` を
-定義していない。したがってチケットや PR に
-`foo = { workspace = true, features = [...] }` と書かれていても、そのままでは解決しない。
-
-**Why:** プロジェクトの現状流儀として、各クレートは直接バージョン指定する
-(例: `crates/session-store/Cargo.toml` の `uuid = { version = "1", features = [...] }`)。
-protocol-design (2026-04-21) レビュー時に発見。
-
-**How to apply:** チケットに `workspace = true` の文言を見たら、
-- 実装が直接バージョン指定にしていれば「コードベース流儀に整合」として Follow-up 扱い、
-- `workspace = true` のまま書かれていたら「ビルドが通らないはず」として Request changes、
-- もしくは `[workspace.dependencies]` を整備する方向の提案を添える。

.claude/agent-memory/ticket-reviewer/feedback_explicit_out_of_scope_violation.md

@@ -1,14 +0,0 @@
----
-name: Explicit out-of-scope violation is Request-changes
-description: Precedent — when implementation contradicts ticket's 要件 or 範囲外 sections verbatim, reviewer should Request changes even if the change seems like a quality-of-life improvement
-type: feedback
----
-
-実装が ticket の「要件」または「範囲外」に明記された指示と矛盾している場合、それが「どう見ても spirit としては改善」であっても Request changes が相場。
-
-**Why:** チケットのライフサイクルは CLAUDE.md で "b. 詳細化や前提の変化: `tickets/foo.md` を更新して commit" と定められており、仕様判断は ticket 更新で先に通すのが手順。実装から暗黙に上書きすると、後続チケットが前提にしている文面とのズレが残る。過去の「protocol-tool-result-shape」では要件に「`output` は残す」、範囲外に「`ToolOutput.content` の protocol 化は別チケット」と明記されているにもかかわらず protocol フィールドを `output: String` → `content: Option<String>` に改名する diff が出て、Blocking として指摘。
-
-**How to apply:**
-- 要件・範囲外セクションの明示的な文言に反する変更を見つけたら、たとえ技術的には合理的でも Blocking として扱う
-- 対処方針として (1) 元通りに戻す、(2) ticket を先に書き換える、の 2 択を review に書き添える
-- 「内部モデル (worker 側 struct など) と名前を揃える」系の動機は特に見落としやすい。protocol / wire 層は内部型と分離しておくのが既定、合わせるなら意思決定を ticket に上げさせる

.claude/agent-memory/ticket-reviewer/feedback_out_of_scope_mixing.md

@@ -1,17 +0,0 @@
----
-name: Out-of-scope diff mixed into ticket
-description: 本チケットのスコープ外修正が同じ diff/作業ツリーに同居していた場合のレビュー判定ルール
-type: feedback
----
-
-ticket の実装 diff にスコープ外の修正（別の疎通バグ fix、別レイヤの API 調整等）が同居している状況では、**major 扱いの Non-blocking**（= Approve 可、ただし follow-up 指摘）で扱うのが precedent。
-
-**Why:** ユーザー自身が「別コミット候補」と認識した上で差分提示してくるケースが複数回ある。コミット分割はユーザーの git 操作領域（CLAUDE.md: Git はユーザー責務）なので、reviewer 側は**コミット分割を推奨する**指摘に留める。blocker にはしない。
-
-**How to apply:**
-- review.md の Non-blocking セクションで「スコープ外 diff が同居している」項目を [major] で立て、該当ファイルと何が本筋外かを列挙する。
-- 「本チケットの review は X 単体の妥当性判定に留め、スコープ外修正の可否まで巻き込まない」ことを明記。
-- 本筋（チケット要件）が満たされていれば総合判定は Approve で良い。
-- 挙動保存の確認は本筋と同時に行うが、スコープ外変更の影響で疎通確認が混同しないか（どの変更が疎通パスした根拠か）を review.md に一言書く。
-
-precedent: `tickets/llm-capability-ownership.review.md` (2026-04-21)

.claude/agent-memory/ticket-reviewer/feedback_test_path_omission.md

@@ -1,19 +0,0 @@
----
-name: Test-path omission precedent
-description: 要件で列挙されたテストパスを「共通ヘルパなので省略」した場合の判断相場
-type: feedback
----
-
-チケット要件にテストパス (例: 成功/失敗/mid-turn の 3 本) が明示列挙されている場合、
-そのうち 1 本を「共通ヘルパ経由だから inspection で担保」として省略する実装が来たら、
-**Approve with follow-up** が相場。Blocking にはしない。
-
-**Why:** 共通化されたインスツルメント (例: `send_event`) 1 点だけが共通で、
-呼び出し側の制御フロー (async 再帰・フラグ管理・エラー伝播) は個別なのが通例。
-ただしビルドと主要パスが動いており、後続チケットでテストを足すだけの差分で済むケースが多い。
-protocol-design (2026-04-21) で先例。
-
-**How to apply:** 要件とテストコードを 1:1 で突き合わせ、欠けたパスがあれば
-- 制御フローが共通化されていれば Follow-up
-- 制御フローが別物 (別関数 / 別状態遷移) なら Request changes
-と切り分ける。`send_event` 型のヘルパ共通化は Follow-up 側の判断。

.claude/agent-memory/ticket-reviewer/project_event_broadcast_pattern.md

@@ -1,20 +0,0 @@
----
-name: Event broadcast pattern
-description: Pod が protocol::Event を broadcast する公式パターン (Notifier と別経路)
-type: project
----
-
-Pod 内部から `protocol::Event` を broadcast する正規ルートは、`Pod` に
-`event_tx: Option<broadcast::Sender<Event>>` を持たせて `attach_event_tx` で
-Controller 側から注入する方式。`Notifier` は `Event::Notification` の
-replay バッファ専用で、他イベントは通さない。
-
-**Why:** `Notifier` は Notification 型の Warn/Error レベル情報 + late subscriber への
-snapshot replay を責務にしており、Event 一般を乗せると意味が噛み合わない。
-protocol-design チケットの決定事項 6/7 で確定 (2026-04-21)。
-
-**How to apply:** 新しい Pod 発の Event を追加するときは、
-1) `Pod::send_event(&self, event)` ヘルパ (`pod.rs:370-374`) を使う、
-2) Controller は `pod.attach_notifier` の直後に `pod.attach_event_tx` を呼ぶ、
-3) late subscriber への届きは期待しない (buffer 化が必要なら別チケット化)。
-Notifier 経由で新種 Event を流す PR が来たら差し戻し対象。

.claude/skills/worktree-workflow/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: worktree-workflow
+description: "Worktreeを用いた開発フローを進める。git上の開発に置けるミクロな指示で、プロジェクトの管理に関する指示は提供されていない。"
+allowed-tools: "Bash(cd *), Bash(git worktree *), Bash(mkdir *), Bash(cp *), Bash(ln *), Bash(ls *), Bash(find *)"
+---
+
+# Worktreeを用いた開発
+
+Goal: 実装を完了させ、ブランチをマージ待ちの状態にする。
+
+`./.worktree`にworktreeを作成します。
+エージェントの1セッション=1ワークツリーとしており、ブランチ/イシュー/チケット単位で切ります。
+
+このワークフローにおいては、ブランチはローカルで並行開発するためのマージ後削除の運用とし、Worktreeと同名のbranchを同時に作って進めます。メインのディレクトリのブランチから切るものとして扱います。
+
+```
+git worktree add .worktree/<task-name> -n <task-name>
+```
+
+## flake.nixの無効化
+
+基本的に、CWDを変更できない場合、.envrcによる自動アクティベートは効かないので無視で構わない。