@shinaps/skills 0.26.0 → 0.28.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-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数を追加しない。既存の情報で決まらず結果を左右する条件だけ確認し、保存を了承された方針をプロジェクト側に残す。
 
@@ -29,9 +31,9 @@ Shinaps AIの利用者向け開発ワークフロー。Claude CodeとCodexそれ
 | `linear-plan` | 相談・必要なspec/explore・Issue作成と整理・プロジェクト設定を行い、実装前で止める |
 | `linear-execute` | Issue単体・Cycle全体・バックログ消化を選び、設定に従って実装・QA・許可された公開を進める |
 
-コミット・PR・リリースは依頼された場合だけ進む。`autonomous-commit-review` の役割は `commit` に統合した。個人用の別AI呼び出し・ブラウザ管理・ゴール管理・動画制作はこのpluginに含めない。
+コミット・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` 欠落以外は未記載を既定値で補わない。実装の担当は作業先の `.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版へ同じ内容を複製し、テストで一致を確認する。
 
 `permissions` の `development_operations` を明示すると、既存アカウントのログイン・環境準備・依存導入・起動・テスト・QAを継続的に許可できる。コミット・公開・破壊的操作の許可や人レビューは別に扱う。
 
@@ -199,11 +201,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.26.0",
+  "version": "0.28.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.26.0",
+  "version": "0.28.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) に従う。
 
 ### プロジェクト条件
 
@@ -200,7 +198,9 @@ dev の入口（Claude 版 `dev-claude`・`dev-claude-ultra`、Codex 版 `dev-co
 
 実施したレビュー回数、設計担当1 の判断と修正内容、検証結果、未解決事項を報告する。2回目の後に修正した場合は、その最終差分が再レビューされていないことを明記する。必須検証の失敗や重大な未解決事項があれば作業終了と品質上の完了を区別し、完了済みとは報告しない。
 
-コミットが明示されていれば、その許可範囲と通常／自律モードを `commit` へ引き継ぐ。コミット依頼がなければ未コミットのまま完了し、毎回コミット許可を要求しない。PRやリリースは明示された場合だけ、それぞれ `create-pr`・`release` へ進む。
+Linearの開発進行から受けた実装・修正では、未コミットの差分と結果を進行役へ返す。dev完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)の継続許可と[担当と工程](../linear/workflow.md)に従い、QA後のコミット依頼を受ける。
+
+単独のdev依頼では、コミットが許可されていれば、その範囲と通常／自律モードを `commit` へ引き継ぐ。許可がなければ未コミットで結果を返し、毎回コミット許可を要求しない。PR・リリースも許可された範囲で `create-pr`・`release` へ渡す。単独利用にLinear進行や新しいゴールを必須にしない。
 
 ## 5. 成果物
 

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

@@ -5,13 +5,13 @@
 ## 作成と再利用
 
 - 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
-- 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で作業先を特定し、`create_thread` で新しいローカルCodexタスクを一つ作る。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。ツールが対象checkoutを選べない場合は別のcheckoutで代用せず、必要な準備を案内する。
+- 既存の同じIssueの実装タスクがあれば状態を読み直して再利用する。なければ `list_projects` で所属先を確認し、`create_thread` で新しいローカルCodexタスクを一つ作る。所属プロジェクトと実際の作業ディレクトリは一致を必須にしない。作業先が登録一覧にない場合も、利用者が指定した所属先を使い、対象checkoutの絶対パスを依頼に明記できる。実装担当は変更前に、指定先のGitルート・ブランチ・差分と適用される規約を確認し、以後の操作をその作業先で行う。指定先にアクセスできない場合は、別checkoutで代用せず必要な準備を報告する。会話全体をforkせず、実装に必要な情報だけを渡す。新しいworktreeは作らず、明示的に別途許可された場合だけ使う。
 - 返された確定済みthreadId・hostIdとIssue・checkout・branchをローカルの作業記録で対応づける。準備中のclientThreadIdを送信先にしない。作成結果が不明なときは一覧と状態を確認してから再試行する。
 - 同じIssueの質問回答・修正・許可されたコミット依頼は `send_message_to_thread` で同じタスクへ送る。モデルを利用者の指定なしに変更しない。dev内のモデル・役割構成は指定した入口に従う。
 
 ## 実装依頼に渡すもの
 
-Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、ローカル設定と補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
+Issueリンク・範囲・受入条件・仕様や調査成果物、指定devスキル、Gitの絶対作業ディレクトリ・ブランチ・現在の差分、設定の保存方式・正本と必要な補足の所在、合意済みの操作許可とユーザーの委託許可、必要な検証、会話側のタスクIDを渡す。秘密値をプロンプトへ転記しない。
 
 実装担当には次を明記する。
 
@@ -19,7 +19,7 @@ Issueリンク・範囲・受入条件・仕様や調査成果物、指定devス
 
 ## 待機・QA・修正
 
-会話側は `wait_threads` / `read_thread` で完了・質問・失敗を読み取り、実装結果を確認する。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。コミット依頼後はSHAも照合する。
+会話側は同じタスクを `wait_threads` / `read_thread` で観測し、完了・質問・失敗と実装結果を確認する。待機中のゴールと観測結果が得られない場合の扱いは [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。コミット依頼後はSHAも照合する。
 
 実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。
 

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

@@ -2,36 +2,56 @@
 
 設定は、運用上の決定と既存資料への参照を持つ。手順の全文は書かない。秘密値を保存しない。設定は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の証拠の要件は変えない。補足と設定が矛盾したら、設定に従って止め、どちらを直すか確認する。
 - 不足や矛盾があれば、影響する工程の開始前に止めて一問ずつ確認する。影響しない工程は続ける。許可の追加やステータスの新設を推測で補わない。
 - 終了地点は操作の許可を兼ねない。設定は、利用中のツールの権限や利用者の明示的な停止・撤回を上書きしない。
-- 利用者と合意して保存した設定の許可は、その対象・操作・条件の範囲で、作業先リポジトリの規約がいう合意・許可に当たる。設定ファイルが存在することや、AIが合意なしに加えた許可は、その根拠にしない。
+- 利用者と合意して保存した設定の許可は、その対象・操作・条件の範囲で、作業先リポジトリの規約がいう合意・許可に当たる。一般的な「明示依頼がある場合だけ」という条件も、この合意済みの範囲では満たすため、同じ操作の許可を改めて求めない。設定ファイルが存在することや、AIが合意なしに加えた許可は、その根拠にしない。利用者による今回の範囲限定・停止・撤回と、ツール固有の明示依頼条件は維持する。
+
+次工程を判断するときは、独立した `commit_mode`・`permissions`・`stop_after`・人レビューの条件を併せて読み、[担当と工程](workflow.md)で定めた担当と前工程の結果を確認する。一つの設定から他の許可や工程の完了を推測しない。終了・待機とゴール状態は [execution.md](execution.md) に従う。
 
 ## 項目
 
-以下の項目はすべて明示必須。省略・不正値を既定値で補わず、依存する工程を止めて設定を確認する。`null`・`none`・空の一覧は、以下で認めた箇所だけで「使用しない」を表す。
+以下の項目は明示必須（既存設定の `config_storage` 欠落だけは上記の扱い）。省略・不正値を既定値で補わず、依存する工程を止めて設定を確認する。`null`・`none`・空の一覧は、以下で認めた箇所だけで「使用しない」を表す。
 
 | キー | 内容 |
 | --- | --- |
+| `config_storage` | `shared`（Git共有）または `local`（メインの作業ツリーだけに保存）。保存・読取規則は上記に従う |
 | `target.workspace` | Linearのworkspace |
 | `target.team` | チームのキー（例 `SHINAPS`） |
 | `target.project` | 使うprojectのURL。projectを使わない運用では `null` |
@@ -112,6 +132,7 @@ shinaps-skills側の例。shinaps-aiも、自分のリポジトリの設定で
 
 ```yaml
 # 設定を置いたこのリポジトリを作業先とするIssueに適用する。
+config_storage: shared
 target:
   workspace: shinaps
   team: SHINAPS
@@ -143,34 +164,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` を実行しているセッションが行う。Claudeも利用者から明示的に依頼された設定を作成・変更できる。開発の進行役を変更するものではない。
+依頼の実行に設定が必要で、「設定の読み方」により両方が真に不在と確認できた場合だけ、同じセッションで `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`）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。作業先リポジトリの既存の規約に文書だけの変更の例外がある場合だけ、その範囲と `document_only_changes` の範囲（「項目」の説明）を示して、`ai_commit` を設定するかを確認する。例外を使わない場合は `none` を記載する。
+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/execution.md

@@ -4,9 +4,9 @@
 
 | モード | 対象 | 終了条件 |
 | --- | --- | --- |
-| Issue単体 | 指定Issue | そのIssueの完了 |
-| Cycle全体 | 指定Cycleの開始時点の対象Issue | 全件完了と合意された全体QA・成果報告 |
-| バックログ消化 | 指定プロジェクト・チーム・フィルター等で限定した開始時点のIssue集合 | 全件消化、または最初のブロッカーに到達し状況を報告 |
+| Issue単体 | 指定Issue | 合意された終了地点への到達 |
+| Cycle全体 | 指定Cycleの開始時点の対象Issue | 全件の合意された終了地点への到達と、依頼に含まれる全体QA・成果報告 |
+| バックログ消化 | 指定プロジェクト・チーム・フィルター等で限定した開始時点のIssue集合 | 全件の合意された終了地点への到達、または最初のブロッカーに到達し状況を報告 |
 
 ## 開始時に固定するもの
 
@@ -16,13 +16,14 @@
 
 各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。設定がない・不足する対象を他のリポジトリの設定で実行しない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
 
-`stop_after` がIssue完了より手前の場合は、開始前に今回の依頼との相違を解消する。途中の終了地点までを明示的に任された場合は、その到達点を実行ゴールとして記録し、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。操作許可を暗黙に増やさない。
+「このIssueを進めて」などの一般的な進行依頼では、設定の `stop_after` を到達点として記録する。Doneより手前という理由だけで再確認しない。具体的に指定された到達点と設定が矛盾する場合だけ、開始前に相違を解消する。途中の終了地点への到達を、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。操作許可を暗黙に増やさない。
 
 ## 継続と待機
 
 原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
 
-- 人レビュー・Human QA・本人認証・予定された手動コミット待ちは必要な工程として依頼し、作業中のまま待機する。回答がないことや待ち時間をブロッカー到達・承認・完了と扱わない。
+- 実装担当の作業中や、人レビュー・Human QA・本人認証・予定された手動コミット・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active` のまま待機する。回答がないことや待ち時間をブロッカー到達・承認・完了と扱わない。
+- 観測結果が得られないことだけでは終了条件を満たさない。同じタスクの状態を確認して待機を続け、新しい実装タスクやゴールを作る根拠にしない。
 - 許可範囲で自分が解消できる実装・QAの不具合は修正して再検証する。テストの失敗だけでバックログ実行を打ち切らない。
 - 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
 - バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
@@ -34,6 +35,6 @@
 
 ゴール機能が利用できない、作成に失敗した、または別の未完了ゴールと競合する場合は、理由と必要な準備を報告して実行開始前で止まる。ゴールなしで代替実行しない。
 
-通常の人の対応待ちで自発的にゴールを一時停止・完了にしない。ツール側のblocked等の状態条件、予算・実行制限と利用者の停止指示を優先する。Issueのステータスとゴールの状態を混同しない。バックログでは、事前に終了条件として合意した「ブロッカー到達と報告」を満たした場合に限り実行ゴールを完了にできる。
+通常の作業待ち・承認待ちだけでゴールを `blocked`・`paused`・`complete` にしない。`paused` は利用者が明示的に停止を求めた場合だけ使い、`blocked`・`complete` は実際のツールが定める条件を満たした場合だけ使う。予算・実行制限も維持し、制約を迂回する新しいゴールを作らない。Issueのステータスとゴールの状態を混同しない。バックログでは、事前に終了条件として合意した「ブロッカー到達と報告」を満たした場合に限り実行ゴールを完了にできる。
 
 再開時は記録した対象・到達点を読み直し、変更されたIssueや設定を照合する。対象の追加や、停止済みバックログの再開を独断で行わない。予約実行や定期監視は別の依頼が必要。

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

@@ -8,7 +8,7 @@
 | 実装担当 | 技術調査、`implementation_skill` で選んだdevの入口による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
 | 人 | 未合意の仕様・権限の判断、設定で必要なコードレビュー・必要な修正、AIに許可していないコミット、本人の操作が必要な認証等、必要なHuman QA |
 
-実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`・`dev-claude-ultra`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`・`dev-codex-ultra`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告を会話側とは別のCodex実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。Bridgeは使わない。どちらでもLocal Agent QAは実装とは別の工程として行い、実装担当の報告を合格の根拠にしない。
+実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`・`dev-claude-ultra`）では、ClaudeがCodexの指示に基づいてBridge経由で実装する。Codexの入口（`dev-codex`・`dev-codex-ultra`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告を会話側とは別のCodex実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。Bridgeは使わない。どちらでも実装担当はdev内レビューと検証を終えて進行役へ結果を返し、進行役がLocal Agent QAを行う。実装担当の報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
 
 人への質問と依頼は会話側のCodexが窓口になる。実装担当は人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
 
@@ -81,7 +81,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 待つときは、必要な対応・担当・再開条件・戻る工程をIssueのコメントへ記録する。人の回答や対応完了を確認したら続け、同じ依頼を繰り返さない。
 
-Linearの工程のステータスと、Codexのゴールの状態は別に扱う。人のレビュー・コミット、Human QA、その場の回答を待つ間、Linearは進行中の工程を維持し、Codexはゴールを作業中のまま利用可能な待機手段で待つ。人の応答待ちという理由だけで、自発的にゴールをblocked・一時停止・完了へ切り替えない。人からの通知を受けたら、対象を照合してから再開する。実行環境の上位の指示やゴール機能の制約はこのスキルで上書きできないため、環境が許す範囲で作業中を維持し、環境が状態の変更を要求する場合はその理由を利用者に説明する。制約を迂回する操作や、代わりの新しいゴールの作成はしない。
+Linearの工程のステータスと、Codexのゴールの状態は別に扱う。会話側のゴールの維持・終了・状態変更は [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。通知を受けたら対象と結果を照合し、次工程の許可と前提が揃っていれば再確認せずに続ける。
 
 ## Bridgeでの依頼と報告
 

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

@@ -5,9 +5,7 @@ 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) に従う。
 
 # 検証できる単位でコミットする
 
@@ -19,14 +17,16 @@ description: 許可された差分を依存順のローカルコミットにし
 
 ## 範囲と進め方
 
-コミットは、ユーザーが明示した場合と、linear-execute の開発進行でCodexからLocal Agent QAの合格後に対象を指定して依頼され、作業先リポジトリの `.shinaps/linear.yaml` が次のどちらかに当たる場合だけ行う: `permissions` に `commit` と `stage` がある、または `document_only_changes: ai_commit` と `permissions` の `stage` があり文書だけの変更として依頼された（条件の詳細は[Linear共通設定](../../references/linear/configuration.md) の「許可」、文書だけの変更の判定は同じファイルの「項目」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linear-executeの開発進行では設定の不足・不正値を解消してから進む。linear-execute以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
+コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の `code_review` に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+
+開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、[Linear共通設定の読み方](../../references/linear/configuration.md#設定の読み方)で正本を決めた `.shinaps/linear.yaml` に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。linear-executeの開発進行では設定の不足・不正値を解消してから進む。linear-execute以外の単独のコミット依頼で設定による選択がない場合は、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
 
 - **通常（推奨）**: 人がレビューする単位ごとに、単位以外の変更をstashへ退避して差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
 - **自律**: エージェントが検証できる単位を選び（許可された一連の変更をまとめてよい）、検証・レビューして個別の承認を求めずコミットする。
 
 質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
 
-`commit_mode` は進め方の設定であり、コミットの許可ではない。人のコードレビューの要否（`human_code_review`）や、ステージ・コミット・push・PR・公開の許可とは独立しており、どちらのモードもそれらを変えない。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
+設定項目の独立性と併せて読む条件は[Linear共通設定](../../references/linear/configuration.md)に従う。`autonomous` は人のコードレビューの省略ではなく、`human_code_review: skip` は通常モードの単位ごとの承認の省略ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
 
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
 

package/plugins/shinaps-claude/skills/create-pr/SKILL.md

@@ -1,13 +1,11 @@
 ---
 name: create-pr
-description: ブランチの変更意図と検証結果を整理し、リポジトリの規約に合ったGitHub PRを作成する。PR作成・公開を依頼されたときに使う。
+description: ブランチの変更意図と検証結果を整理し、リポジトリの規約に合ったGitHub PRを作成する。PR作成・公開の依頼または合意済みの継続許可があるときに使う。
 ---
 
 ## 作業記録の保存先
 
-作業記録はプロジェクトルートの `.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) に従う。
 
 # 変更をレビューできるPRにする
 
@@ -17,6 +15,8 @@ description: ブランチの変更意図と検証結果を整理し、リポジ
 
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
 
+Linearの開発進行から受けた依頼では、[共通設定](../../references/linear/configuration.md)の合意済みの許可と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+
 ## 差分と宛先
 
 プロジェクトルート、Git状態、remote、対象アカウント、base・headを確認する。ユーザーの指定を優先し、base未指定ならGitHubのdefault branchを取得する。比較には取得したリモートのbase refを使い、古いローカルブランチだけで判断しない。

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

@@ -6,9 +6,7 @@ argument-hint: <なし | エラーメッセージ / 症状の説明 | ファイ
 
 ## 作業記録の保存先
 
-作業記録はプロジェクトルートの `.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) に従う。
 
 ## 実行環境とプロジェクト条件
 

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

@@ -1,6 +1,6 @@
 ---
 name: dev-claude
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは別途明示された場合だけ行う。
+description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化をそれぞれ1体で確認する。実装依頼で1体での実行を指定されたときに使う。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
 argument-hint: <実装したい機能・解決したい課題>
 ---
 

package/plugins/shinaps-claude/skills/dev-claude-ultra/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dev-claude-ultra
-description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。機能追加や修正の実装依頼の既定。コミットは別途明示された場合だけ行う。
+description: 既存設計とプロジェクトの条件を確認し、計画・実装・簡素化・検証・レビューを行う。設計・計画レビュー・計画簡素化を同じ役割の2体で独立に確認する。機能追加や修正の実装依頼の既定。コミットは許可と工程の条件に従い、Linear進行ではQAへ結果を返す。
 argument-hint: <実装したい機能・解決したい課題>
 ---
 

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

@@ -6,9 +6,7 @@ argument-hint: <調べたいバグ・挙動・実装上の疑問（省略可）>
 
 ## 作業記録の保存先
 
-作業記録はプロジェクトルートの `.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) に従う。
 
 ## 実行環境とプロジェクト条件
 

package/plugins/shinaps-claude/skills/extract-rules/SKILL.md

@@ -6,9 +6,7 @@ argument-hint: (引数なし、対話で owner-repo / since を確認)
 
 ## 作業記録の保存先
 
-作業記録はプロジェクトルートの `.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) に従う。
 
 ## 実行環境とプロジェクト条件
 

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

@@ -30,12 +30,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 - devの入口が利用者に確認する場面（計画の判断、不明点、承認）では、人ではなくCodexへ相談する。Codexが既存の合意で答えた内容を人へ再確認しない。仕様・受入条件・許可範囲の変更が必要な場合は、Codexが人に確認する。
 - QAで見つかった不具合の修正依頼も同じ扱いにし、人の着手許可を改めて取らない。
 - 同じ作業ツリーをCodexや人と同時に編集しない。人や他のAIの変更を保持する。
-- Claudeは次のいずれかの場合だけコミットする。
-  - 利用者本人がその場で明示的に依頼した場合。
-  - 作業先リポジトリの設定の `permissions` に `commit` と `stage` があり、CodexがLocal Agent QAの合格後にコミットを依頼した場合。
-  - 設定に `document_only_changes: ai_commit` と `stage` があり、CodexがLocal Agent QAの合格後に文書だけの変更としてコミットを依頼した場合。
-
-  後の2つでは、Claude自身が設定（[references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」）で必要なキーと許可を確認する。3つ目では、依頼された対象差分が、作業ツリー上の同じ対象（ファイルと内容）の差分と一致することも確認する（[references/workflow.md](../../references/linear/workflow.md) の `code_review`）。実装完了の直後に先行してコミットしない。それ以外のCodexの依頼はコミットの許可にならない。コミットは `shinaps:commit` で行い、進め方は `commit_mode` か開始時の確認で決める。確認と承認の扱いは、[references/workflow.md](../../references/linear/workflow.md) の「Bridgeでの依頼と報告」に従う。
+- コミットの許可は[共通設定](../../references/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の `code_review` に従う。実装完了の直後に先行してコミットせず、進行役へ結果を返す。条件を満たす依頼を受けたら `shinaps:commit` を使い、許可済みの操作を再確認しない。確認と承認の取り次ぎは同じ文書の「Bridgeでの依頼と報告」に従う。
 
 ## 結果と人の対応を報告する
 
@@ -48,4 +43,4 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 
 - 利用者から直接依頼された実作業（開発進行の依頼を除く）は、着手前に [references/issue.md](../../references/linear/issue.md) の「着手前に作業をIssueへ紐づける」に従う。Issueの作成は利用者がその場で依頼した場合だけ行い、設定の `issue_update` を根拠にしない。
 - 利用者から明示的にIssueの整理を依頼された場合は、[references/issue.md](../../references/linear/issue.md) に従って整理する。Issueの更新は、依頼で指定された範囲だけにする（設定の有無にかかわらない）。
-- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、Claudeは進行役を兼ねない。作業先リポジトリの設定で `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](../../references/linear/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、Codexセッションの起動、Bridgeの導入）を利用者へ案内する。
+- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、Claudeは進行役を兼ねない。[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進み、保存・確認後に元の依頼の引き渡しへ戻る。作業先リポジトリの設定で `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](../../references/linear/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、Codexセッションの起動、Bridgeの導入）を利用者へ案内する。

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

@@ -17,8 +17,8 @@ description: アイデアの相談・調査・仕様整理を行い、LinearのI
 
 ## 設定の初期作成・変更
 
-[configuration.md](../../references/linear/configuration.md)の手順で合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
+依頼の実行に設定が必要で、[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、その場で [configuration.md](../../references/linear/configuration.md) の初期設定手順に進む。未決事項を一問ずつ確認し、合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
 
 ## 終了と引き渡し
 
-作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。
+作成・更新したIssue、決定事項、未決事項と依存を示して終了する。相談だけなら結論を返す。開発用ゴールの設定、実装、コミット・公開には進まない。設定のために `linear-execute` から移った場合は、保存・確認後に元の依頼へ戻り、設定と既存の許可の範囲で再開する。それ以外では、利用者が続けて実行を明示的に依頼したときだけ `shinaps:linear-execute` へIssueと成果物を渡し、実行範囲を確定する。

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

@@ -6,9 +6,7 @@ argument-hint: "[<file/dir path> | <PR URL> | <commit SHA> | <range>] (省略時
 
 ## 作業記録の保存先
 
-作業記録はプロジェクトルートの `.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) に従う。
 
 ## 実行環境とプロジェクト条件
 

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

@@ -1,13 +1,11 @@
 ---
 name: release
-description: プロジェクトの公開手順と完了条件に従ってリリースし、対象バージョンが利用可能なことを検証する。公開・配布・本番デプロイを依頼されたときに使う。
+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) に従う。
 
 # リリースして利用可能性を確かめる
 
@@ -17,6 +15,8 @@ description: プロジェクトの公開手順と完了条件に従ってリリ
 
 既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
 
+Linearの開発進行から受けた依頼では、[共通設定](../../references/linear/configuration.md)の合意済みの許可と[担当・工程](../../references/linear/workflow.md)を引き継ぐ。操作後は進行役へ結果を返し、[終了条件](../../references/linear/execution.md)に従って次工程を判断する。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+
 ## 公開前に条件を確定する
 
 対象環境・配布先・ソースrevision・成果物のバージョンと、成功を判断する操作・証拠を確定する。リポジトリのリリース手順を使い、既存CIや証拠形式があれば再利用する。専用のJSON形式や新しい検証基盤を導入すること自体を必須にしない。