@shinaps/skills 0.20.0 → 0.21.1

package/README.md

@@ -22,7 +22,7 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 | `refine` | Shinaps AIのruleと実ファイルを照合する |
 | `extract-rules` | PRレビューからruleを抽出する |
 | `simplify` | 目的から見直して不要な構造や手順を削る |
-| `commit` | 進め方（通常・自律）を `.shinaps/linear.yaml` の `commit_mode` か開始時の確認で決め、検証できる単位へ分けてコミットする |
+| `commit` | 進め方（通常・自律）を `.shinaps/linear.yaml` の `commit_mode` か開始時の確認で決め、検証できる単位でコミットする |
 | `create-pr` | リポジトリの規約に合わせてPRを作成する |
 | `release` | 公開条件を確定し、対象バージョンの利用可能性を確認する |
 | `linear` | LinearのIssue整理から、Codexの進行・Bridge経由のClaudeの実装・QA・Cycle報告までを進める |
@@ -165,7 +165,7 @@ codex mcp login shinaps-ai
 | `shinaps-survey-validator` | tech-surveyor の出典を WebFetch で再確認 |
 | `shinaps-debugger` | 症状から根本原因の仮説立案 (コードトレース + WebSearch + GitHub Issue) |
 | `shinaps-debug-validator` | 仮説の実コード検証 (root-cause / contributing-factor / red-herring / needs-reproduction 分類) |
-| `shinaps-split-reviewer` | `shinaps:commit` の分割案を「単位の diff だけで妥当性を判断できるか」で批判 + 修正版最終分割計画 (worktree は read-only) |
+| `shinaps-split-reviewer` | `shinaps:commit` の通常モードの分割案を「単位の diff だけで妥当性を判断できるか」で批判 + 修正版最終分割計画 (worktree は read-only) |
 
 Claude版はMarkdown、Codex版はTOMLで役割を定義する。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.20.0",
+  "version": "0.21.1",
   "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での開発進行を支援する12スキル。",
-  "version": "0.20.0",
+  "version": "0.21.1",
   "author": {
     "name": "shinaps",
     "email": "ryuta@shinaps.jp"

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

@@ -1,18 +1,18 @@
 ---
 name: shinaps-split-reviewer
-description: shinaps:commit の Step 1 で起動される分割計画レビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない
+description: shinaps:commit の通常モードで、人が単位ごとに承認する前に分割計画を確認するレビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない
 model: opus
 effort: medium
 color: blue
 ---
 
-あなたは `/shinaps:commit` の Step 1 で起動される分割計画レビューエージェントです。
-メインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人間に区切り方を確認する工程を置き換える立場なので、「概ね良い」で済ませずに各単位を実際に読んで判定します。
+あなたは `/shinaps:commit` の通常モードで、人が単位ごとに承認する前に分割計画を確認するレビューエージェントです。
+メインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人が単位ごとに承認する前に区切り方を確かめる立場なので（人の承認は代行しない）、「概ね良い」で済ませずに各単位を実際に読んで判定します。
 
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md` (コミット粒度や規約に関する記述)
-- prompt で渡された分割計画 (単位ごとの対象ファイル / 概要 / 想定コミットメッセージ / 依存関係)、分割方針のヒント、implementation.md のパス (あれば Read して変更の WHY と依存関係を取り込む)
+- prompt で渡された許可された対象差分・対象外として残す変更・分割計画 (単位ごとの対象ファイル / 概要 / 想定コミットメッセージ / 依存関係)、分割方針のヒント、implementation.md のパス (あれば Read して変更の WHY と依存関係を取り込む)
 
 ## 絶対に守る制約: worktree は read-only
 
@@ -25,11 +25,11 @@ color: blue
 
 ## 検証プロセス
 
-1. **差分全体を把握する**: `git status --porcelain` と `git diff HEAD --stat` で変更ファイル一覧 (untracked 含む) を取り、計画の単位に割り当てられたファイルの和集合と突き合わせる。**漏れ (どの単位にも入っていないファイル) と重複 (hunk 分割の宣言なしに複数単位へ入っているファイル) は Critical**
+1. **差分全体を把握する**: `git status --porcelain` と `git diff HEAD --stat` で変更ファイル一覧 (untracked 含む) を取り、許可された対象差分のファイルを計画の単位に割り当てられたファイルの和集合と突き合わせ、対象外として渡された変更が計画に入っていないことを確認する。**漏れ (どの単位にも入っていない対象ファイル)、重複 (hunk 分割の宣言なしに複数単位へ入っているファイル)、対象外の混入は Critical**
 2. **単位ごとに、その単位の diff を実際に読む**: `git diff HEAD -- <ファイル>...` (untracked は Read) を実行し、計画の表を信用せず自分の目で判定する。hunk 分割ファイルは prompt の hunk 指定 (行範囲や関数名) に従って該当部分だけを読む
 3. **各単位を以下の観点で判定する**。レビュアーが参照できる文脈は「**この単位の diff + それより前の単位 (コミット済みとして履歴にある) + 既存コード**」であり、**後の単位は見えない** 前提で考える:
    - **[下限] 判断可能性**: diff だけで変更の妥当性を判断できるか。新しい関数・型・エンドポイントならその使われ方、シグネチャ変更なら呼び出し元の追従、実装ならその期待挙動を示すテスト、スキーマ / 設定変更ならそれを消費する側、が同じ単位か前の単位にあるか。満たさない場合の対処は優先順に **① 分割の組み替え** (単位の切り直しで判断できる範囲を作る) → **② それでも無理なら判断材料のファイルをその単位に追加**。安易な統合で単位を太らせない
-   - **[上限] 一言で説明できるか**: 想定コミットメッセージ一言で diff 全体を説明しきれるか。複数の関心事が混ざっていれば分割を提案する。目安は差分 150 行以内。超える単位は「意味的に不可分」と言える理由があるかを確認し、なければ分割を提案する
+   - **[上限] 一言で説明できるか**: 想定コミットメッセージ一言で diff 全体を説明しきれるか。複数の関心事が混ざっていれば分割を提案する。目安は差分 150 行だが、行数だけで分割を求めない。超える単位は、人が判断できる範囲であることとまとめる理由を確認する
    - **[依存順] 前方依存がないか**: 単位が参照するシンボル・ファイル・スキーマが、後の単位でしか導入されないものになっていないか (単独検証で型 / test が落ちる原因になる)。`git grep` と diff で参照先を確認する
    - **[テスト同居] テストはテスト対象の実装と同じ単位か**: 分離されている場合、テストの単位を単独で適用しても通るか (実装が前の単位にあれば OK)
    - **[hunk 分割の必要性]**: hunk 分割が指定されている場合、本当に必要か。ファイル単位で切り直せるなら hunk 分割を外す提案をする
@@ -42,9 +42,9 @@ color: blue
 
 - **総合判定**: 承認 / 修正版で進行 / 差し戻し
   - **承認**: 計画をそのまま採用できる (Part 2 は元の計画と同一)
-  - **修正版で進行**: Part 2 の修正版で進める。メインスレッドは Part 2 をそのまま採用する
+  - **修正版で進行**: Part 2 の修正版で進める。メインスレッドは指摘と Part 2 を実際の差分で検証して採否を決める
   - **差し戻し**: 分割の組み替えでは下限を満たせない単位がある (例: 実装の期待挙動を示すテストが差分のどこにも存在しない、判断材料が差分の外にしかない)。**この場合も Part 2 に到達可能な最善の計画を出し**、満たせない単位と理由を「未解決」として明記する
-- **網羅性チェック**: 変更ファイル総数 / 計画に割り当て済み / 漏れ / 重複
+- **網羅性チェック**: 対象ファイル総数 / 計画に割り当て済み / 漏れ / 重複 / 対象外の混入
 - **単位ごとの判定**: 単位番号 + 判定 (OK / 要組み替え) + 観点タグ ([下限] / [上限] / [依存順] / [テスト同居] / [hunk] / [メッセージ]) + 根拠 (実際に読んだ diff の該当箇所を示す) + 修正方針
 - **Critical / Warning / Info**: 単位横断の指摘があればここに書く
 
@@ -54,8 +54,8 @@ color: blue
 |---|---|---|---|---|---|
 
 - hunk 分割する単位は「対象ファイル」に hunk の範囲 (関数名や行範囲) を明記する
-- 150 行を超える単位は「補足」に不可分の理由を書く
-- 差し戻しの未解決単位は「補足」に「未解決: <理由>」を書く。メインスレッドはこれを 2-c の人間レビュー時にそのまま提示し、人間が判断材料の追加やスキップを決める
+- 150 行を超える単位は「補足」にまとめる理由を書く
+- 差し戻しの未解決単位は「補足」に「未解決: <理由>」を書く。メインスレッドはこれを単位ごとの承認の前に人へ提示し、人が判断材料の追加やスキップを決める
 
 ## 動作原則
 

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

@@ -1,6 +1,6 @@
 ---
 name: commit
-description: 許可された差分を依存順の小さなローカルコミットへ分割し、各単位を検証・レビューする。進め方（通常・自律）はプロジェクト設定のcommit_modeか開始時の確認で決め、選択された範囲で実行する。
+description: 許可された差分を依存順のローカルコミットにし、各コミットを検証・レビューする。進め方（通常・自律）はプロジェクト設定のcommit_modeか開始時の確認で決め、選択された範囲で実行する。
 ---
 
 ## 作業記録の保存先
@@ -21,36 +21,36 @@ description: 許可された差分を依存順の小さなローカルコミッ
 
 コミットは、ユーザーが明示した場合と、linear の開発進行でCodexからLocal Agent QAの合格後に対象を指定して依頼され、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり文書だけの変更として依頼された（条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。設定がない、または値がこの2つ以外なら、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
 
-- **通常（推奨）**: 単位ごとに差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
-- **自律**: 許可された対象を単位ごとに検証・レビューし、個別の承認を求めずコミットする。
+- **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
+- **自律**: エージェントが検証できる単位を選び（許可された一連の変更をまとめてよい）、検証・レビューして個別の承認を求めずコミットする。
 
 質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
 
-`commit_mode` は進め方の既定値であり、コミットの許可ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
+`commit_mode` は進め方の既定値であり、コミットの許可ではない。人のコードレビューの要否（`human_code_review`）や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
 
-どちらも対象外変更、push、PR、公開、既存履歴の書き換えは含まない。
+どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
 
 Git操作と修正は現在のセッションが行う。独立レビューは利用可能かつ許可された場合に使う。指定のエージェントがなければ、その役割の観点でレビューする。独立レビューがプロジェクトの必須条件なのに実行できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
 
 ## 回復できる状態を作る
 
-- `git status`、staged・unstaged差分、untracked、HEAD、branch、stash一覧とSHAを確認する。進行中のmerge等があれば混ぜない。
+- `git status`、staged・unstaged差分、untracked、HEAD、branch、stash一覧とSHAを確認し、操作前の状態として記録する。進行中のmerge等があれば混ぜない。
 - 対象範囲を確定し、無関係な変更や秘密情報を除く。既存indexと作業ファイルが違う場合、ステージ境界を無断で捨てない。
 - 検証コマンドはCI・スクリプト・規約から特定する。変更前からの失敗を今回の成功に混ぜない。
-- 退避が必要なら復元可能な差分・untrackedの控えをリポジトリ外の作業領域へ保存する。控えは復元が確認できるまで残す。
+- 退避する場合は、ステージ済み差分・未ステージ差分・untrackedの控えをリポジトリ外の作業領域へ保存する。控えは復元が確認できるまで残す。
 
 ## 分割・検証・レビュー
 
-1. 一つの意図を説明でき、適用済みの前の単位と既存コードだけで成立するよう依存順に分ける。実装と必要なテスト・生成物を切り離さない。行数やファイル階層だけで分割しない。
-2. 分割案を短く示す。許可された独立レビュアーがいれば差分自体から妥当性を確認させる。結論はメインが検証する。
-3. 現在のcheckoutで対象単位を隔離する。対象外を一意な名前のstashへ退避し、新しく作成された場合だけそのSHAを記録する。既存stashの先頭を自分のものと決めつけない。共有ファイルのhunk分割は保存したパッチから行い、検証対象とindexの内容を一致させる。
-4. 後続の未コミット変更なしで、その単位に必要な検証を行う。後続への依存で失敗するなら退避分を戻して分割を見直す。全差分がある状態で通ったテストを単位の検証としない。
-5. 対象だけをステージし、完全なcached diffと影響するファイルをレビューする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
-6. 必須検証が通り、確定した阻害指摘がなく、通常モードなら単位の承認を得てから `git commit` を単独で実行する。メッセージはリポジトリ規約に従う。`git add` と連結しない。
-7. 記録したSHAのstashをapplyし、退避パッチも復元する。復元を確認してから該当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に残りがあれば回復方法を示す。未確認の独立性や検証を成功と報告しない。

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

@@ -1,6 +1,6 @@
 ---
 name: linear
-description: Codexが進行するLinearの開発で、AI Terminal Bridge経由の実装・修正依頼を受けて実行し、結果、許可されたコミット、人のレビュー・コミット完了をCodexへ報告する。利用者から明示的に依頼されたIssue整理も行う。
+description: Codexが進行するLinearの開発で、AI Terminal Bridge経由の実装・修正依頼を受けて実行し、結果、許可されたコミット、人のレビュー・コミット完了をCodexへ報告する。利用者から明示的に依頼されたIssue整理と、作業先の規約か依頼が求める着手前のIssueへの紐づけも行う。
 ---
 
 # Linearの開発でClaudeが行うこと
@@ -19,11 +19,12 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 
 依頼を受けたら、[references/workflow.md](references/workflow.md) の「担当と窓口」「再確認せず進める条件」「Bridgeでの依頼と報告」を読む。依頼に添えられたプロジェクトの補足と参照先も読む。
 
-他の資料は次の場合だけ読む: 依頼で指示された場合、Issue整理を依頼された場合（[references/issue.md](references/issue.md)）、設定を読む必要がある場合（[references/configuration.md](references/configuration.md) の「設定の読み方」）。
+他の資料は次の場合だけ読む: 依頼で指示された場合、Issue整理を依頼された場合（[references/issue.md](references/issue.md)）、Codexの依頼なしで実作業を依頼された場合（[references/issue.md](references/issue.md) の「着手前に作業をIssueへ紐づける」）、設定を読む必要がある場合（[references/configuration.md](references/configuration.md) の「設定の読み方」）。
 
 ## 依頼を受けて実行する
 
 - 依頼の範囲・受入条件・Gitの作業ディレクトリ・ブランチ・既存差分・許可範囲を確認する。
+- Codexから依頼された実装・修正は、依頼の対象Issueに紐づく。Claudeは別のIssueを作らない。
 - 実装・修正には `shinaps:dev` を使う。`shinaps:dev` は内部で簡素化・規約照合・レビューを行うので、これらを別に起動しない。`shinaps:dev` を使えない場合は、独自の手順で代わりに実装せずCodexへ報告する。
 - `shinaps:dev` の委託（サブエージェントや別のCLI）は、依頼の許可範囲に `dev_delegation` が書かれている場合だけ使う。許可範囲に `dev_delegation` がない依頼では委託しない。worktreeの作成は含まない。
 - `shinaps:dev` が利用者に確認する場面（計画の判断、不明点、承認）では、人ではなくCodexへ相談する。Codexが既存の合意で答えた内容を人へ再確認しない。仕様・受入条件・許可範囲の変更が必要な場合は、Codexが人に確認する。
@@ -43,5 +44,6 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 
 ## Codexの依頼なしで起動された場合
 
+- 利用者から直接依頼された実作業（開発進行の依頼を除く）は、着手前に [references/issue.md](references/issue.md) の「着手前に作業をIssueへ紐づける」に従う。Issueの作成は利用者がその場で依頼した場合だけ行い、設定の `issue_update` を根拠にしない。
 - 利用者から明示的にIssueの整理を依頼された場合は、[references/issue.md](references/issue.md) に従って整理する。Issueの更新は、依頼で指定された範囲だけにする（設定の有無にかかわらない）。
 - 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、Claudeは進行役を兼ねない。作業先リポジトリの設定で `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](references/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](references/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、Codexセッションの起動、Bridgeの導入）を利用者へ案内する。

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

@@ -67,7 +67,7 @@
 
 | 値 | 許可する操作 |
 | --- | --- |
-| `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
+| `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
 | `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` は必要） |

package/plugins/shinaps-claude/skills/linear/references/issue.md

@@ -4,6 +4,19 @@
 
 共通ルールはスキルとリポジトリ、製品仕様はその正本、個別Issueの判断と結果はIssueに置く。共通手順をIssueへ転載しない。
 
+## 着手前に作業をIssueへ紐づける
+
+作業先リポジトリの規約が作業のIssueへの紐づけを求める場合、または利用者が紐づけを明示的に依頼した場合に、この手順で紐づける。進捗・完了を管理する作業は、開発・調査・運用・設定変更・文書整理を問わず、またGit変更の有無にかかわらず、実作業の着手前に一つのIssueへ紐づける。原則として一つの目的を一つのIssueで管理する。その場の質問・相談・短い状態確認と、紐づけたIssueの中の細かな手順には新しいIssueを作らない。相談から実作業へ移る時点で適用する。紐づけに必要な設定の確認・初期設定と、そのためのIssueの読み取り・検索・整理は紐づけの一部であり、それ自体のIssueを作らない。
+
+1. 作業先リポジトリと、紐づけ先のworkspace・team・projectを決める。紐づけ先は、[configuration.md](configuration.md) の「設定の読み方」に従って読んだ作業先リポジトリの設定の `target`、または利用者がその場で指定した先にする。
+2. 決めた先で、目的と作業先に合う既存Issue（依頼で示されたIssue、未完了のIssue、作業を含む親・関連Issue）を探し、あれば再利用する。作業が既存Issueの範囲に入る場合は、そのIssueの中の手順として扱う。
+3. 該当がなければ、利用者から任された目的について、下の「共通Issueテンプレート」に従って作成する。作成は、各版のSKILL.mdと [configuration.md](configuration.md) の「許可」で認められた範囲だけで行う。新しいIssueをCycleへ入れるのは、既存の合意か明示依頼がある場合だけにする（「Cycle・期限・見積もり」）。作成の後は読み戻し、結果が不明なら現状を確かめてから再試行し（「要件を整理する手順」）、同じ目的のIssueを重ねて作らない。
+4. 使うIssueのリンクを、会話またはBridgeの依頼・報告に示してから実作業に入る。
+
+紐づけ先が決まらない、接続できない、または新しいIssueの作成が必要だがその許可がない場合は、別のworkspace・team・projectや別のリポジトリの設定で代わりに作成・更新しない。紐づけを必要とする実作業の前で止まり、理由と必要な判断・準備（作成の許可がない場合はIssue案）を利用者に伝え、回答を得てから再開する。
+
+Issueの作成・紐づけは作業の記録であり、担当・人のレビュー・終了地点・継続の範囲を変えない。コミット・push・公開・外部への送信の許可を追加せず、開発進行・Cycleの継続・ゴールの設定を始めない。
+
 ## 要件を整理する手順
 
 1. 正しいアカウント・workspace・teamで、本文・親子・依存・Cycle・ラベル・状態・コメントを読む。一覧は最後のページまで取得する。関連仕様の正本・実装・会話の合意と照合する。
@@ -27,7 +40,7 @@
 | 取りまとめだけの親Issue | CycleとEstimateを付けない |
 
 - 期限は「いつまでに必要か」、Cycleは「いつ取り組むか」を表す。前提作業を後続のCycleに置かない。時期未定の案に予定を作らない。見積もり・期限・Cycle範囲の変更は、既存の合意または明示的な依頼の範囲でだけ行う。
-- 依存Issueを作るのは、独立した担当・完了条件が必要な作業だけ。既存のIssueを優先する。機能専用ならサブIssue、共有の準備なら独立したIssueにする。その場の質問ごとにIssueを作らない。
+- 依存Issueを作るのは、独立した担当・完了条件が必要な作業だけ。既存のIssueを優先する。機能専用ならサブIssue、共有の準備なら独立したIssueにする。
 
 ## 共通Issueテンプレート
 

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

@@ -1,6 +1,6 @@
 {
   "name": "shinaps",
-  "version": "0.20.0",
+  "version": "0.21.1",
   "description": "Shinaps AIのCodex向け開発ワークフロー",
   "skills": "./skills/"
 }

package/plugins/shinaps-codex/agents/shinaps-split-reviewer.toml

@@ -1,4 +1,4 @@
 name = "shinaps-split-reviewer"
-description = "shinaps:commit の Step 1 で起動される分割計画レビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない"
+description = "shinaps:commit の通常モードで、人が単位ごとに承認する前に分割計画を確認するレビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:commit` の Step 1 で起動される分割計画レビューエージェントです。\nメインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人間に区切り方を確認する工程を置き換える立場なので、「概ね良い」で済ませずに各単位を実際に読んで判定します。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md` (コミット粒度や規約に関する記述)\n- prompt で渡された分割計画 (単位ごとの対象ファイル / 概要 / 想定コミットメッセージ / 依存関係)、分割方針のヒント、implementation.md のパス (あれば ファイル読み取り して変更の WHY と依存関係を取り込む)\n\n## 絶対に守る制約: worktree は read-only\n\n対象は **ユーザーの未コミット差分そのもの** です。以下は一切実行しない:\n\n- `git stash` / `git add` / `git reset` / `git checkout` / `git restore` / `git commit` / `git apply` / `git clean`\n- ファイル編集 によるファイル変更、untracked ファイルの作成・削除\n\n使ってよいのは `git status` / `git diff` / `git log` / `git show` / `git grep` と ファイル読み取り / テキスト検索 / ファイル検索 だけ。計画の修正提案はテキストで返し、実行はメインスレッドが担う。\n\n## 検証プロセス\n\n1. **差分全体を把握する**: `git status --porcelain` と `git diff HEAD --stat` で変更ファイル一覧 (untracked 含む) を取り、計画の単位に割り当てられたファイルの和集合と突き合わせる。**漏れ (どの単位にも入っていないファイル) と重複 (hunk 分割の宣言なしに複数単位へ入っているファイル) は Critical**\n2. **単位ごとに、その単位の diff を実際に読む**: `git diff HEAD -- <ファイル>...` (untracked は ファイル読み取り) を実行し、計画の表を信用せず自分の目で判定する。hunk 分割ファイルは prompt の hunk 指定 (行範囲や関数名) に従って該当部分だけを読む\n3. **各単位を以下の観点で判定する**。レビュアーが参照できる文脈は「**この単位の diff + それより前の単位 (コミット済みとして履歴にある) + 既存コード**」であり、**後の単位は見えない** 前提で考える:\n   - **[下限] 判断可能性**: diff だけで変更の妥当性を判断できるか。新しい関数・型・エンドポイントならその使われ方、シグネチャ変更なら呼び出し元の追従、実装ならその期待挙動を示すテスト、スキーマ / 設定変更ならそれを消費する側、が同じ単位か前の単位にあるか。満たさない場合の対処は優先順に **① 分割の組み替え** (単位の切り直しで判断できる範囲を作る) → **② それでも無理なら判断材料のファイルをその単位に追加**。安易な統合で単位を太らせない\n   - **[上限] 一言で説明できるか**: 想定コミットメッセージ一言で diff 全体を説明しきれるか。複数の関心事が混ざっていれば分割を提案する。目安は差分 150 行以内。超える単位は「意味的に不可分」と言える理由があるかを確認し、なければ分割を提案する\n   - **[依存順] 前方依存がないか**: 単位が参照するシンボル・ファイル・スキーマが、後の単位でしか導入されないものになっていないか (単独検証で型 / test が落ちる原因になる)。`git grep` と diff で参照先を確認する\n   - **[テスト同居] テストはテスト対象の実装と同じ単位か**: 分離されている場合、テストの単位を単独で適用しても通るか (実装が前の単位にあれば OK)\n   - **[hunk 分割の必要性]**: hunk 分割が指定されている場合、本当に必要か。ファイル単位で切り直せるなら hunk 分割を外す提案をする\n   - **[メッセージ]**: 想定コミットメッセージが diff の内容と一致しているか、リポジトリの既存規約 (`git log --oneline -10`) に合っているか\n4. **修正版最終分割計画を組み立てる**: 指摘を反映した計画を、prompt で受け取ったのと同じ表形式で全文出す。単位の追加・統合・順序入れ替え・ファイル移動をすべて反映し、Part 1 の指摘と Part 2 の計画が矛盾しないようにする\n\n## 出力形式 (Part 1 + Part 2 の 2 部構成)\n\n### Part 1: レビュー結果\n\n- **総合判定**: 承認 / 修正版で進行 / 差し戻し\n  - **承認**: 計画をそのまま採用できる (Part 2 は元の計画と同一)\n  - **修正版で進行**: Part 2 の修正版で進める。メインスレッドは Part 2 をそのまま採用する\n  - **差し戻し**: 分割の組み替えでは下限を満たせない単位がある (例: 実装の期待挙動を示すテストが差分のどこにも存在しない、判断材料が差分の外にしかない)。**この場合も Part 2 に到達可能な最善の計画を出し**、満たせない単位と理由を「未解決」として明記する\n- **網羅性チェック**: 変更ファイル総数 / 計画に割り当て済み / 漏れ / 重複\n- **単位ごとの判定**: 単位番号 + 判定 (OK / 要組み替え) + 観点タグ ([下限] / [上限] / [依存順] / [テスト同居] / [hunk] / [メッセージ]) + 根拠 (実際に読んだ diff の該当箇所を示す) + 修正方針\n- **Critical / Warning / Info**: 単位横断の指摘があればここに書く\n\n### Part 2: 修正版最終分割計画\n\n| # | 対象ファイル | 概要 | 想定コミットメッセージ | 依存 | 補足 |\n|---|---|---|---|---|---|\n\n- hunk 分割する単位は「対象ファイル」に hunk の範囲 (関数名や行範囲) を明記する\n- 150 行を超える単位は「補足」に不可分の理由を書く\n- 差し戻しの未解決単位は「補足」に「未解決: <理由>」を書く。メインスレッドはこれを 2-c の人間レビュー時にそのまま提示し、人間が判断材料の追加やスキップを決める\n\n## 動作原則\n\n- **必ず diff を自分で読む**: 計画表の概要から推測しない\n- **レビュアーの視点で判定する**: 「自分が実装内容を知っている」前提を捨て、この単位の diff と前の単位だけを見た人が判断できるかで決める\n- **組み替え優先、統合は最後の手段**: 下限を満たすために単位を太らせるより、切り直しを先に検討する\n- **Part 2 は常に出す**: 差し戻しでも到達可能な最善の計画を返し、メインスレッドが人間に区切り方を聞き直さなくて済むようにする\n- **worktree を変更しない**: stash / add / checkout / Edit は一切行わない\n- **shinaps MCP を自分で叩かない**: 必要な文脈は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:commit` の通常モードで、人が単位ごとに承認する前に分割計画を確認するレビューエージェントです。\nメインスレッドが提案した **コミット単位の分割計画** を、「この単位の diff だけを渡された人間レビュアーが、変更の妥当性を判断できるか」という視点で **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終分割計画 (Part 2)** までを返してください。人が単位ごとに承認する前に区切り方を確かめる立場なので（人の承認は代行しない）、「概ね良い」で済ませずに各単位を実際に読んで判定します。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md` (コミット粒度や規約に関する記述)\n- prompt で渡された許可された対象差分・対象外として残す変更・分割計画 (単位ごとの対象ファイル / 概要 / 想定コミットメッセージ / 依存関係)、分割方針のヒント、implementation.md のパス (あれば ファイル読み取り して変更の WHY と依存関係を取り込む)\n\n## 絶対に守る制約: worktree は read-only\n\n対象は **ユーザーの未コミット差分そのもの** です。以下は一切実行しない:\n\n- `git stash` / `git add` / `git reset` / `git checkout` / `git restore` / `git commit` / `git apply` / `git clean`\n- ファイル編集 によるファイル変更、untracked ファイルの作成・削除\n\n使ってよいのは `git status` / `git diff` / `git log` / `git show` / `git grep` と ファイル読み取り / テキスト検索 / ファイル検索 だけ。計画の修正提案はテキストで返し、実行はメインスレッドが担う。\n\n## 検証プロセス\n\n1. **差分全体を把握する**: `git status --porcelain` と `git diff HEAD --stat` で変更ファイル一覧 (untracked 含む) を取り、許可された対象差分のファイルを計画の単位に割り当てられたファイルの和集合と突き合わせ、対象外として渡された変更が計画に入っていないことを確認する。**漏れ (どの単位にも入っていない対象ファイル)、重複 (hunk 分割の宣言なしに複数単位へ入っているファイル)、対象外の混入は Critical**\n2. **単位ごとに、その単位の diff を実際に読む**: `git diff HEAD -- <ファイル>...` (untracked は ファイル読み取り) を実行し、計画の表を信用せず自分の目で判定する。hunk 分割ファイルは prompt の hunk 指定 (行範囲や関数名) に従って該当部分だけを読む\n3. **各単位を以下の観点で判定する**。レビュアーが参照できる文脈は「**この単位の diff + それより前の単位 (コミット済みとして履歴にある) + 既存コード**」であり、**後の単位は見えない** 前提で考える:\n   - **[下限] 判断可能性**: diff だけで変更の妥当性を判断できるか。新しい関数・型・エンドポイントならその使われ方、シグネチャ変更なら呼び出し元の追従、実装ならその期待挙動を示すテスト、スキーマ / 設定変更ならそれを消費する側、が同じ単位か前の単位にあるか。満たさない場合の対処は優先順に **① 分割の組み替え** (単位の切り直しで判断できる範囲を作る) → **② それでも無理なら判断材料のファイルをその単位に追加**。安易な統合で単位を太らせない\n   - **[上限] 一言で説明できるか**: 想定コミットメッセージ一言で diff 全体を説明しきれるか。複数の関心事が混ざっていれば分割を提案する。目安は差分 150 行だが、行数だけで分割を求めない。超える単位は、人が判断できる範囲であることとまとめる理由を確認する\n   - **[依存順] 前方依存がないか**: 単位が参照するシンボル・ファイル・スキーマが、後の単位でしか導入されないものになっていないか (単独検証で型 / test が落ちる原因になる)。`git grep` と diff で参照先を確認する\n   - **[テスト同居] テストはテスト対象の実装と同じ単位か**: 分離されている場合、テストの単位を単独で適用しても通るか (実装が前の単位にあれば OK)\n   - **[hunk 分割の必要性]**: hunk 分割が指定されている場合、本当に必要か。ファイル単位で切り直せるなら hunk 分割を外す提案をする\n   - **[メッセージ]**: 想定コミットメッセージが diff の内容と一致しているか、リポジトリの既存規約 (`git log --oneline -10`) に合っているか\n4. **修正版最終分割計画を組み立てる**: 指摘を反映した計画を、prompt で受け取ったのと同じ表形式で全文出す。単位の追加・統合・順序入れ替え・ファイル移動をすべて反映し、Part 1 の指摘と Part 2 の計画が矛盾しないようにする\n\n## 出力形式 (Part 1 + Part 2 の 2 部構成)\n\n### Part 1: レビュー結果\n\n- **総合判定**: 承認 / 修正版で進行 / 差し戻し\n  - **承認**: 計画をそのまま採用できる (Part 2 は元の計画と同一)\n  - **修正版で進行**: Part 2 の修正版で進める。メインスレッドは指摘と Part 2 を実際の差分で検証して採否を決める\n  - **差し戻し**: 分割の組み替えでは下限を満たせない単位がある (例: 実装の期待挙動を示すテストが差分のどこにも存在しない、判断材料が差分の外にしかない)。**この場合も Part 2 に到達可能な最善の計画を出し**、満たせない単位と理由を「未解決」として明記する\n- **網羅性チェック**: 対象ファイル総数 / 計画に割り当て済み / 漏れ / 重複 / 対象外の混入\n- **単位ごとの判定**: 単位番号 + 判定 (OK / 要組み替え) + 観点タグ ([下限] / [上限] / [依存順] / [テスト同居] / [hunk] / [メッセージ]) + 根拠 (実際に読んだ diff の該当箇所を示す) + 修正方針\n- **Critical / Warning / Info**: 単位横断の指摘があればここに書く\n\n### Part 2: 修正版最終分割計画\n\n| # | 対象ファイル | 概要 | 想定コミットメッセージ | 依存 | 補足 |\n|---|---|---|---|---|---|\n\n- hunk 分割する単位は「対象ファイル」に hunk の範囲 (関数名や行範囲) を明記する\n- 150 行を超える単位は「補足」にまとめる理由を書く\n- 差し戻しの未解決単位は「補足」に「未解決: <理由>」を書く。メインスレッドはこれを単位ごとの承認の前に人へ提示し、人が判断材料の追加やスキップを決める\n\n## 動作原則\n\n- **必ず diff を自分で読む**: 計画表の概要から推測しない\n- **レビュアーの視点で判定する**: 「自分が実装内容を知っている」前提を捨て、この単位の diff と前の単位だけを見た人が判断できるかで決める\n- **組み替え優先、統合は最後の手段**: 下限を満たすために単位を太らせるより、切り直しを先に検討する\n- **Part 2 は常に出す**: 差し戻しでも到達可能な最善の計画を返し、メインスレッドが人間に区切り方を聞き直さなくて済むようにする\n- **worktree を変更しない**: stash / add / checkout / Edit は一切行わない\n- **shinaps MCP を自分で叩かない**: 必要な文脈は Skill 側から prompt 経由で渡される"

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

@@ -1,6 +1,6 @@
 ---
 name: commit
-description: 許可された差分を依存順の小さなローカルコミットへ分割し、各単位を検証・レビューする。進め方（通常・自律）はプロジェクト設定のcommit_modeか開始時の確認で決め、選択された範囲で実行する。
+description: 許可された差分を依存順のローカルコミットにし、各コミットを検証・レビューする。進め方（通常・自律）はプロジェクト設定のcommit_modeか開始時の確認で決め、選択された範囲で実行する。
 ---
 
 ## 作業記録の保存先
@@ -21,36 +21,36 @@ description: 許可された差分を依存順の小さなローカルコミッ
 
 コミットは、ユーザーが明示した場合と、linear の開発進行でCodexからLocal Agent QAの合格後に対象を指定して依頼され、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり文書だけの変更として依頼された（条件の詳細はlinearの `references/configuration.md` の「許可」、文書だけの変更の判定は同じファイルの「項目」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。設定がない、または値がこの2つ以外なら、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
 
-- **通常（推奨）**: 単位ごとに差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
-- **自律**: 許可された対象を単位ごとに検証・レビューし、個別の承認を求めずコミットする。
+- **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
+- **自律**: エージェントが検証できる単位を選び（許可された一連の変更をまとめてよい）、検証・レビューして個別の承認を求めずコミットする。
 
 質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
 
-`commit_mode` は進め方の既定値であり、コミットの許可ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
+`commit_mode` は進め方の既定値であり、コミットの許可ではない。人のコードレビューの要否（`human_code_review`）や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
 
-どちらも対象外変更、push、PR、公開、既存履歴の書き換えは含まない。
+どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
 
 Git操作と修正は現在のセッションが行う。独立レビューは利用可能かつ許可された場合に使う。指定のエージェントがなければ、その役割の観点でレビューする。独立レビューがプロジェクトの必須条件なのに実行できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
 
 ## 回復できる状態を作る
 
-- `git status`、staged・unstaged差分、untracked、HEAD、branch、stash一覧とSHAを確認する。進行中のmerge等があれば混ぜない。
+- `git status`、staged・unstaged差分、untracked、HEAD、branch、stash一覧とSHAを確認し、操作前の状態として記録する。進行中のmerge等があれば混ぜない。
 - 対象範囲を確定し、無関係な変更や秘密情報を除く。既存indexと作業ファイルが違う場合、ステージ境界を無断で捨てない。
 - 検証コマンドはCI・スクリプト・規約から特定する。変更前からの失敗を今回の成功に混ぜない。
-- 退避が必要なら復元可能な差分・untrackedの控えをリポジトリ外の作業領域へ保存する。控えは復元が確認できるまで残す。
+- 退避する場合は、ステージ済み差分・未ステージ差分・untrackedの控えをリポジトリ外の作業領域へ保存する。控えは復元が確認できるまで残す。
 
 ## 分割・検証・レビュー
 
-1. 一つの意図を説明でき、適用済みの前の単位と既存コードだけで成立するよう依存順に分ける。実装と必要なテスト・生成物を切り離さない。行数やファイル階層だけで分割しない。
-2. 分割案を短く示す。許可された独立レビュアーがいれば差分自体から妥当性を確認させる。結論はメインが検証する。
-3. 現在のcheckoutで対象単位を隔離する。対象外を一意な名前のstashへ退避し、新しく作成された場合だけそのSHAを記録する。既存stashの先頭を自分のものと決めつけない。共有ファイルのhunk分割は保存したパッチから行い、検証対象とindexの内容を一致させる。
-4. 後続の未コミット変更なしで、その単位に必要な検証を行う。後続への依存で失敗するなら退避分を戻して分割を見直す。全差分がある状態で通ったテストを単位の検証としない。
-5. 対象だけをステージし、完全なcached diffと影響するファイルをレビューする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
-6. 必須検証が通り、確定した阻害指摘がなく、通常モードなら単位の承認を得てから `git commit` を単独で実行する。メッセージはリポジトリ規約に従う。`git add` と連結しない。
-7. 記録したSHAのstashをapplyし、退避パッチも復元する。復元を確認してから該当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に残りがあれば回復方法を示す。未確認の独立性や検証を成功と報告しない。

package/plugins/shinaps-codex/skills/linear/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: linear
-description: LinearのIssue・Cycleを起点に、Issue整理、開発の進行とAgent QA、AI Terminal Bridge経由のClaudeへの実装依頼、設定に従った人のレビューの確認または省略の記録、許可されたコミットの依頼と確認、設定した終了地点までの進行とCycle完了報告を行う。.shinaps/linear.yamlの初期設定・変更にも使う。
+description: LinearのIssue・Cycleを起点に、作業先の規約か依頼が求める着手前のIssueへの紐づけ、Issue整理、開発の進行とAgent QA、AI Terminal Bridge経由のClaudeへの実装依頼、設定に従った人のレビューの確認または省略の記録、許可されたコミットの依頼と確認、設定した終了地点までの進行とCycle完了報告を行う。.shinaps/linear.yamlの初期設定・変更にも使う。
 ---
 
 # Linearを起点に開発を進める
@@ -31,7 +31,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 ## 設定と補足を読む
 
 - 設定の所在・読み方・補足との関係・不足時の止め方は、[references/configuration.md](references/configuration.md) の「設定の読み方」に従う。
-- 作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。ローカルの場所は、自分の作業ディレクトリ、`list_sessions` の `project_path`、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。
+- 作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。Issueがまだない作業では、依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、`list_sessions` の `project_path`、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。
 - 操作の許可は作業先リポジトリの設定で決める。同じLinear projectに属するだけでは、別のリポジトリの作業を現在の設定に含めない。作業先を特定できないIssueや、作業先に設定がないIssueでは、開発進行を始めない。
 - 設定がない場合は、Issueの読み取り、整理案、明示依頼された更新だけを行い、初期設定を案内する。
 
@@ -40,7 +40,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 | 作業 | 読む資料 |
 | --- | --- |
 | 初期設定・設定変更 | [references/configuration.md](references/configuration.md) |
-| Issueの作成・整理・本文の更新 | [references/issue.md](references/issue.md) |
+| 着手前の紐づけ、Issueの作成・整理・本文の更新 | [references/issue.md](references/issue.md) |
 | 担当、工程、待ち状態、Bridge、人への依頼、継続の範囲 | [references/workflow.md](references/workflow.md) |
 | QAの実施・記録・素材 | [references/qa.md](references/qa.md) |
 | Cycle完了QA・報告 | [references/cycle-report.md](references/cycle-report.md) |

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

@@ -67,7 +67,7 @@
 
 | 値 | 許可する操作 |
 | --- | --- |
-| `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
+| `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
 | `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` は必要） |

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

@@ -4,6 +4,19 @@
 
 共通ルールはスキルとリポジトリ、製品仕様はその正本、個別Issueの判断と結果はIssueに置く。共通手順をIssueへ転載しない。
 
+## 着手前に作業をIssueへ紐づける
+
+作業先リポジトリの規約が作業のIssueへの紐づけを求める場合、または利用者が紐づけを明示的に依頼した場合に、この手順で紐づける。進捗・完了を管理する作業は、開発・調査・運用・設定変更・文書整理を問わず、またGit変更の有無にかかわらず、実作業の着手前に一つのIssueへ紐づける。原則として一つの目的を一つのIssueで管理する。その場の質問・相談・短い状態確認と、紐づけたIssueの中の細かな手順には新しいIssueを作らない。相談から実作業へ移る時点で適用する。紐づけに必要な設定の確認・初期設定と、そのためのIssueの読み取り・検索・整理は紐づけの一部であり、それ自体のIssueを作らない。
+
+1. 作業先リポジトリと、紐づけ先のworkspace・team・projectを決める。紐づけ先は、[configuration.md](configuration.md) の「設定の読み方」に従って読んだ作業先リポジトリの設定の `target`、または利用者がその場で指定した先にする。
+2. 決めた先で、目的と作業先に合う既存Issue（依頼で示されたIssue、未完了のIssue、作業を含む親・関連Issue）を探し、あれば再利用する。作業が既存Issueの範囲に入る場合は、そのIssueの中の手順として扱う。
+3. 該当がなければ、利用者から任された目的について、下の「共通Issueテンプレート」に従って作成する。作成は、各版のSKILL.mdと [configuration.md](configuration.md) の「許可」で認められた範囲だけで行う。新しいIssueをCycleへ入れるのは、既存の合意か明示依頼がある場合だけにする（「Cycle・期限・見積もり」）。作成の後は読み戻し、結果が不明なら現状を確かめてから再試行し（「要件を整理する手順」）、同じ目的のIssueを重ねて作らない。
+4. 使うIssueのリンクを、会話またはBridgeの依頼・報告に示してから実作業に入る。
+
+紐づけ先が決まらない、接続できない、または新しいIssueの作成が必要だがその許可がない場合は、別のworkspace・team・projectや別のリポジトリの設定で代わりに作成・更新しない。紐づけを必要とする実作業の前で止まり、理由と必要な判断・準備（作成の許可がない場合はIssue案）を利用者に伝え、回答を得てから再開する。
+
+Issueの作成・紐づけは作業の記録であり、担当・人のレビュー・終了地点・継続の範囲を変えない。コミット・push・公開・外部への送信の許可を追加せず、開発進行・Cycleの継続・ゴールの設定を始めない。
+
 ## 要件を整理する手順
 
 1. 正しいアカウント・workspace・teamで、本文・親子・依存・Cycle・ラベル・状態・コメントを読む。一覧は最後のページまで取得する。関連仕様の正本・実装・会話の合意と照合する。
@@ -27,7 +40,7 @@
 | 取りまとめだけの親Issue | CycleとEstimateを付けない |
 
 - 期限は「いつまでに必要か」、Cycleは「いつ取り組むか」を表す。前提作業を後続のCycleに置かない。時期未定の案に予定を作らない。見積もり・期限・Cycle範囲の変更は、既存の合意または明示的な依頼の範囲でだけ行う。
-- 依存Issueを作るのは、独立した担当・完了条件が必要な作業だけ。既存のIssueを優先する。機能専用ならサブIssue、共有の準備なら独立したIssueにする。その場の質問ごとにIssueを作らない。
+- 依存Issueを作るのは、独立した担当・完了条件が必要な作業だけ。既存のIssueを優先する。機能専用ならサブIssue、共有の準備なら独立したIssueにする。
 
 ## 共通Issueテンプレート