@shinaps/skills 0.27.0 → 0.29.0

package/plugins/shinaps-codex/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に残りがあれば回復方法を示す。未確認の独立性や検証を成功と報告しない。

package/plugins/shinaps-codex/skills/create-pr/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) に従う。
 
 # 変更をレビューできるPRにする
 

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

@@ -13,4 +13,4 @@ description: 再現手順、コード、ログと必要な外部情報から不
 
 結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正まで依頼されている場合は$shinaps:dev-codex-ultraへ引き継ぐ。1体での実行を指定された場合は$shinaps:dev-codexを使う。調査だけなら変更しない。
 
-必要な記録は.shinaps/work/debug/へ保存し、.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定する。秘密情報・既存記録の削除・外部投稿は含めない。
+必要な記録は.shinaps/work/debug/へ保存し、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。秘密情報・既存記録の削除・外部投稿は含めない。

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

@@ -11,4 +11,4 @@ description: 既存挙動の理由、実装方針、変更の影響を対話し
 
 質問が曖昧なら結果を左右する点だけ一問確認する。回答後に新たな質問が来たら続け、仕様策定や修正へ自動で進まない。理解が揃い実装を依頼されたら、目的・合意事項・未確認事項・関連ファイルを引き継ぎ、$shinaps:dev-codex-ultraを読む。1体での実行を指定された場合は$shinaps:dev-codexを使う。
 
-継続用の記録が必要なら.shinaps/work/explorations/へ保存する。.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定し、秘密情報や無関係な記録を持ち込まない。MCPが使えないときはルール照合未確認と明記する。
+継続用の記録が必要なら.shinaps/work/explorations/へ保存する。[作業記録の共通手順](../../references/work-records.md)に従い、秘密情報や無関係な記録を持ち込まない。MCPが使えないときはルール照合未確認と明記する。

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

@@ -13,4 +13,4 @@ description: GitHubの過去PRレビューから繰り返し適用できる規
 4. 新規候補だけを対象repoのスコープへ、実際のMCPツールのスキーマに従って登録する。全プロジェクト共通へ広げる場合は利用者の判断を確認する。既存ルールの変更は差分を提示して許可を得る。
 5. 大量処理は100 PR程度のまとまりで結果を報告し、継続範囲を確認する。結果が不明な保存失敗では再投入の前に読み戻し、重複を避ける。
 
-終了時は処理したPR・コメント数、新規登録・更新・除外・未処理の件数と根拠を示す。取得・保存が部分的ならその範囲を明記する。記録する場合は.shinaps/work/を使い、.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定する。
+終了時は処理したPR・コメント数、新規登録・更新・除外・未処理の件数と根拠を示す。取得・保存が部分的ならその範囲を明記する。記録する場合は.shinaps/work/を使い、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。

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

@@ -28,7 +28,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 - 設定の所在・読み方・補足との関係・不足時の止め方は、[references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従う。
 - 作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。Issueがまだない作業では、依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、`list_sessions` の `project_path`、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。
 - 操作の許可は作業先リポジトリの設定で決める。同じLinear projectに属するだけでは、別のリポジトリの作業を現在の設定に含めない。作業先を特定できないIssueや、作業先に設定がないIssueでは、開発進行を始めない。
-- 依頼の実行に設定が必要で、作業先の設定がない場合は、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進む。保存・確認後に元の依頼へ戻り、設定と既存の許可の範囲で再開する。設定不要のIssueの読み取り、整理案、明示依頼された更新はそのまま行う。
+- 依頼の実行に設定が必要で、[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進む。保存・確認後に元の依頼へ戻り、設定と既存の許可の範囲で再開する。設定不要のIssueの読み取り、整理案、明示依頼された更新はそのまま行う。
 
 ## 作業ごとに読む資料
 

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

@@ -17,7 +17,7 @@ description: アイデアの相談・調査・仕様整理を行い、LinearのI
 
 ## 設定の初期作成・変更
 
-依頼の実行に設定が必要で、作業先の設定がない場合は、その場で [configuration.md](../../references/linear/configuration.md) の初期設定手順に進む。未決事項を一問ずつ確認し、合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
+依頼の実行に設定が必要で、[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、その場で [configuration.md](../../references/linear/configuration.md) の初期設定手順に進む。未決事項を一問ずつ確認し、合意済みの内容を保存する。運用項目を暗黙に補完しない。設定変更は実装開始を意味せず、実行範囲の既定値をYAMLに追加しない。
 
 ## 終了と引き渡し
 

package/plugins/shinaps-codex/skills/release/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) に従う。
 
 # リリースして利用可能性を確かめる
 

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

@@ -17,4 +17,4 @@ Shinaps AIのルール検索が利用できる場合は関連するルールを
 
 可読性は、対象言語の基礎を知るジュニアが初めて読んでも目的・流れ・判断理由を追えるかで判断する。推測する意味、同時に覚える状態、理解のための往復を減らし、短さや分割数、特定構文を目標にしない。正しさ・型の保証・既存の性能とプロジェクト規約を維持する。指摘には読み手の具体的な負担と軽減する修正案を示し、ほぼ同等の表現や好みだけの差は修正要求にしない。性能への影響が不明なら必要な検証を示す。委託する場合もこの判断軸を渡す。テストに関わる指摘は [テスト方針](../../references/testing.md) に従う。
 
-修正・コミット・PR投稿はユーザーに依頼された範囲だけ行う。記録が必要ならプロジェクトの.shinaps/work/に保存し、.shinaps/.gitignoreに必要な除外を追加する。既存内容と追跡済みファイルは保持する。
+修正・コミット・PR投稿はユーザーに依頼された範囲だけ行う。記録が必要ならプロジェクトの.shinaps/work/に保存し、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。

package/plugins/shinaps-codex/skills/simplify/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) に従う。
 
 # 目的から見直して減らす
 

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

@@ -13,4 +13,4 @@ description: 曖昧な要望を対話と既存実装・実現可能性の調査
 
 利用可能なShinapsルールを制約の根拠に含める。利用できないときはルール照合を未確認とし、実現可能性や仕様確定に残る影響を明記する。
 
-合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装依頼があれば$shinaps:dev-codex-ultraへこの記録を渡す。1体での実行を指定された場合は$shinaps:dev-codexを使う。仕様作成だけの依頼で自動実装しない。
+合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装依頼があれば$shinaps:dev-codex-ultraへこの記録を渡す。1体での実行を指定された場合は$shinaps:dev-codexを使う。仕様作成だけの依頼で自動実装しない。