@shinaps/skills 0.29.1 → 0.31.0

package/plugins/shinaps-codex/references/dev/staffing.md

@@ -0,0 +1,43 @@
+# 実装体制の判断
+
+人数を入口名や変更行数で固定しない。linear-execute の進行役は各Issue開始時にIssue・関連コード・既存検証・設定を短く確認し、設計担当の起動前に初期体制を決める。単独のdevではdevのメインが同じ判断を行う。実装セッション内の「メイン」はClaude・Codex・Managedのleadを指し、linear-executeの進行役とは区別する。
+
+## 判断すること
+
+- **不確実性**: 要件と既存の解法が明確か。責務・依存方向・設計案の比較に独立した検討が必要か。
+- **影響範囲**: 局所的で利用側を追えるか。複数機能・共通基盤・実行環境をまたぐか。
+- **失敗時の影響と検証可能性**: 容易に戻せて既存テストで確認できるか。認証・課金・データ保全などの重要な契約や、再現・検証が難しい挙動に関わるか。
+
+点数・行数・一律の大小ラベルで人数を自動決定せず、未解決の問いと必要な独立確認に担当を対応させる。初期確認だけで分からなければ、まず探索の範囲を決め、その結果で設計前に体制を更新する。担当を起動するためだけの調査や計画書は増やさない。
+
+| 役割 | 専任を置く判断と人数 | 専任を置かない場合 |
+| --- | --- | --- |
+| 探索 | メインの初期確認では根拠が足りない領域に配置。独立に調べられる領域なら分担 | メインが関連コードと既存調査を確認 |
+| 設計 | 責務・依存・方式の判断が必要なら配置。競合する案や重大な見落としを独立に比較する必要があれば複数 | メインが短い計画と検証方針を確定 |
+| 計画レビュー | 実装前に検証すべき設計リスクがあれば配置。異なる観点の独立確認が必要なら複数 | メインが要件・実装可能性・検証方針を確認 |
+| 計画／実装の簡素化 | 状態・抽象化・変更範囲の複雑さに専門の検討が必要なら配置。計画と実装で別々に判断 | 計画は設計責任者、実装は実装担当とコードレビュー担当が確認 |
+| 実装 | 1体。修正も同じ担当に戻す | 委託不可の場合だけ、既存の許可・規約に従ってメインが実装 |
+| 独立コードレビュー | 最低1体。重要な契約や複数領域の見落としを独立に確認する必要があれば追加 | 委託不可・起動不能なら独立レビュー未完了。自己レビューで代替完了にしない |
+| refine | 規約の量・領域の広さから別担当での照合が有効なら配置 | コードレビュー担当に規約全文と照合責務を渡す。サービス規約未取得なら未照合と明示 |
+| 指摘検証（verifier） | 指摘が多い、相互に矛盾する、根拠の確認が難しい場合に配置。計画と実装の各ラウンドで判断 | メインが全指摘の根拠・出典・未確認事項を確認 |
+
+明確で局所的な変更なら、メインが計画し、実装1体・独立コードレビュー1体で進められる。設計が難しければ設計担当や計画レビューを追加し、設計案の独立比較が必要なら設計担当を複数にする。コードのリスクが高い場合はコードレビューを増やす。どれか一つを増やすために全役割を複数にしない。
+
+## 体制の記録と引き渡し
+
+起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を短く記録する。設計担当がいれば担当1が設計・統合を継続し、いなければdevのメインが責任を持つ。独立レビュー担当は実装担当と別のコンテキストにする。
+
+linear-executeの進行役は初期体制を利用者へ短く示し、実装依頼に根拠とともに渡す。通常の体制判断で人の承認を待たない。実装側は開始時に受け取った体制と現物を照合し、欠けていれば既定の人数へ戻さず、初期確認して体制を決め、進行役へ報告する。ローカル記録は `.shinaps/work/` 以下へ保存する。別セッションへは本文も渡し、相手から見えないパスだけに依存しない。
+
+## 途中の増員
+
+初期体制は上限ではない。設計上の新しい不確実性、影響領域の追加、重要な契約への影響、検証失敗、指摘の対立が判明した時点でdevのメインが必要な役割・人数・確認範囲を増やす。担当からの提案はメインが判断する。理由と体制の変更を記録し、linear-executeでは進行役へ報告する。初期判断や報告のために作業を止める必要はないが、追加担当の確認が必要な工程は結果が揃うまで完了にしない。
+
+- 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。
+- 設計担当を途中で置く場合は担当1を統合責任者として引き継ぎ、メインの旧計画も検討対象にする。既存担当の仕事を理由なく最初から繰り返さない。
+- 増員で既存の未完了・不利な指摘を消さない。同じ対象への増員・交代でレビューラウンドの上限をリセットしない。枠不足は順番に起動し、人数を黙って減らさない。
+- 体制判断は委託・モデル変更・操作・予算の許可を作らない。既存の許可と予算内の増員は再承認不要。仕様・範囲・明示された人数制限・許可・予算を変える必要がある場合だけ、人へ理由と選択肢を一問で確認する。
+
+## 人数によらず維持する条件
+
+要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、実装者と独立したコードレビュー、適用規約の照合、全指摘の採否と根拠の記録を維持する。専任なしは責務の省略ではない。サービス規約を取得できない、担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。linear-executeのLocal Agent QA、人レビュー、公開条件、終了地点は体制によって変えない。

package/plugins/shinaps-codex/references/dev/workflow.md

@@ -1,234 +1,112 @@
 # dev の工程
 
-dev の入口（Claude 版 `dev-claude`・`dev-claude-ultra`、Codex 版 `dev-codex`・`dev-codex-ultra`）が共有する工程。入口は同じ役割の担当数（1体／2体）だけを決める。担当の起動・継続と使うツールは、同じディレクトリの[起動手順](launch.md)に従う。
+Claude・Codex・Managed Agentsのdevはこの工程を共有する。役割・人数は[実装体制の判断](staffing.md)に従って作業ごとに決め、担当の起動・継続は各runtimeの[起動手順](launch.md)に従う。
 
-## 1. 前提
+## 1. 前提と作業記録
 
-### 作業記録の保存先
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから作業条件を読み、依頼・範囲・操作許可を引き継ぐ。仕様を左右する不足だけ一問ずつ確認する。新しい恒久方針は了承を得て保存する。利用できないツールを仮定しない。
 
-作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../work-records.md) に従う。
+委託・worktreeは許可された場合だけ使う。委託できない場合はメインが可能な調査・実装・自己確認を行ってよいが、独立レビューを実施したとは報告せず、未完了として返す。サービス規約を取得できない工程は未照合と明示する。
 
-### プロジェクト条件
+作業記録は `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` へ保存し、[共通手順](../work-records.md)に従って保全する。担当の応答は全文を参照できる形で保存し、対象版・役割・担当ID・確認範囲・完了状態を対応づける。選ばなかった専任の空レポートは作らない。短い作業は短い計画・記録にする。
 
-この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・許可を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
+## 2. 役割と継続
 
-質問は現在のセッションで利用できる質問の手段を使い、一問ずつ確認して回答を待つ。現在のセッションで提供されていないツールは仮定しない。
+担当数と専任なしの責任者は `staffing.md` の基準で決める。下の役割表は必須起動一覧ではない。
 
-### 委託と規約照合
+| 工程 | 役割定義 | 継続と責任 |
+| --- | --- | --- |
+| Phase 2 | `shinaps-explorer` | 必要な探索範囲ごとに起動 |
+| Phase 3・4・6・7 | `shinaps-architect` | 担当1は設計・統合・設計適合性を継続。担当2以降は独立設計と追加確認のみ |
+| Phase 4 | `shinaps-plan-reviewer` | 修正版の再確認も同じ担当 |
+| Phase 4・6 | `shinaps-simplifier` | 計画の再確認は継続。実装の簡素化は別担当 |
+| Phase 4・6 | `shinaps-review-verifier` | 必要なラウンドごとに新規。今回の指摘を出した担当を流用しない |
+| Phase 5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す |
+| Phase 6 | `shinaps-reviewer` | 実装担当とは別。レビューラウンドごとに新規 |
+| Phase 6 | `shinaps-refine-agent` | 専任を置く場合に起動。同ラウンドのバッチは継続 |
 
-別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。このときテストの判断は[テスト方針](../testing.md)に従う。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名は各 runtime の plugin で公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
+- 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合は同じ役割へ確認済み・未確認・最新の文脈を引き継いで交代を記録する。
+- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・成果物のパスを依頼に渡す。実装担当にはファイルの所有範囲を明記し、他者の変更を戻さず現物に合わせるよう伝える。他の担当は読み取り専用で、自分でエージェントを起動しない。
+- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず意見交換させない。継続担当には前回の確定済み指摘と採否を渡してよい。対象を編集中にレビューせず、全結果が揃うまでメインと実装担当も対象を変えない。外部変更が入れば影響範囲を同じ最新の版で確認し直す。
+- メインは起動・待機・全文保存・引き渡しを行い、担当に割り当てた判断を先回りして選別しない。専任を置かなかった責務だけは、体制に記録した担当が行う。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
 
-## 2. 役割と継続の規則
+## 3. Phase 1: タスクと初期体制の確定
 
-| Phase | 役割 | 担当数 | 継続／新規 | 役割定義 |
-|---|---|---|---|---|
-| 2 | 探索 | 1（領域が広ければ範囲を分けて並列） | 新規 | `shinaps-explorer` |
-| 3 | 設計担当1（設計案統合・プラン統合・設計適合性・指摘統合） | 1 | 全工程で継続 | `shinaps-architect` |
-| 3 | 設計担当2 | 1体: なし／2体: あり | 設計の追加確認だけ継続。他の役割へ流用しない | `shinaps-architect` |
-| 4 | 計画レビュー担当1 | 1 | 修正版の再確認で継続 | `shinaps-plan-reviewer` |
-| 4 | 計画レビュー担当2 | 1体: なし／2体: あり | 同上 | `shinaps-plan-reviewer` |
-| 4 | 計画簡素化担当1 | 1 | 同上 | `shinaps-simplifier`（計画の簡素化） |
-| 4 | 計画簡素化担当2 | 1体: なし／2体: あり | 同上 | `shinaps-simplifier`（計画の簡素化） |
-| 4, 6 | 指摘検証（verifier） | 1 | 検証ラウンドごとに新規 | `shinaps-review-verifier` |
-| 5, 7 | 実装 | 1（複製しない） | 修正で継続 | `shinaps-implementer` |
-| 6 | 設計適合性 | 1（設計担当1 を再開） | 継続 | `shinaps-architect` |
-| 6 | 独立コードレビュー | 1 | ラウンドごとに新規 | `shinaps-reviewer` |
-| 6 | refine | 1 | 同一ラウンドのバッチは継続 | `shinaps-refine-agent` |
-| 6 | 実装の簡素化 | 1 | ラウンドごとに新規 | `shinaps-simplifier`（実装の簡素化） |
+依頼・引数・指定された成果物から目的・受入条件・範囲を確定する。確定済みの内容を聞き直さず、依頼されていない過去の作業を始めない。成果物に実装可否の状態があればreadyを確認し、欠落・不明なら変更内容を推測せずタスクを確定する。内容ハッシュがある根拠は現在値と照合し、古い根拠は読み直す。
 
-- 担当は[起動手順](launch.md)に従って起動し、今回の入力（役割名・担当番号・ラウンド・担当数と、各 Phase が定める渡す情報）を依頼の本文で渡す。担当番号は起動前に固定する。読む資料はパスで指定し、作業記録にある他の担当の成果物は、工程が渡すと定めたもの以外を読ませない。担当には、他のエージェントを起動しないこと、実装担当以外はファイルを変更しないことを伝える。
-- 異なる役割は、同じモデルでも別のコンテキストで起動する。同じ役割の継続は同じ ID を再開する。再開できなければ同じ役割の新しい担当へ確認済み・未確認の範囲と最新の文脈を引き継ぎ、交代を報告に残す。
-- 設計担当2 を他の役割へ流用しない。設計担当1 は設計から指摘統合まで同じ ID で続ける。
-- 独立に確認する担当（設計担当、計画レビュー担当、計画簡素化担当、実装後の4役割）は、今回の他担当の結果を受け取らず、意見を交換しない。全担当の完了まで計画・対象コードを変更しない。
-- メインは担当の起動・待機・全文保存・受け渡し・ユーザーへの確認と、各 Phase が定める作業を行う。担当の判断を代わりに行わず、指摘を先に選別・要約・重複整理せず、検証をやり直さない。担当は自分で他の担当やエージェントを起動しない。
-- 並行して起動する担当が同時実行の上限を超える場合は、[起動手順](launch.md)のとおり分けて起動する。分けても、担当の数・独立性・渡す情報は変えない。
+Issue・既存spec・調査記録・関連コード・検証方法を必要な範囲だけ確認する。linear-executeからの初期体制を引き継ぎ、なければメインが `staffing.md` に従って判断する。設計担当を起動する前に、根拠・役割別人数・専任なしの責任者・統合責任者・必須検証を `staffing.md` として作業記録へ保存し、短く報告する。不足する調査があればPhase 2で補い、体制を更新する。
 
-## 3. 担当数の設定
+## 4. Phase 2: 規約と必要な探索
 
-担当数の設定（1体／2体）が作用するのは、独立設計（Phase 3）・計画レビュー（Phase 4）・計画簡素化（Phase 4）の 3 か所の担当2 の有無だけである。1体の設定では担当2 を起動しない。実装担当は常に 1 体で、修正も同じ担当が行う。設計適合性・独立コードレビュー・refine・実装の簡素化・verifier を含む、それ以外の工程・役割・成果物・終了条件は担当数で変わらない。
+規約はメインが取得し、以降の担当へ全文を渡す。担当はShinaps MCPを呼ばない。
 
-## 4. 実行フロー
+- `list_search_facets` でfacetを確認し、`search_rules` に現在のrepoOwner・repoNameと対象に関連するfacetを渡す。manifest・lockfileなどで確認できた対象バージョンだけ `projectVersions` に指定する。確認できない場合は共通ルールのみの照合と記録する。
+- プロジェクト規約と関連docs、引き継いだ調査の必読ファイルを確認する。時間に依存する根拠が判断に影響する場合は公式情報で確かめる。
+- 十分な根拠があれば探索担当を追加しない。不足する領域だけメインまたは体制で選んだ探索担当が補う。追加担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
 
-### Phase 1: タスクの確定
+新しい不確実性・影響範囲が見つかったら、設計前に体制を更新する。
 
-1. 今回の明示的な依頼・引数・指定された引き継ぎ資料からタスクを確定する。どれかで確定していれば、形式的な引数の再入力を求めずに進める。確定できないときだけ一問確認し、過去の文脈から依頼されていない作業を始めない。作業範囲・許可は広げない。
-2. 依頼や引数に成果物のパス（旧 `.claude/shinaps/` を含む）があれば読み、タスク・確定事項・未解決点を取り込む。
-   - 成果物に実装可否の状態（例: 実装 handoff の status）があれば ready であることを確認する。欠落・不明・ready 以外なら変更内容を推測せず、元の調査に戻るか、実装内容をここで確定するかを確認する。
-   - 根拠ファイルの内容ハッシュの記録があれば現在値と照合する。不一致・欠落の根拠は古いとみなし、同じパスを読み直して結論を確かめ直す。ブランチ・HEAD・作業ツリーの状態が同じでも照合を省かない。
-   - 同じディレクトリの調査記録（`raw/` 配下）は Phase 2 で再利用する。
-3. 今回の依頼に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。既存成果物がなければ追加取得は不要。
-4. タスクから英語 slug（kebab-case、30 文字以内）を作り、作業ディレクトリ `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` を作る。
-5. タスクの文面が曖昧、または制約が不明確な場合は一問ずつ確認する。
+## 5. Phase 3: 設計と計画
 
-### Phase 2: 規約の取得とコードベース探索
+設計責任者は設計担当1、専任なしならメインとする。目的・受入条件・調査結果・規約・既存配置を踏まえ、変更後の責務・依存方向・利用側・外部契約・実装順・検証を決める。構造変更が必要なら含め、単に変更量が少ない案を優先しない。不要な変更と仮想的な汎用化は避ける。
 
-規約はメインが取得し、以降の担当へ全文を渡す。担当は shinaps MCP を呼ばない。
+設計担当が複数なら同じ入力で独立に検討させ、全結果の後に担当1が根拠とトレードオフを比較して一つの案へ統合する。多数決にしない。各結果は `raw/architect-{n}.md`、統合案は `raw/architect.md` に保存する。専任なしならメインが短い案を作り、未実施の独立設計を行ったとは報告しない。
 
-- `list_search_facets` で facet を確認し、`search_rules` に対象リポジトリの repoOwner・repoName と、対象ファイルから推定した facet を渡して userRules・officialRules の全文を得る。
-- facet の取得結果にあるバージョンの対象と manifest・lockfile 等を照合し、確認できたバージョンだけを `projectVersions` に指定する。確認できない対象は、共通ルールだけの照合になったと記録する。
-- 関連する `AGENTS.md`・`CLAUDE.md` と、それが正本として参照する docs のうち今回の領域に関係するものを読む。
+## 6. Phase 4: 計画の確認
 
-引き継ぎ成果物がある場合は、Phase 1 で読んだ成果物と同じディレクトリの調査記録を現在の実装を理解する証拠として再利用し、必読ファイルをメインが直接読む。時間に依存する外部の根拠（現行仕様・バージョンなど）は、実装判断を左右する場合に公式情報で確かめ直す。情報が十分かつ最新なら `shinaps-explorer` を起動しない。情報不足・陳腐化・実装範囲の追加がある場合だけ補完として起動し、`raw/explorer-supplement.md` に保存する。
+選んだ計画レビュー・計画簡素化の担当だけを起動し、同じ計画・要件・調査・規約を渡す。レビューは要件・実現可能性・設計リスク・検証方針、簡素化は目的と外部契約を保って減らせる構造・状態・手順を確認する。専任なしの観点は体制に記録した責任者が確認する。
 
-引き継ぎがない、または事前調査が不足する場合は `shinaps-explorer` を起動する（領域が広ければ範囲を分けて並列）。タスク、Phase 1 の既存成果物の要約、探索の狙いを渡す。記録先は `raw/explorer.md`（並列時は `raw/explorer-{n}.md`）。
+全結果を `raw/plan-review-{round}-{n}.md` / `raw/plan-simplify-{round}-{n}.md` に保存し、「指摘の検証と統合」に従う。計画変更があれば `raw/architect-revised-{round}.md` に残し、変更の影響を受ける担当へ同じ修正版と前回の採否を渡して再確認する。契約・設計・検証条件に影響しない表記整理だけで新たなラウンドを作らない。
 
-### Phase 3: 実装ブループリント策定
+採用すべき指摘と必要な判断が解決したら `plan.md` を確定する。計画段階には回数上限を設けないが、目的のない反復や新しい根拠のない却下案の再提案は行わない。runtime固有の上限があれば起動手順に従い、未確認の最終変更と残課題を明示する。専任なしでも計画と検証方針は確定する。
 
-設計担当1 と、2体の設定なら設計担当2 を、同じ入力で並行して起動する。互いの案や今回の他担当のレポートを読ませず、読み取り専用で独立に設計させる。
+## 7. Phase 5: 実装と検証
 
-渡す情報:
+メインは `plan.md` を再読し、実装担当1体へ目的・確定計画・必読ファイル・規約全文・設計判断・所有ファイル・既存差分・必要な検証を渡す。実装担当が編集中はメインも同じ範囲を編集しない。
 
-- タスクの目的・受入条件・合意済みの制約
-- Phase 2 の調査結果・必読ファイル・根拠
-- Phase 2 で取得した規約全文と、適用される `CLAUDE.md`・`AGENTS.md`
-- 既存配置を前提にせず、変更後の責務の所有者・配置・依存方向を先に決めること。必要な移動・分割・置き換えは変更量が大きくても含め、最小化するのは到達に不要な変更とする
-- 利用範囲が変わる責務の配置判断（移動／維持の理由）・外部契約・データフロー・全利用側の更新・実装順・回帰検証を、根拠付きの一つの推奨案として返すこと
-- コード編集・追加委託・shinaps MCP の直接呼び出しは禁止
+実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)に沿った必要な検証を行う。仕様上の不明点や計画と現物の矛盾は変更を広げずメインへ返す。通常の判断は既存の合意と規約で解決し、仕様・範囲の変更だけ人に確認する。
 
-2体の設定では、設計担当1 の案を `raw/architect-1.md`、設計担当2 の案を `raw/architect-2.md` に保存する。
+実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を返し、メインが追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
 
-- 2体の設定: 両方の結果が揃ったら設計担当1 を「設計案統合」として再開し、両案の根拠・トレードオフを比較して一つの計画を返させ、`raw/architect.md` に保存する。多数決や単純な継ぎ合わせにせず、採否と理由を残す。設計者間の反復議論は追加しない。
-- 1体の設定: 設計担当1 の案を統合済みの計画とし、`raw/architect.md` に保存する。
+メインは報告だけで完了とせず、差分と検証の根拠を確認して `implementation.md` に保存する。内容は変更と設計理由、重要な判断、計画からの変更と合意、検証結果、未実施事項。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。
 
-この計画を Phase 4 のレビュー対象にする。設計担当2 は設計上の追加確認が必要な場合だけ再開し、独立コードレビューなど他の役割へ流用しない。起動失敗や未完了を設計済みと扱わない。
+## 8. Phase 6: 実装後の確認
 
-### Phase 4: プランレビューと計画の簡素化
+同じ差分を固定し、選んだ担当を並行して起動する。実装者と独立したコードレビューは最低1体。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
 
-計画レビュー担当と計画簡素化担当（それぞれ担当1、2体の設定なら担当2 も）を、同じ計画で並行して起動する。
+| 観点 | 責任者と入力 |
+| --- | --- |
+| 設計適合性 | 設計担当1を再開。専任なしならメイン。計画・受入条件・責務・依存方向と実コードを照合 |
+| 独立コードレビュー | 新規の `shinaps-reviewer`。対象コード・全差分・利用側・規約・検証結果を読み、計画自体も誤りうるものとして正しさ・安全性・性能を確認 |
+| 規約照合 | 選んだrefine担当、専任なしならコードレビュー担当。規約全文・対象ファイル全文・変更範囲を照合 |
+| 実装の簡素化 | 選んだsimplifier、専任なしなら実装担当の自己確認に加えてコードレビュー担当。目的・契約を保って削除・統合できる内容を確認 |
 
-計画レビュー担当へ渡す情報:
+変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。staged・unstaged・untrackedを含めて対象を特定し、新規ファイルも確認する。設計担当1は自身の確認が終わるまで他担当の今回の結果を読まない。
 
-- タスクの目的・受入条件、Phase 2 の調査結果と規約全文
-- Phase 3 の計画全文（再策定時は最新案）
-- 「設計・要件・実装可能性・リスク・テスト戦略をレビューし、判定と具体的な修正案を返す。他のプランレビュー担当の結果は読まず、意見を交換しない」
+結果を `architecture-review.md` / `review-{round}-{n}.md` / `raw/refine-{round}.md` / `raw/simplify-{round}-{n}.md` に保存する。専任なしの確認は担当レポート内に責任者と範囲を残す。未確認部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。
 
-計画簡素化担当へは、今回の目的・受入条件・最新計画・規約・調査結果・成果物パスを渡し、「計画の簡素化」として、仕様・状態・操作・実装方針から減らせるものだけを検討させる。
+## 9. 指摘の検証と統合（Phase 4・6共通）
 
-全担当へ同じ計画を渡し、他担当の今回の結果は読ませない。全担当の完了まで計画を変更しない。メインは `raw/plan-review-{round}-{n}.md` / `raw/plan-simplify-{round}-{n}.md` に全文保存する（round は 1 始まり、n は担当番号）。未完了は同じ担当へ戻す。
+指摘検証は、選んだ新規verifier、専任なしならメインが行う。全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、根拠・誤認・重複・対立・未確認を区別する。元の項目を消さず出典IDを保持する。指摘なしの場合は担当の完了と確認範囲を確認し、空の検証のためだけに担当を起動しない。
 
-全結果が揃ったら、新しい verifier を起動して全結果を渡す（渡す内容は「指摘の検証」の節）。検証結果を `raw/plan-verification-{round}.md` に保存し、設計担当1 を「プラン統合」として再開する。設計担当1 は検証結果の全項目の採否・根拠と計画の修正案を返す。簡素化で機能・ユーザー体験・外部契約・受入条件が変わる提案は、変更点・失うもの・期待効果を示してメインからユーザーに確認する。承認前に計画へ採用しない。
+検証結果は `raw/plan-verification-{round}.md` または `raw/implementation-verification-{round}.md` に記録し、設計責任者へ全文を渡す。設計責任者が全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。設計担当なしならメインが統合する。複雑な指摘や対立があれば `staffing.md` に従い担当を追加する。
 
-計画を変更する場合は設計担当1 が修正版を返し、メインが `raw/architect-revised-{round}.md` に保存する。同じ計画レビュー担当と計画簡素化担当へ同じ修正版・承認済み変更・前回の採否を渡し、再確認 → 新しい verifier → 設計担当1 を繰り返す。担当を再開できなければ同じ役割の担当へ引き継ぐ。他担当の今回の未確定結果は共有しない。
+統合は多数決ではなく根拠で行い、不確実な点は確認する。仕様・受入条件・ユーザー体験の変更や許可範囲の拡大は人の合意前に採用しない。verifierを置いた場合は全件の事実確認を最初からやり直さない。
 
-計画段階には回数上限を設けない。修正不要で、採用すべき指摘と必要な判断・確認が解決したら `plan.md` を確定し、Phase 5 へ進む。回数を埋める再確認や、新しい根拠のない却下案の再提案は行わない。委託不可なら制約と独立確認の未実施を明記する。
+## 10. Phase 7〜8: 修正と終了判定
 
-計画段階では refine を行わない。設計に関わる規約はプランレビューで確認し、コードの規約照合は実装後に行う。
+設計責任者の修正指示を同じ実装担当へ返し、変更と必要な検証を `fix-log.md` に記録する。修正不要ならPhase 9へ進む。
 
-### Phase 5: 実装
+実装後の全体レビューは初回を1として最大2ラウンド。1回目の後に修正したら、同じ最新差分でPhase 6の体制に必要な増員を加えて2回目を行い、検証・統合する。2回目の後に修正したら必要なテストを行い、3回目の全体レビューは起動せず、最終差分が再レビューされていないことを報告する。増員・交代・同じ対象の計画変更で上限をリセットしない。
 
-#### A. 引き継ぎ
+重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
 
-メインが `plan.md` を再読し、実装順を進捗の管理に展開する。実装担当を 1 体起動し、以下を渡す。
+## 11. Phase 9: 完了と引き渡し
 
-- タスクの目的・受入条件、確定した `plan.md` 全文
-- Phase 2 の調査結果と必読ファイル、Phase 4 のレビュー指摘と設計判断の理由
-- Phase 2 で取得した規約全文と、適用されるプロジェクト規約
-- 作業ディレクトリ、担当するファイル・責務、既存の未コミット変更、必要な検証
-- 「同じ作業ツリーには他の作業があるため、他者の変更を戻さず、現在の内容に合わせて実装する」
+初期体制と変更理由、実際の担当・確認範囲、計画と実装後のレビュー回数、採否・修正、検証結果、未実施・未照合・未解決事項を報告する。
 
-実装担当が作業している間は、メインも同じ範囲を編集しない。
+linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、QA後のcommit工程の依頼を受け、autoはAIコミット、manualは人への提示準備を行う。Claudeのauto経路は [Claude CLI](../linear/claude-cli.md) のresultへ報告し、同じsessionのresumeで質問・修正を受ける。manual経路はBridgeで返す。Codex・Managedはそれぞれの既存返却経路を使う。
 
-#### B. 実装と確認
+単独のdevではコミットが許可されている場合だけ範囲とモードを `commit` へ渡す。許可がなければ未コミットで返し、形式的な許可確認を追加しない。PR・リリースも許可された範囲で各スキルへ渡す。単独devにLinear進行・新しいゴールを必須にしない。
 
-実装担当は確定した計画を実装し、セルフレビューの前に仕様を保つ簡素化と必要な検証を行う。メインは報告と実際の差分を確認し、完了した項目の進捗を更新する。
-
-目的・仕様を左右する不明点、計画と既存実装の不一致があれば、実装担当は変更を広げずメインへ返す。メインが既存の合意で解決できない点だけユーザーに一問ずつ確認し、決定を実装担当へ返す。計画から外れる場合は確認したうえで経緯を `implementation.md` に残す。通常の実装判断は既存規約に従って進める。
-
-実装担当の実装ミスによる検証失敗は 3 回まで自己修正する。それを超える場合はメインへ失敗の根拠と未解決点を返し、メインが「さらに修正試行 / Phase 6 のレビュー対象として差分を渡す / Phase 4 に戻って再策定する」をユーザーに確認する。
-
-#### C. 記録と検証
-
-メインが実装担当の報告を `implementation.md` に保存する。
-
-- 変更ファイルと変更内容、設計上の理由
-- 実装中の重要な判断、計画からの変更とその合意
-- 実行した検証コマンドと結果、未実施の確認
-- 残課題・規約衝突・未解決の論点
-
-必要な検証はプロジェクト規約・CI・変更の影響から決める。UIレビューはこの工程に含まれず、別の工程（linear-execute ではAgent QA）で行う。未実施のUIレビューを完了と報告しない。メインは報告だけで完了とせず、差分と検証の根拠を確認して Phase 6 へ進む。
-
-### Phase 6: 実装後の4役割を並行実行
-
-実装と必要な検証が終わった同じ差分を固定し、次の4役割を並行して起動する。実装後のレビューラウンドは初回を 1 として数え、最大 2 回までとする。計画段階のプランレビューはこの回数に含めない。
-
-起動の前に、実際の変更ファイルの言語・領域・バージョンが Phase 2 で取得した規約の範囲に入るかを確認する。外れる分だけ Phase 2 と同じ条件で補って取得し、全担当へ同じ規約全文を渡す。
-
-| 役割 | 渡す情報 |
-|---|---|
-| 設計適合性（設計担当1 を再開） | 対象ファイルと差分（staged / unstaged / untracked を含む）、最終計画・受入条件・合意済み変更、実装報告と検証結果、規約全文 |
-| 独立コードレビュー（新規） | 同上と、下の「独立コードレビューの前提」 |
-| refine（1 体） | 規約全文と関連する `AGENTS.md`・`CLAUDE.md`・docs の該当節、対象ファイル一覧、リポジトリルートの絶対パス、変更範囲の確認コマンド（`git diff HEAD -- <path>`。未追跡ファイルは全行を変更扱い）、バッチID |
-| 実装の簡素化（新規） | 目的・受入条件・最終計画・維持する契約・対象ファイルと差分・規約全文 |
-
-独立コードレビューの前提: 計画を正しいと仮定せず、実コード・利用箇所・契約から不具合を確認する。計画と形式的に異なるだけでは不具合にしない。重要度・file:line・影響・根拠・修正案、確認済みと未確認の範囲を返す。設計適合性は設計担当1 の担当なので、ここでは計画との照合ではなくコードの正しさ・安全性・性能・保守性・規約を確認する。
-
-設計担当1 は自身の設計適合性レビューを確定するまで他担当の今回の結果を読まない。先に起動した担当の完了を待ってから次を起動するのではなく、4役割を起動してから結果を待つ。同じ担当を重複起動しない。対象が大きい場合は同じ担当を再開して続きのバッチを渡し、担当数や確認範囲を黙って減らさない。
-
-全担当は読み取り専用で、今回の他担当の結果を読まず、意見を交換しない。メインと実装担当も全結果が揃うまで対象を編集しない。途中で外部の変更が入った場合は、その影響範囲を最新の同じ差分で確認し直してから統合する。
-
-各担当の確認範囲・未完了報告を確認し、未確認部分は同じ担当へ戻す。失敗・未完了を「指摘なし」として処理しない。
-
-初回は `architecture-review.md` / `review.md` / `raw/refine.md` / `raw/simplify.md`、2回目は各ファイル名に `-2` を付けて保存する。4役割の全結果が揃ったら新しい verifier へ渡し、検証結果を `raw/implementation-verification-{round}.md` に保存する。検証完了後、設計担当1 を「指摘統合」として再開し、検証結果全文・原文への参照・差分の更新・検証結果・ラウンド番号を渡す。
-
-### 指摘の検証（Phase 4・6 共通）
-
-全担当の結果が揃ったら、新しい verifier を 1 体起動する。今回のレビューをした担当を流用しない。
-
-- 生レポート全文と原文のパス、各担当の確認範囲、目的・最新計画・受入条件・合意済み変更、対象コードと差分、検証結果、規約全文、ラウンド番号を渡す。
-- verifier が各指摘の根拠を検証して出典IDを保持し、重複・誤認・対立・未確認事項を整理する。
-- メインは出典の対応と完了状況を確認し、不足を同じ verifier へ戻す。検証不能は未確認として明示し、誤認も削除しない。失敗や未完了を検証済みとして先へ渡さない。
-
-### Phase 7: 設計担当1 が統合し、実装担当が修正
-
-設計担当1 が verifier の報告から全項目の採否を決め、対立・不確実性・設計上の重要点に必要な根拠を確認する。全件の事実確認を最初から繰り返さない。全指摘の採否と理由、採用した修正の対象・責務・具体的な変更・維持する契約・必要な検証を、一つの修正指示として返す。メインはそのまま記録し、仕様・受入条件の変更や未許可の範囲拡大が必要な点だけユーザーに確認する。通常の設計・修正判断をメインでやり直さない。
-
-修正不要なら Phase 9 へ進む。修正があれば、メインが同じ実装担当を再開し、設計担当1 の修正指示・確定した計画・現在の差分・規約・検証条件を渡す。再開できなければ実装履歴と採否を同じ役割の新しい担当へ引き継ぐ。設計担当1 は次のレビューに備えて継続し、コードを編集したり、実装担当を追加で起動したりしない。
-
-実装担当が修正と必要な検証を行い、変更・検証結果・未解決点を返す。メインは設計担当1 の採否と修正結果を `fix-log.md` に記録する。委託不可の場合はメインが同じ観点で対応し、独立した確認とは報告しない。
-
-### Phase 8: 最大2ラウンドで終了する
-
-- **1回目のレビュー後に修正した場合**: 修正後の同じ差分について、Phase 6 の4役割を2回目として並行実行する。最新の計画、前回の指摘と採否、修正内容、検証結果を渡す。全結果を新しい verifier で検証してから設計担当1 に渡し、Phase 7 で必要な最終修正を実施する。
-- **2回目のレビュー後に修正した場合**: 実装担当が最終修正と必要なテストを行ったら Phase 9 へ進む。3回目の実装後レビューは起動しない。
-- **修正不要の場合**: 回数を埋めるために再実行せず Phase 9 へ進む。
-
-最大2回は実装後の全体レビューに対する上限であり、担当の再開・交代や計画の変更でリセットしない。検証失敗・重大な未解決事項・未完了の担当が残る場合も追加ラウンドで無期限に続けず、その状態を明記してユーザーへ返す。未完了の確認を完了済みのラウンドと偽らない。
-
-### Phase 9: 完了と必要な引き継ぎ
-
-実施したレビュー回数、設計担当1 の判断と修正内容、検証結果、未解決事項を報告する。2回目の後に修正した場合は、その最終差分が再レビューされていないことを明記する。必須検証の失敗や重大な未解決事項があれば作業終了と品質上の完了を区別し、完了済みとは報告しない。
-
-Linearの開発進行から受けた実装・修正では、未コミットの差分と結果を進行役へ返す。dev完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)の継続許可と[担当と工程](../linear/workflow.md)に従い、QA後のコミット依頼を受ける。
-
-単独のdev依頼では、コミットが許可されていれば、その範囲と通常／自律モードを `commit` へ引き継ぐ。許可がなければ未コミットで結果を返し、毎回コミット許可を要求しない。PR・リリースも許可された範囲で `create-pr`・`release` へ渡す。単独利用にLinear進行や新しいゴールを必須にしない。
-
-## 5. 成果物
-
-```text
-.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/
-├── plan.md                    ← Phase 4 の全結果を検証・統合した最終 plan
-├── raw/
-│   ├── explorer.md            ← または explorer-1.md, explorer-2.md ...（引き継ぎ時の補完は explorer-supplement.md）
-│   ├── architect-1.md         ← 設計担当1 の独立設計案（2体の設定のみ）
-│   ├── architect-2.md         ← 設計担当2 の独立設計案（2体の設定のみ）
-│   ├── architect.md           ← 統合した計画（1体の設定では設計担当1 の案）
-│   ├── plan-review-{round}-{n}.md   ← 計画レビュー担当 n の結果
-│   ├── plan-simplify-{round}-{n}.md ← 計画簡素化担当 n の結果
-│   ├── plan-verification-{round}.md ← 計画指摘の検証結果
-│   ├── implementation-verification-{round}.md ← 実装指摘の検証結果
-│   ├── refine.md              ← Phase 6 の規約照合の生レポート（2 回目は refine-2.md）
-│   ├── simplify.md            ← Phase 6 の実装の簡素化の生レポート（2 回目は simplify-2.md）
-│   └── architect-revised-{round}.md  ← 計画の修正版（round は 1 始まり）
-├── implementation.md          ← 実装ログ・変更ファイル一覧・動作確認結果
-├── architecture-review.md     ← 設計担当1 の設計適合性レビュー
-├── architecture-review-{n}.md ← 修正後の設計適合性レビュー（n は 2 始まり）
-├── review.md                  ← 独立コードレビューの生レポート
-├── review-{n}.md              ← 修正後の再レビュー（n は 2 始まり）
-└── fix-log.md                 ← 修正ループの履歴（修正があった場合のみ）
-```
-
-全担当の応答は全文を参照できる状態で保存する。担当は結果を文字列で返し、進行管理の成果物はメインが保存する。実装担当は担当範囲のコード・テスト・必要なドキュメントだけを編集する。
-
-## 6. 他スキルからの呼び出し
-
-explore・spec・review・debug などは、生成した成果物のパスを入口の引数に直接渡す。専用の引き継ぎファイルは作らない。受け取った成果物は Phase 1・2 のとおりに扱う。どの成果物を渡すかと、既定で使う入口は、元のスキルの引き継ぎの記述に従う。
+explore・spec・review・debugからの成果物は入口の引数で直接渡す。専用の引き継ぎファイルは作らず、Phase 1・2で既存成果物を再利用する。

package/plugins/shinaps-codex/references/human-review.md

@@ -0,0 +1,28 @@
+# 人レビューの差分提示
+
+manualで人がレビュー・修正・commitする場合に使う。review_flow・操作許可は、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+
+Claude経路のmanualはWebStormでレビューする。Plasmaを必須にしない。以下のCodex UI手順はCodex経路に適用する。
+
+## 対象の準備
+
+レビュー対象のcheckoutの絶対パス、ブランチ、比較元のcommit、対象ファイルと完全な差分、検証結果を確定する。未追跡ファイルも対象に含める。stageは許可された範囲だけで行い、無関係な差分や既存のステージ境界を変更しない。対象差分と比較元は作業記録へ残し、後で承認対象と照合できるようにする。
+
+## CodexではPlasmaで開く
+
+Codex実装経路で人への窓口がCodexの場合は、レビューを依頼する会話でPlasmaを開く。人への窓口がClaudeの場合は既存の差分提示方法を使い、Plasmaのためだけに別のCodexタスクを作らない。
+
+1. 利用可能なPlasmaの`open_workbench`ツールと現在の入力仕様を確認する。ファイルを開く`route`が使える場合は、対象checkoutの絶対パスとレビュー対象のファイルを指定する。現在の形式は`/open?project=ABSOLUTE_PATH&file=RELATIVE_PATH&line=START&endLine=END`で、各値をURLエンコードする。存在するファイルを使い、適切なファイルがない場合はプロジェクト選択画面から対象checkoutを選ぶ。
+2. ファイルを開くことと差分を表示することを区別する。ファイル用routeに差分モードの未定義パラメーターを足さない。利用可能なUI操作ツールでPlasmaのGit画面を確認し、レビュー対象に合う比較を選ぶ。UI操作が使えない場合は、対象プロジェクト・比較方法・ファイル一覧を示して利用者に選択を依頼する。
+3. 表示中のcheckout・比較元・対象範囲をGitで確定した差分と照合する。ステージ済みの単位なら`git diff --cached`を基準にする。作業ツリー全体や別ブランチの差分を、その単位の差分として提示しない。対象全体を表示できない場合は、未表示の範囲を明示し、完全な差分を確認できる方法を利用者と決める。
+4. 会話に変更の目的、確認してほしい点、検証結果、対象単位を示し、レビュー・必要な修正・コミット完了を依頼する。Linear進行ではIssueも示す。Plasma内の注釈は指摘として扱い、画面を開いたことや操作の終了を承認とみなさない。
+
+Plasmaが未導入・起動失敗の場合は、その状態を伝え、Codexの差分表示など利用者が選んだ方法で同じ対象を提示する。無断でインストールや設定変更を行わず、表示できていないレビューを完了扱いにしない。
+
+## 人のレビュー・コミット完了後の照合
+
+利用者の明示的なレビュー・修正・コミット完了通知を、対象単位と対応付けて記録する。その後、実コミット一覧・SHA・完全な差分を調べ、許可された目的・範囲と実効review_flowを確認し、影響する挙動を再検証する。Gitにcommitがあるだけでは完了としない。
+
+本人が明示確認した正当な修正は確定単位と全体期待差分に反映する。元の予定差分を保持し、完了通知・修正理由・確定差分・実コミットの対応を記録する。その修正だけを理由に再提示・再承認を要求しない。目的や範囲が不明、対象外変更が混入、適用flowが未解決の場合は人へ確認し、次工程を止める。最終照合は確定済みの期待差分を使い、元の差分との機械的な一致を要求しない。
+
+stashの復元では人の修正を保持し、古い対象パッチで上書きしない。具体的な単位照合・復元は `commit` に従う。表示UIを開くことはstage・commit・pushの許可を追加しない。

package/plugins/shinaps-codex/references/linear/claude-cli.md

@@ -0,0 +1,37 @@
+# ローカルClaude CLIによる実装
+
+`dev-claude` の基本 `review_flow: auto` は、Codexが作業先でローカル `claude -p` を起動する。manualはWebStormのClaudeとBridgeを使う。初回実装前に基本flow、正確なcheckout・branch・HEAD・既存差分、経路許可（autoは `claude_cli`、manualは `bridge_request` または今回の明示依頼）を確定する。manualのBridge不足でCLIへfallbackしない。CodexとManagedの既存経路は変更しない。
+
+パス例外はコミット単位のreview_flowだけを変え、実装経路を途中で切り替えない。CLI経路でmanual単位になった場合は、CLIの実行終了を確認して同じcheckoutをWebStormで人へ提示する。Codexが人のレビュー・修正・commit完了を受け取り、単位差分・SHAと照合する。その後の実装依頼は変更後のHEADと差分を添えて同じCLIセッションをresumeする。Bridge経路のauto単位も同じBridgeセッションでQA後にcommitを依頼する。
+
+## 起動と観測
+
+通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。model・effort・plugin構成を指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
+
+依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。必要なSkill/Agent・Read/Edit・検証コマンド等の `--allowedTools` は依頼の許可と範囲から個別に追加する。たとえばcommit段階の `Bash(git add <対象パス>)` と `Bash(git commit -m <確定メッセージ>)` は実際の引数に限定し、初回実装にはcommit権限を渡さない。広範な既存allow設定がある場合も対象外操作の許可とは扱わない。
+
+```sh
+claude -p --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
+```
+
+途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は同じprocessを短い待機（最大60秒）で観測し、終了コードを取得する。新しいCLIを並行起動せず、進捗を会話へ返す。stream-jsonはイベントを読み、最終resultがない途中出力を完了と扱わない。
+
+jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、stream-jsonではsession初期化と最終resultを照合する。session_idをIssueとcwdに紐づけてローカル作業記録に保持する。終了コード0だけで成功にせず、エラー・拒否・質問・成果を確認して実差分と検証結果を独立QAする。ID欠落、異常終了、出力欠落なら停止してprocessと記録を調べる。結果不明のまま新規セッションを起動したり同じ依頼を再送したりしない。
+
+## 依頼・質問・修正・コミット
+
+promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、初期体制、exact cwd・branch・HEAD・既存差分、許可・禁止操作、規約と参照先、返却条件を含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。CLIからBridge送信や人の対話入力を待たせない。
+
+回答・QA修正・QA後のautoコミット依頼は、元のprocess終了後、記録済みの正確なIDで同じセッションをresumeする。`--continue` で別セッションを推測しない。
+
+```sh
+claude -p --resume '<recorded-session-id>' --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
+```
+
+resumeにも同じcwdと許可境界を指定し、外部で変化したHEAD・差分を渡す。commit依頼にはLocal Agent QA結果、独立レビュー、単位案と全差分、実効review_flowと合意根拠を含める。完了報告は変更範囲、検証、未解決事項、単位案、commitした場合はSHA・単位照合・残差分・stash復元結果を含める。復帰不能時は理由を報告し、黙って別sessionに作り直さない。
+
+## 操作権限
+
+`review_flow: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動では `--permission-mode dontAsk` を明示し、既存設定がbypassでも継承しない。model・effort・pluginsは保持し、操作許可は既存の個別allow設定と今回の範囲に限定する。`--permission-prompts none` は対話できないpromptを拒否として返すためであり、許可を付与しない。permission_denialsがあれば操作と必要な権限を報告し、既存の明示許可が対象を満たすか確認する。満たす場合だけ必要なSkill/Agentや対象を限定した `--allowedTools` を明示し、同じsessionへ明示的に再依頼する。新しい権限が必要ならCodexが人へ確認する。`--allowedTools` を使う場合も対象・操作に限定し、無条件の `Bash(*)`、bypassPermissions、dangerously-skip-permissionsを使わない。拒否を隠すsilent retryをしない。会話上の許可はCLIの権限チェックを消さない。
+
+CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応なら状態を報告して停止し、権限回避へ切り替えない。

package/plugins/shinaps-codex/references/linear/codex-task.md

@@ -1,21 +1,21 @@
 # Codexの実装タスク
 
-`implementation_skill` が `dev-codex` または `dev-codex-ultra` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
+`implementation_skill` が `dev-codex` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
 
 ## 作成と再利用
 
 - 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
 - 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で所属先を確認し、`create_thread` で新しいローカルCodexタスクを一つ作る。所属プロジェクトと実際の作業ディレクトリは一致を必須にしない。作業先が登録一覧にない場合も、利用者が指定した所属先を使い、対象checkoutの絶対パスを依頼に明記できる。実装担当は変更前に、指定先のGitルート・ブランチ・差分と適用される規約を確認し、以後の操作をその作業先で行う。指定先にアクセスできない場合は、別checkoutで代用せず必要な準備を報告する。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。
 - 返された確定済みthreadId・hostIdとIssue・checkout・branchをローカルの作業記録で対応づける。準備中のclientThreadIdを送信先にしない。作成結果が不明なときは一覧と状態を確認してから再試行する。
-- 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデル・役割構成は指定した入口に従う。
+- 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデルは起動手順に従い、役割構成は初期体制と途中の判断に従う。
 
 ## 実装依頼に渡すもの
 
-Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、設定の保存方式・正本と必要な補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
+Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、初期体制（役割別人数・根拠・専任なしの責任者・必須検証）、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、設定の保存方式・正本と必要な補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
 
 実装担当には次を明記する。
 
-> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果を伴う依頼を受け、必要な許可を確認して行う。単位案・判定・依頼・照合・報告は [共通手順](workflow.md#単位案からコミット完了まで)に従う。他の人・AIの差分を戻さない。
+> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。初期体制を現物と照合し、途中の新しい根拠で必要な担当を追加して進行役へ報告する。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果を伴う依頼を受け、必要な許可を確認して行う。単位案・判定・依頼・照合・報告は [共通手順](workflow.md#単位案からコミット完了まで)に従う。他の人・AIの差分を戻さない。
 
 ## 待機・QA・修正