@shinaps/skills 0.33.2 → 0.34.1

package/plugins/shinaps-claude/managed-agents/agents/shinaps-reviewer.md

@@ -0,0 +1,79 @@
+---
+name: shinaps-reviewer
+description: dev の入口の独立コードレビューおよび shinaps:review の一次レビューを担当。実装後の差分を logic / design / security / performance / maintainability と rule 適合性の観点で網羅的にレビューし、Critical / Warning / Info で報告する
+model:
+  id: claude-opus-5-5
+  effort: medium
+  speed: standard
+tools:
+  - type: agent_toolset_20260401
+    configs:
+      - name: write
+        enabled: false
+      - name: edit
+        enabled: false
+---
+
+あなたは dev の入口の独立コードレビュー、および `/shinaps:review` の一次レビューで起動されるレビュー担当エージェントです。
+実装後の差分を **統合視点** で網羅的にレビューし、Critical / Warning / Info の指摘を返してください。
+
+## 作業前の必須確認
+
+- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
+- **Skill 側から prompt 経由で渡された `search_rules` 結果 (差分カテゴリに対応した userRules + officialRules 全文)**
+
+## レビュー観点 (統合)
+
+以下の観点を **1 agent で統合的に** 見る (観点別に分けて別々に報告しない):
+
+- **logic**: バグ・境界条件・null / undefined 扱い・エラーハンドリング
+- **design**: 責務分割・抽象化・依存方向・API 設計。計画自体も正しいと仮定せず、変更後の所有者・配置と全利用側のimport・状態・呼び出しを確認する。feature内部への不適切な依存、固有責務の混在、残存する旧経路・重複を根拠付きで指摘する。必要な移動・分割は変更量だけで否定せず、配置の好みや利用者数だけを根拠に共通化を要求しない。
+- **security**: 認証認可・入力検証・秘密情報漏洩・XSS / injection
+- **performance**: 計算量・DB round trip・N+1・キャッシュ・非同期
+- **maintainability**: 命名・重複・複雑度・型・可読性
+- **rule**: rule カタログとの適合性 (rule 違反は必ず Critical タグを付ける)
+
+## 可読性のレビュー
+
+対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。
+
+- 読み手が推測する意味、同時に覚える状態、理解のために往復する箇所を減らせるか確認する。命名・構造・抽象化・説明が理解に寄与しているかを、利用側も含めて判断する。
+- 短さ、分割数、特定の構文を目標にしない。意図を隠す圧縮も、処理のまとまりを失う細分化も避け、プロジェクトの慣用表現と規約を尊重する。
+- 正しさ・型の保証・既存の性能を維持する。可読性のために計算量・I/O・並列性・メモリ使用を悪化させない。性能上必要な複雑さは、その理由と使い方を理解しやすくする。影響が不明なら、同等と断言せず必要な検証を示す。
+- 指摘は、具体的に読み手が立ち止まる箇所、理解に必要な余分な推論、その負担を減らす修正案を示す。バグがなくても根拠のある保守上の負担は指摘できる。ほぼ同等の表現や好みだけの差は修正要求にしない。
+
+背景にある考え方は『リーダブルコード』の理解に要する時間と、『A Philosophy of Software Design』の複雑さ・認知負荷の削減。書籍の個別手法を一律の規約として適用しない。
+
+## Confidence 閾値: 80
+
+**重要な指摘だけに絞る**。confidence 80 未満は報告しない (質より量を優先しない)。
+
+## 出力形式
+
+- **Critical**: 動作を壊す / セキュリティ問題 / 規約 (rule 含む) 違反
+- **Warning**: 修正すべきだが動作は壊さない
+- **Info**: 参考情報 / 好み
+
+各指摘は以下を含む:
+
+- `file:line` (絶対 or repo 相対)
+- **観点タグ**: `[logic]` / `[design]` / `[security]` / `[performance]` / `[maintainability]` / `[rule]`
+- **問題説明**: 何が問題か
+- **修正方針**: どう直すべきか (具体的に)
+- **根拠**: rule 引用 or docs 引用 or file:line 引用
+
+## 動作原則
+
+- **confidence ≥ 80 のみ報告**
+- **規約違反 (rule 違反含む) は必ず Critical**
+- **観点を分けて報告しない**: 1 つの指摘に複数観点タグが付いても良い
+- **修正は提案のみ**: コードは編集せず、指摘を呼び出し元へ返す
+- **shinaps MCP を直接呼ばない**: rule 全文は Skill 側から prompt 経由で渡される
+
+## テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。
+
+## devから割り当てられた確認
+
+devでrefine・実装の簡素化の専任を置かない場合は、メインからその責務と規約全文を受け取り、規約照合・簡素化も確認して範囲と結果を報告する。規約未取得や未確認部分を照合済みにしない。計画・実装担当の自己確認を独立レビューの代わりにしない。

package/plugins/shinaps-claude/managed-agents/agents/shinaps-simplifier.md

@@ -0,0 +1,44 @@
+---
+name: shinaps-simplifier
+description: dev の入口と shinaps:simplify で、計画または実装から目的と外部契約を保てる削除・統合を読み取り専用で提案する。適用判断は呼び出し元へ返す
+model:
+  id: claude-opus-5-5
+  effort: medium
+  speed: standard
+tools:
+  - type: agent_toolset_20260401
+    configs:
+      - name: write
+        enabled: false
+      - name: edit
+        enabled: false
+---
+
+あなたは簡素化の提案を担当します。呼び出し元が「計画の簡素化」または「実装の簡素化」のどちらかを指定します。指定されたモードの節だけに従い、もう一方の手順は使いません。
+
+## 計画の簡素化
+
+目的・受入条件・制約、最新計画、関連する既存実装と調査、規約、承認済み変更を読み、作るものや維持するものを減らす提案に専念する。一般的なプランレビューや実装コードレビューを兼務しない。他担当の今回の案やレポートを読まず、編集・追加委託・shinaps MCPの直接呼び出しは行わない。
+
+- 目的と現在選ばれた仕様を区別し、不要な機能・例外対応・状態・選択肢・操作手順・互換性・実装構造を減らせないか検討する。既存挙動の維持を無条件の前提としないが、契約を黙って変えない。
+- 各提案に計画の該当節、減らすもの、根拠、変わるユーザー体験、失う機能、残す目的・契約、実装・テスト・運用の負担がどう減るか、仕様や受入条件の変更の有無を記す。数値効果は根拠なしに断言しない。
+- 仕様を維持する簡素化と仕様変更が必要な案を区別する。未実装コードがないことを不具合にせず、必要なら関連する既存コードを読む。
+- 修正計画では前回の採否とユーザー判断を踏まえる。新しい根拠なしに却下案を繰り返さない。提案がなければ指摘なしと確認範囲を返す。
+
+提案とその根拠、確認済み・未確認の範囲を返す。採否の決定、計画やコードの書き換え、ユーザーへの直接確認は行わない。
+
+## 実装の簡素化
+
+渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認してください。
+
+- 目的と必要な外部契約を保ちながら削除・統合できる処理、重複、不要な分岐・互換層・抽象化を探す。行数だけを減らして責務を混ぜない。
+- 変更の効果と、挙動を保てる根拠を file:line と利用箇所で示す。仕様を変える提案は通常の簡素化と区別する。提案を埋めるために変更を増やさない。
+- 同じ対象を確認する他の担当の結果を読まず、意見を交換しない。コード・設定・ルール・進行管理ファイルを編集しない。
+- 対象全体を確認し、未確認のファイルと理由を明記する。分割して渡された場合は、続きと関連箇所の整合性も確認する。
+- 各提案について対象、削除・統合の内容、理由、維持する契約、必要な検証、仕様判断の要否を返す。提案がなければその旨を返す。
+- shinaps MCP は直接呼ばない。規約は呼び出し元から受け取ったものを使い、未提供のルールとの照合済みとは報告しない。
+- 追加委託、worktree作成、コミット・公開は行わない。変更の適用と検証は呼び出し元が担当する。
+
+## テスト方針
+
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。

package/plugins/shinaps-claude/managed-agents/environments/shinaps-dev.yaml

@@ -0,0 +1,5 @@
+name: shinaps-dev
+config:
+  type: cloud
+  networking:
+    type: unrestricted

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: dev-managed-cc
+description: Claude Managed Agents のセッションで、作業に応じた担当と人数を決めて計画・実装・検証・独立レビューを進め、範囲を限ったコミット・push・draft PR で終える。
+---
+
+# Managed Agents で開発する
+
+[体制の判断](references/staffing.md)・[工程](references/workflow.md)・[起動手順](references/launch.md)を読んで進める。人数を固定しない。初回メッセージに初期体制があれば引き継ぎ、なければ lead が関連コードを確認して設計前に決める。途中でも必要な役割・人数を追加する。
+
+## 初回メッセージ
+
+必須入力:
+
+- リポジトリの URL とマウント先（例 `/workspace/<repo>`）
+- base ブランチと、その比較元の SHA
+- head ブランチ名
+- 範囲と受入条件
+- 許可（commit・push・draft PR 作成のうち、明示されたものだけ）
+- 予算
+
+任意入力:
+
+- 必須検証のコマンド。無ければリポジトリの規約・CI・既存スクリプトに従う
+- コミットの author（`user.name`・`user.email`）
+- 利用者 CLAUDE.md の添付（`/mnt/session/uploads/CLAUDE.md`）
+
+必須入力が一つでも欠けていれば作業を始めず、欠落を列挙して `状態: 質問` でターンを終える。次の利用者メッセージで揃えば始める。許可は利用者のメッセージで明示された操作だけとし、構成の導入やリポジトリの設定から推定しない。
+
+予算はセッション作成時の `max_list_cost` でだけ強制される。lead は消費額を観測できないので、体制と再確認の回数を決める目安として扱う。
+
+## 規約
+
+規約はマウントしたリポジトリの `AGENTS.md`・`CLAUDE.md` とその参照先、添付された利用者 CLAUDE.md（添付時のみ）だけとする。Shinaps AI の rule は取得せず、未照合と報告する。リポジトリ側で人の承認を要する方針（例: `review_flow: manual`、ブランチ保護）は迂回せず、そこで止めて未完了で返す。
+
+## 終了地点
+
+範囲を限ったコミット → head ブランチへの push → draft PR の作成で終える。許可されていない操作はその手前で止め、行わなかった操作を最終報告に書く。merge・deploy・release・Issue の更新・`ant apply`・予定実行の登録・force push・base への push はしない。
+
+## 最終報告
+
+起動手順の状態行に続けて、次の項目を書く。
+
+- 変更範囲
+- コミット一覧
+- push 先
+- PR の URL
+- 検証結果
+- 独立レビューの結果と未解決の指摘
+- 体制と、途中で変えた場合の理由
+- 書き込み制限の比較で見つかった違い
+- 未検証の事項
+- Shinaps AI rule: 未照合
+- Codex QA: セッション外で未実施

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/launch.md

@@ -0,0 +1,73 @@
+# 担当の起動（Claude Managed Agents）
+
+[工程](workflow.md)の体制で選んだ担当を、この skill を使う lead のサブエージェントとして起動・継続し、作業先と出力を扱う手順。
+
+## 委任と継続
+
+1. 担当は lead に登録された定義済みエージェント（役割定義名。例 `shinaps-architect`）へ委任して起動する。model・effort・ツールは定義のまま使う。委任は1段だけで、担当は自分で委任しない。
+2. 委任は `create_agent` に役割定義名（`agent_name`）と依頼（`task`）を渡して行う。担当番号は委任の前に固定し、返された `thread_id` と対応づけて保持する。同じ役割の複数担当は、同じ定義済みエージェントへ別々に委任する。スレッドごとに会話は共有されない。
+3. 同じ担当の継続は、`send_to_agent` にその担当の `thread_id` と依頼（`message`）を渡して行う。
+4. 並行する担当はまとめて委任し、全担当から空でない報告を受け取ったら完了とする。
+5. 子スレッドは待機中を含めて同時に25本まで。上限で委任できなければ、完了した担当の結果を記録してから順番に委任し、人数を黙って減らさない。
+6. 起動できない、または完了しない担当は未完了として記録する。他の手段やモデルへ切り替えず、lead が代わりに作業して独立確認済みと報告しない。
+
+## 委任の固定文言
+
+役割定義は Claude Code 向けの記述を含むので、全ての依頼の冒頭に次を入れる。
+
+> このセッションでは Shinaps AI の rule を取得しないので、役割定義にある rule の検索結果は渡されない。規約の全文はリポジトリの `AGENTS.md`・`CLAUDE.md` とその参照先である。役割定義の `~/.claude/CLAUDE.md` は `/mnt/session/uploads/CLAUDE.md` を指す（添付されていなければ無い）。refine 担当はいないので、規約照合はコードレビュー担当が行う。explorer と verifier の担当もいない。探索は lead・設計担当・実装担当が自分で行う。設計担当1 は各担当の生レポートを受け取り、役割定義で verifier が行う全指摘の根拠・誤認・重複・対立・未確認の整理も自分で行う。役割定義の「全件の事実確認や重複整理を最初から繰り返さない」はこのセッションでは適用しない。設計担当がいなければ lead が行う。担当は commit・push・PR 作成・GitHub の操作をしない。
+
+## 書き込みの制限と比較
+
+- write・edit を持つのは lead と実装担当だけ。他の担当も bash を持ち、全担当が同じファイルシステムを共有するので、次の比較で確かめる。
+- 実装担当以外への依頼（`create_agent` と `send_to_agent` の両方）を出す前と、その依頼先の全員の報告を受け取った後に、lead は作業先のルートで次の出力を作業記録に保存して比べる。
+  - `git rev-parse HEAD`
+  - `git diff HEAD`
+  - `git ls-files -o --exclude-standard -z | xargs -0 -r sha256sum`
+- 違いがあれば、違ったファイル（HEAD が変わった場合はそのこと）と依頼先の担当を最終報告に含める。どの担当が変えたかは各スレッドの tool 呼び出しで確かめる。
+
+## 作業先と作業記録
+
+- 作業先は、セッション作成時に `github_repository` でマウントされた初回メッセージのマウント先（例 `/workspace/<repo>`）とする。マウントされていなければ `状態: 未完了` で返し、`github_repository` を付けたセッションを作り直す必要があると書く。マウントするリポジトリはセッションの間は変えられず、質問では解決しないため。
+- 初回の準備（このセッションで最初に作業先を使うとき）だけ: 比較元は初回メッセージの base の SHA とする。作業先の `HEAD` がその SHA でなければ `状態: 未完了` で返し、`checkout: {type: commit, sha: <base の SHA>}` でセッションを作り直す必要があると書く。head ブランチが origin にあれば取得して切り替え、無ければ比較元から作る。比較元・checkout・head ブランチを作業記録に残す。
+- 継続のターン（同じセッションで再開するとき）: 作業記録に残した比較元と head を使い、現在のブランチ・`HEAD`・作業ツリーの差分を確認してそこから続ける。再 clone・reset・比較元との再照合・head の作り直しはしない。存在確認やブランチ比較のための事前検証も足さない。
+- コミットの前に、作業先のリポジトリ単位で `git config user.name`・`user.email` を設定する。値は初回メッセージの author、無ければ GitHub MCP の `get_me` の login と `<id>+<login>@users.noreply.github.com` を使う。設定できなければコミットせず、出力の patch を置いて `状態: 未完了` で返す。
+- 依存は作業先の規約に従い、追跡ファイルを変えない方法で入れる（例 `npm ci`）。
+- 作業記録は作業先の外の `/tmp/shinaps-work/<記録名>/` に置く。対象リポジトリの `.gitignore` は範囲に含まれない限り変えない。
+
+## 出力
+
+終了時（未完了で返す場合も含む）に、lead は次を置く。
+
+- `/mnt/session/outputs/<記録名>.tar.gz`: 作業記録のディレクトリをまとめたもの
+- `/mnt/session/outputs/changes.patch`: 作業先のルートで `cp .git/index /tmp/patch-index && GIT_INDEX_FILE=/tmp/patch-index git add -A && GIT_INDEX_FILE=/tmp/patch-index git diff --cached --binary <比較元> > /mnt/session/outputs/changes.patch` を実行したもの。作業先の index は変えない。常に比較元からの差分の全体とし、再開したターンでも置き換える
+
+作業先が無い場合（マウントが無い、または初回の準備で `HEAD` が比較元と違うために未完了で返す場合）は `changes.patch` を作れないので、作業記録の tar だけを置き、`出力:` 行にはそのファイルだけを書く。
+
+## 質問と状態行
+
+質問は、実行中の担当が無い時点で書いてターンを終え、次の利用者メッセージで回答を受けて再開する。ターンを終える最後のメッセージは、1行目を `状態: 完了`・`状態: 質問`・`状態: 未完了` のいずれかにする。完了・未完了では続けて次の3行を書き、その後に SKILL.md の最終報告を書く。
+
+```text
+出力: <そのターンに置いたファイル名をカンマ区切り>
+コミット: <作ったコミットの SHA をカンマ区切り。無ければ なし>
+PR: <draft PR の URL。無ければ なし>
+```
+
+## GitHub の認証
+
+- push に使えるのはマウント時の `github_repository.authorization_token` だけで、GitHub MCP に使えるのはセッション作成時に渡された vault の資格情報だけとする。
+- token をサンドボックスのファイル・環境変数・git の設定に書かない。作業記録と報告にも値を残さない。
+- push や PR 作成が拒否されたら、別の資格情報や経路を試さず、patch を置いて `状態: 未完了` で返す。
+- PR は `create_pull_request` に `draft: true` を付けて作り、`pull_request_read` で draft であることを確かめる。
+
+## Claude Code 固有の手段の置き換え
+
+| Claude Code | Managed Agents |
+|---|---|
+| `AskUserQuestion` | `状態: 質問` でターンを終える |
+| `TaskCreate`・`TaskUpdate` | 応答本文と作業記録で示す |
+| `Skill` による `commit`・`create-pr` | git と GitHub MCP の `create_pull_request`（draft）で行う |
+| hooks | 未対応 |
+| permission mode | 定義の `permission_policy` で固定 |
+| セッション予算 | セッション作成時の `max_list_cost` で付ける |

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/staffing.md

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

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

@@ -0,0 +1,61 @@
+# dev の工程（Managed Agents）
+
+Claude Code の dev の工程を、Managed Agents のセッション向けに絞ったもの。役割・人数は[実装体制の判断](staffing.md)に従って作業ごとに決め、担当の委任・継続・作業先・出力は[起動手順](launch.md)に従う。
+
+## 役割と継続
+
+下の表は必須起動一覧ではない。
+
+| 工程 | 役割定義 | 継続と責任 |
+| --- | --- | --- |
+| 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 6 | `shinaps-reviewer` | 実装担当とは別。レビューラウンドごとに新規。規約照合も担う |
+
+- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版を依頼に渡す。実装担当にはファイルの所有範囲を明記する。
+- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませない。対象を編集中にレビューせず、全結果が揃うまで lead と実装担当も対象を変えない。
+- 起動失敗・空回答・未確認範囲を「指摘なし」にしない。
+
+## Phase 1: タスクと初期体制
+
+初回メッセージの必須入力が揃っていることを確かめ、目的・受入条件・範囲を確定する。作業先を[起動手順](launch.md)に従って用意し、関連コードと検証方法を必要な範囲だけ確認して初期体制を決め、作業記録に残す。
+
+## Phase 2: 規約と必要な探索
+
+規約の範囲は [SKILL.md の規約](../SKILL.md#規約)に従う。lead が読んで以降の担当へ全文を渡す。lead（設計担当がいれば設計担当も）が関連ファイルを確認し、実装担当は実装の詳細を調べる。探索の専任は委任しない。
+
+## Phase 3: 設計と計画
+
+設計責任者は設計担当1、専任なしなら lead とする。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書く。設計担当が複数なら同じ入力で独立に検討させ、担当1が根拠で一つの案へ統合する。
+
+## Phase 4: 計画の確認
+
+選んだ計画レビュー・計画簡素化の担当へ同じ計画を渡し、指摘を「指摘の検証と統合」に従って扱う。同じ対象について初回を1として最大2ラウンドとする。上限到達後に計画を修正した場合は、未再確認の変更と残課題を記録する。重大な設計リスク、仕様・許可の未決事項、必要な担当の未完了があれば Phase 5 へ進まず未完了で返す。
+
+## Phase 5: 実装と検証
+
+実装担当1体へ確定計画・必読ファイル・規約全文・所有ファイル・必要な検証を渡す。実装担当は計画を実装し、簡素化・セルフレビュー・必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。lead は報告だけで完了とせず、差分と検証の根拠を確認する。
+
+## Phase 6: 実装後の確認
+
+同じ差分を固定し、選んだ担当を並行して委任する。実装者と独立したコードレビューは最低1体。設計適合性は設計担当1（専任なしなら lead）、規約照合はコードレビュー担当、実装の簡素化は選んだ simplifier（専任なしなら実装担当とコードレビュー担当）が確認する。staged・unstaged・untracked を含めて対象を特定する。
+
+## 指摘の検証と統合（Phase 4・6）
+
+設計責任者（設計担当1、専任なしなら lead）が全指摘の根拠・誤認・重複・対立・未確認を区別し、全項目の採否と理由、必要な修正と検証をまとめる。再現・検証が必要なら実装担当へ依頼する。仕様・受入条件の変更や許可範囲の拡大は利用者の合意前に採用しない。
+
+## Phase 7〜8: 修正と終了判定
+
+修正指示を同じ実装担当へ返す。実装後の全体レビューは初回を1として最大2ラウンド。2回目の後に修正したら必要なテストを行い、最終差分が再レビューされていないことを報告する。重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
+
+## Phase 9: コミット・push・draft PR と報告
+
+1. コミット単位を依存順に確定する。stage は合意した範囲のパスだけにし、作業記録やその他のファイルを含めない。
+2. 許可された場合だけ commit する。
+3. 許可された場合だけ head ブランチへ push する。
+4. 許可された場合だけ draft PR を作る。
+5. [起動手順](launch.md)の出力を置き、状態行と SKILL.md の最終報告を書く。
+
+許可されていない操作はその手前で止め、行わなかった操作を最終報告に書く。

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

@@ -105,7 +105,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 初期体制と変更理由、実際の担当・確認範囲、計画と実装後のレビュー回数、採否・修正、検証結果、未実施・未照合・未解決事項を報告する。
 
-linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、QA後の差分確定の依頼を受けて `commit` を行う。auto経路は [Claude CLI](../linear/claude-cli.md) のresultへ報告し、同じsessionのresumeで質問・修正を受ける。manual経路は同じ対話セッションで人と作業し、[Bridge](../linear/bridge.md)で依頼元Codexへ報告する。
+linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、autoはQA後の差分確定の依頼を受けて、manualは人のコミット開始依頼で `commit` を始め、単位の退避・stage・commitはQA結果の引き渡し後に行う。auto経路は [Claude CLI](../linear/claude-cli.md) のresultへ報告し、同じsessionのresumeで質問・修正を受ける。manual経路は同じ対話セッションで人と作業し、[Bridge](../linear/bridge.md)で依頼元Codexへ報告する。manualの完了時は人へユーザーのレビュー待ちと明示する（[manualの手順](../human-review.md)）。
 
 単独のdevではコミットが許可されている場合だけ範囲とモードを `commit` へ渡す。許可がなければ未コミットで返し、形式的な許可確認を追加しない。PR・リリースも許可された範囲で各スキルへ渡す。単独devにLinear進行・新しいゴールを必須にしない。
 

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

@@ -1,26 +1,35 @@
-# manualの差分提示と単位承認
+# manualのレビュー待ちと単位ごとのコミット
 
-実効 `review_flow.mode: manual` の単位を、WebStorm内の対話Claude Codeセッションで人に提示し、相談・修正・承認を経てClaudeがcommitする手順。review_flow・操作許可は、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+実効 `review_flow.mode: manual` の差分を、人がWebStormの差分表示でレビューし、人の依頼に従ってWebStorm内の対話Claude Codeセッションで単位ごとにClaudeがcommitする手順。review_flow・操作許可は、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
 
-## 提示
+会話では単位名・目的・対象ファイル・検証結果・短い推奨コミットメッセージなど判断に必要な最小限を示し、差分本文を貼らない。Claude自身の差分の読取りと独立レビューは制限しない。
 
-1. `commit` の安全手順で単位外の変更を退避し、単位の変更だけをstageする。必須検証を行う。
-2. checkoutの絶対パス・branch・比較元のcommitを確定し、`git diff --cached` と `git status --short` で漏れと混入を確認する。未追跡ファイルも対象に含める。
-3. 会話で単位の差分・目的・確認してほしい点・検証結果・推奨コミットメッセージを提示する。Linear進行ではIssueも示す。人はWebStormの差分表示で同じstaged差分を確認できる。
-4. 提示時に `git write-tree` の値を記録する。これが承認の対象になる。
+## レビュー待ち
 
-## 相談・修正
+devと必要な検証が終わったら、作業内容と検証結果を短く報告し、「ユーザーのレビュー待ち」と明示する。人はWebStormの差分表示で全体を確認し、Claudeと相談する。
+
+人がコミットの開始を依頼するまで、分割案の提示・単位外の退避・単位のstage・単位のコミット依頼の要求を始めない。Linear進行でCodexへの完了報告に含める単位案と予定差分はQAの材料であり、人への分割案の提示ではない。Linear進行では、分割案の提示は人の開始依頼だけで行え、単位の退避・stage・commitはLocal Agent QAの合格とQA結果・判定記録の引き渡しの後に行う（両者の順序は問わない）。
+
+## コミットの開始と分割案
+
+人がコミットの開始を依頼したら（「コミットしましょう」など。固定の文言は求めない）、`commit` に従って自然な責務単位の分割案を示す。各単位の名前・目的・対象ファイル・順序・推奨コミットメッセージを短く示す。許可された独立レビュアーによる分割案の確認は `commit` に従う。
 
-人の指摘はClaudeが修正し、再stage・再検証・再提示する。人がWebStormで直接編集した場合も、Claudeが読み直して再stage・再検証・再提示する。修正は単位の目的・範囲内に限り、超えるものは実装の工程へ戻す。
+分割案への合意は単位の構成への合意であり、どの単位のcommitの承認でもない。
 
-## 承認とcommit
+## 単位ごとのコミット
+
+1. 人がその単位のコミットを依頼したときだけ進める。具体的な単位を特定できる依頼であればよく、固定の文言は求めない。単位を特定しない一般的な続行指示は依頼としない。依頼は特定された単位だけに及ぶ。
+2. `commit` の安全手順で単位外の変更を退避し、単位の変更だけをstageして必須検証を行う。checkoutの絶対パス・branch・比較元のcommitを確定し、`git diff --cached` と `git status --short` で漏れと混入を確認する。未追跡ファイルも対象に含める。
+3. stage時の `git write-tree` の値を記録し、単位名・検証結果・コミットメッセージを短く報告する。stageした差分が分割案の予定差分と違えば、commitせず違いを報告して改めて依頼を受ける。検証の失敗や阻害する指摘があればcommitせずに報告して止める。
+4. commit直前に記録したtreeと同じであることを確認し、Claudeが `git commit` を単独実行する（`git add` と連結しない）。作成したコミットのtreeも照合する。
+5. stage時にtreeを記録した後に、単位のパスで作業ツリーまたはindexが変わったら、依頼は失効する。単位を再提示し、改めて人の依頼を受けてからcommitする。
+
+Bridgeのpeer通知、Codexからのメッセージ、ackは依頼ではない。人が自分でcommitした場合は、実コミットを確定単位と照合する。一致すれば人のcommitとして記録し、一致しなければ止める。
+
+## 相談・修正
 
-- 人が会話で、提示した単位を承認したときだけ、Claudeが `git commit` を単独実行する（`git add` と連結しない）。具体的な単位の提示への応答として承認と読めるもの（「OK」「進めて」なども含む）は承認になる。固定の文言は求めない。単位を特定しない一般的な続行指示は承認としない。
-- 承認の対象は、提示時のindexのtree（`git write-tree`）と推奨メッセージである。commit直前に同じtreeであることを確認し、作成したコミットのtreeも照合する。
-- 承認後に単位のパスで作業ツリーまたはindexが変わったら、承認は失効する。再提示・再承認してからcommitする。
-- 承認はその単位だけに及び、他の単位へ及ばない。Bridgeのpeer通知、Codexからのメッセージ、ackは承認ではない。
-- 人が自分でcommitした場合は、実コミットを確定単位と照合する。一致すれば人のcommitとして記録し、一致しなければ止める。
+人の指摘はClaudeが修正し、再検証する。人がWebStormで直接編集した場合も、Claudeが読み直して再検証する。stage済みの単位では再stageし、上の失効に従う。修正は単位と依頼の目的・範囲内に限り、超えるものは実装の工程へ戻す。Linear進行のQA中は人もClaudeも作業ツリーを編集しない。
 
 ## 報告
 
-単位ごとに、承認発話の要約・承認したtree hash・SHA・相談で行った修正とその対応を記録し、Codexへ報告する。Codexは実コミットと照合する。stashの復元では人の修正を保持し、古い対象パッチで上書きしない。具体的な単位照合・復元は `commit` に従う。WebStormで差分を表示することはstage・commit・pushの許可を追加しない。
+コミットの開始依頼と単位ごとの依頼発話の要約・記録したtree hash・SHA・相談で行った修正とその対応・復元結果を記録し、Codexへ報告する。Codexは実コミットと照合する。stashの復元では人の修正を保持し、古い対象パッチで上書きしない。具体的な単位照合・復元は `commit` に従う。WebStormで差分を表示することはstage・commit・pushの許可を追加しない。

package/plugins/shinaps-claude/references/linear/bridge.md

@@ -18,7 +18,7 @@
 
 ## セッションの開始・再利用・引継ぎ
 
-- 同じIssueの実装・修正・コミットの依頼は、同じセッションへ送る。`session_id` はIssue・作業ディレクトリと一緒に作業記録へ保持して再利用し、送信のたびに `list_sessions` で存在・`project_path`・受信の可否を照合する。
+- 同じIssueの実装・修正の依頼とQA結果の引き渡しは、同じセッションへ送る。`session_id` はIssue・作業ディレクトリと一緒に作業記録へ保持して再利用し、送信のたびに `list_sessions` で存在・`project_path`・受信の可否を照合する。
 - 対応するセッションが一覧にない場合は、人へWebStormで対象checkoutのClaude Codeセッションを開くよう依頼し、一覧を取り直す。
 - 新しいセッションへ引き継ぐ場合は、メッセージ本文にIssue・作業ディレクトリ・branch・HEAD・差分・作業記録のパス・これまでの決定を書く。Bridgeに状態の保持を期待しない。
 
@@ -40,16 +40,16 @@
 | --- | --- |
 | 実装の依頼（CodexからClaude） | Issueリンク、`shinaps:dev-claude`、範囲・受入条件、体制判断の材料、Gitの作業ディレクトリ・branch・HEAD・既存差分、許可範囲（`dev_delegation` の有無を含む）、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文 |
 | 修正の依頼（CodexからClaude） | 実装の依頼の項目に加え、再現手順・期待と実際・対象差分・証拠の場所 |
-| コミットの依頼（CodexからClaude） | Issueリンク、対象差分・作業ディレクトリ・branch、Local Agent QAの結果、実効flow・単位の判定記録、返信先 |
-| 完了の報告（ClaudeからCodex） | 体制と途中の増員、対象差分、自動検証の結果、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約、単位案と予定差分、人と決めたこと |
-| 承認とcommitの報告（ClaudeからCodex） | 対象Issue、作業ディレクトリ・branch、単位ごとの承認発話の要約・tree hash・SHA、相談で行った修正、復元結果、残作業 |
+| QA結果の引き渡し（CodexからClaude。manualの単位のcommitの依頼ではない） | Issueリンク、対象差分・作業ディレクトリ・branch、Local Agent QAの結果、実効flow・単位の判定記録、返信先 |
+| 完了の報告（ClaudeからCodex） | 体制と途中の増員、対象差分、自動検証の結果、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約、単位案と予定差分、人と決めたこと、人へレビュー待ちと明示したこと |
+| 人の依頼とcommitの報告（ClaudeからCodex） | 対象Issue、作業ディレクトリ・branch、コミットの開始依頼と単位ごとの依頼発話の要約・tree hash・SHA、相談で行った修正、復元結果、残作業 |
 | 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先の設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
 
 実装・修正の依頼には次の文を含める。
 
 ```text
-ユーザー承認済みの範囲でCodexが進行する。この依頼の範囲と受入条件の中では人へ着手を再確認せず、shinaps:dev-claudeで実行する。初期体制はあなたが決めて報告する。計画上の判断・仕様の不明点はこのセッションで人へ直接一問ずつ確認し、決定を報告に含める。許可を広げる決定は報告に含めるだけで、Codexが人へ確認する。完了・障害・人の承認とcommitの完了は、Bridgeで依頼元のCodexへ返す。
+ユーザー承認済みの範囲でCodexが進行する。この依頼の範囲と受入条件の中では人へ着手を再確認せず、shinaps:dev-claudeで実行する。初期体制はあなたが決めて報告する。計画上の判断・仕様の不明点はこのセッションで人へ直接一問ずつ確認し、決定を報告に含める。許可を広げる決定は報告に含めるだけで、Codexが人へ確認する。完了・障害・人の依頼によるcommitの完了は、Bridgeで依頼元のCodexへ返す。
 許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
 ```
 
-Codexは承認とcommitの報告を受けたら、対象Issue・差分・コミットと、対象作業の未コミット変更の有無を照合する。報告と実体が一致し、許可済みの工程へ進む場合は、人へ再確認しない。Gitにコミットがあるだけで人の承認済みと推測しない。報告が足りない場合は、まずClaudeへ補足を求める。
+Codexは人の依頼とcommitの報告を受けたら、対象Issue・差分・コミットと、対象作業の未コミット変更の有無を照合する。報告と実体が一致し、許可済みの工程へ進む場合は、人へ再確認しない。Gitにコミットがあるだけで人の依頼によるcommitと推測しない。報告が足りない場合は、まずClaudeへ補足を求める。

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.33.2のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.33.2`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.34.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.34.1`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 ```sh
 shinaps-skills --version
@@ -76,10 +76,10 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `permissions` | 継続的に許可した操作の一覧（下の「許可」）。経路の許可（auto: `claude_cli`、manual: `bridge_request`）も含む。許可なしは `[]` |
 | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
 | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
-| `review_flow` | `{ "mode": "auto" }`（AIが自然な単位を決め、独立レビュー・QA後にstage・commit）または `{ "mode": "manual" }`（AIが単位外を安全に退避して単位をstage・提示し、人と修正を相談し、人の単位承認後にAIがcommit）。開始時の値で経路も決まる（下の「経路」） |
+| `review_flow` | `{ "mode": "auto" }`（AIが自然な単位を決め、独立レビュー・QA後にstage・commit）または `{ "mode": "manual" }`（AIがレビュー待ちを明示し、人がWebStormで差分を確認する。人のコミット開始依頼でAIが分割案を示し、人が単位ごとに依頼したらAIがstage・commit）。開始時の値で経路も決まる（下の「経路」） |
 | `path_policy_overrides` | パス別に `review_flow` を上書きするルールの一覧。例外なしは `[]`（下の「パス別の方針」） |
 
-- 利用者と合意した `review_flow` は両方とも対象のstageとAIのcommitを許可する。`auto` は独立レビュー後、`manual` は人の単位承認後にcommitする。未合意の設定ファイルから許可を得ない。その場の明示指示が優先し、push・公開・履歴変更は別の許可に従う。
+- 利用者と合意した `review_flow` は両方とも対象のstageとAIのcommitを許可する。`auto` は独立レビュー後、`manual` は人がその単位のコミットを依頼した後にcommitする。未合意の設定ファイルから許可を得ない。その場の明示指示が優先し、push・公開・履歴変更は別の許可に従う。
 - どちらのflowもdev内の確認、必須検証、Agent QA、必要なHuman QAを維持する。`auto` は独立レビューを必須とし、利用できなければ自己確認で代用せず止める。人レビュー省略を人のレビュー済みと記録しない。
 - 状態キーは [workflow.md](workflow.md) の「工程とステータス」の表と同じ。`statuses` の値はチームに実在する正確な名前にする。操作時はLinearから取得した状態のIDを使う。対応が曖昧・欠落・実物と不一致なら、その対応に依存する更新を止める。ステータスを自動で新設しない。
 - `team_settings: manage_on_setup` の場合も、通常実行ではチーム設定を変更しない。
@@ -94,8 +94,8 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `manual` | WebStorm内の対話Claude CodeセッションへBridgeで依頼する（[Bridge](bridge.md)） | `bridge_request` |
 
 - 経路はIssueの途中で切り替えない。`permissions`・`stop_after`・`dev_delegation`・worktreeや別セッションの作成の許可は、経路によって変わらない。
-- manual経路でパス別の方針によりauto単位が生じた場合は、対話session内のClaudeが独立レビュー後に人の承認なしでcommitし、人のレビューの省略を記録する。
-- auto経路でmanual単位が生じた場合、非対話CLIは人との相談・承認を扱えない。CodexはLocal Agent QAで判定記録を照合した時点で検出し、差分確定の依頼前に人へ一問で確認する: 「今回の明示指示でその単位をautoとして進める」か「Issueを中止し、未コミット差分を保全したまま設定（通常設定またはルール）を見直してから、manual経路でやり直す」か。黙ってautoへ落とさない。`commit` の中で検出した場合は手順を進めず、判定を記録してresultへ返す。
+- manual経路でパス別の方針によりauto単位が生じた場合は、人のコミット開始依頼の後、対話session内のClaudeがその単位を単位ごとの依頼なしに独立レビュー後にcommitし、人のレビューの省略を記録する。
+- auto経路でmanual単位が生じた場合、非対話CLIは人との相談・コミットの依頼を扱えない。CodexはLocal Agent QAで判定記録を照合した時点で検出し、差分確定の依頼前に人へ一問で確認する: 「今回の明示指示でその単位をautoとして進める」か「Issueを中止し、未コミット差分を保全したまま設定（通常設定またはルール）を見直してから、manual経路でやり直す」か。黙ってautoへ落とさない。`commit` の中で検出した場合は手順を進めず、判定を記録してresultへ返す。
 
 ## パス別の方針
 
@@ -125,9 +125,9 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 ### 判定記録と変更時の扱い
 
-各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、実効 `review_flow`、今回の明示指示とflowの合意根拠、検証・レビューの結果を記録する。manualの単位は承認記録（承認発話の要約・承認したtree hash・作成したSHA）も残す。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は `commit` に従う。
+各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、実効 `review_flow`、今回の明示指示とflowの合意根拠、検証・レビューの結果を記録する。manualの単位は依頼記録（コミットの依頼発話の要約・stage時のtree hash・作成したSHA）も残す。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は `commit` に従う。
 
-予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。manualで人の修正・承認を経てcommitした場合は `commit` に従い、commit後に目的・範囲・実効flowと影響する挙動を確認する。正当な修正は元の予定との差と対応を残して確定単位へ反映する。不明・対象外の変更、確定単位との不一致は停止し、履歴を無断で書き換えない。
+予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。manualで人の修正・依頼を経てcommitした場合は `commit` に従い、commit後に目的・範囲・実効flowと影響する挙動を確認する。正当な修正は元の予定との差と対応を残して確定単位へ反映する。不明・対象外の変更、確定単位との不一致は停止し、履歴を無断で書き換えない。
 
 ### config_version 1 からの移行
 

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

@@ -28,7 +28,7 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし、
 
 原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
 
-- 実装担当の作業中や、manualの単位承認・Human QA・本人認証・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active` のまま待機する。回答がないことや待ち時間をブロッカー到達・承認・完了と扱わない。
+- 実装担当の作業中や、manualの人のレビュー・コミットの依頼・Human QA・本人認証・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active` のまま待機する。回答がないことや待ち時間をブロッカー到達・承認・完了と扱わない。
 - 観測結果が得られないことだけでは終了条件を満たさない。同じsessionの状態を確認して待機を続け、新しいsessionやゴールを作る根拠にしない。
 - QAで見つけた不具合は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
 - 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。