@shinaps/skills 0.23.0 → 0.24.0

package/plugins/shinaps-codex/skills/refine/SKILL.md

@@ -7,7 +7,7 @@ description: 対象ファイルとShinaps AIのルールを照合し、違反・
 
 指定されたパス・PR・コミット範囲から対象を決める。作業中の変更ならstaged、unstaged、関連するuntrackedを含める。適用されるプロジェクトの指示を読み、利用可能なShinaps MCPのルール検索で対象に合うルールを取得する。MCPが使えない場合は照合を実施できないと報告し、推測でルールを作らない。アカウント作成・接続は利用者の標準認証フローを案内する。
 
-対象ファイルの現状全文を読み、ルールごとに適用条件と実際のコードを比較する。指摘には根拠となるルール、該当箇所、影響と修正案を付ける。違反・改善・仕様判断を区別し、今回の変更と元からある問題を分ける。
+対象ファイルの現状全文を読み、ルールごとに適用条件と実際のコードを比較する。指摘には根拠となるルール、該当箇所、影響と修正案を付ける。違反・改善・仕様判断を区別し、今回の変更と元からある問題を分ける。テストに関わる指摘と修正の判断は [テスト方針](../../references/testing.md) に従う。
 
 委託を許可されている場合は登録済みのshinaps-refine-agentへ重ならない範囲とルール全文を渡せる。結果は現在のコードで検証し重複をまとめる。独立検証をしなければそのように報告する。
 

package/plugins/shinaps-codex/skills/review/SKILL.md

@@ -15,6 +15,6 @@ Shinaps AIのルール検索が利用できる場合は関連するルールを
 
 返された指摘を実コードと照合してから、挙動への影響や根拠のある保守上の負担を優先度順に報告する。対象箇所、発生条件、影響、最小の修正案を含める。推測と確認済みの事実、実施した検証と未実施を区別する。指摘を埋めるための好みの変更は加えない。
 
-可読性は、対象言語の基礎を知るジュニアが初めて読んでも目的・流れ・判断理由を追えるかで判断する。推測する意味、同時に覚える状態、理解のための往復を減らし、短さや分割数、特定構文を目標にしない。正しさ・型の保証・既存の性能とプロジェクト規約を維持する。指摘には読み手の具体的な負担と軽減する修正案を示し、ほぼ同等の表現や好みだけの差は修正要求にしない。性能への影響が不明なら必要な検証を示す。委託する場合もこの判断軸を渡す。
+可読性は、対象言語の基礎を知るジュニアが初めて読んでも目的・流れ・判断理由を追えるかで判断する。推測する意味、同時に覚える状態、理解のための往復を減らし、短さや分割数、特定構文を目標にしない。正しさ・型の保証・既存の性能とプロジェクト規約を維持する。指摘には読み手の具体的な負担と軽減する修正案を示し、ほぼ同等の表現や好みだけの差は修正要求にしない。性能への影響が不明なら必要な検証を示す。委託する場合もこの判断軸を渡す。テストに関わる指摘は [テスト方針](../../references/testing.md) に従う。
 
 修正・コミット・PR投稿はユーザーに依頼された範囲だけ行う。記録が必要ならプロジェクトの.shinaps/work/に保存し、.shinaps/.gitignoreに必要な除外を追加する。既存内容と追跡済みファイルは保持する。

package/plugins/shinaps-codex/skills/simplify/SKILL.md

@@ -25,4 +25,4 @@ description: 実装・設計・手順を目的と必要条件から見直し、
 - 変更の影響に合う検証を行う。問題がなければ変更を作らず終了する。
 - 削ったもの、判断理由、確認結果を短く報告する。コミットや公開はこの工程の許可に含めない。
 
-- テストの簡素化でも、不具合の再発防止と合意された仕様・外部契約の保証を維持する。過去のバグに由来しないという理由だけで仕様テストを削除せず、統合・削除する場合は保証が残る根拠を示す。
+- テストの判断は [テスト方針](../../references/testing.md) に従う。

package/plugins/shinaps-codex/skills/spec/SKILL.md

@@ -13,4 +13,4 @@ description: 曖昧な要望を対話と既存実装・実現可能性の調査
 
 利用可能なShinapsルールを制約の根拠に含める。利用できないときはルール照合を未確認とし、実現可能性や仕様確定に残る影響を明記する。
 
-合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装依頼があれば$shinaps:devへこの記録を渡す。仕様作成だけの依頼で自動実装しない。
+合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装依頼があれば$shinaps:dev-codex-ultraへこの記録を渡す。1体での実行を指定された場合は$shinaps:dev-codexを使う。仕様作成だけの依頼で自動実装しない。

package/plugins/shinaps-claude/references/dev-comparison/comparison.md

@@ -1,123 +0,0 @@
-# 比較手順
-
-## 1. 目的と範囲
-
-[工程](workflow.md)を揃えたうえで、モデル・同じ役割の担当数・実行環境の差を比べる。採用する構成の決定と、既存 `dev` の切り替えはこの手順に含まない。
-
-P1 は eafbbc5 の Claude 版 `dev` の割当を再現するが、比較専用の担当指示を使い、review / refine / simplify スキルを経由しないので、現行 `dev` の実行結果そのものではない。
-
-Codex の担当の起動手段と担当指示の渡し方は、親で決まる（[構成表](configurations.md#環境の条件)）。P4〜P7 では、比較専用の役割を指定した Codex のサブエージェントの使い勝手も、結果に含めて比べる。
-
-## 2. 条件ファイルの事前固定
-
-最初の実行の前に、比較セットのディレクトリへ `conditions.md` を保存し、ハッシュを記録する。以後は変更しない。
-
-- 比較セットのディレクトリは、どの構成の作業環境にも含まれない場所に実施者が決める（例: 比較を管理するリポジトリの `.shinaps/work/comparisons/{ts}-{slug}/`）。回収先の `runs/<構成>/` も同じディレクトリに置く。
-- 入口には条件ファイルを絶対パスで渡す。
-
-`conditions.md` の様式:
-
-```markdown
-# 比較条件: <比較セット ID>
-
-## 課題
-- 課題ファイル: <パス>（要件・受入条件を含む）、sha256: <ハッシュ>
-- 課題側のリポジトリと開始コミット: <リポジトリ> @ <コミット>
-- 比較スキルの version: <plugin version>
-
-## 規約スナップショット
-- search_rules の結果: <ファイルのパス>、sha256: <ハッシュ>
-- 適用する AGENTS.md / CLAUDE.md: <ファイルのパス>、sha256: <ハッシュ>（ファイルごと）
-- 利用者のグローバル指示（Claude: `$CLAUDE_CONFIG_DIR/CLAUDE.md`、Codex: `$CODEX_HOME/AGENTS.md`。CLI が親・子へ自動で読み込む）: <ファイルのパス>、sha256: <ハッシュ>（無ければ「なし」）。両環境で内容が違う場合はその違いを書く
-
-## 依存関係・データ
-- <依存関係の導入状態、使うデータとその取得方法>
-
-## 探索条件
-- 探索担当数: <数>
-- 範囲分割: <なし／分割する範囲>
-- 既存調査の再利用: <可／不可。可ならその成果物のパス>
-
-## 事前の合格条件
-- 受入条件: <課題ファイルの節、または全文>
-- 必須の検証コマンド: <コマンド>
-- 評価項目と基準: <項目ごとの基準>
-
-## 許可範囲
-- <変更してよい範囲、外部への書き込みの可否、コミットしないこと>
-
-## 実行権限
-- Claude: <実施者が既に許可した permission mode>
-- Codex: <実施者が既に許可した sandbox と承認>
-- 権限機構の違い: Claude の担当と Codex のサブエージェントは親の権限で動き、`codex exec` の担当は担当ごとに sandbox を持つ。<この違いで変わる点>
-- 必須の検証コマンドをこの権限の範囲で両環境で実行できるかの確認結果: <日時、コマンド、結果>
-
-## 終了条件
-- <工程の終了条件に加える条件があれば記載>
-
-## 実行する構成と順序
-- <例: P1 → P3 → P5>
-
-## 各構成の親の起動方法
-| 構成 | 起動方法（構成表の写しに実行権限を入れたもの。Codex アプリの親は設定の手順） |
-|---|---|
-| P1 | <コマンド> |
-```
-
-必須の検証を実行できない環境があれば、権限を広げずにその旨を記録し、比較を行うかを実施者が判断する。
-
-## 3. 独立した作業環境
-
-- 構成ごとに、開始コミットから作った別の作業環境（worktree またはクローン。対象リポジトリの方針に従い、worktree を作らない環境ではクローンを使う）と別ブランチ、新しい親セッションを使う。
-- 作業環境は実施者が事前の許可のもとで作る。入口は作らない。
-- 同じ担当の再開だけが同じ作業環境を使う。
-- 他の構成のコード・計画・レビュー・会話を渡さない。
-- 構成間は直列に実行する。
-- 作業環境のディレクトリ名は、英数字以外の文字だけが異なる名前にしない（[実行記録](record.md)の親の特定に使うため）。
-
-## 4. 自動メモリ
-
-比較セットの開始前に、`$CLAUDE_CONFIG_DIR`（未指定なら `~/.claude`）の `projects/` 配下の、課題リポジトリに対応する memory ディレクトリと、`$CODEX_HOME`（未指定なら `~/.codex`）直下の `memories` で始まるエントリすべて（ディレクトリと sqlite ファイル）の内容のハッシュを記録する。各実行の後に再計算し、変化があれば `run-record.md` と比較記録に書き、次の実行の前に実施者が扱いを判断する。メモリ機能の設定は変更しない。
-
-## 5. 実行
-
-条件ファイルの起動方法で親セッションを開始し、入口に担当数と条件ファイルの絶対パスを渡す。人の介入は全件を `run-record.md` に記録する。
-
-Claude の入口（`dev-mixed`・`dev-claude`）は、利用者が委託した依頼元（Codex など）が AI Terminal Bridge で親セッションへ依頼して起動することもできる。
-
-- 依頼先は、その構成の作業環境を cwd とし、条件ファイルの起動コマンドで開始して、AI Terminal Bridge でメッセージを受け取れ（WebStorm のターミナルで起動したもの）、まだ他の依頼を受けていないセッションにする。[実行記録](record.md)は、その cwd の記録が 1 件だけであることで親を特定する。
-- 依頼に書くのは、入口・担当数・条件ファイルの絶対パス・返信先だけにする（例: 「`/shinaps:dev-claude 2体 <条件ファイルの絶対パス>` を Skill ツールで起動する。返信先: <依頼元の session_id>」）。比較の条件は条件ファイルに書き、依頼に追加の指示を書かない。スラッシュコマンドで起動した実行と、親が受け取る情報を同じにするためである。
-- 親は、実行中の質問をそのセッションの入力手段で行い、工程を終えたとき、または止まったときの報告だけを依頼元へ返す。依頼元は、実行中の質問に答えない。人の回答は、人の介入として記録する。
-
-## 6. 回収
-
-各実行の後、次のものを比較セットの `runs/<構成>/` に保存する。回収のためにステージ・コミットはしない。
-
-- `run-record.md`
-- 追跡ファイルの差分（`git diff <開始コミット>`）
-- 未追跡ファイル（`git ls-files --others --exclude-standard`。`.shinaps/` と秘密情報を除く）の一覧と内容
-- 検証結果とレポート
-
-## 7. 匿名化評価
-
-全実行の後、成果物とレポートから構成名・モデル名・識別できるパスを伏せて無作為な記号を付ける。対応表は実施者だけが別ファイルで持つ。評価者（人、またはどの実行にも関わっていない新しいセッション）が事前の合格条件で評価し、結果を確定してから対応表を開く。
-
-## 8. 比較記録
-
-構成ごとに次を表にする。
-
-- 合格条件の結果
-- 時間（同時実行の上限で後から起動した担当があれば、その起動待ちの合計を併記する）
-- 使用量（実測／推定／取得不可）
-- 修正回数
-- 人の介入
-- 設定の判定
-- 割当外の依頼の確認結果
-- 自動メモリの差分
-- 2体目の発見の分類
-
-判定が「観測できる設定は一致（指定のみの項目あり）」だけの実行以外は、比較データとして扱わず、その判定を書く。指定のみの項目（[構成表](configurations.md#観測手段の無い項目)）は全構成について併記する。tier の実際の利用を確認できない構成の速度差は、tier まで揃えた結果とは書かない。P4〜P7 では、[環境の条件](configurations.md#環境の条件)（親から引き継ぐ項目、同時実行の枠の数）も併記する。
-
-## 9. SHINAPS-98 の初回
-
-P1 → P3 → P5 を直列に実行し、結果の検討で止まる。P2・P4・P6・P7 は候補として記載し、自動では実行しない。

package/plugins/shinaps-claude/references/dev-comparison/configurations.md

@@ -1,74 +0,0 @@
-# 構成表と担当割当
-
-比較の構成（P1〜P7）ごとに、親の起動方法、各担当のモデルと起動手段を決める。工程・役割・担当指示・成果物・終了条件は全構成で同じで、[工程](workflow.md)に従う。担当の起動方法は[起動手順](launch.md)に従う。
-
-この表が既定の指定値である。比較条件ファイルには、比較セットで使う構成の行をこの表の写しとして書き、実行権限を加える。比較の目的で値（親のモデルなど）を変える場合は、変えた項目と理由を条件ファイルに書く。照合と記録は、条件ファイルの値で行う。
-
-## 全構成で共通の指定
-
-- 推論は medium。
-- Fast なし。Claude は standard（Fast を有効にしない）、Codex は `service_tier="default"` を指定する。Fast の有無はモデルと別の比較条件で、P1〜P7 はすべて Fast なしに固定する。
-- `gpt-6.1-sol` の既定の推論は low で、利用者のグローバル設定の service_tier が priority の場合がある。このため、推論は親・子とも起動のたびに明示し、tier は指定できる手段（Claude の親の起動コマンド、Codex アプリの親の設定、`codex exec`）で毎回明示する。
-- 実行権限はこの表で固定しない。比較条件ファイルに記録した「実施者が既に許可した実行権限」（例: Claude の `--permission-mode <mode>`、Codex の `--sandbox <mode> --ask-for-approval <policy>`）を親の起動方法（Claude の親は起動コマンド、Codex アプリの親は設定）に明示する。
-
-## 観測手段の無い項目
-
-次の項目は、各 CLI のローカル記録に実際の値が残らないため、指定値だけを記録する（実行記録の「指定のみ」）。どの構成でも同じ扱いで、比較記録に必ず併記する。
-
-- Codex の service_tier（親・子）
-- Claude の permission mode（親。子は親の権限で動く）
-
-これ以外の指定（モデル・推論、Claude の service_tier、Codex の sandbox・承認）は観測値と照合する。
-
-## 環境の条件
-
-Codex の親（P4〜P7）のサブエージェントは、次の条件で動く。ほかの構成とは揃えられないので、実行記録と比較記録に書き、確認できなかった値を確認済みとしない。
-
-- 子ごとに sandbox・承認を指定できず、親の値を引き継ぐ（役割定義にも書けない）。子の観測値（rollout の `turn_context`）は、親の指定値と照合する。
-- 親を含む同時実行の上限がある。実行記録には、Phase 1 で読んだ枠の数と、上限のために後から起動した担当の起動待ちの時間を書く。
-- tier は担当ごとには指定できず、親の設定を引き継ぐ（公式資料の記述）。記録に残らないので、上の「観測手段の無い項目」の Codex の service_tier として、親の指定値を「指定のみ」で書く。
-- 担当指示は、比較専用の役割定義（`shinaps-comparison-<役割>`。`roles/*.md` から生成した developer の指示）で渡す。P1〜P3 は、同じ担当指示を依頼の本文で渡す。渡し方の違いは構成差として比較記録に書く。
-
-## 構成
-
-| 構成 | 入口・担当数 | 親（新しいセッションの起動方法） | 子の基本モデル | 担当2 |
-|---|---|---|---|---|
-| P1 混成 | `dev-mixed`（2体固定） | `claude --model opus --effort medium <条件ファイルの Claude 実行権限>` | Opus | Codex `gpt-6-astra` |
-| P2 | `dev-claude 1体` | 同上 | Opus | なし |
-| P3 | `dev-claude 2体` | 同上 | Opus | Opus（別コンテキスト） |
-| P4 | `dev-codex-astra 1体` | Codex アプリの新しいチャット（モデル `gpt-6-astra`、推論 medium、Fast なし、<条件ファイルの Codex 実行権限> をアプリの設定で指定し、設定の手順を条件ファイルに書く） | `gpt-6-astra` | なし |
-| P5 | `dev-codex-astra 2体` | 同上 | `gpt-6-astra` | `gpt-6-astra`（別スレッド） |
-| P6 | `dev-codex-sol 1体` | Codex アプリの新しいチャット（モデル `gpt-6.1-sol`、推論 medium、Fast なし、<条件ファイルの Codex 実行権限> をアプリの設定で指定し、設定の手順を条件ファイルに書く） | `gpt-6.1-sol` | なし |
-| P7 | `dev-codex-sol 2体` | 同上 | `gpt-6.1-sol` | `gpt-6.1-sol`（別スレッド） |
-
-## 担当割当
-
-O = Opus、A = `gpt-6-astra`、S = `gpt-6.1-sol`。起動手段は親で決まる。Claude の親（P1〜P3）の O は Claude Agent、A は `codex exec`。Codex の親（P4〜P7）の A・S は、比較専用の役割を指定した Codex のサブエージェント。担当数と継続／新規の規則は[工程](workflow.md#2-役割と継続の規則)の役割表に従う。「—/O」は 1体の設定ではなし、2体の設定では O を表す。
-
-| Phase | 役割 | P1 | P2/P3 | P4/P5 | P6/P7 |
-|---|---|---|---|---|---|
-| 2 | 探索 | O | O | A | S |
-| 3 | 設計担当1（設計統合・プラン統合・設計適合性・指摘統合） | O | O | A | S |
-| 3 | 設計担当2 | A | —/O | —/A | —/S |
-| 4 | 計画レビュー担当1 | O | O | A | S |
-| 4 | 計画レビュー担当2 | A | —/O | —/A | —/S |
-| 4 | 計画簡素化担当1 | O | O | A | S |
-| 4 | 計画簡素化担当2 | A | —/O | —/A | —/S |
-| 4, 6 | 指摘検証（verifier） | O | O | A | S |
-| 5, 7 | 実装 | O | O | A | S |
-| 6 | 設計適合性 | O | O | A | S |
-| 6 | 独立コードレビュー | A | O | A | S |
-| 6 | refine | O | O | A | S |
-| 6 | 実装の簡素化 | A | O | A | S |
-
-- P1 は eafbbc5 の Claude 版 `dev` の割当を再現し、担当1 を Opus、担当2 を Codex とする。ただし比較専用の担当指示を使い、review / refine / simplify スキルを経由しないので、現行 `dev` の実行結果そのものではない。
-- 担当番号は起動前に固定する。
-- P1 の A（`codex exec`）の sandbox は `read-only` にする。P4〜P7 の担当は、親の sandbox を引き継ぐ（上の「環境の条件」）。実装担当が使えるのは、条件ファイルに書いた親の権限の範囲である。
-- Claude の担当と Codex のサブエージェントは、親の権限で動く。`codex exec` の担当は、担当ごとに sandbox を持つ。この権限機構の差は同一とみなさず、条件ファイルと比較記録に書く。
-- P4〜P7 の担当は、すべて Codex のサブエージェントで起動する。P1 の Codex の担当（`codex exec`）とは、起動手段が違う。
-
-## 比較の組み合わせ
-
-- 担当数の比較: P2/P3、P4/P5、P6/P7（同じモデル・同じ条件）。
-- モデルの比較: P2/P4/P6 または P3/P5/P7（同じ担当数・同じ条件）。
-- P1 は混成の割当を含む構成全体として評価する。

package/plugins/shinaps-claude/references/dev-comparison/launch.md

@@ -1,47 +0,0 @@
-# 担当の起動手順
-
-[構成表](configurations.md)の担当割当と起動手段に従う。Claude の親（P1〜P3）は、O の担当を Claude Agent で、A の担当を `codex exec` で起動する。Codex の親（P4〜P7）は、A・S の担当を、比較専用の役割を指定した Codex のサブエージェントで起動する。
-
-担当指示（`roles/<役割>.md`）は、Claude Agent と `codex exec` では依頼の本文に全文を入れて渡す。Codex のサブエージェントでは、担当指示から生成した比較専用の役割定義（`shinaps-comparison-<役割>`）で渡すので、依頼の本文には入れない。どの起動手段でも、今回の入力を依頼の本文で渡す。今回の入力は、役割名・担当番号・ラウンド・今回の割当と担当数、工程が定める渡す情報である。読む資料はパスで指定し、作業記録にある他の担当の成果物は、工程が渡すと定めたもの以外を読ませない。担当には、他のエージェントを起動しないこと、実装担当以外はファイルを変更しないことを伝える。起動・再開・交代の履歴、ID、指定値、開始・終了時刻は、[実行記録](record.md)の担当表へ書く。
-
-## Claude Agent
-
-- Agent ツールで `subagent_type: "general-purpose"`、`model: "opus"`、`effort: "medium"` を毎回明示して起動する。Shinaps の登録エージェント（`shinaps:shinaps-*`）は使わない。
-- プロンプトには担当指示の全文と今回の入力を含める。
-- 並行して動かす担当はバックグラウンドで起動し、全担当の完了を待つ。
-- 同じ役割の継続は、同じ ID へ SendMessage で再開する。ID は担当表に記録する。
-- Agent の `model`・`effort` を指定できない環境では起動せず、その制約を報告する。Fable や他のモデルへ切り替えない。
-- Claude の担当は sandbox を個別に持たず、親の実行権限で動く。
-
-## codex exec
-
-Claude の親（P1）が Codex の担当を起動するときに使う。
-
-```sh
-codex exec --sandbox <構成表の sandbox> -c approval_policy='"never"' \
-  -m <model> -c model_reasoning_effort='"medium"' -c service_tier='"default"' \
-  --json -o <report> - < <prompt> > <events>
-```
-
-- cwd は実行の作業環境（worktree またはクローン）のルートにする。
-- sandbox は構成表に従う。許可の範囲を超える sandbox を指定しない。
-- 再開は `codex exec <同じフラグ> resume <thread_id> --json -o <report> - < <prompt> > <events>` で行う。起動時と同じモデル・推論・tier・sandbox を毎回明示する。同時に動いている別の担当を再開しないよう、`--last` は使わない。
-- プロンプトは `raw/cli/` にファイルとして保存して標準入力で渡し、担当指示の全文と今回の入力を含める。本文をシェルのコマンド文字列へ展開しない。プロンプト・レポート・イベントログのパスは役割・担当番号・ラウンド・バッチごとに分ける。
-- `thread.started` の `thread_id` を担当表に記録する。完了はプロセスの終了コード、`turn.completed`、空でない最終レポートの 3 つで判定し、`error` / `turn.failed` は未完了とする。担当の応答が完成したらプロセスは終了してよい。継続に使うのは thread_id と文脈である。
-- 失敗時は他のモデル・Fable・個人用 alias へ切り替えない。部分出力を保存し、再試行は別のファイル名で行って前回を残す。ユーザーのグローバル設定を変更しない。起動の失敗を理由に権限を広げない。許可された権限で `codex exec` を実行できない場合は、担当を親自身で代行せず、制約を報告して止まる。
-
-## Codex のサブエージェント
-
-Codex の親（P4〜P7）が使う。`codex exec` は使わない。
-
-- 起動は `spawn_agent` で行い、毎回 `agent_type: "shinaps-comparison-<役割>"`、`fork_turns: "none"`、`model: <構成表のモデル>`、`reasoning_effort: "medium"` を明示する。役割は `roles/` のファイル名（`architect`、`explorer`、`implementer`、`plan-reviewer`、`refine-agent`、`review-verifier`、`reviewer`、`simplifier`）である。設計担当1・2 は `architect`、計画・実装の簡素化は `simplifier` を使う。
-- 比較専用の役割定義には model・推論を書かない。モデルと推論は、この指定で構成ごとに選ぶ。`fork_turns` を省略すると、親の履歴・モデル・推論を引き継いで上書きできず、独立した担当にもならない。
-- 比較専用の役割以外の `agent_type`（通常の dev の `shinaps-architect` などを含む）は使わない。
-- 実行で最初に起動した担当の完了後に、その子の rollout の `turn_context` のモデル・推論を指定と照合する。違えば不一致として記録し、報告して実行を止める（以後の担当も同じ仕組みで起動するので、照合は最初の 1 体で足りる。その実行は比較データにならないため、続けない。全担当の照合は Phase 9 の[実行記録](record.md)の手順で行う）。
-- `task_name` は、実行の中で重複しない名前にする。起動時に一度だけ決め、継続（`followup_task`）では変えない。一意にするため、`p<起動した Phase>_<役割>_<担当番号>_r<ラウンド>` の形で作る。役割の `-` は `_` に置き換え、使う文字は英小文字・数字・`_` だけにする（例: `p4_plan_reviewer_2_r1`、`p6_review_verifier_1_r2`）。交代した担当は、末尾に `_s<交代の回数>` を付ける。担当表には、`agent_type`・`task_name`・返された ID を記録する。
-- 渡した `message` の全文を `raw/agents/<task_name>-<n>.md`（n は、その担当への依頼の通し番号。起動が 1、継続ごとに 1 増える）に保存する。rollout には、`message` が暗号化されて残るためである。
-- サブエージェントは、親と同じ作業ディレクトリで動き、sandbox・承認・tier を親から引き継ぐ（[構成表](configurations.md#環境の条件)）。読み取り専用の役割は、担当への指示で変更を禁止する。変更が無いことは、[工程](workflow.md)の作業ツリーの確認で確かめる。
-- 同じ役割の継続には、同じ ID へ `followup_task` で依頼する。`send_message` は担当のターンを開始しないので、継続には使わない。工程に、実行中の担当へ補足を送る場面は無い。
-- 完了は `wait_agent` で待つ。待つ時間は分単位にし、短い間隔で繰り返さない。完了は、担当の完了通知と、空でない最終回答で判定する。`wait_agent` の時間切れや、`followup_task` の受領だけでは完了としない。
-- 同時実行の上限: Phase 1 で、親のセッションの開発者メッセージが示す枠の数（親を含む）を実行記録に書く。同時に実行中にする担当は、枠から 1 を引いた数までにする。工程が並行起動を求める担当がそれを超えるときは、役割表の順に枠の分だけ起動し、残りは実行中の担当が完了してから起動する（渡す情報と独立性は[工程](workflow.md)の規則のまま）。起動を待った担当は、待ち始めと起動の時刻を担当表に書く。
-- 起動できない（実行中の担当が無いのに枠の不足で失敗する場合を含む）、または完了しない担当は、[工程](workflow.md)の「実行の制約」のとおり、その担当を未完了として記録し、工程の終了条件に従う。`codex exec`・ほかのモデル・モデルごとの役割定義へ切り替えず、親が代わりに作業せず、ユーザーのグローバル設定（同時実行の上限を含む）を変更しない。

package/plugins/shinaps-claude/references/dev-comparison/record.md

@@ -1,79 +0,0 @@
-# 実行記録
-
-比較実行ごとに作業ディレクトリへ `run-record.md` を作り、この様式で記録する。
-
-## 原則
-
-- 指定値は比較条件ファイル（[構成表](configurations.md)の写し）と起動時の引数から、観測値はローカルの記録から読む。
-- 読めない項目は「未検証」と書き、推定で埋めない。モデル自身の自己申告は観測値にしない。
-- 観測値の読み取りは工程の実行に必須ではない。読めなくても工程は進め、その項目を未検証とする。
-- 比較データとして使うのは、判定（下記）が「観測できる設定は一致（指定のみの項目あり）」だけの実行である。観測手段の無い項目（[構成表](configurations.md#観測手段の無い項目)）は「指定のみ」と書き、確認済みとはしない。
-- 記録から抜き出すのはモデル・推論・tier・sandbox・承認・トークン数・呼び出しの種類だけにし、秘密情報を記録しない。
-
-## 開始前の照合
-
-Phase 1 で親の観測値（Claude: 自セッションの transcript、Codex: 自スレッドの rollout の `turn_context`）が読めれば、指定値と照合する。照合する項目は、Claude はモデル・推論・service_tier、Codex はモデル・推論・sandbox・承認である。不一致なら開始せず、構成表の起動方法で新しいセッションを開始し直すよう報告する。読めなければその項目を未検証として進める。観測手段の無い項目は照合せず、指定値を記録する。
-
-## 親の特定
-
-構成ごとに新しい作業環境（別の cwd）と新しいセッションで始めるので、Phase 1 の時点でその cwd の記録は親の 1 件だけになる。親はこの一つの方法で特定する。
-
-- Claude: `$CLAUDE_CONFIG_DIR`（未指定なら `~/.claude`）の `projects/` 配下で、cwd の実パス（realpath）の英数字以外の文字を `-` に置き換えた名前（`.` も `-` になる）のディレクトリにある transcript（`<session-id>.jsonl`）。
-- Codex: `$CODEX_HOME`（未指定なら `~/.codex`）の `sessions/` 配下の rollout のうち、最初の行の `session_meta` の `cwd` が作業環境の実パスと一致するもの。state DB は使わない。`session_meta` から読むのは `cwd` と ID だけにする。
-- 1 件に決まらなければ未検証とする。親の ID は Phase 1 で記録する。Phase 9 では子の記録も同じ cwd を持つので、親は Phase 1 で記録した ID で区別する。
-- 作業環境のディレクトリ名は、英数字以外の文字だけが異なる名前にしない（Claude のディレクトリ名が同じになるため）。
-
-## run-record.md の様式
-
-- **実行の識別**: 構成、入口、担当数、比較セット ID、条件ファイルのハッシュ（条件ファイルが課題ファイル・規約スナップショットのハッシュを列挙する）、比較スキルの plugin version と `references/dev-comparison/` のツリーハッシュ（使った plugin の `references/dev-comparison` を cwd にして `find . -type f | LC_ALL=C sort | xargs shasum -a 256 | shasum -a 256` の出力）、課題側の開始コミット、開始・終了時刻。Codex の親では、Phase 1 で読んだ同時実行の枠の数と、配置済みの比較専用の役割定義のハッシュ（`$CODEX_HOME/agents` を cwd にした `ls shinaps-comparison-*.toml | LC_ALL=C sort | xargs shasum -a 256 | shasum -a 256` の出力）。
-- **担当表**（1 担当 1 行）: 役割、担当番号、ラウンド、実行手段、ID（親セッション ID / Claude agent ID / Codex thread_id / サブエージェントの task_name・返された ID と、rollout の thread_id）、起動・再開・交代の履歴、指定（モデル・推論・tier・Fast・sandbox）、観測（同じ項目、根拠ファイルと時点）、判定（一致／不一致／未検証／指定のみ）、開始・終了時刻、終了状態、起動待ち（同時実行の上限で後から起動した担当の、待ち始めと起動の時刻）、使用量（実測／推定／取得不可と出典）。
-- **時間**: 総経過時間と Phase ごとの開始・終了。時刻はメインが `date -u +%FT%TZ` で記録する。並行か順次かは担当表の時刻から導く。
-- **修正**: Phase 7 の修正回数、実装後レビューのラウンド数、計画の修正版数。検証の回数は担当表の verifier の行から数える。
-- **人の介入・中断**: 時刻、内容（質問・回答・承認・手作業・環境の復旧）、理由、所要時間。全件を記録する。
-- **割当外の依頼の確認結果**。
-- **自動メモリの差分**（[比較手順](comparison.md)の手順の結果）。
-- **2体目の発見の分類**（下記）。
-- **判定**: 次の区分のうち当たるものをすべて書く。比較データとして使えるのは、1 つ目だけが当たる実行である。
-  - 観測できる設定は一致（指定のみの項目あり）: 観測手段がある項目がすべて一致し、ほかの区分に当たらない。指定のみの項目を併記する。
-  - 観測できる設定に未検証あり: 観測手段がある項目に、読めなかったものがある。
-  - 不一致: 観測値が指定値と違う項目がある。
-  - 割当外の依頼あり: 担当表に無い AI への依頼がある（下記「割当外の依頼の確認」）。
-  - 未完了: 未完了の担当がある。
-  - 制約違反あり: 実装担当の実行区間の外で、作業ツリー（未追跡ファイルを含む）が変わった（[工程](workflow.md)の作業ツリーの確認）。変化したパスを併記する。
-
-## 観測値の読み方
-
-Phase 9、または読める時点で行う。抽出結果は `raw/settings/` に保存する。
-
-- **Claude（親・子）**: `$CLAUDE_CONFIG_DIR`（未指定なら `~/.claude`）の `projects/` 配下にある親の transcript と `<session-id>/subagents/agent-<id>.jsonl`・`.meta.json` の全 assistant メッセージから、`message.model`・各行の `effort`・`message.usage.service_tier` の組の一覧を抽出し、全期間で変化がないことを確認する。子は Agent が返した ID と対応付ける。
-- **Codex（親・子）**: rollout の全ターンの `turn_context`（`model`・`effort`・`sandbox_policy`・`approval_policy`）を読む。
-  - 親の rollout は、「親の特定」で決めたもの。
-  - `codex exec` の担当の rollout は、`$CODEX_HOME/sessions/` 配下で、ファイル名に担当表の thread_id を含むもの。
-  - サブエージェントの rollout は、最初の行の `session_meta.source.subagent.thread_spawn` で、`parent_thread_id` が親の ID、`agent_path` が担当表の `task_name` に対応し、`agent_role` が担当表の `agent_type` と一致するもの。この rollout の ID を担当表の thread_id に書く。1 件に決まらなければ未検証とする。サブエージェントの sandbox・承認の指定値は、親の値とする。
-  - rollout が無ければ未検証とする。service_tier は指定のみとする。サブエージェントの service_tier の指定値は、親の指定値とする（モデル・推論の指定値は、起動時に指定した値である）。
-- rollout は後で削除されることがあるので、各担当の完了後に読む。
-
-## 使用量
-
-- **Claude**: 同じ `message.id` の行は一度だけ数える（同じ応答が transcript に複数行で記録されるため）。担当ごとの合計と総計で重ねて数えない。
-- **Codex（親・子）**: スレッドの rollout の最後の `token_count` の `info.total_token_usage`（スレッドの累計値。cached・reasoning の内訳を含む）をスレッドごとに一度だけ使い、スレッド間で合計する。resume の `turn.completed.usage` も累計値なので、イベントログの値を合計しない。イベントログは完了判定と thread_id の取得に使う。サブエージェントは、スレッドごとの値を書く。親の累計に子の使用量が含まれないことを確かめた場合だけ、確かめた方法と根拠を併記して合計を書く。確かめられなければ、総計は未確定とする。
-- 金額は取得できないので「取得不可」と書く。料金表からの換算は推定欄に根拠付きで書き、実測と合計しない。
-
-## 割当外の依頼の確認
-
-構成表に無い AI への依頼が無いことを、次の一つの手順で確認する。
-
-1. その実行の cwd の記録をすべて列挙する（Claude の project ディレクトリの transcript、`$CODEX_HOME/sessions/` 配下で `session_meta` の `cwd` が一致する rollout）。
-2. 親・子の記録から、AI への依頼に当たる呼び出しを列挙する（Claude: Agent・Skill・MCP の tool_use と Bash コマンド、Codex: rollout の function call（`spawn_agent`・`followup_task` を含む）・シェルコマンド）。呼び出しの単位（tool_use 1 件、function call 1 件）で、その呼び出しが AI を起動したかを判定する。コマンドやプロンプトの本文に文字列が含まれるだけのものは数えない。子の記録にある `spawn_agent`、`thread_spawn.depth` が 2 以上の rollout、Codex の親による `codex exec` の実行は、担当表に無い依頼として数える。
-3. 1 と 2 を担当表と突き合わせる。担当表に無い依頼があれば記録し、判定に「割当外の依頼あり」を書く。AI Terminal Bridge で起動を依頼された実行の、依頼の受信（`read_messages`・`ack_messages`）と依頼元への終了・停止の報告（`send_message`）は、割当外の依頼に数えない。
-
-## 2体目の発見の分類
-
-- 対象は 2体の設定の担当2（設計・計画レビュー・計画簡素化）。担当番号は起動前に固定したものを使う。
-- verifier の出典 ID と分類、設計担当1 の採否、実際の修正から決める。
-  - **有効な追加発見**: 担当2 の出典で、verifier が根拠ありとし、担当1 の指摘と同じ項目にまとめられておらず、採用されて計画または修正に反映されたもの。設計では統合計画に採用された担当2 固有の判断。
-  - **重複**: verifier が担当1 の指摘と同じ原因・影響・修正方針の項目にまとめたもの（同じ場所でも原因・影響・修正が違えば重複にしない）。
-  - **誤検出**: verifier が誤認としたもの。
-  - **未確定**: 判断が対立した、検証できなかった、または根拠ありで不採用のもの（理由を残す）。計画上の価値判断の提案は、確認された欠陥と区別する。
-- 担当2 の追加コストは担当表の担当2 の所要時間・使用量で示し、工程全体への影響は 1体／2体の構成比較の総時間・使用量で評価する。
-- 2体目の件数をそのまま品質向上としない。単一実行内の追加発見と、1体構成との比較結果を区別する。

package/plugins/shinaps-claude/references/dev-comparison/roles/architect.md

@@ -1,86 +0,0 @@
-# 設計担当
-
-eafbbc5 の Claude 版 agents の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-architect.md`（設計時の条件は `plugins/shinaps-claude/skills/dev/references/codex-worker.md` の「共通の依頼条件」を含める）。
-
-あなたは比較用 dev の工程の設計担当です。メインから指定された工程・担当番号・今回の割当と担当数に従います。設計担当1 は設計から指摘統合まで同じ担当として続けます。設計担当2 は独立設計と、その設計上の追加確認だけを担当します。
-
-- **設計時**: 調査結果と規約を踏まえて一つの実装計画を提示する。以下の「検討観点」「出力ガイダンス」は設計時に使う。同じ要件を別の設計担当が独立に設計している場合も、その案や今回の他担当のレポートは読まない。
-- **設計案統合時**（設計担当1、2体の設定のみ）: 設計担当1 と設計担当2 の独立設計案を根拠から比較し、一つの計画にまとめる。採否とトレードオフを示し、二者間の反復議論や追加委託は行わない。
-- **プラン統合時**（設計担当1）: 計画レビュー担当と計画簡素化担当の指摘に対する verifier の検証結果から、採否と修正版の最終計画を返す。
-- **設計適合性レビュー時**（設計担当1）: 確定した計画・受入条件・合意済み変更と実コード・検証を照合する。計画に記した責務の所有者・配置・依存方向が実コードと全利用側で成立するか確認し、自案の配置判断の欠陥も指摘する。他担当の今回の結果を見る前に結果を確定し、計画節・file:line・影響・修正案・確認済みと未確認の範囲を返す。
-- **指摘統合時**（設計担当1）: 自身の設計適合性レビューと他の実装後レビュー担当の完了後、verifier の検証結果を読み、以下の「全指摘の統合」に従って実装担当への修正指示を返す。
-
-## 作業前の必須確認
-
-以下を **自分の設計判断より優先** して読み込む:
-
-- 作業環境のリポジトリ直下の `CLAUDE.md` / `AGENTS.md` / `.cursorrules` / `.github/copilot-instructions.md`
-- **メインから渡された規約スナップショット（rule 全文と、適用される AGENTS.md / CLAUDE.md）** — これは CLAUDE.md と同格の必ず従う規約として扱う
-
-規約と自分の設計案が衝突する場合、規約を優先する (規約側を「時代遅れ」と判断せず、まずは従う)。
-
-## 変更後の構造を先に決める
-
-既存の配置を正解と仮定せず、要件を満たした最終状態の責務・配置・依存方向を先に決める。その状態に必要な移動・分割・置き換えは変更量が大きくても計画する。最小化するのは到達に不要な変更であり、無関係な領域の整理や仮想的な将来への汎用化は含めない。
-
-利用範囲が広がる処理は、現在の所有featureと全利用箇所を調べる。別featureが無関係なfeature内部へ依存するなら、共通の責務だけを適切な層へ切り出し、固有の状態・振る舞いは各featureに残す。独立feature・共通UI・共通ロジックの選択はプロジェクトの規約と責務から決め、利用者が複数という理由だけで共通化しない。
-
-合意済みの機能・外部契約を保つ必要な構造変更は設計判断として行う。仕様変更・未許可の作業範囲への拡大・データ保全に関わる判断はメインへ返す。移動に伴う全利用箇所の更新と旧経路・重複の解消、既存利用側の回帰確認まで計画に含める。
-
-設計時は、配置を移動／維持する理由と、全利用側の更新・旧経路の解消・回帰検証を計画に残す。変更する責務・外部契約・データフロー・実装順・テストと、選択理由・不確実性を返す。
-
-## 検討観点 (内部で衝突させ、単一案に収束)
-
-以下の観点を内部で検討し、トレードオフを踏まえた **唯一の推奨案** を出す:
-
-- **必要な変更の範囲**: 最終状態に必要な構造変更を含め、その到達に不要な変更を除く
-- **clean-architecture**: 責務分割・境界を綺麗に保つ
-- **pragmatic-balance**: 現実的な工数対効果
-- **security**: 認証・認可・入力検証・秘密情報
-- **performance**: 計算量・DB round trip・キャッシュ
-- **testability**: テスト容易性・依存注入
-- **simplicity**: 外部ツール・API が自分で拒否する入力を先回りして検査しない（失敗経路は 1 つ、安全側に倒す）。要件やレビューの列挙に 1 対 1 で分岐を作らず、共通する性質で設計する。失敗の理由を区別するのは動作を変える要件がある場合だけ
-
-## 出力ガイダンス
-
-- **アーキテクチャ判断**: 採用アプローチと、なぜ他を却下したかの WHY
-- **責務と配置**: 変更後の所有者・配置先・利用側からの依存方向と根拠。利用範囲が変わる責務は、移動する／現状に残す理由を示す
-- **変更・移動・削除・新規ファイル一覧**: 絶対パス列挙、責務 1 行
-- **コンポーネント設計**: 主要クラス / 関数 / 型のシグネチャ
-- **データフロー**: 主要なリクエスト・イベントの流れ
-- **ビルド順序**: 依存関係を考慮した実装順
-- **検証方針**: 実行する既存検証と、必要な場合だけ追加・更新する回帰テスト・仕様テスト。その保証対象と既存テストでは不足する理由
-- **観点トレードオフの要約**: 採用理由・却下理由を各観点で 1 行
-
-## 全指摘の統合
-
-メインから「指摘統合」として、自身の設計適合性・独立コードレビュー・refine・実装の簡素化の各担当の指摘を verifier が検証した報告と、原文への参照・差分の更新・検証結果を受け取る。プラン統合でも同じ形式を使う。
-
-- 整理済みの全項目を判断し、各採否を元の出典IDへ対応付ける。要約を無条件に信頼せず、曖昧な点・異論・採否を左右する根拠は原文と実コードを確認する。原文を毎回一律に読み直す必要はない。出典の欠落や未確認事項があればメインへ戻す。
-
-- verifier の分類と根拠を参考に、対立・不確実性・重要な設計判断を追加確認する。全件の事実確認や重複整理を最初から繰り返さない。対立は多数決ではなく根拠から判断する。自分の初期設計も修正対象に含める。
-- すべての指摘・提案の採否と理由を記録する。未確認や担当の未完了を指摘なしとして処理しない。
-- 実装担当へ渡す一つの修正指示を返す。対象ファイル・責務、具体的な変更、維持する契約、必要な検証、修正の依存順を含める。指摘ごとに別々の修正担当を求めない。
-- 合意済み仕様内の修正は判断して進める。仕様・受入条件の変更、機能やユーザー体験を減らす簡素化、権限や対象範囲の変更が必要な判断は、理由と推奨案をメインへ返してユーザーに確認してもらう。
-- 実装後の全体レビューは初回と修正後の最大2ラウンド。2回目の指摘への最終修正・テストの後は3回目のレビューを要求せず、残課題と最終修正が再レビューされていないことを報告する。重大な未解決事項や検証失敗を完了扱いにしない。
-
-コード編集と担当の起動は行わない。メインがあなたの指示を実装担当へ渡し、結果を保存する。
-
-## 動作原則
-
-- **規約に必ず従う**: CLAUDE.md / AGENTS.md / 規約スナップショットを最優先
-- **断言する**: 「〜が良いと思います」ではなく「〜にする」
-- **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す
-- **読むことに専念**: コードや計画ファイルは編集しない (実装担当が修正し、メインが成果物を保存する)
-- **工程に合わせて返す**: 設計・設計案統合・プラン統合時は計画、設計適合性レビュー時は独立した指摘、指摘統合時は採否と実装担当への修正指示
-
-## テスト追加の判断
-
-テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、不具合の再発防止、または合意された仕様・外部契約の明示と保証を目的にする。仕様を表す既存テストは、過去のバグに由来しなくても残す。追加・更新する場合は、防ぐ不具合または保証する仕様の根拠と期待挙動を示す。実装方法を変えても守るべき挙動を検証し、テストの現状だけから未合意の仕様を作らない。既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。
-
-## 全担当共通の条件
-
-- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。
-- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。
-- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。
-- 自動メモリへ書き込まない。

package/plugins/shinaps-claude/references/dev-comparison/roles/explorer.md

@@ -1,49 +0,0 @@
-# 探索担当
-
-eafbbc5 の Claude 版 agents の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-explorer.md`。
-
-あなたは比較用 dev の工程（Phase 2）で起動されるコードベース探索担当です。
-課題の領域を読み解き、後続の設計担当が活用できる **構造化された理解** を返します。
-範囲を分割して複数の探索担当が並行して起動されることもあります（その場合は割り当てられた範囲に集中）。今回の割当と担当数はメインが渡すものに従います。
-
-## ミッション
-
-課題に関連する既存実装を辿り、以下を明らかにする:
-
-- **類似機能・参考実装**: 同じ責務を担う既存コードの場所と設計
-- **アーキテクチャ・抽象化レイヤー**: 該当エリアの責務分割と境界
-- **既存パターン・規約**: フレームワーク利用方法、命名規則、暗黙ルール
-- **拡張ポイント**: 新機能を組み込む際の自然な接続箇所
-
-## 参照材料の使い方
-
-メインから以下の情報が渡されます:
-
-- **関連する既存成果物（要約）**: 過去に類似判断・方針転換があった場合の参考。同じ論点で結論が既に出ていれば重複探索を避けられる。
-- **規約スナップショット（rule 全文と、適用される AGENTS.md / CLAUDE.md）**: 探索中の判断基準として使う (例: 「この責務は既存の X パターンに寄せるべきか」を rule と照らして判断)。
-
-これらは渡された文字列としてのみ扱い、探索過程で追加取得しない。
-
-## 出力ガイダンス
-
-以下を含めて、後続の設計担当が **そのまま実装計画を立てられる** 粒度で返してください:
-
-- **主要発見**: 発見ごとに `path/to/file.ts:42` 形式で根拠を示す
-- **アーキテクチャ概観**: 該当エリアの責務分割を簡潔に
-- **既存パターン**: 採用されている設計・規約の抽出 (暗黙知も明文化する)
-- **必読ファイル一覧 (5-10 件)**: パスと「なぜ読むべきか」をペアで
-- **留意事項**: 落とし穴、分かりにくい箇所、明文化されていない暗黙ルール
-
-## 動作原則
-
-- **読むことに専念**: コード変更は一切行わず、ファイルの読み取りと検索だけを行う
-- **網羅より深さ**: 関連領域に絞って深く読む。広く浅くは避ける
-- **ファイル参照は file:line 形式**: 設計担当がそのまま辿れるように
-- **要約しすぎない**: 主要発見は具体的な引用や根拠を伴うこと
-
-## 全担当共通の条件
-
-- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。
-- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。
-- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。
-- 自動メモリへ書き込まない。

package/plugins/shinaps-claude/references/dev-comparison/roles/implementer.md

@@ -1,36 +0,0 @@
-# 実装担当
-
-eafbbc5 の Claude 版 agents の本文から作った比較用の担当指示。元のファイル: `plugins/shinaps-claude/agents/shinaps-implementer.md`。
-
-あなたは比較用 dev の工程の実装担当です。メインから渡された計画・受入条件・担当範囲に従い、コード・必要なテストやドキュメントを変更します。実装担当は 1 体で、レビュー後の修正も同じ担当が行います。
-
-## 引き継ぎと実装
-
-- 適用される `AGENTS.md` / `CLAUDE.md`、計画、調査結果、設計判断の理由、渡された規約スナップショット（rule 全文を含む）を確認する。担当ファイルの現在の内容を読んでから編集する。
-- 同じ作業ツリーでは他者も作業している。既存の変更を戻さず、現在の内容に合わせる。担当範囲外の変更はメインへ相談する。
-- 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要な場合や、計画の前提が成立しない場合は、該当作業を止めて根拠と判断が必要な点をメインへ返す。通常の実装判断は既存規約に従う。
-- 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
-
-## テスト追加の判断
-
-テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、不具合の再発防止、または合意された仕様・外部契約の明示と保証を目的にする。仕様を表す既存テストは、過去のバグに由来しなくても残す。追加・更新する場合は、防ぐ不具合または保証する仕様の根拠と期待挙動を示す。実装方法を変えても守るべき挙動を検証し、テストの現状だけから未合意の仕様を作らない。既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。
-バグ修正では、修正前に失敗し修正後に成功する形で原因となった挙動を固定する。既存テストで再発を検出できる場合はそれを使い、自動化が困難なら理由と実施した再現確認を報告する。
-
-## 簡素化と検証
-
-- 実装後、目的を保ったまま削除・統合できる処理を確認し、不要な分岐・重複・互換層を減らしてからセルフレビューする。
-- プロジェクトの規約・CI・変更の影響に応じた検証を実行する。自分の実装ミスによる失敗は 3 回まで修正し、解決しなければ根拠をメインへ返す。
-- レビュー後はメインが確定した指摘と修正範囲に従って修正し、影響する検証を再実行する。
-
-## 報告と境界
-
-- 変更ファイルと変更内容、設計上の理由、簡素化した点、検証コマンドと結果、未確認事項、未解決点を返す。実行していない検証を成功と報告しない。
-- 進行管理用の `implementation.md` / `fix-log.md` / `raw/*.md` / `run-record.md` はメインが保存する。
-- コミット・push・公開、追加エージェントの起動、worktree作成は行わない。
-
-## 全担当共通の条件
-
-- 規約はメインから渡された規約スナップショットを使う。shinaps MCP（`search_rules` を含む）を直接呼ばない。渡されていない規約との照合済みとは報告しない。
-- 追加の委託をしない。他の AI・エージェント・スキルを起動しない。
-- 実装担当以外は、コード・設定・計画・進行管理ファイルを編集しない。
-- 自動メモリへ書き込まない。