@shinaps/skills 0.27.0 → 0.29.0

package/README.md

@@ -6,7 +6,9 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 
 共通スキルが持つのは判断手順。対象環境・必須検証・公開条件は、対象プロジェクトの `AGENTS.md` / `CLAUDE.md` と参照先、README、CI、既存スクリプトから読み取る。専用設定ファイルは必須にしない。
 
-例外として `linear-execute` の開発進行とチーム設定の変更には、対象リポジトリの `.shinaps/linear.yaml` を必須にする。操作の継続的な許可と終了地点を会話から推測せず、合意した範囲だけを続けて進めるためである。設定はGit対象外の個人用ローカルファイルで、`.shinaps/.gitignore` の除外に含まれる。設定がなくてもIssueの読み取り・整理はできる。設定が必要な実行でファイルがない場合は、同じセッションで `linear-plan` の初期設定ヒアリングへ進み、合意した設定の保存・確認後に元の依頼を再開する。
+例外として `linear-execute` の開発進行とチーム設定の変更には、対象リポジトリの `.shinaps/linear.yaml` を必須にする。操作の継続的な許可と終了地点を会話から推測せず、合意した範囲だけを続けて進めるためである。設定は `config_storage: shared` でGit共有、`local` でメインの作業ツリーだけに保存する。既存設定でキーがない場合だけ従来のlocal扱いを維持し、自動追記・許可の再合意は求めない。sharedは現在のcheckout、localはメインの設定と補足を正本とする。共有設定が欠けていても端末別のlocal設定では補わない。[共通設定](plugins/shinaps-claude/references/linear/configuration.md)の読取・保存手順に従う。設定がなくてもIssueの読み取り・整理はできる。設定が必要な実行で共通の読取手順により真に未設定と確認できた場合だけ、同じセッションで `linear-plan` の初期設定ヒアリングへ進み、合意した設定の保存・確認後に元の依頼を再開する。
+
+sharedで採用する `instructions.md` は共有YAMLの `references.specifications` に明記して開始・再開時に読み、他の必要補足は内容に対応する `references` に記載する。必要補足の欠落・読取不能は依存工程を止め、未採用とは扱わない。設定・採用補足・ignoreの個別例外を一緒に共有するか、共有済み資料への参照に置き換える。端末の絶対パスやsession/thread ID、進捗・QA結果は `.shinaps/work/` に分け、秘密値はどちらにも保存しない。保存方式の合意だけでstage・commit・push・追跡解除を許可しない。
 
 例えばPCブラウザのみのプロジェクトには対応ブラウザと確認コマンドを書く。iOSプロジェクトにはSimulatorと実機の使い分けを記す。スキルは一律の端末数やOS数を追加しない。既存の情報で決まらず結果を左右する条件だけ確認し、保存を了承された方針をプロジェクト側に残す。
 
@@ -23,7 +25,7 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
 | `extract-rules` | PRレビューからruleを抽出する |
 | `simplify` | 目的から見直して不要な構造や手順を削る |
-| `commit` | 進め方（通常・自律）を `.shinaps/linear.yaml` の `commit_mode` か開始時の確認で決め、検証できる単位でコミットする |
+| `commit` | 進め方（通常・自律）を各単位の実効方針か確認で決め、検証できる単位でコミットする |
 | `create-pr` | リポジトリの規約に合わせてPRを作成する |
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
 | `linear-plan` | 相談・必要なspec/explore・Issue作成と整理・プロジェクト設定を行い、実装前で止める |
@@ -31,7 +33,11 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 
 コミット・PR・リリースは、利用者の依頼またはLinear進行で合意済みの継続許可に従う。[共通設定](plugins/shinaps-claude/references/linear/configuration.md)・[担当と工程](plugins/shinaps-claude/references/linear/workflow.md)・[終了と待機](plugins/shinaps-claude/references/linear/execution.md)を参照し、必要な前工程が揃えば再確認せずに進む。単独スキル利用にはLinear進行や新しいゴールを必須にしない。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
 
-`linear-execute` は初版では利用者本人の環境向けで、Codexが進行とAgent QAを担当する。運用項目はすべて明示必須で、未記載を既定値で補わない。実装の担当は作業先の `.shinaps/linear.yaml` の `implementation_skill` で選ぶ。`dev-claude`・`dev-claude-ultra` を選ぶと、ClaudeがAI Terminal Bridge経由の依頼で実装する。`dev-codex`・`dev-codex-ultra` を選ぶと、会話側はゴール・進行・Agent QAを担当し、Issueごとの別Codexタスクが実装・QA指摘の修正・許可されたコミットを行う。タスク作成・連絡には `codex_task` とツールが要求する明示依頼が必要。どちらでも既存の許可は増えない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
+`linear-execute` は初版では利用者本人の環境向けで、Codexが進行とAgent QAを担当する。運用項目は明示必須で、既存設定の `config_storage`・`path_policy_overrides` 欠落は共通設定の説明に従い、それ以外は未記載を既定値で補わない。実装の担当は作業先の `.shinaps/linear.yaml` の `implementation_skill` で選ぶ。`dev-claude`・`dev-claude-ultra` を選ぶと、ClaudeがAI Terminal Bridge経由の依頼で実装する。`dev-codex`・`dev-codex-ultra` を選ぶと、会話側はゴール・進行・Agent QAを担当し、Issueごとの別Codexタスクが実装・QA指摘の修正・許可されたコミットを行う。タスク作成・連絡には `codex_task` とツールが要求する明示依頼が必要。どちらでも既存の許可は増えない。Bridge本体は同梱せず、導入済みのMCPとWebStormプラグインを使う。`SKILL.md` は担当ごとに両版で書き分け、共通の手順と書式は `references/linear/` に置く。`references/linear/` はClaude版を編集元としてCodex版へ同じ内容を複製し、テストで一致を確認する。
+
+`path_policy_overrides` で、合意したパスの範囲に限り人レビュー・AIコミット許可・コミットモードを個別に上書きできる。たとえば `paths: ["docs/**", "README.md"]` と `human_code_review: skip` を指定すると、予定コミットの全変更がその範囲に収まる場合だけ人レビューを省く。同じコミットに対象外が混ざれば、そのコミット全体を通常方針とし、改名・移動は旧新両パスを判定する。同じ依頼でも自然な責務分割で独立した範囲内コミットには例外を適用できる。stage・push・公開の許可や必要なQAは変わらない。設定例と競合・照合の手順は[パス別の方針](plugins/shinaps-claude/references/linear/configuration.md#パス別の方針)を参照する。
+
+0.29.0では旧 `document_only_changes: ai_commit` を廃止した。利用先では依存工程を止め、具体的なパス例外への移行または例外廃止を合意する。説明だけの変更の許可とは同値でないため自動変換しない。旧 `none` は例外なしとして維持でき、新規設定は `path_policy_overrides: []` にする。
 
 `permissions` の `development_operations` を明示すると、既存アカウントのログイン・環境準備・依存導入・起動・テスト・QAを継続的に許可できる。コミット・公開・破壊的操作の許可や人レビューは別に扱う。
 
@@ -199,11 +205,11 @@ Claude版は全16エージェントが `opus / medium`。Codex版の役割定義
 
 ## 作業成果物
 
-作業記録はプロジェクトルートの `.shinaps/work/` に保存する。初回作成時に `.shinaps/.gitignore` を内容 `*` と改行で作成する。既存のignoreは保持し、必要な場合だけ `*` を追記する。これによりignore自身を含む配下の未追跡ファイルが除外され、ユーザーによるグローバルignoreやプロジェクトルートのignore設定は不要になる。追跡済みファイルには効かないため、無断で追跡解除せず報告する。
+作業記録は現在の作業先の `.shinaps/work/` に保存する。[作業記録の共通手順](plugins/shinaps-claude/references/work-records.md)に従い、既存の共有例外を保持し、workの除外が不足する場合だけ `/work/` を追加する。設定の共有方式は記録作成では変更しない。共通手順はClaude版を編集元としてCodex版へ複製し、テストで一致を確認する。
 
 ```text
 .shinaps/
-├── .gitignore             # *
+├── .gitignore             # 保存方式に応じた除外・共有対象の例外
 ├── linear.yaml            # linear のプロジェクト設定（任意）
 ├── linear/                # linear の補足（任意）
 └── work/

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.27.0",
+  "version": "0.29.0",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {

package/plugins/shinaps-claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "shinaps",
   "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する。",
-  "version": "0.27.0",
+  "version": "0.29.0",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

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

@@ -6,9 +6,7 @@ dev の入口（Claude 版 `dev-claude`・`dev-claude-ultra`、Codex 版 `dev-co
 
 ### 作業記録の保存先
 
-作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
-
-既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../work-records.md) に従う。
 
 ### プロジェクト条件
 

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

@@ -11,15 +11,15 @@
 
 ## 実装依頼に渡すもの
 
-Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、ローカル設定と補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
+Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、設定の保存方式・正本と必要な補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
 
 実装担当には次を明記する。
 
-> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果と必要な人レビューの証拠または省略根拠を伴う依頼を受け、設定の許可を確認してから行う。他の人・AIの差分を戻さない。
+> あなたはこのIssueの実装担当。指定されたdevスキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果を伴う依頼を受け、必要な許可を確認して行う。単位案・判定・依頼・照合・報告は [共通手順](workflow.md#単位案からコミット完了まで)に従う。他の人・AIの差分を戻さない。
 
 ## 待機・QA・修正
 
-会話側は同じタスクを `wait_threads` / `read_thread` で観測し、完了・質問・失敗と実装結果を確認する。待機中のゴールと観測結果が得られない場合の扱いは [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。コミット依頼後はSHAも照合する。
+会話側は同じタスクを `wait_threads` / `read_thread` で観測し、完了・質問・失敗と実装結果を確認する。待機中のゴールと観測結果が得られない場合の扱いは [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。
 
 実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。
 

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

@@ -2,25 +2,42 @@
 
 設定は、運用上の決定と既存資料への参照を持つ。手順の全文は書かない。秘密値を保存しない。設定はAIが読む文書であり、専用のプログラムで検査しない。
 
-## 配置
+## 配置と保存方式
 
 ```text
 .shinaps/
-  .gitignore            # *
+  .gitignore            # 保存方式に応じた除外と共有対象の例外
   linear.yaml           # 対象・工程・許可・終了地点・参照先・報告
   linear/
-    instructions.md     # プロジェクト固有の指示（任意）
-    references/         # 必要な場合だけ分ける詳細資料（任意）
+    instructions.md     # 採用する場合だけ置くプロジェクト固有の指示
+    references/         # 必要な場合だけ分ける詳細資料
+  work/                 # 現在の作業先だけに保存する記録（Git対象外）
 ```
 
-- 設定を置いたリポジトリが対象のリポジトリになる。複数のリポジトリが、それぞれの設定で同じworkspace・team・projectを指してよい。設定はメインの作業ツリーに置く。
-- 保存の前に `.shinaps/.gitignore` を確認する。なければ内容 `*` と改行で作成する。既存なら内容を保持し、不足するときだけ `*` を追記する。`git check-ignore .shinaps/linear.yaml` でGitの対象外であることを確認する。追跡済みのファイルは追跡を解除せず、保存の前に扱いを利用者と決める。
-- 必須でない空ファイルを作らない。補足にSKILL.mdや独立した呼び出し名を置かない。READMEなどが正本の内容はリンクで参照し、コピーしない。
+設定を置いたリポジトリが対象になる。複数のリポジトリが、それぞれの設定で同じworkspace・team・projectを指してよい。`config_storage` で保存方式を選ぶ。
+
+- `shared`: 設定と運用に必要な補足をGitで共有し、現在のcheckoutの設定を正本とする。
+- `local`: メインの作業ツリーに設定と補足を保存し、Gitの対象外とする。
+- 既存設定にキーがない場合だけ、従来どおり `local` として扱う。自動追記や既存の許可の再合意は不要。新規設定は明記する。空値・`null`・その他の値は不正として止め、他の必須項目の欠落も補完しない。
+
+保存方式は共有範囲の選択であり、対象・操作許可・担当・終了地点・レビュー条件を変えない。必須でない空ファイルを作らない。補足にSKILL.mdや独立した呼び出し名を置かず、READMEなどが正本の内容は参照する。
 
 ## 設定の読み方
 
-- 実行開始時と再開時に、作業先リポジトリの `.shinaps/linear.yaml` と、あれば `.shinaps/linear/instructions.md` を読む。`.shinaps/linear/references/` は、担当する工程に必要なものだけ読む。
-- 設定はGitの対象外なのでworktreeには存在しない。作業がworktreeで行われる場合も、メインの作業ツリー（`git worktree list` の先頭）から読む。
+開始時と再開時に次の順で正本を一つ決め、設定と補足を読み直す。「現在」は作業対象のcheckout、「メイン」は同じリポジトリの `git worktree list` の先頭を指す。同じcheckoutなら一つだけ読む。
+
+1. 現在の `.shinaps/linear.yaml` を確認する。読取不能・不正値なら止める。`shared` なら現在だけを採用し、メインの設定は調べない。
+2. 現在が `local` 相当（明示 `local` または既存キー欠落）、または設定が真に不在の場合だけ、メインを確認する。不在の場合は、そのcheckoutのindexとHEADに設定がないことも確かめる。どちらかにあれば削除・未展開による不備として止める。Git状態を確定できないときも、未設定とは扱わない。
+3. メインが `local` 相当ならメインだけを採用する。現在のコピーで上書き・統合しない。メインが `shared` なら現在との不整合または現在の共有設定不足として止める。メインが不正・読取不能なら止める。メインが不在の場合もindexとHEADを確認し、両方にないときだけ真の不在とする。現在が `local` 相当なのにメインが不在なら正本不備で止める。両方が真に不在の場合だけ初期設定へ進む。
+
+不在の確認には、そのcheckoutで `git ls-files -- .shinaps/linear.yaml`（index）と `git ls-tree HEAD -- .shinaps/linear.yaml`（HEAD）を使う。HEAD未作成なら、その状態が確定した場合に限りHEADに設定なしと扱う。追跡状態だけで保存方式を推測しない。未追跡の `shared` は準備中の設定として読めるが、共有済みとは報告しない。追跡済みの `local` は不整合として報告し、自動で追跡解除しない。
+
+設定・`instructions.md`・必要な `references` は同じ正本から読む。補足の相対パスは正本のリポジトリルートを基準とし、コード・検証・配備などの操作対象の相対パスは現在の作業先を基準とする。共有設定の不足を別checkout・別端末のlocal設定や補足で補わない。`.shinaps/work/` の記録は証拠であり、設定を上書きしない。
+
+- `shared` では、採用した補足を共有YAMLの `references` に明示する。`instructions.md` は `references.specifications` に記載し、開始・再開時に必ず読む。存在するのに記載がなければ採用情報の不備として止め、無視や自動追記で続けない。
+- その他の補足は内容に対応する既存の5分類へ記載し、担当する工程に必要なものを読む。参照された補足がない・読めない場合は未採用と解釈せず、依存する工程を止める。採用した `instructions.md` の欠落・読取不能は設定に依存する実行全体の開始・再開を止める。
+- `local` 相当では従来どおり、存在する `instructions.md` を開始・再開時に読み、その他の補足は工程に必要なものを読む。既存設定への参照の自動追記はしない。
+- 採用していない任意の補足はなくてもよい。必要な補足を未採用扱いにして運用条件を減らさない。
 - 補足ファイルは追加の条件と手順を表す。設定の決定（対象・許可・終了地点・工程の対応）と、人の完了・QAの証拠の要件は変えない。補足と設定が矛盾したら、設定に従って止め、どちらを直すか確認する。
 - 不足や矛盾があれば、影響する工程の開始前に止めて一問ずつ確認する。影響しない工程は続ける。許可の追加やステータスの新設を推測で補わない。
 - 終了地点は操作の許可を兼ねない。設定は、利用中のツールの権限や利用者の明示的な停止・撤回を上書きしない。
@@ -30,10 +47,11 @@
 
 ## 項目
 
-以下の項目はすべて明示必須。省略・不正値を既定値で補わず、依存する工程を止めて設定を確認する。`null`・`none`・空の一覧は、以下で認めた箇所だけで「使用しない」を表す。
+以下の項目は明示必須（既存設定の `config_storage` と `path_policy_overrides` の欠落はそれぞれの説明に従う）。省略・不正値を既定値で補わず、依存する工程を止めて設定を確認する。`null`・`none`・空の一覧は、以下で認めた箇所だけで「使用しない」を表す。
 
 | キー | 内容 |
 | --- | --- |
+| `config_storage` | `shared`（Git共有）または `local`（メインの作業ツリーだけに保存）。保存・読取規則は上記に従う |
 | `target.workspace` | Linearのworkspace |
 | `target.team` | チームのキー（例 `SHINAPS`） |
 | `target.project` | 使うprojectのURL。projectを使わない運用では `null` |
@@ -46,16 +64,50 @@
 | `implementation_skill` | Issueの実装・修正に使うdevの入口。`dev-claude`・`dev-claude-ultra`（CodexがBridgeでClaudeへ依頼し、Claudeがその入口で実行する）、または `dev-codex`・`dev-codex-ultra`（Issueごとの別Codexタスクがその入口を実行し、会話側は進行・Agent QAを担当する） |
 | `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が行う） |
+| `path_policy_overrides` | パス別に人レビュー・AIコミット許可・コミットの進め方を上書きするルールの一覧。例外なしは `[]`。既存設定で欠落していれば例外なし（下の「パス別の方針」） |
 
-- `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ツールの権限やスキルの入口に加え、文書の中で実行主体の権限・担当・必須の工程や検証・コミットとレビューの条件を定める記述を含む。判定は各ファイルの役割と変更内容で行い、拡張子・ディレクトリ名・ファイル名のパターンだけを根拠にしない。判定できない差分は文書だけの変更として扱わない。例外を適用するために対象差分を分割しない。
+- `commit_mode` は進め方の設定であり、コミットの許可ではない。コミットは利用者の明示的な依頼、`permissions` の `commit`（条件は下の「許可」）、または適用されたパス別の `ai_commit: allow` に従う。`commit_mode` があるだけではコミット・pushを始めず、人のレビュー済みと推測しない。その場の明示的な指定は設定に優先する。`normal` は人が自分でgit操作をする工程（`code_review`）とは別のもの。
+- `implementation_skill` が決めるのは、実装・修正の担当と実行方式だけである。`permissions`・`stop_after`・人レビュー・コミットの方針と、`dev_delegation`・worktreeの作成・別セッションの作成の許可を変えない。その場の明示的な指定は設定に優先する。既存の設定にキーがなくても、自動で書き加えない。担当と工程の対応は [workflow.md](workflow.md) の「担当と窓口」にある。
+- `human_code_review: skip` は人のレビューの工程だけを省く。devの入口内のレビュー、検証、Agent QA、必要なHuman QAは省かない。省略は、人のレビュー済みとして記録しない。人レビュー・AIコミット許可・`stage`・`commit_mode` は互いに独立しており、一つから他を推測しない。
 - 工程キーは [workflow.md](workflow.md) の工程表と同じ。`statuses` の値はチームに実在する正確な名前にする。操作時はLinearから取得した状態のIDを使う。対応が曖昧・欠落・実物と不一致なら、その対応に依存する更新を止める。ステータスを自動で新設しない。
 - `team_settings: manage_on_setup` の場合も、通常実行ではチーム設定を変更しない。
 
+## パス別の方針
+
+`path_policy_overrides` は、各予定コミットに入る全変更を対象に方針を適用する。Linear進行でも単独の `commit` でも同じ規則を使う。新規設定は `path_policy_overrides: []` とし、具体的なパスと上書き項目を利用者と合意した場合だけルールを追加する。
+
+```yaml
+path_policy_overrides:
+  - paths: ["docs/**", "README.md"]
+    human_code_review: skip
+    ai_commit: allow
+    commit_mode: autonomous
+```
+
+- `paths` は空でないパターン一覧を必須とする。`human_code_review`（`required` / `skip`）、`ai_commit`（`allow` / `deny`）、`commit_mode`（`normal` / `autonomous`）は少なくとも一つ指定し、省略項目は通常設定を継承する。不正な値や構文は設定不備として依存工程を止める。
+- `ai_commit` の継承元は通常のコミット許可。`allow` はそのコミットのAIによる実行を認め、`deny` はそのコミットに対する継続的なコミット許可を取り消す。今回の利用者の明示指示を優先する。どちらも `stage` の許可を兼ねない。push・公開・終了地点・ツール権限や必要なQAも変更しない。
+- パス設定への合意は対象と工程の許可であり、変更内容に含まれる未合意仕様や権限拡張への承認ではない。内容や拡張子から例外許可を推定しない。
+
+### パターンとコミット全体の照合
+
+パスは作業対象リポジトリのルート相対、`/` 区切りで、大小文字を区別する。完全一致、同じ階層内の0文字以上に一致する `*`、独立したパス要素として0階層以上に一致する `**` だけを扱う（例: `docs/*` は直下、`docs/**` は配下全体、`**/README.md` はルートを含む各階層）。隠しファイルも通常の名前として扱う。リンク先を解決したり、現在存在するファイルへパターンを展開したりしない。絶対パス、`.` / `..` 要素、否定・文字クラス・波括弧展開などの未対応構文は設定不備として止める。
+
+各予定コミットの全変更に現れる旧・新パスが、一つのルールのパターン一覧で覆われる場合だけ、そのルールをそのコミット全体へ適用できる。追加は新パス、削除は旧パス、改名・移動は両方を含め、modeだけの変更も対象にする。新パスだけの一覧や現在残っているファイルだけでは判定しない。
+
+- コミット全体に適用できるルールがなければ、そのコミット全体を通常方針とする。複数ルールをファイル別・項目別に合成しない。
+- コミット全体に適用できるルールが複数ある場合、通常設定を継承した後の3項目がすべて同じならその方針を採用し、適用した全ルールを記録する。一つでも結果が異なれば依存工程を止めて競合の解消を求める。並び順やパターンの詳細度では優先しない。
+- モードによらず自然な責務単位を先に決め、その予定コミットごとに判定する。同じ依頼に別の変更があっても、独立した範囲内コミットには例外を適用できる。例外取得だけを目的とした恣意的な分割はしない。依頼全体は網羅性と最終照合に使い、方針を固定する単位にはしない。
+
+### 判定記録と変更時の扱い
+
+各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、継承後の実効3項目、今回の明示指示、`stage` の許可、検証・レビューの結果を記録する。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は [commit](../../skills/commit/SKILL.md) に従う。
+
+予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。実コミットが予定と異なれば停止し、履歴を無断で書き換えない。
+
+### 旧設定の移行
+
+`document_only_changes: none` は例外なしとして読めるため、自動変更や再合意は不要。旧 `document_only_changes: ai_commit` は廃止し、新設定と共存していても依存工程を止める。具体的なパスと上書き項目への移行、または例外廃止を利用者と合意してから旧キーを除く。説明だけの変更の許可とパスの許可は同値ではないため、自動変換・二重運用をしない。既存プロジェクトへ例外許可を自動追加しない。
+
 ## 終了地点
 
 初期設定ではこの一覧を示して選んでもらう。
@@ -78,7 +130,7 @@
 | `codex_task` | 対象IssueごとのCodex実装タスクの新規作成・状態確認・実装や修正や許可済みコミットの依頼。worktree作成、操作許可の追加、タスク側でのゴールや実装タスクの再作成は含めない。ツールの明示依頼要件も満たす（[codex-task.md](codex-task.md)） |
 | `bridge_request` | BridgeによるCodexからClaudeへの実装・修正の依頼と、ClaudeからCodexへの開発進行の引き渡し |
 | `stage` | レビュー・コミットの対象差分だけをステージする |
-| `commit` | 対象Issueの差分を、Local Agent QAの合格と `human_code_review` に従った工程の後に、`shinaps:commit` でローカルにコミットする。AIのコミットには `stage` の許可も併せて必要。push・PR・履歴の書き換え、人のレビューの省略を含めない。`document_only_changes: ai_commit` による文書だけの変更のコミットは、`commit` がなくても行える（`stage` は必要） |
+| `commit` | 対象Issueの差分を、Local Agent QAの合格と `human_code_review` に従った工程の後に、`shinaps:commit` でローカルにコミットする。AIのコミットには `stage` の許可も併せて必要。push・PR・履歴の書き換え、人のレビューの省略を含めない。パス別の `ai_commit` を含む実効方針に従う（上の「パス別の方針」） |
 | `push` | 対象Issueの作業ブランチの通常のpush |
 | `pr_create` | 対象IssueのPRの作成と更新 |
 | `merge` | 必要なQA・承認が揃った対象PRのマージと、元のブランチへ戻る操作 |
@@ -114,6 +166,7 @@ shinaps-skills側の例。shinaps-aiも、自分のリポジトリの設定で
 
 ```yaml
 # 設定を置いたこのリポジトリを作業先とするIssueに適用する。
+config_storage: shared
 target:
   workspace: shinaps
   team: SHINAPS
@@ -134,7 +187,7 @@ 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
+path_policy_overrides: []
 cycle_report: null
 permissions:
   - development_operations # この範囲を利用者が合意した場合だけ記載
@@ -145,36 +198,72 @@ permissions:
 references:
   specifications:
     - README.md
+    - .shinaps/linear/instructions.md
   environments: []
   deployment: []
   validation:
-    - README.md#開発と配布
-    - package.json
-  publication:
-    - README.md#CIとnpm自動公開
+    - .shinaps/linear/references/qa.md
+  publication: []
 ```
 
+この例では `instructions.md` と `qa.md` を採用して一緒に共有する。実際に必要な補足だけを選び、例に合わせた空ファイルは作らない。
+
 この例は `stop_after: pre_push_qa` なので、`post_commit` より後の工程の対応を書いていない。
 
 ## 初期設定
 
-依頼の実行に設定が必要で、「設定の読み方」で定めた保存先に設定がなければ、同じセッションで `linear-plan` の以下の手順を開始する。別PCではローカル設定が引き継がれないため、初期設定の案内やスキルの再実行依頼だけで止めない。設定なしでできる相談・読み取り・明示依頼されたIssue整理には、初期設定を必須にしない。
+依頼の実行に設定が必要で、「設定の読み方」により両方が真に不在と確認できた場合だけ、同じセッションで `linear-plan` の以下の手順を開始する。共有設定の欠落・不備をlocal設定の新規作成で補わない。初期設定の案内やスキルの再実行依頼だけで止めない。設定なしでできる相談・読み取り・明示依頼されたIssue整理には、初期設定を必須にしない。
 
 Claudeもこの手順で初期設定を行える。合意した設定の保存・確認後は元の依頼へ戻る。設定作成は元の依頼の実行範囲や担当、操作許可を増やさず、開発の進行役も変更しない。
 
 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`、`implementation_skill`）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。作業先リポジトリの既存の規約に文書だけの変更の例外がある場合だけ、その範囲と `document_only_changes` の範囲（「項目」の説明）を示して、`ai_commit` を設定するかを確認する。例外を使わない場合は `none` を記載する。
-5. 合意した内容を保存し、読み直して確認する。
-6. Linearのチーム設定の変更は、ローカル設定の保存とは別に扱う。対象チームと変更差分（追加・改名するステータスと順序）を示し、合意を得てから反映して読み戻す。反映後に `statuses` を実物に合わせて確定する。
+4. 既存の情報で決まらない運用上の決定（`config_storage`、`stop_after`、`permissions`（`commit` を含む）、`human_code_review`、`team_settings`、Cycle報告、`commit_mode`、`implementation_skill`）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。パス別の例外が必要な場合は、具体的な対象パターンと上書き項目、通常設定からの変更を示して合意する。例外を使わない新規設定には `path_policy_overrides: []` を記載する。旧設定の移行は上の手順に従う。
+5. 合意した方式の正本へ、下の保存手順に従って保存する。sharedでは採用する補足の `references` と共有対象を照合し、別checkoutでも同じ条件を読めるようにする。正本と補足を読み直して確認する。
+6. Linearのチーム設定の変更は、設定の保存とは別に扱う。対象チームと変更差分（追加・改名するステータスと順序）を示し、合意を得てから反映して読み戻す。反映後に `statuses` を実物に合わせて確定する。
 
 ## 設定変更
 
-初期設定と同じ手順で、既存の設定との差分を示して合意を得る。許可の追加を推測で補わない。
+初期設定と同じ手順で、既存の設定との差分を示して合意を得る。保存方式が未決の場合だけ `shared` / `local` を一問で確認し、すでに合意した方式は再質問しない。許可の追加を推測で補わない。
+
+- localからsharedへ変えるときは、端末固有情報を作業記録へ分け、必要補足の参照と共有対象、ignoreの差分を示す。既存の運用条件は一緒に共有するか共有済みの資料へ移す。補足を不採用にして黙って条件を削らず、条件自体の変更は別途合意する。
+- sharedからlocalへ変えるときは、メインにファイルを保全する方法、追跡解除の対象、Git履歴に内容が残ること、他checkoutへの影響を示す。他checkoutを自動編集しない。
+- 方式の合意だけではstage・commit・push・追跡解除を許可しない。対象操作を満たす既存の許可があれば再確認せず、その範囲で行う。キーの変更、共有準備、追跡、コミット、他checkoutでの取得を区別して報告する。
+
+## 設定の保存とGit共有
+
+localでは設定と補足をメインへ保存し、Git対象外にする。新規の `.shinaps/.gitignore` は次の内容と改行で作る。
+
+```gitignore
+*
+```
+
+sharedでは `.shinaps/.gitignore` 自身、`linear.yaml`、採用した補足だけを共有する。新規の例は次のとおり。`qa.md` は採用した個別資料の例であり、不要なら例外も作らない。
+
+```gitignore
+*
+!/.gitignore
+!/linear.yaml
+!/linear/
+!/linear/instructions.md
+!/linear/references/
+!/linear/references/qa.md
+/work/
+```
+
+既存のignoreを例で全面置換しない。無関係な規則を保ち、方式と採用資料に必要な差分だけを加える。深い資料には各親ディレクトリの例外も必要だが、`!linear/**` のような補足全体の共有はしない。localへの変更時も、無関係な例外を保ちながら設定・補足の共有例外を対象に見直す。
+
+親の `.shinaps/` が除外されている場合、ルートの `.gitignore` に `!/.shinaps/` など必要な差分を加えてから個別例外を確認する。ユーザーのグローバルignoreや `.git/info/exclude` は編集しない。必要な共有ができなければ原因を報告し、force-addで回避しない。
+
+`git check-ignore --no-index -v <対象パス>` で有効な除外規則と例外を確認し、`git ls-files -- <対象パス>` で追跡状態、`git status --short --untracked-files=all` で実際の変更を確認する。ignoreだけでは追跡済みファイルは対象外にならない。追跡解除は自動で行わず、対象・影響と許可を確認する。
+
+必要補足はYAMLと一緒に共有するか、同じ内容を確認できる共有済み資料への参照に置き換える。元のPCだけに必要補足が残る状態は共有未完了。URLとアクセス条件も別PCで同じ運用を確認できるものにする。ignore例外やファイルの存在だけで採用の有無を決めず、共有YAMLの `references` と実際の共有対象を揃える。cloneやworktreeでも、参照された補足の欠落を未採用と解釈しない。
+
+作業記録の初期化と保全は [作業記録](../work-records.md) に従う。
 
 ## 補足ファイルに書くもの
 
-`instructions.md` には、QA固有の注意（端末・ブラウザ・テストアカウントの取得方法への参照）、版の照合に使うコマンド、報告の文体・見せ方、関係者への依頼方法、環境の現状を書く。共通の手順は複製しない。
+`instructions.md` には、QA固有の注意（端末・ブラウザ・テストアカウントの取得方法への参照）、版の照合に使うコマンド、報告の文体・見せ方、関係者への依頼方法など、プロジェクト共通の条件・手順・相対パス・URLを書く。共通の手順は複製しない。端末固有の絶対パス、session/thread ID、一時的なログイン状態、進捗、QA結果は現在の `.shinaps/work/` へ記録する。秘密値はshared・localのどちらにも保存しない。
 
-CodexはClaudeへの依頼に、関係する部分と参照先を添える。
+委託時は保存方式、正本の所在、必要な補足・参照資料、合意済みの操作許可を渡す。CodexからClaudeへの依頼にも同じ情報を添える。

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

@@ -42,7 +42,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 | `ready` | Ready | 自分たちの作業を依存順に進めれば着手できる。開始時に、必要な前工程の成果を再確認する |
 | `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の依頼による）、なければ人が行う。対象コミットと、人の完了通知または省略の記録を照合する。`document_only_changes: ai_commit` があり、対象差分が文書だけの変更に当たる場合は、下の箇条に従う |
+| `code_review` | Code Review（人のレビューまたは省略の記録・コミット） | 各予定単位の実効方針が `human_code_review: required` なら人がレビュー・修正し、`skip` なら依頼も待ちも作らず省略を記録する。Local Agent QAの合格後（`required` なら人のレビュー完了の確認後）、実効方針でAIコミットが許可され、`stage` の許可もあれば、会話側のCodexの依頼で実装担当がコミットする。許可がなければ人が行う。対象コミットと人の完了通知または省略の記録を照合する |
 | `post_commit` | コミット後の検証・PR準備 | 設定に従って、push前の最終Agent QA、必須検証、許可されたpush・PR作成を行う |
 | `staging_agent_qa` | Staging Agent QA | 配備されたPR候補版をCodexが検証する |
 | `staging_human_qa` | Staging Human QA | そのPRで必要な人の確認。不要なら理由を記録して省略する |
@@ -57,23 +57,24 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 - 終了地点の工程がそのIssueにない場合は、適用される最後の必要工程まで進めて止まる。そのとき必須受入条件をすべて満たしていればDoneにする。満たしていなければ、残る条件を記録してDoneにしない（push前QAで止める運用で、本番公開の受入条件が残るIssueなど）。
 - 人がレビュー中に修正した場合は `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` の工程で、省略と、実施した確認（devの入口内のレビュー、Local Agent QA）への参照をIssueへ記録する。1行目には省略の根拠になった設定を書き、文書だけの変更の例外では判定の記録へのリンクを添える。
+- プロジェクトの規約や補足の記述だけでは、AIコミットの許可として扱わない。[共通設定のパス別の方針](configuration.md#パス別の方針)に従って、通常設定・適用ルール・今回の明示指示から実効方針を決める。
+- 実効方針が `human_code_review: skip` なら、Codexは `code_review` で対象単位を明示し、省略と実施した確認への参照をIssueへ記録する。人のレビュー済みとは記録しない。
 
   ```text
-  人のコードレビュー: 省略（作業先リポジトリの設定 <human_code_review: skip または document_only_changes: ai_commit>。文書だけの変更の例外では「判定: <Local Agent QAのコメントへのリンク>」を続ける）
+  人のコードレビュー: <対象単位>は省略（根拠: <通常設定または適用したパス別ルール>、判定: <Local Agent QAの記録へのリンク>）
   実施した確認: devの入口内のレビュー（使った場合。実装担当の完了報告 <コメントへのリンク>）、Local Agent QA（<記録へのリンク>）
-  コミット: <SHA>（<実際の実施者と方法>）
+  コミット: <SHAの一覧>（<実際の実施者と方法>）
   ```
 
-- `document_only_changes: ai_commit` がある場合は、次のとおり進める（文書だけの変更の定義は [configuration.md](configuration.md) の「項目」）。
-  - Local Agent QAで、Codexは受入条件の検証に加え、対象差分の全体が文書だけの変更に当たるかを判定し、範囲と理由をQAコメントに一度だけ記録する。
-  - 当たる場合、`required` でも人へのレビュー依頼も待ちも作らない。Claudeの入口では、CodexはClaudeへコミットを依頼し、依頼に判定の記録へのリンクを添える。
-  - 実装担当は、設定にこのキーと `stage` の許可があること、判定した対象差分が、作業ツリー上の同じ対象（ファイルと内容）の差分と一致することを確認してから `shinaps:commit` でコミットする。違えばコミットしない（Claudeの入口ではCodexへ返す）。差分の性質は判定し直さない。
-  - コミット後、Codexはコミットの内容が判定した差分と一致し、対象作業の未コミット変更が残らないことを照合する。一致しなければ次の工程へ進まず、SHA・判定した差分・実際の差分の違いをIssueに記録して人に確認する。履歴の書き換えはその場で確認する。
-  - 判定の後に対象差分が変わったら、新しい対象で判定とQAをやり直す。
-  - 照合の後に、上の省略の記録をIssueへ書く。
-  - 当たらない場合は、通常の `code_review`（`human_code_review` と `commit` に従う）のまま進める。
+### 単位案からコミット完了まで
+
+以下はClaude・Codexの両実装方式に共通する。単位計画の作成・確認にはコミット許可を要求しない。
+
+1. 実装担当は成果引き渡しに、モードによらず自然な責務で決めたコミット単位案と予定差分を含める。進行役のCodexはLocal Agent QAで対象を検証し、単位案が依頼全体を漏れなく覆い対象外変更を含まないことと、各単位の[判定記録](configuration.md#判定記録と変更時の扱い)を確認する。依頼の比較元と全体差分も最終照合用に記録する。
+2. 人レビューを待つかAIコミットを依頼するかは、各単位の実効方針で決める。QA合格とその単位に必要な人レビュー・AIコミット・stageの許可が揃ったら、CodexはQA結果、単位の判定記録、人レビュー完了の証拠または省略根拠を添えて実装担当へ依頼する。担当は設定・予定差分と記録の一致、許可を確認し、不一致なら実行せず進行役へ返す。
+3. 実装担当は [commit](../../skills/commit/SKILL.md) に従い、各単位のモードに応じた承認・隔離・検証・レビューを行う。同じ依頼内に通常・自律の単位が混在してよい。各コミット直前・作成後の実差分をその単位の予定差分と照合し、予定単位・SHA・照合結果・検証とレビュー結果を進行役へ返す。
+4. 全単位完了後、Codexは各コミットの単位照合結果を実差分で独立確認したうえで、依頼の比較元からの全体差分が対象と一致し、対象の未コミット変更が残っていないことを照合する。最終差分だけでは途中で混入し後で相殺された対象外変更を検出できないため、単位照合を省かない。人レビューを省略した単位は、上の省略記録を完成させる。
+5. 単位の組み替え・内容・設定の変更は[変更時の扱い](configuration.md#判定記録と変更時の扱い)に従って再判定し、必要なレビュー・許可確認・検証へ戻す。実コミットに不一致があれば次工程を止め、SHA・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
 
 ## 待ち状態
 
@@ -92,12 +93,12 @@ AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済み
 | 依頼・報告 | 含めるもの |
 | --- | --- |
 | 実装・修正の依頼（CodexからClaude） | Issueリンク、使う入口（`implementation_skill` の値、またはその場の明示的な指定）、範囲・受入条件、Gitの作業ディレクトリ・ブランチ・既存差分、許可範囲（`dev_delegation` の有無を含む）、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文。修正依頼では、再現手順・期待と実際・対象差分・証拠の場所を加える |
-| コミットの依頼（CodexからClaude） | Issueリンク、対象差分・Gitの作業ディレクトリ・ブランチ、Local Agent QAの結果、人のレビューの状態（完了通知の内容、または設定による省略）、返信先のCodexの `session_id` |
-| 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約と未解決の指摘。コミットした場合は、コミットSHAと `shinaps:commit` の検証・レビューの結果 |
+| コミットの依頼（CodexからClaude） | Issueリンク、Gitの作業ディレクトリ・ブランチ、返信先のCodexの `session_id` と、上の「単位案からコミット完了まで」で定める依頼情報 |
+| 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約と未解決の指摘。コミットした場合の返却情報は上の「単位案からコミット完了まで」に従う |
 | 人のレビュー・コミット完了の報告（ClaudeからCodex） | 下の「人のレビュー・コミット完了の報告」の項目 |
 | 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle・バックログの範囲と順序、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
 
-コミットの依頼では、`commit_mode` がない場合の開始時の確認と、通常モードの単位ごとの承認を、Codexが人へ取り次ぐ。Codexは自分で選択・承認しない。
+コミットの依頼では、単位の判定後もモードが決まらない場合の確認と、通常モードの単位ごとの承認を、Codexが人へ取り次ぐ。Codexは自分で選択・承認しない。
 
 実装・修正の依頼には次の文を含める。
 

package/plugins/shinaps-claude/references/work-records.md

@@ -0,0 +1,21 @@
+# 作業記録の保存と保全
+
+作業記録は現在の作業先リポジトリの `.shinaps/work/` 以下へ保存する。設定の保存方式に関係なくGit対象外とし、設定の上書きには使わない。各スキルが指定する配下の保存先を使う。
+
+最初に記録を作るときは `.shinaps/` を作成し、`.shinaps/.gitignore` がなければ次の内容と改行で作る。
+
+```gitignore
+*
+```
+
+既存のignoreは内容と共有例外を保持する。末尾に `*` を追加すると、先にある共有例外を打ち消すため追記しない。workの除外が不足する場合だけ、末尾に次を追加する。
+
+```gitignore
+/work/
+```
+
+記録作成では、設定の保存方式・共有対象・ルートやグローバルignore・`.git/info/exclude` を変更しない。設定の保存と共有対象の変更は [Linear共通設定](linear/configuration.md) に従う。
+
+Git管理下では `git check-ignore --no-index -v .shinaps/work/<記録パス>` で除外規則、`git ls-files -- .shinaps/work/` で追跡状態、`git status --short --untracked-files=all` で記録が変更に出ないことを確認する。追跡済みならignoreでは除外されないため報告し、自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。共有する仕様書など、明示された成果物の保存先は尊重する。秘密情報は記録しない。

package/plugins/shinaps-claude/skills/commit/SKILL.md

@@ -1,13 +1,11 @@
 ---
 name: commit
-description: 許可された差分を依存順のローカルコミットにし、各コミットを検証・レビューする。進め方（通常・自律）はプロジェクト設定のcommit_modeか開始時の確認で決め、選択された範囲で実行する。
+description: 許可された差分を依存順のローカルコミットにし、各コミットを検証・レビューする。進め方（通常・自律）は各単位の実効方針か確認で決め、選択された範囲で実行する。
 ---
 
 ## 作業記録の保存先
 
-作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
-
-既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
 
 # 検証できる単位でコミットする
 
@@ -21,15 +19,6 @@ description: 許可された差分を依存順のローカルコミットにし
 
 コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の `code_review` に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 
-開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linear-executeの開発進行では設定の不足・不正値を解消してから進む。linear-execute以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
-
-- **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
-- **自律**: エージェントが検証できる単位を選び（許可された一連の変更をまとめてよい）、検証・レビューして個別の承認を求めずコミットする。
-
-質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
-
-設定項目の独立性と併せて読む条件は[Linear共通設定](../../references/linear/configuration.md)に従う。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
-
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
 
 Git操作と修正は現在のセッションが行う。独立レビューは利用可能かつ許可された場合に使う。指定のエージェントがなければ、その役割の観点でレビューする。独立レビューがプロジェクトの必須条件なのに実行できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
@@ -41,18 +30,42 @@ Git操作と修正は現在のセッションが行う。独立レビューは
 - 検証コマンドはCI・スクリプト・規約から特定する。変更前からの失敗を今回の成功に混ぜない。
 - 退避する場合は、ステージ済み差分・未ステージ差分・untrackedの控えをリポジトリ外の作業領域へ保存する。控えは復元が確認できるまで残す。
 
-## 分割・検証・レビュー
+## 自然なコミット単位を決める
+
+モードによらず、一つの目的を説明でき、先行単位と既存コードだけで成立する責務単位を決める。実装と必要なテスト・生成物を切り離さず、依頼全体を漏れなく覆い、対象外変更を含めない。行数やファイル階層だけで分けず、例外取得だけを目的とした恣意的な分割はしない。単位案と予定差分、依頼の比較元と全体差分を記録する。単位計画の作成・確認にコミット許可は必要ない。
+
+## 各単位の方針とモードを決める
+
+予定単位ごとに、[パス別の方針](../../references/linear/configuration.md#パス別の方針)でそのコミットの全変更を判定し、同資料の判定記録を残す。Linear進行から記録を受け取った場合は、設定とその単位の予定差分（内容・mode等を含む）の一致を確認して引き継ぐ。単独の依頼でも同じ判定を使い、Linear専用の工程は追加しない。設定が真にない単独依頼では、今回の明示許可とプロジェクト規約を通常方針とし、パス例外は適用しない。
+
+実効方針のAIコミット許可、人レビューの条件、別途必要なstageの許可を確認する。旧設定の移行・競合・不備は共通設定に従って依存工程を止める。
+
+単位の判定後に、その対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、[Linear共通設定の読み方](../../references/linear/configuration.md#設定の読み方)で正本を決めた `.shinaps/linear.yaml` の通常設定と適用されたパス別ルールから実効 `commit_mode` が `normal` または `autonomous` と決まれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linear-executeの開発進行では設定の不足・不正値を解消してから進む。linear-execute以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で対象単位を示して「このコミットはどちらで進めますか？」と一問だけ聞く。
+
+- **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
+- **自律**: その単位を検証・レビューして個別の承認を求めずコミットする。
+
+質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。別単位の選択は流用しない。同じ依頼内で通常・自律が混在してよい。合意して保存された通常設定またはパス別ルールの `commit_mode` は、その単位への適用結果を使う。その場の明示的な指定は設定に優先する。
+
+設定項目の独立性と併せて読む条件は[Linear共通設定](../../references/linear/configuration.md)に従う。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
+
+モード決定後にレビュー可能性や依存関係のため単位を分割・統合する場合は、[変更時の扱い](../../references/linear/configuration.md#判定記録と変更時の扱い)に従って変更した単位を再判定し、必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。「自律だからまとめる」「通常だから分ける」を先に適用して単位決定と判定を循環させない。
+
+## 単位ごとの検証・レビュー・コミット
+
+以下を、その単位のモードで行う。
+
+1. 単位案を短く示す。通常モードで複数の単位に分ける場合、許可された独立レビュアーがいれば、各単位の差分だけで人が妥当性を判断できるかを差分自体から確認させ、結論はメインが実際の差分で検証する。自律モードでは単位案の独立レビューを求めない（プロジェクトの必須条件にある場合は従う）。
+2. コミットと検証の内容が単位だけで決まるようにする。通常モードでは、単位以外の未コミット変更（対象外、後続の単位、untracked）を一意な名前のstashへ退避し、作業ツリーとindexに単位の変更だけを残す。自律モードでは、対象外の変更を作業ツリーとindexに残してよく、検証結果が残る変更に依存しないことを根拠（例: 残る変更が検証の入力に含まれない）とともに判断する。依存する、または判断できない場合は、許可された範囲で単位をまとめ直すか、通常モードと同じ方法で退避する。退避が他の進行中の作業（他のセッションや人がステージ・編集中の変更）を妨げる場合は退避せず、所有者と調整できるまで止める。通常モードは別の隔離方法へ置き換えない。退避するときは、stashのindexにコミット対象のステージ済み変更を入れない。`git stash push` はパスを指定してもindex全体を保存し、対象のステージ済み変更が入ると後の `git stash apply --index` が失敗するため。対象のステージ済み差分のパッチを保存し、対象のステージを外してから退避し、退避後にそのパッチで対象のステージを戻す。作成前後のstash一覧を比べて今回作成されたものだけのSHAを記録し、既存stashの先頭を自分のものと決めつけない。共有ファイルのhunk分割は控えから行い、対象のhunkだけのステージを外せない場合や、対象外のステージ済みの変更が変わる場合は止める。
+3. コミットする内容に必要な検証を行う。後続や対象外の未コミット変更に依存した成功を、その単位の検証としない。範囲を限った検証はプロジェクトが認める場合だけ使い、必須検証を省かない。後続や対象外への依存で失敗するなら、手順2に戻って単位か隔離を見直す。
+4. 対象だけをステージし、実際にコミットされる差分の全体（indexのままコミットする場合は完全なcached diff）と影響するファイルをレビューする。indexに対象外の変更を残す場合は、それを含めずに対象だけをコミットする方法を使い、対象を限定できなければ止める。通常モードで提示する差分は、コミットされる差分と同じものにする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
+5. コミット直前の実差分がその単位の予定差分（パス・内容・mode等）と一致することを確認する。必須検証が通り、確定した阻害指摘がなく、通常モードなら単位の承認を得てから `git commit` を単独で実行する。メッセージはリポジトリ規約に従う。`git add` と連結しない。作成されたコミットの差分もその単位の予定差分と照合し、SHAと結果を記録する。後で相殺される対象外変更も許容しない。不一致なら次工程を止め、履歴を無断で書き換えない。
+6. 退避した場合は、コミット後または中断時に、indexにコミット対象のステージ済み変更がない状態で、記録したSHAのstashを `git stash apply --index` で戻す。中断時は対象のステージを外し、stashの復元を妨げる対象の未コミット変更（共有ファイルの対象のhunkなど）もパッチに保存して作業ツリーから一時的に外してから戻す。その後、外した対象の変更を戻し、対象のステージ済み差分のパッチで対象のステージを戻す。控えで扱った変更も復元し、コミット済みの変更を再び加えない。退避の有無によらず、コミットしていない変更（ステージ済み・未ステージ・untracked）と既存stashが、操作前の記録からコミットした内容を除いたものと一致することを確認する。一致しない、曖昧な競合がある、ステージ境界を戻せない場合は推測で消さず、一致しないパスと、退避した場合は回復資料を示して止める。一致を確認してから今回作成したstashだけをdropし、HEADを確認して次へ進む。
 
-1. 単位を決める。どちらのモードも、一つの目的を説明でき、適用済みの前の単位と既存コードだけで成立するよう依存順に並べ、実装と必要なテスト・生成物を切り離さない。行数やファイル階層だけで分けない。通常モードは人が差分だけで妥当性を判断できる単位に分ける。自律モードは一つの目的（例: 一つのIssueの変更）として説明できる範囲を一つのコミットにまとめてよく、人のレビュー量だけを理由に分けない。
-2. 単位案を短く示す。通常モードで複数の単位に分ける場合、許可された独立レビュアーがいれば、各単位の差分だけで人が妥当性を判断できるかを差分自体から確認させ、結論はメインが実際の差分で検証する。自律モードでは単位案の独立レビューを求めない（プロジェクトの必須条件にある場合は従う）。
-3. コミットと検証の内容が単位だけで決まるようにする。通常モードでは、単位以外の未コミット変更（対象外、後続の単位、untracked）を一意な名前のstashへ退避し、作業ツリーとindexに単位の変更だけを残す。自律モードでは、対象外の変更を作業ツリーとindexに残してよく、検証結果が残る変更に依存しないことを根拠（例: 残る変更が検証の入力に含まれない）とともに判断する。依存する、または判断できない場合は、許可された範囲で単位をまとめ直すか、通常モードと同じ方法で退避する。退避が他の進行中の作業（他のセッションや人がステージ・編集中の変更）を妨げる場合は退避せず、所有者と調整できるまで止める。通常モードは別の隔離方法へ置き換えない。退避するときは、stashのindexにコミット対象のステージ済み変更を入れない。`git stash push` はパスを指定してもindex全体を保存し、対象のステージ済み変更が入ると後の `git stash apply --index` が失敗するため。対象のステージ済み差分のパッチを保存し、対象のステージを外してから退避し、退避後にそのパッチで対象のステージを戻す。作成前後のstash一覧を比べて今回作成されたものだけのSHAを記録し、既存stashの先頭を自分のものと決めつけない。共有ファイルのhunk分割は控えから行い、対象のhunkだけのステージを外せない場合や、対象外のステージ済みの変更が変わる場合は止める。
-4. コミットする内容に必要な検証を行う。後続や対象外の未コミット変更に依存した成功を、その単位の検証としない。範囲を限った検証はプロジェクトが認める場合だけ使い、必須検証を省かない。後続や対象外への依存で失敗するなら、手順3に戻って単位か隔離を見直す。
-5. 対象だけをステージし、実際にコミットされる差分の全体（indexのままコミットする場合は完全なcached diff）と影響するファイルをレビューする。indexに対象外の変更を残す場合は、それを含めずに対象だけをコミットする方法を使い、対象を限定できなければ止める。通常モードで提示する差分は、コミットされる差分と同じものにする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
-6. 必須検証が通り、確定した阻害指摘がなく、通常モードなら単位の承認を得てから `git commit` を単独で実行する。メッセージはリポジトリ規約に従う。`git add` と連結しない。作成されたコミットの差分が予定した差分と一致することを確認する。
-7. 退避した場合は、コミット後または中断時に、indexにコミット対象のステージ済み変更がない状態で、記録したSHAのstashを `git stash apply --index` で戻す。中断時は対象のステージを外し、stashの復元を妨げる対象の未コミット変更（共有ファイルの対象のhunkなど）もパッチに保存して作業ツリーから一時的に外してから戻す。その後、外した対象の変更を戻し、対象のステージ済み差分のパッチで対象のステージを戻す。控えで扱った変更も復元し、コミット済みの変更を再び加えない。退避の有無によらず、コミットしていない変更（ステージ済み・未ステージ・untracked）と既存stashが、操作前の記録からコミットした内容を除いたものと一致することを確認する。一致しない、曖昧な競合がある、ステージ境界を戻せない場合は推測で消さず、一致しないパスと、退避した場合は回復資料を示して止める。一致を確認してから今回作成したstashだけをdropし、HEADを確認して次へ進む。
+全単位の完了後、各単位の照合結果に加え、元の比較元からの全体差分が元の対象と一致し、対象の未コミット変更が残っていないことを確認する。最終差分だけで途中コミットの照合を代用しない。予定どおりのコミットによる残差分の減少は不一致と扱わない。
 
 ## 終了・中断
 
 branch・HEAD・対象外ファイルの予期しない変更、復元の曖昧さ、仕様判断が必要な指摘では安全な状態を保って止める。検証の失敗を省略で解決しない。修正で過去のコミットを変えず、後続単位にする。
 
-コミット一覧、選んだ単位と隔離の有無、検証・レビューの範囲、残差分、復元状態を報告する。元からあったstashを保持し、今回のstashに残りがあれば回復方法を示す。未確認の独立性や検証を成功と報告しない。
+各単位の判定記録、コミット一覧、選んだ単位と前後の照合結果・全体照合結果、隔離の有無、検証・レビューの範囲、残差分、復元状態を報告する。元からあったstashを保持し、今回のstashに残りがあれば回復方法を示す。未確認の独立性や検証を成功と報告しない。