npm - @shinaps/skills - Versions diffs - 0.23.0 → 0.25.0 - Mend

@shinaps/skills 0.23.0 → 0.25.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (95) hide show

package/plugins/shinaps-codex/skills/linear/references/configuration.md CHANGED Viewed

@@ -28,23 +28,27 @@
 ## 項目
-| キー | 内容 | 未記載のとき |
-| --- | --- | --- |
-| `target.workspace` | Linearのworkspace | 開発進行を始めない |
-| `target.team` | チームのキー（例 `SHINAPS`） | 開発進行を始めない |
-| `target.project` | 使うprojectのURL。projectを使わない運用では `null` | 未決として扱い、project未使用とは推測しない。projectに依存する操作の前で止める |
-| `team_settings` | `existing_only`（既存の定義に合わせ、変更しない）または `manage_on_setup`（初期設定・設定変更のときだけ変更案を示し、合意後に整備できる） | `existing_only` |
-| `statuses` | 工程キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる | そのキーの状態更新の前で止める |
-| `stop_after` | 終了地点（下の「終了地点」） | 開発進行を始めない |
-| `permissions` | 継続的に許可した操作の一覧（下の「許可」） | 何も許可していない |
-| `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` ごとに、既存資料のパスまたはURLの一覧 | 各リポジトリのAGENTS.md・README・CIから読む |
-| `cycle_report` | Cycle報告の設定（下の「Cycle報告」） | Cycle報告を書き込まない |
-| `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`（単位ごとに承認を得る）または `autonomous`（個別の承認なしで単位ごとに検証してコミットする） | `shinaps:commit` が開始時に一問確認する。値が2つ以外のときも同じ |
-| `human_code_review` | 人のコードレビューの要否。`required`（人がレビューする）または `skip`（人のレビューを行わない） | `required`。値が2つ以外のときも同じ |
-| `document_only_changes` | 文書だけの変更（下の説明）の扱い。`ai_commit`: 対象差分が文書だけの変更のとき、人のコードレビューを行わず、Local Agent QAの合格後にCodexの依頼でClaudeが `shinaps:commit` でコミットする | 例外を使わない。値が `ai_commit` 以外のときも同じ |
-- `commit_mode` は進め方の既定値であり、コミットの許可ではない。コミットは利用者の明示的な依頼、`permissions` の `commit`（条件は下の「許可」）、または `document_only_changes: ai_commit` による文書だけの変更のコミットのときだけ行う。`commit_mode` があるだけではコミット・pushを始めず、人のレビュー済みと推測しない。その場の明示的な指定は設定に優先する。`normal` は人が自分でgit操作をする工程（`code_review`）とは別のもの。
-- `human_code_review: skip` は人のレビューの工程だけを省く。`shinaps:dev` 内のレビュー、Agent QA、必要なHuman QAは省かない。省略は、人のレビュー済みとして記録しない。`human_code_review`・`commit`・`stage`・`commit_mode`・`document_only_changes` は互いに独立しており、一つから他を推測しない。
+以下の項目はすべて明示必須。省略・不正値を既定値で補わず、依存する工程を止めて設定を確認する。`null`・`none`・空の一覧は、以下で認めた箇所だけで「使用しない」を表す。
+| キー | 内容 |
+| --- | --- |
+| `target.workspace` | Linearのworkspace |
+| `target.team` | チームのキー（例 `SHINAPS`） |
+| `target.project` | 使うprojectのURL。projectを使わない運用では `null` |
+| `team_settings` | `existing_only`（既存の定義に合わせ、変更しない）または `manage_on_setup`（初期設定・設定変更のときだけ変更案を示し、合意後に整備できる） |
+| `statuses` | 工程キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる |
+| `stop_after` | 終了地点（下の「終了地点」） |
+| `permissions` | 継続的に許可した操作の一覧（下の「許可」）。許可なしは `[]` |
+| `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
+| `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
+| `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`（CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する）、または `dev-codex`・`dev-codex-ultra`（Codexが自分でその入口を実行する） |
+| `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`（単位ごとに承認を得る）または `autonomous`（個別の承認なしで単位ごとに検証してコミットする） |
+| `human_code_review` | 人のコードレビューの要否。`required`（人がレビューする）または `skip`（人のレビューを行わない） |
+| `document_only_changes` | 文書だけの変更（下の説明）の扱い。`none` は例外なし。`ai_commit`: 対象差分が文書だけの変更のとき、人のコードレビューを行わず、Local Agent QAの合格後に実装担当が `shinaps:commit` でコミットする（Claudeの入口ではCodexの依頼でClaudeが行う） |
+- `commit_mode` は進め方の設定であり、コミットの許可ではない。コミットは利用者の明示的な依頼、`permissions` の `commit`（条件は下の「許可」）、または `document_only_changes: ai_commit` による文書だけの変更のコミットのときだけ行う。`commit_mode` があるだけではコミット・pushを始めず、人のレビュー済みと推測しない。その場の明示的な指定は設定に優先する。`normal` は人が自分でgit操作をする工程（`code_review`）とは別のもの。
+- `implementation_skill` が決めるのは、実装・修正の担当と実行方式だけである。`permissions`・`stop_after`・`human_code_review`・`commit_mode`・`document_only_changes` の意味と、`dev_delegation`・worktreeの作成・別セッションの作成の許可を変えない。その場の明示的な指定は設定に優先する。既存の設定にキーがなくても、自動で書き加えない。担当と工程の対応は [workflow.md](workflow.md) の「担当と窓口」にある。
+- `human_code_review: skip` は人のレビューの工程だけを省く。devの入口内のレビュー、Agent QA、必要なHuman QAは省かない。省略は、人のレビュー済みとして記録しない。`human_code_review`・`commit`・`stage`・`commit_mode`・`document_only_changes` は互いに独立しており、一つから他を推測しない。
 - `document_only_changes: ai_commit` は、文書だけの変更について、`human_code_review: required` でも人のレビューを省き、`commit` の許可がなくてもAIのコミットを認める。`stage` の許可は通常のコミットと同じく必要で、ほかのキーの意味と許可は変えず、push以降の操作、利用中のツールの権限、利用者の停止・撤回（「設定の読み方」）を上書きしない。
 - 対象差分の全体（追加・削除・改名・移動・ファイルの実行権限の変更を含む、そのコミットに入るすべての変更）が、説明だけを変え、人またはAIを含む実行主体の動作・権限・必須の工程を変える内容を一つも含まないとき、文書だけの変更とする。動作・権限・必須の工程を変える内容には、実行コード、テスト、スクリプト、ビルド・CI・配備・フック・依存・環境・Linterの設定、生成物とその元、データやmigration、AIツールの権限やスキルの入口に加え、文書の中で実行主体の権限・担当・必須の工程や検証・コミットとレビューの条件を定める記述を含む。判定は各ファイルの役割と変更内容で行い、拡張子・ディレクトリ名・ファイル名のパターンだけを根拠にしない。判定できない差分は文書だけの変更として扱わない。例外を適用するために対象差分を分割しない。
 - 工程キーは [workflow.md](workflow.md) の工程表と同じ。`statuses` の値はチームに実在する正確な名前にする。操作時はLinearから取得した状態のIDを使う。対応が曖昧・欠落・実物と不一致なら、その対応に依存する更新を止める。ステータスを自動で新設しない。
@@ -76,23 +80,25 @@
 | `merge` | 必要なQA・承認が揃った対象PRのマージと、元のブランチへ戻る操作 |
 | `deploy:<環境>` | 指定した環境への配備・配布（例 `deploy:staging`） |
 | `publish:<操作>` | 一般公開やストアへの提出など、指定した公開操作（例 `publish:app_store_submit`） |
-| `dev_delegation` | Claudeが `shinaps:dev` の中で委託（サブエージェント・別のCLI）を使う。worktreeの作成は含まない |
+| `dev_delegation` | `implementation_skill` で選んだdevの入口の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
 | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
-- 開発進行には `issue_update` と `bridge_request` が必要である。初期設定では、この2つと `stage`・`dev_delegation` を開発進行の標準の組として提案する。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
+- 開発進行には `issue_update` が必要である。`implementation_skill` がClaudeの入口のときは `bridge_request` も必要で、Codexの入口のときは不要である。初期設定では、`issue_update`・`bridge_request`・`stage`・`dev_delegation` を開発進行の標準の組として提案する（Codexの入口を選ぶ場合は `bridge_request` を除く）。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
 - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
 - 次の操作は一覧に含めず、常にその場で確認する: force-push、履歴の書き換え、ブランチの削除、チーム設定の変更。
 - 設定の許可は、今回の依頼で任されたIssue・Cycleの範囲を広げない。
 ## Cycle報告
+報告を使う場合は次のサブキーをすべて記載する。使わない場合は `cycle_report: null` とする。
 | サブキー | 内容 |
 | --- | --- |
 | `qa_scope` | 全体QAの対象となる環境・端末の一覧 |
 | `destination` | 報告本文の保存先（例 `linear_cycle_document`） |
 | `index` | 索引のURL、または `null` |
 | `audience` | 読み手 |
-| `format` | 既存の書式や直近の報告への参照（任意） |
+| `format` | 既存の書式や直近の報告への参照。個別の書式指定なしは `null`（共通テンプレートを使う） |
 書き込むのは `destination` と `index` だけ。記載のない報告先や送信先には、補足ファイルに書かれていても書き込まない。
@@ -119,12 +125,21 @@ statuses:
   human_input: In Progress
   done: Done
 stop_after: pre_push_qa
+implementation_skill: dev-claude-ultra # CodexがBridgeでClaudeへ依頼する。Codexが実装する場合は dev-codex-ultra など
+human_code_review: required
+commit_mode: autonomous
+document_only_changes: none
+cycle_report: null
 permissions:
   - issue_update
   - bridge_request
   - stage
   - dev_delegation
 references:
+  specifications:
+    - README.md
+  environments: []
+  deployment: []
   validation:
     - README.md#開発と配布
     - package.json
@@ -141,7 +156,7 @@ Codexが行う。
 1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
 2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。
 3. 設定案を一つ作る。チーム設定を管理できる場合だけ、FamilyStayを基にした工程の分離（[workflow.md](workflow.md) の工程表に対応するステータス）を変更案として示す。利用者のプロジェクトらしいという推測で `manage_on_setup` にしない。
-4. 既存の情報で決まらない運用上の決定（`stop_after`、`permissions`（`commit` を含む）、`human_code_review`、`team_settings`、Cycle報告、`commit_mode`）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。作業先リポジトリの既存の規約に文書だけの変更の例外がある場合だけ、その範囲と `document_only_changes` の範囲（「項目」の説明）を示して、設定するかを確認する。
+4. 既存の情報で決まらない運用上の決定（`stop_after`、`permissions`（`commit` を含む）、`human_code_review`、`team_settings`、Cycle報告、`commit_mode`、`implementation_skill`）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。作業先リポジトリの既存の規約に文書だけの変更の例外がある場合だけ、その範囲と `document_only_changes` の範囲（「項目」の説明）を示して、`ai_commit` を設定するかを確認する。例外を使わない場合は `none` を記載する。
 5. 合意した内容を保存し、読み直して確認する。
 6. Linearのチーム設定の変更は、ローカル設定の保存とは別に扱う。対象チームと変更差分（追加・改名するステータスと順序）を示し、合意を得てから反映して読み戻す。反映後に `statuses` を実物に合わせて確定する。

package/plugins/shinaps-codex/skills/linear/references/cycle-report.md CHANGED Viewed

@@ -1,6 +1,6 @@
 # Cycle完了QAと成果報告
-Codexが実行する。Cycle全体を任され、報告まで許可されている場合は、報告用Issue以外の対象Issue（文書・運用のIssueを含む）がすべてDoneであることを確認して続ける。Issue単位の依頼では自動で開始せず、全件完了を案内する。報告だけを明示的に依頼された場合も開始できる。設定の `cycle_report` がなければ書き込まず、必要な設定を案内する。
+Codexが実行する。Cycle全体を任され、報告まで許可されている場合は、報告用Issue以外の対象Issue（文書・運用のIssueを含む）がすべてDoneであることを確認して続ける。Issue単位の依頼では自動で開始せず、全件完了を案内する。報告だけを明示的に依頼された場合も開始できる。設定が `cycle_report: null` なら報告を行わない。報告を依頼された場合は設定変更を先に行う。設定の不足・不正値は [configuration.md](configuration.md) に従って確認する。
 対象のCycle IDとIssue一覧を記録する。日付の到来・自動繰り越し・Cycleの移動・取消を、全件完了の根拠にしない。取消・持ち越し・対象外への変更は、成果と区別して記録する。履歴を取得できない場合は不明と書く。

package/plugins/shinaps-codex/skills/linear/references/workflow.md CHANGED Viewed

@@ -4,13 +4,15 @@
 | 担当 | 責務 |
 | --- | --- |
-| Codex | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、Bridgeでの依頼、Local・Staging・ProductionのAgent QA、許可されたPR・配備等の運用、結果の記録、人への依頼 |
-| Claude | Codexの指示に基づく技術調査、`shinaps:dev` による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従い `shinaps:dev` の対象外にできる。スキル・コードの変更は文書の形でも実装として `shinaps:dev` を使う |
+| Codex | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、Claudeの入口のときのBridgeでの依頼、Local・Staging・ProductionのAgent QA、許可されたPR・配備等の運用、結果の記録、人への依頼 |
+| 実装担当 | 技術調査、`implementation_skill` で選んだdevの入口による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
 | 人 | 未合意の仕様・権限の判断、設定で必要なコードレビュー・必要な修正、AIに許可していないコミット、本人の操作が必要な認証等、必要なHuman QA |
+実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`・`dev-claude-ultra`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`・`dev-codex-ultra`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告をCodexが自分で行い、そのためのBridgeの依頼・報告を使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
 人への質問と依頼はCodexが窓口になる。Claudeは人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
-CodexはQAで見つけた不具合を自分で実装修正せず、再現条件と証拠をClaudeへ返す。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
+CodexはQAで見つけた不具合をQAの工程の中で修正せず、再現条件と証拠を実装担当へ返す。Codexの入口では、Codexが実装担当として同じ入口で修正し、改めてQAを行う。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
 Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐付けなど）は、Codexが利用可能なブラウザで行う。MCPが対応していないという理由だけで人へ回さない。人の認証や権限が必要な場合だけ人へ依頼する。
@@ -19,8 +21,8 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 | 状況 | 必要な行動 |
 | --- | --- |
 | Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | Claudeは人へ着手を再確認せず、指定されたスキルで実行する |
-| `shinaps:dev` の中で計画上の判断が必要になった | ClaudeはCodexへ相談する。Codexは既存の合意で判断できれば回答し、人へ再承認を求めない |
-| QAで受入条件の範囲内の不具合が見つかった | CodexがClaudeへ修正を依頼し、Claudeは人の着手許可を改めて取らずに修正する。Codexが再検証する |
+| devの入口の中で計画上の判断が必要になった | Claudeの入口ではClaudeがCodexへ相談する。Codexは既存の合意で判断できれば回答し、人へ再承認を求めない |
+| QAで受入条件の範囲内の不具合が見つかった | CodexがClaudeへ修正を依頼し（Codexの入口では自分で修正し）、実装担当は人の着手許可を改めて取らずに修正する。Codexが再検証する |
 | Claudeが人のレビュー・コミット完了をBridgeで報告した | Codexは人に同じ事実を聞き直さず、報告の対象とGitの状態を照合して次の工程へ進む |
 | 次の操作の継続的な許可があり、必要な工程の結果が揃った | Codexは「進めてもよいか」を再質問せずに実行する |
 | Cycle全体を任され、対象Issueが設定された終了地点に達した | CodexはCycleを読み直し、依存・優先順位から次の実行可能なIssueを選んで続ける |
@@ -38,9 +40,9 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 | `todo` | Todo | 未着手のIssue |
 | `refinement` | 仕様整理中 | 目的・仕様・範囲・依存・受入条件を整理する |
 | `ready` | Ready | 自分たちの作業を依存順に進めれば着手できる。開始時に、必要な前工程の成果を再確認する |
-| `coding` | Coding | Claudeが実装・自動検証・簡素化・セルフレビューを完了し、差分と結果を渡す |
+| `coding` | Coding | 実装担当が実装・自動検証・簡素化・セルフレビューを完了し、差分と結果を渡す |
 | `local_agent_qa` | Local Agent QA | Codexが受入条件を検証する。不合格なら `coding` へ戻す |
-| `code_review` | Code Review（人のレビューまたは省略の記録・コミット） | `human_code_review: required` では人がレビュー・修正する。`skip` では人へのレビュー依頼も待ちも作らず、省略を記録する。コミットは、Local Agent QAの合格後（`required` では人のレビュー完了の確認後）に、`commit` と `stage` の許可があればCodexの依頼でClaudeが行い、なければ人が行う。対象コミットと、人の完了通知または省略の記録を照合する。`document_only_changes: ai_commit` があり、対象差分が文書だけの変更に当たる場合は、下の箇条に従う |
+| `code_review` | Code Review（人のレビューまたは省略の記録・コミット） | `human_code_review: required` では人がレビュー・修正する。`skip` では人へのレビュー依頼も待ちも作らず、省略を記録する。コミットは、Local Agent QAの合格後（`required` では人のレビュー完了の確認後）に、`commit` と `stage` の許可があれば実装担当が行い（Claudeの入口ではCodexの依頼による）、なければ人が行う。対象コミットと、人の完了通知または省略の記録を照合する。`document_only_changes: ai_commit` があり、対象差分が文書だけの変更に当たる場合は、下の箇条に従う |
 | `post_commit` | コミット後の検証・PR準備 | 設定に従って、push前の最終Agent QA、必須検証、許可されたpush・PR作成を行う |
 | `staging_agent_qa` | Staging Agent QA | 配備されたPR候補版をCodexが検証する |
 | `staging_human_qa` | Staging Human QA | そのPRで必要な人の確認。不要なら理由を記録して省略する |
@@ -56,18 +58,18 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 - 人がレビュー中に修正した場合は `code_review` を続ける。AIへ追加実装を依頼する場合は、範囲と受入条件をIssueで更新してから `coding` へ戻す。
 - Human QAが新たに必要になった場合は、理由と具体的な残項目をIssueに記録して利用者に相談する。
 - プロジェクトの規約や補足の記述だけでは、AIのコミットの許可として扱わない。文書だけの変更であることを理由に人のレビューを省きAIがコミットする例外は、設定に `document_only_changes: ai_commit` があるときだけ適用する。適用しない場合は、通常のレビュー・コミットの条件（`human_code_review` と [configuration.md](configuration.md) の「許可」の `commit`）に従う。
-- `human_code_review: skip`、または下の文書だけの変更の例外で人のレビューを行わなかった場合、Codexは `code_review` の工程で、省略と、実施した確認（`shinaps:dev` 内のレビュー、Local Agent QA）への参照をIssueへ記録する。1行目には省略の根拠になった設定を書き、文書だけの変更の例外では判定の記録へのリンクを添える。
+- `human_code_review: skip`、または下の文書だけの変更の例外で人のレビューを行わなかった場合、Codexは `code_review` の工程で、省略と、実施した確認（devの入口内のレビュー、Local Agent QA）への参照をIssueへ記録する。1行目には省略の根拠になった設定を書き、文書だけの変更の例外では判定の記録へのリンクを添える。
   ```text
   人のコードレビュー: 省略（作業先リポジトリの設定 <human_code_review: skip または document_only_changes: ai_commit>。文書だけの変更の例外では「判定: <Local Agent QAのコメントへのリンク>」を続ける）
-  実施した確認: shinaps:dev 内のレビュー（使った場合。Claudeの完了報告 <コメントへのリンク>）、Local Agent QA（<記録へのリンク>）
+  実施した確認: devの入口内のレビュー（使った場合。実装担当の完了報告 <コメントへのリンク>）、Local Agent QA（<記録へのリンク>）
   コミット: <SHA>（<実際の実施者と方法>）
   ```
 - `document_only_changes: ai_commit` がある場合は、次のとおり進める（文書だけの変更の定義は [configuration.md](configuration.md) の「項目」）。
   - Local Agent QAで、Codexは受入条件の検証に加え、対象差分の全体が文書だけの変更に当たるかを判定し、範囲と理由をQAコメントに一度だけ記録する。
-  - 当たる場合、`required` でも人へのレビュー依頼も待ちも作らない。CodexはClaudeへコミットを依頼し、依頼に判定の記録へのリンクを添える。
-  - Claudeは、設定にこのキーと `stage` の許可があること、依頼された対象差分が、作業ツリー上の同じ対象（ファイルと内容）の差分と一致することを確認してから `shinaps:commit` でコミットする。違えばコミットせずCodexへ返す。差分の性質は判定し直さない。
+  - 当たる場合、`required` でも人へのレビュー依頼も待ちも作らない。Claudeの入口では、CodexはClaudeへコミットを依頼し、依頼に判定の記録へのリンクを添える。
+  - 実装担当は、設定にこのキーと `stage` の許可があること、判定した対象差分が、作業ツリー上の同じ対象（ファイルと内容）の差分と一致することを確認してから `shinaps:commit` でコミットする。違えばコミットしない（Claudeの入口ではCodexへ返す）。差分の性質は判定し直さない。
   - コミット後、Codexはコミットの内容が判定した差分と一致し、対象作業の未コミット変更が残らないことを照合する。一致しなければ次の工程へ進まず、SHA・判定した差分・実際の差分の違いをIssueに記録して人に確認する。履歴の書き換えはその場で確認する。
   - 判定の後に対象差分が変わったら、新しい対象で判定とQAをやり直す。
   - 照合の後に、上の省略の記録をIssueへ書く。
@@ -83,25 +85,25 @@ Linearの工程のステータスと、Codexのゴールの状態は別に扱う
 ## Bridgeでの依頼と報告
-AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済みのMCPとWebStormプラグインを使う。開発進行には必須で、Issue整理だけなら不要。
+AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済みのMCPとWebStormプラグインを使う。Claudeの入口で開発進行するときは必須で、Codexの入口やIssue整理だけなら不要。
-送信前に `list_sessions` で、相手の `project_path`、完全な `session_id`、受信の可否を確認する。`session_id` は保存せず、依頼のたびに一覧から取得する。`project_path` はIDEのプロジェクトのルートで、作業ディレクトリと一致するとは限らない。依頼と報告には、Gitの作業ディレクトリを別に書く。
+送信前に `list_sessions` で、相手の `project_path`、完全な `session_id`、受信の可否を確認する。`session_id` は保存せず、依頼のたびに一覧から取得する。`project_path` はIDEのプロジェクトのルートで、作業ディレクトリと一致するとは限らない。依頼と報告には、Gitの作業ディレクトリを別に書く。次の表のCodexとClaudeの間の依頼・報告は、Claudeの入口のときに使う。
 | 依頼・報告 | 含めるもの |
 | --- | --- |
-| 実装・修正の依頼（CodexからClaude） | Issueリンク、範囲・受入条件、Gitの作業ディレクトリ・ブランチ・既存差分、許可範囲（`dev_delegation` の有無を含む）、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文。修正依頼では、再現手順・期待と実際・対象差分・証拠の場所を加える |
+| 実装・修正の依頼（CodexからClaude） | Issueリンク、使う入口（`implementation_skill` の値、またはその場の明示的な指定）、範囲・受入条件、Gitの作業ディレクトリ・ブランチ・既存差分、許可範囲（`dev_delegation` の有無を含む）、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文。修正依頼では、再現手順・期待と実際・対象差分・証拠の場所を加える |
 | コミットの依頼（CodexからClaude） | Issueリンク、対象差分・Gitの作業ディレクトリ・ブランチ、Local Agent QAの結果、人のレビューの状態（完了通知の内容、または設定による省略）、返信先のCodexの `session_id` |
-| 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、`shinaps:dev` 内のレビュー結果の要約と未解決の指摘。コミットした場合は、コミットSHAと `shinaps:commit` の検証・レビューの結果 |
+| 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約と未解決の指摘。コミットした場合は、コミットSHAと `shinaps:commit` の検証・レビューの結果 |
 | 人のレビュー・コミット完了の報告（ClaudeからCodex） | 下の「人のレビュー・コミット完了の報告」の項目 |
 | 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
-| 比較実行の依頼（CodexからClaude） | [比較手順](../../../references/dev-comparison/comparison.md#5-実行)の項目だけ。下の定型文と許可範囲は含めない。Claudeは指定された比較用入口で実行し、このスキルの実装・修正の手順（`shinaps:dev`、Codexへの相談、コミット）を適用しない |
 コミットの依頼では、`commit_mode` がない場合の開始時の確認と、通常モードの単位ごとの承認を、Codexが人へ取り次ぐ。Codexは自分で選択・承認しない。
 実装・修正の依頼には次の文を含める。
 ```text
-ユーザー承認済みの範囲でCodexが進行する。shinaps:linearを読み込み、この依頼の範囲と受入条件の中では人へ着手を再確認せず、shinaps:devで実行する。計画の相談・質問・障害・完了はBridgeで依頼元のCodexへ返す。人のレビュー・コミット完了を受けた場合も同じ返信先へ報告する。
+ユーザー承認済みの範囲でCodexが進行する。shinaps:linearを読み込み、この依頼の範囲と受入条件の中では人へ着手を再確認せず、指定した入口で実行する。計画の相談・質問・障害・完了はBridgeで依頼元のCodexへ返す。人のレビュー・コミット完了を受けた場合も同じ返信先へ報告する。
+入口: shinaps:<dev-claude または dev-claude-ultra>
 許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
 ```

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

@@ -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 CHANGED Viewed

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

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

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

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

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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 DELETED Viewed

@@ -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`・ほかのモデル・モデルごとの役割定義へ切り替えず、親が代わりに作業せず、ユーザーのグローバル設定（同時実行の上限を含む）を変更しない。