@shinaps/skills 0.35.1 → 0.35.3

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/references/workflow.md

@@ -11,11 +11,12 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
 | Phase 3・4・6・7 | `shinaps-architect` | 担当1は設計・統合・設計適合性を継続。担当2以降は独立設計と追加確認のみ |
 | Phase 4 | `shinaps-plan-reviewer` | 修正版の再確認も同じ担当 |
 | Phase 4・6 | `shinaps-simplifier` | 計画の再確認は継続。実装の簡素化は別担当 |
-| Phase 5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す |
+| Phase 3・5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す。設計担当がいなければ計画と指摘の統合も担う |
 | Phase 6 | `shinaps-reviewer` | 実装担当とは別。レビューラウンドごとに新規。規約照合も担う |
 
 - 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版を依頼に渡す。実装担当にはファイルの所有範囲を明記する。
 - 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませない。対象を編集中にレビューせず、全結果が揃うまで lead と実装担当も対象を変えない。
+- lead は体制と工程の調整、委任・待機・引き渡し、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。実装・修正、指摘の技術的検証と採否、設計適合性の実コード照合、既存の証拠がある検証の再実行は引き取らない。継続のターンで来る質問・修正も同じで、修正は同じ実装担当へ返す。
 - 起動失敗・空回答・未確認範囲を「指摘なし」にしない。
 
 ## Phase 1: タスクと初期体制
@@ -24,11 +25,11 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
 
 ## Phase 2: 規約と必要な探索
 
-規約の範囲は [SKILL.md の規約](../SKILL.md#規約)に従う。lead が読んで以降の担当へ全文を渡す。lead（設計担当がいれば設計担当も）が関連ファイルを確認し、実装担当は実装の詳細を調べる。探索の専任は委任しない。
+規約の範囲は [SKILL.md の規約](../SKILL.md#規約)に従う。lead が読んで以降の担当へ全文を渡す。探索は[実装体制の判断](staffing.md)の割り当てに従い、専任は委任しない。
 
 ## Phase 3: 設計と計画
 
-設計責任者は設計担当1、専任なしなら lead とする。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書く。設計担当が複数なら同じ入力で独立に検討させ、担当1が根拠で一つの案へ統合する。
+設計責任者は設計担当1、専任なしなら実装担当とする。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書く。設計担当が複数なら同じ入力で独立に検討させ、担当1が根拠で一つの案へ統合する。
 
 ## Phase 4: 計画の確認
 
@@ -36,15 +37,15 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
 
 ## Phase 5: 実装と検証
 
-実装担当1体へ確定計画・必読ファイル・規約全文・所有ファイル・必要な検証を渡す。実装担当は計画を実装し、簡素化・セルフレビュー・必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。lead は報告だけで完了とせず、差分と検証の根拠を確認する。
+実装担当1体へ確定計画・必読ファイル・規約全文・所有ファイル・必要な検証を渡す。実装担当は計画を実装し、簡素化・セルフレビュー・必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。lead は報告の対象版・範囲・完了状態と、検証の証拠の所在・終了コードを照合する。全文の再レビューや同じ版の検証の再実行はせず、不足や矛盾は当該担当へ戻す。
 
 ## Phase 6: 実装後の確認
 
-同じ差分を固定し、選んだ担当を並行して委任する。実装者と独立したコードレビューは最低1体。設計適合性は設計担当1（専任なしなら lead）、規約照合はコードレビュー担当、実装の簡素化は選んだ simplifier（専任なしなら実装担当とコードレビュー担当）が確認する。staged・unstaged・untracked を含めて対象を特定する。
+同じ差分を固定し、選んだ担当を並行して委任する。実装者と独立したコードレビューは最低1体。設計適合性は設計担当1（専任なしならコードレビュー担当）、規約照合はコードレビュー担当、実装の簡素化は選んだ simplifier（専任なしなら実装担当とコードレビュー担当）が確認する。staged・unstaged・untracked を含めて対象を特定する。
 
 ## 指摘の検証と統合（Phase 4・6）
 
-設計責任者（設計担当1、専任なしなら lead）が全指摘の根拠・誤認・重複・対立・未確認を区別し、全項目の採否と理由、必要な修正と検証をまとめる。再現・検証が必要なら実装担当へ依頼する。仕様・受入条件の変更や許可範囲の拡大は利用者の合意前に採用しない。
+設計責任者（設計担当1、専任なしなら実装担当）が全指摘の根拠・誤認・重複・対立・未確認を区別し、全項目の採否と理由、必要な修正と検証をまとめる。自分の成果物への指摘も根拠で採否を決め、その確認を独立検証とは報告しない。事実の食い違いや根拠不足で判断できない指摘だけ指摘元に確認する。指摘元への確認は同じ担当の継続で行い、レビューのラウンドに数えない。再現・検証が必要なら実装担当へ依頼する。仕様・受入条件の変更や許可範囲の拡大は利用者の合意前に採用しない。
 
 ## Phase 7〜8: 修正と終了判定
 

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

@@ -12,20 +12,22 @@
 
 | 役割 | 専任を置く判断と人数 | 専任を置かない場合 |
 | --- | --- | --- |
-| 探索 | メインの初期確認では根拠が足りない領域に配置。独立に調べられる領域なら分担 | メインが関連コードと既存調査を確認 |
-| 設計 | 責務・依存・方式の判断が必要なら配置。競合する案や重大な見落としを独立に比較する必要があれば複数 | メインが短い計画と検証方針を確定 |
-| 計画レビュー | 実装前に検証すべき設計リスクがあれば配置。異なる観点の独立確認が必要なら複数 | メインが要件・実装可能性・検証方針を確認 |
+| 探索 | メインの初期確認では根拠が足りない領域に配置。独立に調べられる領域なら分担 | 設計担当1、いなければ実装担当が計画・実装に必要な範囲を調べる |
+| 設計 | 責務・依存・方式の判断が必要なら配置。競合する案や重大な見落としを独立に比較する必要があれば複数 | 実装担当が短い技術計画と検証方針を作り、設計責任者を兼ねる |
+| 計画レビュー | 実装前に検証すべき設計リスクがあれば配置。異なる観点の独立確認が必要なら複数 | 計画を作った担当が要件カバーと実現可能性の根拠を計画に書き、独立コードレビューが計画自体も誤りうるものとして確かめる |
 | 計画／実装の簡素化 | 状態・抽象化・変更範囲の複雑さに専門の検討が必要なら配置。計画と実装で別々に判断 | 計画は設計責任者、実装は実装担当とコードレビュー担当が確認 |
-| 実装 | 1体。修正も同じ担当に戻す | 委託不可の場合だけ、既存の許可・規約に従ってメインが実装 |
+| 実装 | 1体。修正も同じ担当に戻す | 委託が許可されない、または起動できない場合もメインは代行しない。再開・交代し、できなければ未完了として必要な判断を求める（[工程](workflow.md)の§1・§2） |
 | 独立コードレビュー | 最低1体。重要な契約や複数領域の見落としを独立に確認する必要があれば追加 | 委託不可・起動不能なら独立レビュー未完了。自己レビューで代替完了にしない |
 | refine | 規約の量・領域の広さから別担当での照合が有効なら配置 | コードレビュー担当に規約全文と照合責務を渡す。サービス規約未取得なら未照合と明示 |
-| 指摘検証（verifier） | 指摘が多い、相互に矛盾する、根拠の確認が難しい場合に配置。計画と実装の各ラウンドで判断 | メインが全指摘の根拠・出典・未確認事項を確認 |
+| 指摘検証（verifier） | 指摘が多い、相互に矛盾する、根拠の確認が難しい場合に配置。計画と実装の各ラウンドで判断 | 設計担当1、いなければ実装担当が全指摘の根拠・出典・未確認事項を整理して採否を決める（採否は[工程](workflow.md)の「指摘の検証と統合」に従う） |
 
-明確で局所的な変更なら、メインが計画し、実装1体・独立コードレビュー1体で進められる。設計が難しければ設計担当や計画レビューを追加し、設計案の独立比較が必要なら設計担当を複数にする。コードのリスクが高い場合はコードレビューを増やす。どれか一つを増やすために全役割を複数にしない。
+専任を置かない責務はメインへ戻さず、成果物を作った担当から独立している必要があるかで既存の担当へ割り当てる。
+
+明確で局所的な変更なら、実装担当が短い計画を作り、実装1体・独立コードレビュー1体で進められる。設計が難しければ設計担当や計画レビューを追加し、設計案の独立比較が必要なら設計担当を複数にする。コードのリスクが高い場合はコードレビューを増やす。どれか一つを増やすために全役割を複数にしない。
 
 ## 体制の記録と引き渡し
 
-起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を短く記録する。設計担当がいれば担当1が設計・統合を継続し、いなければdevのメインが責任を持つ。独立レビュー担当は実装担当と別のコンテキストにする。
+起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を短く記録する。設計担当がいれば担当1が設計・統合を継続し、いなければ実装担当が設計責任者になる。独立レビュー担当は実装担当と別のコンテキストにする。
 
 linear-executeから受けた作業では、メインが決めた初期体制と根拠を進行役へ報告する。通常の体制判断で人の承認を待たない。材料が欠けていれば既定の人数へ戻さず、初期確認して体制を決める。ローカル記録は `.shinaps/work/` 以下へ保存する。別セッションへは本文も渡し、相手から見えないパスだけに依存しない。
 
@@ -34,7 +36,7 @@ linear-executeから受けた作業では、メインが決めた初期体制と
 初期体制は上限ではない。設計上の新しい不確実性、影響領域の追加、重要な契約への影響、検証失敗、指摘の対立が判明した時点でdevのメインが必要な役割・人数・確認範囲を増やす。担当からの提案はメインが判断する。理由と体制の変更を記録し、linear-executeでは進行役へ報告する。初期判断や報告のために作業を止める必要はないが、追加担当の確認が必要な工程は結果が揃うまで完了にしない。
 
 - 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。
-- 設計担当を途中で置く場合は担当1を統合責任者として引き継ぎ、メインの旧計画も検討対象にする。既存担当の仕事を理由なく最初から繰り返さない。
+- 設計担当を途中で置く場合は担当1を統合責任者として引き継ぎ、実装担当の旧計画も検討対象にする。既存担当の仕事を理由なく最初から繰り返さない。
 - 増員で既存の未完了・不利な指摘を消さない。同じ対象への増員・交代でレビューラウンドの上限をリセットしない。枠不足は順番に起動し、人数を黙って減らさない。
 - 体制判断は委託・モデル変更・操作・予算の許可を作らない。既存の許可と予算内の増員は再承認不要。仕様・範囲・明示された人数制限・許可・予算を変える必要がある場合だけ、人へ理由と選択肢を一問で確認する。
 

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

@@ -6,7 +6,7 @@ Claude Codeのdev（`dev-claude`）の工程。役割・人数は[実装体制
 
 適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから作業条件を読み、依頼・範囲・操作許可を引き継ぐ。仕様を左右する不足だけ一問ずつ確認する。新しい恒久方針は了承を得て保存する。利用できないツールを仮定しない。
 
-委託・worktreeは許可された場合だけ使う。委託できない場合はメインが可能な調査・実装・自己確認を行ってよいが、独立レビューを実施したとは報告せず、未完了として返す。サービス規約を取得できない工程は未照合と明示する。
+devの依頼は登録済みのdev役割への委託（Agentでの起動）を含む。委託しないのは、利用者が委託を明示的に禁止した場合と、Linear進行で[`dev_delegation`](../linear/configuration.md)がない場合だけ。worktreeは許可された場合だけ使う。委託が許可されない、または担当を起動・再開できず§2の交代もできない場合も、メインはその担当の作業（実装・修正・計画・検証・統合）を代わりに行わない。その工程を未完了として返し、必要な判断（許可・準備・体制）を求める。サービス規約を取得できない工程は未照合と明示する。
 
 作業記録は `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` へ保存し、[共通手順](../work-records.md)に従って保全する。担当の応答は全文を参照できる形で保存し、対象版・役割・担当ID・確認範囲・完了状態を対応づける。選ばなかった専任の空レポートは作らない。短い作業は短い計画・記録にする。
 
@@ -21,14 +21,15 @@ Claude Codeのdev（`dev-claude`）の工程。役割・人数は[実装体制
 | Phase 4 | `shinaps-plan-reviewer` | 修正版の再確認も同じ担当 |
 | Phase 4・6 | `shinaps-simplifier` | 計画の再確認は継続。実装の簡素化は別担当 |
 | Phase 4・6 | `shinaps-review-verifier` | 必要なラウンドごとに新規。今回の指摘を出した担当を流用しない |
-| Phase 5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す |
+| Phase 3・5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す。設計担当がいなければ計画と指摘の統合も担う |
 | Phase 6 | `shinaps-reviewer` | 実装担当とは別。レビューラウンドごとに新規 |
 | Phase 6 | `shinaps-refine-agent` | 専任を置く場合に起動。同ラウンドのバッチは継続 |
 
-- 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合は同じ役割へ確認済み・未確認・最新の文脈を引き継いで交代を記録する。
+- 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合は同じ役割へ既存の成果・最新の差分・未解決点を引き継いで交代を記録する。
 - 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・成果物のパスを依頼に渡す。実装担当にはファイルの所有範囲を明記し、他者の変更を戻さず現物に合わせるよう伝える。他の担当は読み取り専用で、自分でエージェントを起動しない。
 - 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず意見交換させない。継続担当には前回の確定済み指摘と採否を渡してよい。対象を編集中にレビューせず、全結果が揃うまでメインと実装担当も対象を変えない。外部変更が入れば影響範囲を同じ最新の版で確認し直す。
-- メインは起動・待機・全文保存・引き渡しを行い、担当に割り当てた判断を先回りして選別しない。専任を置かなかった責務だけは、体制に記録した担当が行う。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
+- メインは依頼の確認、体制と工程の調整、担当の起動・待機・全文保存・引き渡し、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。実装・修正、指摘の技術的検証と採否、設計適合性の実コード照合、既存の証拠がある検証の再実行は引き取らず、担当に割り当てた判断を先回りして選別しない。専任を置かなかった責務は、体制に記録した担当が行う。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
+- devの完了後に同じ会話・sessionで来る依頼（対話の次のターン、resume、Bridge、人の相談、QA差し戻し）も同じdevの分担で扱う。メインは確認済み結果の説明・質問の整理・取り次ぎだけを行い、調査・技術的検証・編集は担当へ渡す。修正は同じ実装担当を再開し、できなければ上の交代に従う。初回devの完了・短い追加依頼・通常の会話への復帰を例外にしない。修正の影響に応じて必要なレビュー・QAへ戻り、入力が一致する検証は[テスト方針](../testing.md)に従って証拠を再利用する。
 
 ## 3. Phase 1: タスクと初期体制の確定
 
@@ -42,15 +43,15 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 - `list_search_facets` でfacetを確認し、`search_rules` に現在のrepoOwner・repoNameと対象に関連するfacetを渡す。manifest・lockfileなどで確認できた対象バージョンだけ `projectVersions` に指定する。確認できない場合は共通ルールのみの照合と記録する。
 - プロジェクト規約と関連docs、引き継いだ調査の必読ファイルを確認する。時間に依存する根拠が判断に影響する場合は公式情報で確かめる。
-- 十分な根拠があれば探索担当を追加しない。不足する領域だけメインまたは体制で選んだ探索担当が補う。追加担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
+- 十分な根拠があれば探索担当を追加しない。不足する領域だけ体制で選んだ探索担当（専任なしなら `staffing.md` の責任者）が補う。追加担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
 
 新しい不確実性・影響範囲が見つかったら、設計前に体制を更新する。
 
 ## 5. Phase 3: 設計と計画
 
-設計責任者は設計担当1、専任なしならメインとする。目的・受入条件・調査結果・規約・既存配置を踏まえ、変更後の責務・依存方向・利用側・外部契約・実装順・検証を決める。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書き、個々の置換や文言は実装担当が現物に合わせて決める。構造変更が必要なら含め、単に変更量が少ない案を優先しない。不要な変更と仮想的な汎用化は避ける。
+設計責任者は設計担当1、専任なしなら実装担当とする。目的・受入条件・調査結果・規約・既存配置を踏まえ、変更後の責務・依存方向・利用側・外部契約・実装順・検証を決める。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書き、個々の置換や文言は実装担当が現物に合わせて決める。構造変更が必要なら含め、単に変更量が少ない案を優先しない。不要な変更と仮想的な汎用化は避ける。
 
-設計担当が複数なら同じ入力で独立に検討させ、全結果の後に担当1が根拠とトレードオフを比較して一つの案へ統合する。多数決にしない。各結果は `raw/architect-{n}.md`、統合案は `raw/architect.md` に保存する。専任なしならメインが短い案を作り、未実施の独立設計を行ったとは報告しない。
+設計担当が複数なら同じ入力で独立に検討させ、全結果の後に担当1が根拠とトレードオフを比較して一つの案へ統合する。多数決にしない。各結果は `raw/architect-{n}.md`、統合案は `raw/architect.md` に保存する。専任なしなら実装担当が短い案を作り、未実施の独立設計を行ったとは報告しない。計画を確認する担当がいなければ実装担当はそのまま実装し、メインは報告の冒頭の計画を `plan.md` に保存する。
 
 ## 6. Phase 4: 計画の確認
 
@@ -64,11 +65,11 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 メインは `plan.md` を再読し、実装担当1体へ目的・確定計画・必読ファイル・規約全文・設計判断・所有ファイル・既存差分・必要な検証を渡す。実装担当が編集中はメインも同じ範囲を編集しない。
 
-実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)に沿った必要な検証を行う。仕様上の不明点や計画と現物の矛盾は変更を広げずメインへ返す。通常の判断は既存の合意と規約で解決し、仕様・範囲の変更だけ人に確認する。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
+実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)に沿った必要な検証を行う。仕様上の不明点や計画と現物の矛盾は変更を広げず報告する。技術的な矛盾は、設計責任者が実装担当自身なら自分で解決して報告に含め、そうでなければメインが設計責任者へ渡す。仕様・範囲の変更はメインが人に確認する。通常の判断は既存の合意と規約で解決する。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
 
 実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を返し、メインが追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
 
-メインは報告だけで完了とせず、差分と検証の根拠を確認して `implementation.md` に保存する。内容は変更と設計理由、重要な判断、計画からの変更と合意、検証結果、未実施事項。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。
+メインは報告の対象版・範囲・完了状態と、検証の証拠の所在・終了コードを照合して `implementation.md` に保存する。全文の再レビューや同じ版の検証の再実行はせず、不足や矛盾は当該担当へ戻す。内容は変更と設計理由、重要な判断、計画からの変更と合意、検証結果、未実施事項。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。
 
 ## 8. Phase 6: 実装後の確認
 
@@ -76,7 +77,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 | 観点 | 責任者と入力 |
 | --- | --- |
-| 設計適合性 | 設計担当1を再開。専任なしならメイン。計画・受入条件・責務・依存方向と実コードを照合 |
+| 設計適合性 | 設計担当1を再開。専任なしなら独立コードレビュー担当。計画・受入条件・責務・依存方向と実コードを照合 |
 | 独立コードレビュー | 新規の `shinaps-reviewer`。対象コード・全差分・利用側・規約・検証結果を読み、計画自体も誤りうるものとして正しさ・安全性・性能を確認 |
 | 規約照合 | 選んだrefine担当、専任なしならコードレビュー担当。規約全文・対象ファイル全文・変更範囲を照合 |
 | 実装の簡素化 | 選んだsimplifier、専任なしなら実装担当の自己確認に加えてコードレビュー担当。目的・契約を保って削除・統合できる内容を確認 |
@@ -87,17 +88,17 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 ## 9. 指摘の検証と統合（Phase 4・6共通）
 
-指摘検証は、選んだ新規verifier、専任なしならメインが行う。全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、根拠・誤認・重複・対立・未確認を区別する。元の項目を消さず出典IDを保持する。指摘なしの場合は担当の完了と確認範囲を確認し、空の検証のためだけに担当を起動しない。
+指摘検証は、選んだ新規verifier、専任なしなら設計責任者が行う。全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、根拠・誤認・重複・対立・未確認を区別する。元の項目を消さず出典IDを保持する。指摘なしの場合は担当の完了と確認範囲を確認し、空の検証のためだけに担当を起動しない。
 
-検証結果は `raw/plan-verification-{round}.md` または `raw/implementation-verification-{round}.md` に記録し、設計責任者へ全文を渡す。設計責任者が全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。設計担当なしならメインが統合する。複雑な指摘や対立があれば `staffing.md` に従い担当を追加する。
+検証結果は `raw/plan-verification-{round}.md` または `raw/implementation-verification-{round}.md` に記録し、設計責任者へ全文を渡す。設計責任者が全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。設計担当なしなら実装担当が統合する。複雑な指摘や対立があれば `staffing.md` に従い担当を追加する。
 
-統合は多数決ではなく根拠で行い、不確実な点は確認する。仕様・受入条件・ユーザー体験の変更や許可範囲の拡大は人の合意前に採用しない。verifierを置いた場合は全件の事実確認を最初からやり直さない。
+統合は多数決ではなく根拠で行う。設計責任者は自分の成果物への指摘も根拠で採否を決めて理由を記録し、その確認を独立検証とは報告しない。事実の食い違いや根拠不足で判断できない指摘だけ指摘元に確認し、Infoや提案を採らないことに同意を求めない。指摘元への確認は同じ担当の継続で行い、レビューのラウンドに数えない。仕様・受入条件・ユーザー体験の変更や許可範囲の拡大は人の合意前に採用しない。verifierを置いた場合は全件の事実確認を最初からやり直さない。
 
 ## 10. Phase 7〜8: 修正と終了判定
 
 設計責任者の修正指示を同じ実装担当へ返し、変更と必要な検証を `fix-log.md` に記録する。修正不要ならPhase 9へ進む。
 
-実装後の全体レビューは初回を1として最大2ラウンド。1回目の後に修正したら、同じ最新差分でPhase 6の体制に必要な増員を加えて2回目を行い、検証・統合する。2回目は修正箇所と影響範囲を中心に確認し、影響範囲を確定できなければ確認範囲を広げる。範囲を絞った場合も必須検証は全体で実行し、完了前にメインが全差分を計画・受入条件と照合する。2回目の後に修正したら必要なテストを行い、3回目の全体レビューは起動せず、最終差分が再レビューされていないことを報告する。増員・交代・同じ対象の計画変更で上限をリセットしない。
+実装後の全体レビューは初回を1として最大2ラウンド。1回目の後に修正したら、同じ最新差分でPhase 6の体制に必要な増員を加えて2回目を行い、検証・統合する。2回目は修正箇所と影響範囲を中心に確認し、影響範囲を確定できなければ確認範囲を広げる。範囲を絞った場合も必須検証は全体で実行し、完了前に設計担当1（いなければ2回目のレビュー担当）が全差分を計画・受入条件と照合する。2回目の後に修正したら必要なテストを行い、3回目の全体レビューは起動せず、最終差分が再レビューされていないことを報告する。増員・交代・同じ対象の計画変更で上限をリセットしない。
 
 重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
 

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

@@ -28,7 +28,7 @@ Bridgeのpeer通知、Codexからのメッセージ、ackは依頼ではない
 
 ## 相談・修正
 
-人の指摘はClaudeが修正し、再検証する。人がWebStormで直接編集した場合も、Claudeが読み直して再検証する。stage済みの単位では再stageし、上の失効に従う。修正は単位と依頼の目的・範囲内に限り、超えるものは実装の工程へ戻す。Linear進行のQA中は人もClaudeも作業ツリーを編集しない。
+devから続く作業では、人の指摘はdevの継続（[工程](dev/workflow.md)の「役割と継続」）として同じ実装担当が修正し、再検証する。人がWebStormで直接編集した場合の読み直しと再検証も担当へ渡す。stage済みの単位では再stageし、上の失効に従う。修正は単位と依頼の目的・範囲内に限り、超えるものは実装の工程へ戻す。Linear進行のQA中は人もClaudeも作業ツリーを編集しない。
 
 ## 報告
 

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.35.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.35.1`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.35.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.35.3`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
 
@@ -180,7 +180,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `merge` | 必要なQA・承認が揃った対象PRのマージと、元のブランチへ戻る操作 |
 | `deploy:<環境>` | 指定した環境への配備・配布（例 `deploy:staging`） |
 | `publish:<操作>` | 一般公開やストアへの提出など、指定した公開操作（例 `publish:app_store_submit`） |
-| `dev_delegation` | `shinaps:dev-claude` の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
+| `dev_delegation` | `shinaps:dev-claude` の中で、サブエージェントへ委託する。許可がない場合、入口のメインは担当の作業を代わりに行わず、必要な許可を求める。worktreeの作成は含まない |
 | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
 
 - 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション。ask: 着手時に選んだ経路の許可）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可（askでは選択肢にする両経路の許可）・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。

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

@@ -14,7 +14,7 @@
 
 対象一覧は最後のページまで読み、作業先・依存・状態・優先順位を確認する。対象IDの一覧、依存順の実行順、開始時点、終了条件を既存の親Issue・依頼元Issueのコメントまたはローカル作業記録へ残す。記録のためだけに親Issueを新設しない。後から追加されたIssue、別Cycle、対象外の依存Issueを自動で取り込まない。順序を変える必要がある場合は理由を記録し、範囲の変更は利用者と合意する。
 
-作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。Issueがまだない作業では依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、利用できるセッションの一覧、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。操作の許可は作業先リポジトリの設定で決め、同じLinear projectに属するだけでは別のリポジトリの作業を含めない。設定がない・不足する対象は、他のリポジトリの設定で実行せず、開発進行を始めない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
+作業先リポジトリは、Issue本文に記載した作業先のリポジトリ名（共通テンプレートでは「実装方針」）で特定する。Issueがまだない作業では依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、利用できるセッションの一覧、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。操作の許可は作業先リポジトリの設定で決め、同じLinear projectに属するだけでは別のリポジトリの作業を含めない。設定がない・不足する対象は、他のリポジトリの設定で実行せず、開発進行を始めない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
 
 「このIssueを進めて」などの一般的な進行依頼では、設定の `stop_after` を到達点として記録する。Doneより手前という理由だけで再確認しない。具体的に指定された到達点と設定が矛盾する場合だけ、開始前に相違を解消する。途中の終了地点への到達を、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。操作許可を暗黙に増やさない。
 
@@ -40,8 +40,8 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし、
 上の待機で、進行役のCodexが現在のターンの中で待つ手順。通知・回答を受けて同じゴール・工程から続けられるよう、待機中に最終応答を送ってターンを終えない（待機ツールがない場合は1項目目に従う）。人への依頼・確認は、利用可能な質問UIまたはターンを終えない途中の発言で伝えてから待機する。Claudeが質問・障害を最終resultへ返してターンを終える規則（[Claude CLI](claude-cli.md)）は実装側の規則で、この手順とは別に扱う。
 
 - 通知または人の入力で再開できる待機ツールを優先する。それがなく、新しい入力で中断される待機ツール（例: `clock.sleep`）が提供される場合は、1回の待機を60秒以下（`duration_ms` 60000以下）にする。この手順を確認したCodexの実行環境の指示（2026-10-20時点）が、60秒を超えて応答を止める待機を避けるよう求めるため。どちらの待機ツールもなくターンの中で待てない場合に限り、待機理由・再開条件と人への依頼を最終応答で伝えてターンを終え、次の入力で同じゴール・工程から続ける（新しいゴールを作らない）。
-- 待機から戻ったら、届いた通知・入力だけを処理し、処理するものがなければ同じ待機を繰り返す。待機中や戻ったときに、ログ・出力ファイル・Git差分・メッセージ・画面を繰り返し取得して進み具合を確かめない。変化のない進捗の報告や、待機理由と関係のない作業もしない。実行環境の上位の指示が求める場合はそれに従う。
-- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。autoで通知を受け取れない場合の確認は [Claude CLI](claude-cli.md) の「起動と観測」の間隔に従い、待機から戻るたびには行わない。
+- 待機から戻ったら、届いた通知・入力だけを処理し、処理するものがなければ何も伝えず同じ待機を繰り返す。待機中や戻ったときに、ログ・出力ファイル・Git差分・メッセージ・画面を繰り返し取得して進み具合を確かめない。待機から戻るたびの報告、変化のない進捗の報告、待機理由と関係のない作業もしない。利用者へ伝えるのは、完了・質問・障害などの重要な変化と、人の判断・対応が必要なときだけにする。実行環境の上位の指示が報告を求める場合はそれに従う。
+- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。autoで通知を受け取れない場合の確認は [Claude CLI](claude-cli.md) の「起動と観測」の間隔に従い、待機から戻るたびには行わない。この間隔は確認の間隔で利用者への報告の周期ではなく、終了していなければ伝えない。
 - 待機中もゴールは `active`、Linearの工程も同じままにする。ゴールの状態の変更と、利用者の明示的な停止・予算・実行制限の扱いは下の「ゴール機能」に従う。
 - 再開時は、届いた通知・入力を待機理由（対象Issue・工程・相手）と照合し、同じゴール・工程で続ける。Bridgeの通知で再開した場合は [Bridge](bridge.md) の「受信」に従って読む。peer通知を利用者の承認と扱わない。
 

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

@@ -45,12 +45,14 @@ Issueの作成・紐づけは作業の記録であり、担当・人のレビュ
 ## 共通Issueテンプレート
 
 ```markdown
-## 目的
-このIssueで実現する到達点と利用者・運営にとっての効果。
+## 背景・目的
+今の困りごとと、それを解決する理由。
 
-## 変更内容・レビュー観点
-変更前と変更後、変更理由。仕様・デザインの根拠と対応する実装箇所へのリンク。
-UIがある場合は代表スクショ、動きの説明には短い動画を添える。
+## できるようになること
+誰が何をすると、何ができるようになるか。変更前と変更後の操作・結果・制約を、技術の説明を読まなくても分かるように書く。画面のない変更は、利用する人や運用への効果として書く。
+
+## 実装方針
+「できるようになること」をどう実現するかの短い設計。責務の分担、データの流れ、既存構成の変更を書く。作業先のリポジトリ名もここに書く。前提、依存するIssue、根拠（仕様の正本・要件ID・詳細設計）への参照は、ここか関係する欄に書く。ファイルの一覧や作業手順だけで設計の代わりにしない。
 
 ## 受入条件
 ### Agent QA
@@ -58,22 +60,13 @@ UIがある場合は代表スクショ、動きの説明には短い動画を添
 ### Human QA
 - [ ] 人が確認する性質 — AIだけでは確認できない理由・環境
 （不要なら「不要。」だけを記載）
-
-## 検証状況
-最新の合否・未確認事項と、詳細なQAコメントへのリンク。
-
-## 対象・範囲外
-作業先のリポジトリ名、担当範囲、前提、依存するIssue、引継ぎ先。
-
-## 決定事項・参照
-判断と理由、仕様の正本と要件ID、未決事項。
 ```
 
-- 「対象・範囲外」の作業先のリポジトリ名は、同じprojectを複数のリポジトリが使うときに、適用する設定を決めるために使う。ローカルの絶対パスは書かない。
+- 「実装方針」の作業先のリポジトリ名は、同じprojectを複数のリポジトリが使うときに、適用する設定を決めるために使う。ローカルの絶対パスは書かない。
 - Linear側のテンプレート設定を変えることは別の設定操作である。本文への適用では変更しない。
 
 ## 書き方
 
-- 任意の欄は必要なときだけ使い、空欄や定型文で埋めない。Human QAが不要なら「不要。」だけを書く。
-- 一つの欄で一つの疑問に答え、同じ情報を複数の欄に書かない。長いログを本文へ貼らない。途中の議論はコメントへ残し、採用した結論を本文へ統合する。
-- 「変更内容・レビュー観点」では、変更前と変更後、根拠、対応する実装箇所、確認してほしい点を結ぶ。UIにはデザインと実装後のスクショ、操作や遷移には短い動画、APIや内部処理には入出力の例を添える。
+- 一つの欄で一つの疑問に答え、空欄や定型文で埋めず、同じ情報を複数の欄に書かない。判断の要点（採用した案と理由、未決事項）は該当する欄の本文に書き、詳細な設計は参照先に置く。途中の議論と検証の詳細はコメントへ残し、採用した結論を本文へ統合する。長いログを本文へ貼らない。
+- Issueの範囲は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)のとおり目的・変更内容・受入条件から判断するので、範囲外の一覧は作らず、誤解されやすい境界だけを該当する欄に書く。
+- 「できるようになること」の説明に必要なら、画面はデザインやスクショ、操作や遷移は短い動画、画面のない処理は入出力の例を添える。

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

@@ -40,7 +40,7 @@ Codexは各工程のQA結果を、対応するIssueのコメントへ残す。
 ```
 
 - 失敗や中断も記録し、成功の結果で過去の失敗を消さない。送信の再試行では重複したコメントを作らない。実際に再検証した場合は、新しい対象と結果を区別して記録する。長いログは必要な箇所を要約して証拠へリンクする。
-- 本文の「検証状況」から最新のQAコメントへ辿れるようにし、コメント・添付・リンクを読み戻して確認する。
+- 最新の合否と未確認事項は最新のQAコメントで示し、コメント・添付・リンクを読み戻して確認する。
 - 人のQAの結果は本人の報告に基づいて対象と結果を記録し、AIが代わりに合格を決めない。
 
 ## スクショ・動画

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

@@ -49,6 +49,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 - **戻し先**: 検証失敗・レビュー指摘・QA不合格・単位照合の不一致は、見つけた担当が直さず原因の担当へ戻す。実装・修正はすべて同じClaude session（autoは同じCLI sessionのresume、manualは同じ対話セッション）で行い、Codexは再検証だけを行う。
 - **許可**: 操作の前に `permissions`・実効 `review_flow`・今回の明示指示を照合する。許可がなければ許可待ちで止める。これは終了地点への到達ではない。設定の存在だけを合意と扱わない。
+- **Issueの範囲**: 範囲はIssueの目的・変更内容・受入条件から判断する。記載のない作業でも、目的の実現に必要な手段は範囲に含む。仕様や範囲の拡大が必要になったら、進める前に次の「停止と人への確認」に従って確認する。
 - **停止と人への確認**: 設定不備、経路と単位modeの競合、照合の不一致、目的・仕様・受入条件・許可範囲の変更、本人にしかできない操作、根拠を確認しても解消できない報告の矛盾では、安全な状態で止める。確認の担当は経路で決まる。auto経路と、manualで人がセッションにいない間は、Codexが人へ一問で確認する。manualの作業中は対話セッションのClaudeが人へ一問で確認し、決定を報告に含める。新しい許可が要る決定や許可範囲を広げる決定（push・PR・merge・配備・公開・破壊的操作など）は報告では成立させず、Codexが人へ一問で確認する。
 - 経過時間、無回答、Bridgeの送信成功・ack・peer通知、CLIのprocessの終了を、承認・完了・合格として扱わない。
 - 人がClaudeへ直接伝えた指示・承認はClaudeが報告に含め、CodexはGitの状態と照合し、合意済みの設定・会話の許可範囲内で次へ進む。報告は新しい許可を作らない（[Bridge](bridge.md)）。既存の許可内の後続処理は人へ聞き直さない。

package/plugins/shinaps-codex/references/testing.md

@@ -1,3 +1,3 @@
 # テスト方針
 
-テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。検証の入力（対象の内容）・環境と条件・コマンドと範囲・成功の証拠を、証拠の粒度に合う版の識別（ファイル・blob・treeのハッシュ等）で照合できる場合は、担当・工程・commit SHAが変わっただけで再実行しない。入力や条件が変わった、証拠が不足・失敗・未確認、またはプロジェクトが段階ごとの実行を求める場合は、必要な範囲を実行して理由を残す。照合できない結果を合格にせず、独立QAや新しい環境での公開確認はこの再利用で省かない。