npm - @shinaps/skills - Versions diffs - 0.32.0 → 0.33.0 - Mend

@shinaps/skills 0.32.0 → 0.33.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (45) hide show

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

@@ -22,11 +22,11 @@ description: 許可された差分を依存順のローカルコミットにし
 ## 範囲と進め方
-コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の `code_review` に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
+コミットは利用者の明示依頼、または[Linear共通設定](../../references/linear/configuration.md)の合意済みの許可に従う。Linear進行では[担当と工程](../../references/linear/workflow.md)の差分確定に従い、Local Agent QA後に進行役から対象を指定した依頼を受けて行う。単独の依頼にはLinear進行や新しいゴールを必須にしない。
 どちらのモードも、許可された対象以外の変更と秘密情報、push、PR、公開、既存履歴の書き換えを含まない。
-AIが担当するGit準備・修正は現在のセッションで行い、manualのレビュー・修正・commitは人が行う。autoは独立レビューを必須とする。必要な担当・許可が利用できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
+Git準備・修正・commitはAIが現在のセッションで行い、manualのレビュー・承認は人が行う。autoは独立レビューを必須とする。必要な担当・許可が利用できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
 ## 回復できる状態を作る
@@ -43,17 +43,15 @@ AIが担当するGit準備・修正は現在のセッションで行い、manual
 予定単位ごとに、[パス別の方針](../../references/linear/configuration.md#パス別の方針)でそのコミットの全変更を判定し、同資料の判定記録を残す。Linear進行から記録を受け取った場合は、設定とその単位の予定差分（内容・mode等を含む）の一致を確認して引き継ぐ。単独の依頼でも同じ判定を使い、Linear専用の工程は追加しない。設定が真にない単独依頼では、今回の明示許可とプロジェクト規約を通常方針とし、パス例外は適用しない。
-合意済みの実効 `review_flow` と今回の明示指示から進め方を確定する。両方とも対象のstageを許可し、`auto` ではAI、`manual` では人がcommitする。設定の存在だけを合意と扱わない。旧キー・不備・競合は共通設定に従って止める。
+合意済みの実効 `review_flow` と今回の明示指示から進め方を確定する。両方とも対象のstageとAIのcommitを許可し、`auto` では独立レビュー後、`manual` では人の単位承認後にAIがcommitする。設定の存在だけを合意と扱わない。旧キー・不備・競合は共通設定に従って止める。
-設定がない単独依頼でも「各単位をAIがレビューして自動コミット」「人がレビューして自分でコミット」など明確な意図を引き継ぐ。「コミットして」「進めて」だけからautoを推測しない。flowが未解決のときだけ対象を示し「auto（AIがレビュー・コミット）とmanual（人がレビュー・修正・コミット）のどちらで進めますか？」と一問聞き、回答まで依存操作を待つ。未回答を承認と扱わない。同じ依頼内でもパス例外により異なるflowの単位があってよい。
+設定がない単独依頼でも「各単位をAIがレビューして自動コミット」「単位ごとに見せて承認後にコミット」など明確な意図を引き継ぐ。「コミットして」「進めて」だけからautoを推測しない。flowが未解決のときだけ対象を示し「auto（AIがレビュー・コミット）とmanual（人がレビュー・承認し、AIが修正・コミット）のどちらで進めますか？」と一問聞き、回答まで依存操作を待つ。未回答を承認と扱わない。同じ依頼内でもパス例外により異なるflowの単位があってよい。
 モード決定後にレビュー可能性や依存関係のため単位を分割・統合する場合は、[変更時の扱い](../../references/linear/configuration.md#判定記録と変更時の扱い)に従って変更した単位を再判定し、必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。「autoだからまとめる」「manualだから分ける」を先に適用して単位決定と判定を循環させない。
 ## 単位ごとの検証・レビュー・コミット
-manualでは[人レビューの差分提示](../../references/human-review.md)に従う。実装runtimeによらず、実効 `review_flow.tool`（`plasma` / `webstorm`）で対象を提示する。未指定や利用不能なら止め、無断で別UIに切り替えない。人がレビュー・修正・commitする工程をAIによる承認後commitへ置き換えない。
-Claude CLIの非対話実行でmanualを準備する場合は、stash・stage・検証と対象情報をresultへ返してprocessを終了する。人への提示と完了待ちは進行役が行い、CLI内で対話を待たない。完了後の同じsessionへのresumeでHEAD・人の修正・実コミット・stash情報を受け、以下の照合と復元を続ける。
+manualでは[manualの差分提示と単位承認](../../references/human-review.md)に従い、人と対話できるセッションで提示・相談・承認を受ける。ローカルClaude CLIの非対話実行でmanualの単位を検出した場合は、手順を進めず、判定を記録してresultへ返す（[経路](../../references/linear/configuration.md#経路)）。
 以下を、その単位のモードで行う。
@@ -61,7 +59,7 @@ Claude CLIの非対話実行でmanualを準備する場合は、stash・stage・
 2. コミットと検証の内容が単位だけで決まるようにする。manualでは、単位以外の未コミット変更（対象外、後続の単位、untracked）を一意な名前のstashへ退避し、作業ツリーとindexに単位の変更だけを残す。autoでは、対象外の変更を作業ツリーとindexに残してよく、検証結果が残る変更に依存しないことを根拠（例: 残る変更が検証の入力に含まれない）とともに判断する。依存する、または判断できない場合は、許可された範囲で単位をまとめ直すか、manualと同じ方法で退避する。退避が他の進行中の作業（他のセッションや人がステージ・編集中の変更）を妨げる場合は退避せず、所有者と調整できるまで止める。manualは別の隔離方法へ置き換えない。退避するときは、stashのindexにコミット対象のステージ済み変更を入れない。`git stash push` はパスを指定してもindex全体を保存し、対象のステージ済み変更が入ると後の `git stash apply --index` が失敗するため。対象のステージ済み差分のパッチを保存し、対象のステージを外してから退避し、退避後にそのパッチで対象のステージを戻す。作成前後のstash一覧を比べて今回作成されたものだけのSHAを記録し、既存stashの先頭を自分のものと決めつけない。共有ファイルのhunk分割は控えから行い、対象のhunkだけのステージを外せない場合や、対象外のステージ済みの変更が変わる場合は止める。
 3. コミットする内容に必要な検証を行う。後続や対象外の未コミット変更に依存した成功を、その単位の検証としない。範囲を限った検証はプロジェクトが認める場合だけ使い、必須検証を省かない。後続や対象外への依存で失敗するなら、手順2に戻って単位か隔離を見直す。
 4. 対象だけをステージし、実際にコミットされる差分の全体（indexのままコミットする場合は完全なcached diff）と影響するファイルをレビューする。indexに対象外の変更を残す場合は、それを含めずに対象だけをコミットする方法を使い、対象を限定できなければ止める。manualで提示する差分は、コミットされる差分と同じものにする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
-5. 必須検証と独立レビュー（auto必須）が通り、阻害指摘がないことを確認する。autoでは直前の全差分が予定単位と一致してからAIが `git commit` を単独実行する（`git add` と連結しない）。manualでは単位の差分・理由・検証結果・推奨メッセージを提示し、人がレビュー・必要な修正・commitを行い、その完了を知らせるまで待つ。AIは承認を受けても代わりにcommitしない。人の完了通知後に、比較元からの実コミット一覧と各SHA・全差分を調べ、通知された修正が許可された目的・範囲を満たすことを確認する。実差分で実効flowを再判定し、影響する挙動を再検証する。正当な人の修正は確定単位と全体の期待差分へ反映し、元の予定差分・完了通知・変更理由・実コミットとの対応を残す。本人が明示確認した修正という理由だけで新たな承認を求めない。意図や範囲が不明、対象外の混入、flowの適用が未解決なら人へ確認して止める。Gitにcommitがあるだけで人レビュー完了としない。各コミットを確定単位と照合してSHA・結果を記録し、不一致なら次工程を止める。履歴を無断で書き換えない。
+5. 必須検証と独立レビュー（auto必須）が通り、阻害指摘がないことを確認する。autoでは直前の全差分が予定単位と一致してからAIが `git commit` を単独実行する（`git add` と連結しない）。manualでは単位の差分・理由・検証結果・推奨メッセージを提示し、提示時の `git write-tree` を記録する。人との相談で修正したら再stage・再検証・再提示する。人がその単位を明示的に承認したら、直前のindexのtreeが承認したtreeと一致することを確認してAIが `git commit` を単独実行し、作成したコミットのtreeも照合する。承認後に単位のパスで作業ツリーまたはindexが変わったら承認は失効し、再提示・再承認する。承認はその単位にだけ及ぶ。commit後に（人自身のcommitを含む）、比較元からの実コミット一覧と各SHA・全差分を調べ、相談で行った修正が許可された目的・範囲を満たすことを確認する。実差分で実効flowを再判定し、影響する挙動を再検証する。正当な人の修正は確定単位と全体の期待差分へ反映し、元の予定差分・承認記録・変更理由・実コミットとの対応を残す。意図や範囲が不明、対象外の混入、flowの適用が未解決なら人へ確認して止める。Gitにcommitがあるだけで人レビュー完了としない。各コミットを確定単位と照合してSHA・結果を記録し、不一致なら次工程を止める。履歴を無断で書き換えない。
 6. 退避した場合は、コミット後または中断時に、indexにコミット対象のステージ済み変更がない状態で、記録したSHAのstashを `git stash apply --index` で戻す。中断時は対象のステージを外し、stashの復元を妨げる対象の未コミット変更（共有ファイルの対象のhunkなど）もパッチに保存して作業ツリーから一時的に外してから戻す。その後、外した対象の変更を戻し、対象のステージ済み差分のパッチで対象のステージを戻す。復元前に人が修正した最新のHEAD・作業ツリー・indexを記録して保全する。控えで扱った対象外変更だけを復元し、古い対象パッチで人の修正を上書きしたり、コミット済みの変更を再び加えたりしない。退避の有無によらず、コミットしていない変更（ステージ済み・未ステージ・untracked）と既存stashが、操作前の記録と確定済みの人の修正からコミットした内容を除いたものと一致することを確認する。一致しない、曖昧な競合がある、ステージ境界を戻せない場合は推測で消さず、一致しないパスと、退避した場合は回復資料を示して止める。一致を確認してから今回作成したstashだけをdropし、HEADを確認して次へ進む。
 全単位の完了後、各単位の照合結果に加え、元の比較元からの全体差分が、人の正当な修正を反映した確定済みの全体期待差分と一致し、対象の未コミット変更が残っていないことを確認する。最終差分だけで途中コミットの照合を代用しない。予定どおりのコミットによる残差分の減少は不一致と扱わない。

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

@@ -16,8 +16,8 @@ description: 再現手順、コード、ログと必要な外部情報から不
 委託が許可され登録されている場合はshinaps-debuggerで仮説を立て、shinaps-debug-validatorで実コードを検証する。外部調査にはshinaps-tech-surveyorとshinaps-survey-validatorを必要に応じて使う。取得済みのShinapsルールは親が担当へ渡す。MCP不可ならルール照合未確認とする。
-結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正まで依頼されている場合は$shinaps:dev-codexへ引き継ぐ。担当と人数はdevのメインが作業に応じて判断する。調査だけなら変更しない。
+結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正はClaude Codeが行い、Codexに実装の入口はない。Linear進行で修正まで依頼されている場合は `$shinaps:linear-execute` でClaudeへ依頼する。調査だけなら変更しない。
 必要な記録は.shinaps/work/debug/へ保存し、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。秘密情報・既存記録の削除・外部投稿は含めない。
-Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。
+Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

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

@@ -14,8 +14,8 @@ description: 既存挙動の理由、実装方針、変更の影響を対話し
 委託を許可されている場合は登録済みのshinaps-investigatorに現在の質問と対象範囲を渡せる。許可がなければ現在のセッションで調べる。調査依頼を実装・設定変更・外部投稿の許可として扱わない。
-質問が曖昧なら結果を左右する点だけ一問確認する。回答後に新たな質問が来たら続け、仕様策定や修正へ自動で進まない。理解が揃い実装を依頼されたら、目的・合意事項・未確認事項・関連ファイルを引き継ぎ、$shinaps:dev-codexを読む。担当と人数はdevのメインが作業に応じて判断する。
+質問が曖昧なら結果を左右する点だけ一問確認する。回答後に新たな質問が来たら続け、仕様策定や修正へ自動で進まない。理解が揃い実装を依頼されたら、目的・合意事項・未確認事項・関連ファイルをまとめる。実装はClaude Codeが行い、Codexに実装の入口はない。Linear進行では `$shinaps:linear-execute` でClaudeへ依頼する。
 継続用の記録が必要なら.shinaps/work/explorations/へ保存する。[作業記録の共通手順](../../references/work-records.md)に従い、秘密情報や無関係な記録を持ち込まない。MCPが使えないときはルール照合未確認と明記する。
-Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。
+Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

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

@@ -5,27 +5,24 @@ description: 指定したIssue・Cycle・バックログの実装からQA・許
 # Linearを起点に開発を進める
-Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当する。実装担当は作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口ではauto/manualともローカルClaude CLIで実装し、Codexの入口（`dev-codex`）ではIssueごとの別Codexタスクが `$shinaps:<入口>` で実装・QA指摘の修正を行う。Managedの入口（`dev-managed-cc`）では、会話側のCodexが進行役のまま、IssueごとのClaude Managed Agentsセッションが実装する（[managed-session.md](../../references/linear/managed-session.md)）。担当の対応は[references/workflow.md](../../references/linear/workflow.md) の「担当と窓口」にある。設定と異なる担当への入れ替えは扱わない。
+Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行役として進行・Agent QA・Issueの記録・人への窓口を担当し、実装・修正・コミットはClaude Codeが行う。Codexに実装の入口はない。主フローは着手・実装・差分確定・公開確認・結果報告の5工程で、担当と工程は[references/workflow.md](../../references/linear/workflow.md)にある。
-## Claudeの実行経路を先に確定する
+## 経路を先に確定する
-auto/manualともCodexが [Claude CLI](../../references/linear/claude-cli.md) を起動し、質問・修正・QA後のコミット準備を同じsessionへresumeする。manualはprocess終了後に実効 `review_flow.tool` で提示し、人がレビュー・修正・commitする。初回実装前に経路と権限を確定する。パス例外はreview_flow全体だけを変更し、実装経路を変えない。報告はCLI resultへ返し、任意のBridge報告は照合入力として扱う。
+着手時に作業先設定の通常の `review_flow.mode` で経路を決め、Issueの途中で切り替えない（[経路](../../references/linear/configuration.md#経路)）。
-## 再確認せず進める条件
+- auto: [ローカルClaude CLI](../../references/linear/claude-cli.md)を起動し、質問への回答・修正・差分確定を同じsessionのresumeで依頼する。許可は `claude_cli`。
+- manual: WebStorm内の対話Claude Codeセッションへ[Bridge](../../references/linear/bridge.md)で依頼する。人とClaudeの作業中は同じIssueへ指示を送らず、報告を待つ。許可は `bridge_request`。
-Codexから許可範囲と受入条件を伴う実装・修正の依頼をCLIで受けたClaudeは、人へ着手を再確認せず、指定されたスキルで実行する。質問・相談・障害・完了はCodexへ返す。
-人のレビュー・コミット完了の報告をBridgeで受けたCodexは、報告の対象とGitの状態を照合し、一致すれば既存の許可の範囲で人へ再確認せず次の工程へ進む。
-条件の一覧と照合の項目は `../../references/linear/workflow.md` にある。
+体制判断の材料（受入条件・関連範囲・既存検証・リスク）を依頼に添える。初期体制はClaudeのメインが決めて報告する。
 ## 実行範囲を確定する
 [実行範囲とゴール](../../references/linear/execution.md)を読み、Issue単体・Cycle全体・バックログ消化から依頼に合う範囲を確定する。依頼が明確なら聞き直さず、不明な場合だけ一問確認する。対象ID・順序・終了条件を記録してから実装を始める。
-開発進行には作業先の明示された設定と `issue_update` が必要。入口ごとに必要な許可とツールは [configuration.md](../../references/linear/configuration.md) の「許可」に従う。設定の許可・`stop_after` を超えない。Issue未作成の明示的な実装依頼は共通の紐づけ手順でIssueを作って続けられるが、仕様が未決なら `shinaps:linear-plan` へ整理を戻す。
+開発進行には作業先の明示された設定と `issue_update`、経路の許可が必要（[configuration.md](../../references/linear/configuration.md) の「許可」）。設定の許可・`stop_after` を超えない。Issue未作成の明示的な実装依頼は共通の紐づけ手順でIssueを作って続けられるが、仕様が未決なら `shinaps:linear-plan` へ整理を戻す。
-実行には対象と終了条件を持つゴールの設定成功が必須。環境が明示許可を要求する場合は、既存の依頼で満たされるか確認し、なければ開始前に一度確認する。ゴール未設定のまま実装へ進まない。人レビュー・Human QA待ちは予定された工程として待機する。スキルの実行だけで予約実行・定期監視は開始しない。Managedの入口では、セッションの完了を、シェルで[managed-session.md](../../references/linear/managed-session.md)の「観測と判定」の確認を60秒ごとに繰り返して待つ。これは進行中のIssueの観測であり、予約実行・定期監視には当たらない。人への確認は会話で一問ずつ行う。
+実行には対象と終了条件を持つゴールの設定成功が必須。環境が明示許可を要求する場合は、既存の依頼で満たされるか確認し、なければ開始前に一度確認する。ゴール未設定のまま実装へ進まない。Claudeの作業・manualの単位承認・Human QA待ちは予定された工程として待機する。スキルの実行だけで予約実行・定期監視は開始しない。人への確認は会話で一問ずつ行う。
 ## 設定と補足を読む
@@ -39,14 +36,10 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をCLIで
 | --- | --- |
 | 設定の確認（初期設定・変更は `shinaps:linear-plan`） | [references/configuration.md](../../references/linear/configuration.md) |
 | 着手前の紐づけ、Issueの作成・整理・本文の更新 | [references/issue.md](../../references/linear/issue.md) |
-| 担当、工程、待ち状態、Bridge、人への依頼、継続の範囲 | [references/workflow.md](../../references/linear/workflow.md) |
-| Codex実装タスクの作成・再利用・依頼とQAへの受け渡し | [codex-task.md](../../references/linear/codex-task.md) |
-| Managedセッションの作成・観測・取り出し・適用とQAへの受け渡し | [managed-session.md](../../references/linear/managed-session.md) |
+| 担当、工程、共通ルール、待ち状態、人への依頼、継続の範囲 | [references/workflow.md](../../references/linear/workflow.md) |
+| auto経路の起動・観測・resume | [references/claude-cli.md](../../references/linear/claude-cli.md) |
+| manual経路の宛先・依頼・報告 | [references/bridge.md](../../references/linear/bridge.md) |
 | QAの実施・記録・素材 | [references/qa.md](../../references/linear/qa.md) |
 | Cycle完了QA・報告 | [references/cycle-report.md](../../references/linear/cycle-report.md) |
-コミットは `shinaps:commit`（Claudeの入口ではClaudeへ依頼し、Codexの入口では会話側がQA後に実装タスクへ依頼し、Managedの入口では会話側がQA後にautoのcommitまたはmanualの提示を行う）、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで継続する。
-## 初期体制と途中の増員
-[Issue開始時の実装体制](../../references/linear/execution.md#issue開始時の実装体制)と[体制の判断](../../references/dev/staffing.md)に従う。進行役は各Issueの初期体制を設計前に決めて渡し、実装側のメインは現物と照合して必要な担当を追加できる。Claudeが実装の受け手の場合も同じ基準を使い、変更理由と体制を進行役へ返す。Managedの進行役も初期体制をleadへ渡す。人数の固定された入口へ戻さず、必須検証と独立性を保つ。
+コミットはClaudeへ差分確定を依頼して `shinaps:commit` で行い、Codexは各コミットの単位照合と全体照合を行う。pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで継続する。

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

@@ -24,4 +24,4 @@ Shinaps AIのルール検索が利用できる場合は関連するルールを
 修正・コミット・PR投稿はユーザーに依頼された範囲だけ行う。記録が必要ならプロジェクトの.shinaps/work/に保存し、[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。
-Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。
+Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

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

@@ -18,6 +18,6 @@ description: 曖昧な要望を対話と既存実装・実現可能性の調査
 利用可能なShinapsルールを制約の根拠に含める。利用できないときはルール照合を未確認とし、実現可能性や仕様確定に残る影響を明記する。
-合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装依頼があれば$shinaps:dev-codexへこの記録を渡す。担当と人数はdevのメインが作業に応じて判断する。仕様作成だけの依頼で自動実装しない。
+合意した仕様を.shinaps/work/specs/のspec.mdへ保存する。[作業記録の共通手順](../../references/work-records.md)に従って初期化・保全する。仕様には目的・範囲・挙動・受入条件・設計判断・根拠・未決事項を含める。実装はClaude Codeが行い、Codexに実装の入口はない。Linear進行での実装依頼は `$shinaps:linear-execute` でClaudeへこの記録を渡す。仕様作成だけの依頼で自動実装しない。
-Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。
+Linear進行への成果引き渡しでは、確定済みの経路を維持する。autoは同じ[Claude CLI](../../references/linear/claude-cli.md)のsessionのresultへ返す。manualは同じ対話セッションで続け、[Bridge](../../references/linear/bridge.md)で依頼元のCodexへ報告する。調査スキルから経路を切り替えない。

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

@@ -1,38 +0,0 @@
-# Codexの実装タスク
-`implementation_skill` が `dev-codex` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
-## 作成と再利用
-- 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
-- 既存の同じ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スキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。初期体制を現物と照合し、途中の新しい根拠で必要な担当を追加して進行役へ報告する。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果を伴う依頼を受け、必要な許可を確認して行う。単位案・判定・依頼・照合・報告は [共通手順](workflow.md#単位案からコミット完了まで)に従う。他の人・AIの差分を戻さない。
-## 待機・QA・修正
-会話側は同じタスクを `wait_threads` / `read_thread` で観測し、完了・質問・失敗と実装結果を確認する。待機中のゴールと観測結果が得られない場合の扱いは [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。
-実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。
-質問は会話側が既存の合意で答え、仕様・権限を変える判断だけ人へ確認する。実装タスクの失敗・利用不能時は未完了として報告し、独断で別タスクを重ねない。利用者の停止・範囲変更は実装タスクにも伝え、停止を確認する。次のIssueへは今回の実行範囲と終了条件に従って進む。
-## 完了後の整理
-会話側のCodexが、合意した終了条件への到達、成果・検証結果・未実施事項の記録、その実装タスクで続ける作業がないことを確認してから、専用の実装タスクだけをアーカイブする。実装担当の完了報告や、IssueのDone・ゴールの完了だけでは、この確認の代わりにならない。修正・QA・コミットなどの続きがあるタスク、停止中・ブロッカー待ちのタスク、人との窓口や他の作業と共有しているタスクは保持する。
-アーカイブには、整理まで含む今回の利用者の明示合意、または対象・条件を確認できる記録済みの継続合意が必要。`codex_task` の許可だけからは推測せず、ツール固有の明示依頼条件も満たす。合意がない場合はタスクを保持し、整理が未実施であることを報告する。
-1. ローカル作業記録の確定済み `threadId`・`hostId` とIssue・checkout・branchの対応を確認する。対象を確定できなければ操作しない。
-2. `set_thread_archived` に、その `threadId`・`hostId` と `archived: true` を明示して実行する。IDを省略して呼出元を対象にしない。
-3. 結果を確認し、対象と成否を作業記録に残す。結果が不明なら `list_threads`・`list_archived_threads`・`read_thread` など利用可能な読取手段で同じ対象の状態を確認する。一覧に見当たらないだけで成功と扱わず、状態を確定できない場合は重複操作せず未整理として報告する。ツールが利用不能・失敗の場合も、未整理の対象と理由を報告する。
-この整理はブランチやworktreeの削除を含まない。タスク整理の成否は、終了地点への到達・IssueのDone・ゴールの状態と分けて記録する。

package/plugins/shinaps-claude/references/linear/managed-session.md DELETED Viewed

@@ -1,144 +0,0 @@
-# Managedセッション
-作業先の設定の `implementation_skill` が `dev-managed-cc` のときに、IssueごとのClaude Managed Agentsセッションへ実装・修正を依頼し、結果を受け取る手順。進行役は、linear-executeを実行している会話（ClaudeまたはCodex）である（[担当と工程](workflow.md)の「担当と窓口」）。
-## 適用と前提
-- 必要な許可は [configuration.md](configuration.md) の「許可」に従う。
-- `ant auth login` とvaultの登録は人が行う。AIは認証情報の値を扱わない。
-- 人への確認と待ち方は、runtimeごとのlinear-executeの手順に従う。
-- `beta:` で始まる `ant` のコマンドには `--beta managed-agents-2026-04-01` を付ける（以下の例では省く）。
-## 未完了の扱い
-IDの取得から適用・展開までのどこかで、完了の条件（最後のメッセージが `状態: 完了`、`出力:` のファイルが揃い、patchとtarが「確認・適用・展開」の確認を通って適用できる）を満たさなかった場合は、すべて同じ扱いにする（例: IDの取得・アップロード・作成・予算の引き上げなど `ant` の失敗、`budget_reached` などでの停止やセッションの終了、状態行がない・`状態: 未完了`、ファイルが揃わない、範囲外の変更、確認や適用の失敗）。`状態: 質問` は「質問への応答」で扱う。
-原因、`stop_reason`（あれば）、累計の費用（セッションがあれば、最新の `session.usage` のlist_cost）、leadの報告（あれば）を作業記録に残す。そのうえで、状況に合う選択肢を示して次の対応を一問だけ利用者に確認する（例: 予算の引き上げ額を示して再開、修正依頼、準備を整えて再開、新しいセッションで再開、中止）。
-予算の引き上げに合意を得たら、`ant beta:sessions update --session-id <session> --budget '{type: limit, max_list_cost: {amount: "<セント>", currency: USD}}'` を実行し、user.messageで再開を伝える。ブロッカーを報告しただけでは完了にしない（[execution.md](execution.md) の「継続と待機」）。
-## 作業ブランチと持ち込み
-1. 進行役が、作業先の規約に従った名前で、合意した土台からブランチを切る。
-2. 作業ツリーにHEADとの差（ignoreされていない未追跡ファイルを含む）があれば開始せず、利用者に一問で確認する。
-3. `git bundle create <記録先>/<repo>.bundle <branch>` を作る。この時点の `git rev-parse HEAD` が比較元になる。記録先は進行役の作業記録のディレクトリとする。
-4. 同じセッションを続けて使う間は、進行役による適用と展開を除き、ローカルのHEADと作業ツリーを変えない。変わった後の扱いは「QAと修正」に従う。
-## IDの取得、アップロードと作成
-一覧は `--max-items -1 --format jsonl` で全件を取り、jqで名前を照合する。
-- lead: `ant beta:agents list` の `name` が `shinaps-<入口名>`（例 `shinaps-dev-managed-cc`）
-- environment: `ant beta:environments list` の `name` が `shinaps-dev`
-- vault: `ant beta:vaults list` の `display_name` が `shinaps-ai`
-leadとenvironmentが一件に定まらなければ「未完了の扱い」に従う。vaultは一件に定まる場合だけ `--vault-id` で渡し、定まらなければ渡さずに「規約照合は未確認」と記録して進める。vaultはセッションの作成時にしか渡せない。
-bundleと、`~/.claude/CLAUDE.md` があればそれも、`ant files upload --file <パス> --expires-in-seconds 604800 --transform id --raw-output` でアップロードし、返されたfile_idを記録する。
-セッションは次のように作る。予算は許可の値（USD）の100倍を、セント単位の文字列で書く。CLAUDE.mdがなければ、resourcesはbundleの1つだけにする。
-```sh
-ant beta:sessions create --agent <lead> --environment-id <environment> [--vault-id <vault>] \
-  --title "<IssueのID> <題名>" --transform id --raw-output <<'YAML'
-budget: {type: limit, max_list_cost: {amount: "<セント>", currency: USD}}
-resources:
-  - {type: file, file_id: <bundleのfile_id>, mount_path: /<repo>.bundle}
-  - {type: file, file_id: <CLAUDE.mdのfile_id>, mount_path: /CLAUDE.md}
-initial_events:
-  - type: user.message
-    content:
-      - type: text
-        text: |
-          <初回メッセージ>
-YAML
-```
-作業記録には、Issue、session_id、入口、ブランチ、比較元、file_id、vaultの有無、予算を残す。
-## 観測と判定
-判定の境界の時刻tは、最後に送ったuser.messageの `processed_at` とする。
-- 送信の結果に送ったeventのIDがあれば、`ant beta:sessions:events list --session-id <session> --type user.message --max-items -1 --format jsonl` からそのIDのeventを探し、`processed_at` が入った時点の値をtとする。
-- IDがない場合（作成時を含む）は、送る前に `processed_at` の入ったuser.messageの件数Nを数えておき、送った後に `processed_at` の入ったuser.messageがN+1件になるまで待つ。そのうえで、それらの最新の `processed_at` をtとする（作成時はN=0）。
-idle、`agent.message`、出力ファイルは、すべてtより後のものだけで判定する。
-- 待ちを終える条件は、tより後の `session.status_idle` または `session.status_terminated` が現れること。`--type session.status_idle --type session.status_terminated --created-at-gt <t> --max-items 1` で取り、なければ待ち続ける。待つ時間の上限は設けない（費用の上限は予算が担う）。`session.status_terminated` なら「未完了の扱い」に従う。
-- スレッド単位の `session.thread_status_idle` と、再試行中の `session.error` は判定に使わない。担当のスレッドはleadの作業中にも個別にidleになり、再試行中のerrorの後もセッションは続くため。
-idleの `stop_reason.type` が `end_turn` なら、tより後の最新の `agent.message` の1行目で分ける。`end_turn` 以外なら「未完了の扱い」に従う。
-- `状態: 完了` なら「取り出し」へ進む。
-- `状態: 質問` なら「質問への応答」へ進む。
-- それ以外は「未完了の扱い」に従う。
-## 質問への応答
-既存の合意で答えられる質問には、一問ずつ答えて「観測と判定」に戻る。仕様・権限を変える判断は人に確認してから答える。
-```sh
-ant beta:sessions:events send --session-id <session> --format json <<'YAML'
-events:
-  - type: user.message
-    content:
-      - type: text
-        text: |
-          <回答>
-YAML
-```
-## 取り出し
-1. `ant beta:files list --scope-id <session> --beta managed-agents-2026-04-01 --max-items -1 --format jsonl` から、`出力:` 行の各名前について、tより後に作られた最新の1件を選ぶ。`--beta` がないと `scope_id: unknown field` で拒否される。
-2. 進行役の作業記録の、ラウンドごとのディレクトリへ `ant files download --file-id <file_id> -o <保存先>` で保存する。
-一覧への表示が数秒遅れることがあるので、名前が揃わなければ最大30秒待って1回だけ読み直す。それでも揃わなければ「未完了の扱い」に従う。
-## 確認・適用・展開
-作業先のルートで、次の順に行う。
-1. `tar -tvzf <作業記録のtar.gz>` の一覧で、全項目が作業記録の名前の形（`{YYYYMMDD-HHMMSS}-{slug}`）の一つのディレクトリの下にある普通のファイルかディレクトリで、`..` と絶対パスを含まないことを確かめる。そのディレクトリが `.shinaps/work/` に既にある場合は、同じセッションで前回展開したleadの記録のときだけ可とする。セッションから取得したtarを展開して、進行役や他の作業記録を上書きしないため。
-2. `git apply --numstat <patch>` と `git apply --summary <patch>` で、変更されるパスとmodeをIssueの範囲と照合する。範囲の外があれば「未完了の扱い」に従う。
-3. 今回のpatchが比較元に適用できることを、作業ツリーを変えずに確かめてから適用する。前回のpatchを外した後に今回が適用できないと、作業ツリーがどちらの状態でもなくなるため。
-   - 確認: `idx=$(mktemp)` を実行し、`GIT_INDEX_FILE="$idx" git read-tree <比較元> && GIT_INDEX_FILE="$idx" git apply --cached --check <今回のpatch>` で確かめ、終わったら `rm -f "$idx"` を実行する。
-   - 確認が通ったら、このセッションで前回適用したpatchがあれば `git apply -R <前回のpatch>` を実行し、続けて `git apply <今回のpatch>` を実行する。
-   - 確認や適用が失敗したら、作業先をそのままにして「未完了の扱い」に従う。
-4. `tar -xzf <作業記録のtar.gz> -C .shinaps/work` で展開し、leadの記録のディレクトリ名を作業記録に残す。
-5. 検証コマンドは、この後に実行する。
-## QAと修正
-適用した時点を「差分と対象版の固定」とし、[codex-task.md](codex-task.md) の「待機・QA・修正」と同じように扱う。不合格なら修正を依頼する。
-- 前回の適用の後に、進行役による適用と展開のほかに作業ツリーが変わっておらず、比較元の後にコミットもしていない場合は、下の修正依頼を同じセッションへ送り、「観測と判定」に戻る。
-- コミットの後で、作業ツリーにHEADとの差（進行役が展開した作業記録を除く）がない場合は、同じセッションへ送らない。leadの差分と今の作業ツリーが合わなくなるため。「作業ブランチと持ち込み」の手順2から（ブランチはそのまま使う）、現在のHEADでbundleと比較元を作り直し、新しいセッションを作る。予算は許可の上限まで改めて設定する。初回メッセージの「タスク」には、不具合と前回までの経緯を書く（前回のleadの作業記録はbundleに含まれない）。
-- それ以外（コミットされていない人の修正がある）は、新しいセッションを作らず「未完了の扱い」に従う（選択肢の例: 人がコミットしてから新しいセッションで再開、中止）。
-## Managed固有の読み替えと記録
-- [単位案からコミット完了まで](workflow.md#単位案からコミット完了まで)の手順2は、依頼を送らず、進行役が許可と記録の一致を確かめる手順として読む。手順3は、進行役が `commit` に従い、autoなら独立レビュー・QA後にstage・commitし、manualなら安全なstash・stage・提示を行い、人のレビュー・修正・commitと復元確認を待つ。
-- 各idleでの累計の費用と最終の費用を、作業記録とIssueの記録に残す。
-## 初回メッセージと修正依頼
-初回メッセージ:
-```text
-初期体制: <役割別人数・根拠・専任なしの責任者・必須検証。leadは現物と照合し、必要な増員を予算と許可内で行い報告する>
-Linear進行の実装依頼として、skill dev-managed-cc の工程と起動手順に従ってください。
-作業先: /mnt/session/uploads/<repo>.bundle をブランチ <branch> で /workspace/<repo> に用意する。比較元 <SHA>。
-タスク: <Issueの識別子とリンク>。<範囲・受入条件・範囲外・仕様や調査成果物の本文。leadはLinearを読めない>。必要な検証: <references.validation に従うコマンド>。
-設定: 保存方式 <shared|local>。正本 <作業先の .shinaps/linear.json。bundleに含まれるか>。読む補足 <references のうち工程に必要なもの>。正本や補足がbundleに含まれない場合（`local` など）は、その本文をこの欄に写す。
-前提: <CLAUDE.mdを添付した場合だけ: 利用者共通方針は /mnt/session/uploads/CLAUDE.md>。規約照合: <vaultあり | vaultなし。取得できなければ未確認として進める>。許可範囲: devの入口の中の委託（dev_delegation）。コミット・push・PR作成・Issueの更新・ant apply はしない。仕様・権限の不明点は一問ずつ質問してターンを終える。通常の実装判断は任せる。
-報告: 最終報告に、変更範囲、検証結果、dev内レビューの結果と未解決の指摘、起動方法、未解決事項、コミット単位案と単位ごとの予定差分（references/linear/workflow.md「単位案からコミット完了まで」の1）を含める。
-```
-修正依頼（同じセッションへのuser.message）:
-```text
-Local Agent QAで不合格。skill <入口> の工程で、修正依頼として Phase 1 から進める。前回の作業記録 .shinaps/work/<dir>/ を引き継ぎ資料とする。比較元 <SHA>。
-不具合: <再現手順・期待と実際・対象差分・証拠>
-```

package/plugins/shinaps-codex/references/linear/codex-task.md DELETED Viewed

@@ -1,38 +0,0 @@
-# Codexの実装タスク
-`implementation_skill` が `dev-codex` の場合に使う。会話側のCodexがゴール・Linear・人への窓口・Agent QA・公開の進行を所有し、Issueごとの別のCodexタスクに実装を任せる。実装タスクは指定されたdevの入口でサブエージェントを使う。別タスクとdev内部のサブエージェントは別の役割である。
-## 作成と再利用
-- 利用者の明示的な依頼または合意済みの `permissions: [codex_task, ...]` の範囲を確認する。ツールが利用者からの明示依頼を要求する場合はその条件も満たす必要があり、設定だけで迂回しない。必要な許可やツールがなければ開始前に止め、会話側での実装やCLIへの置き換えをしない。
-- 既存の同じ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スキルで実装・検証し、結果をこのタスクの最終回答へ返す。linear-executeを再起動せず、別の実装タスクや開発ゴールを作らない。dev内部のサブエージェントはdev_delegationの許可範囲で使う。初期体制を現物と照合し、途中の新しい根拠で必要な担当を追加して進行役へ報告する。仕様・権限の未決事項は質問として返し、人へ直接着手確認をしない。実装完了だけでコミット・push・公開・IssueのDone更新をしない。コミットは会話側からQA結果を伴う依頼を受け、必要な許可を確認して行う。単位案・判定・依頼・照合・報告は [共通手順](workflow.md#単位案からコミット完了まで)に従う。他の人・AIの差分を戻さない。
-## 待機・QA・修正
-会話側は同じタスクを `wait_threads` / `read_thread` で観測し、完了・質問・失敗と実装結果を確認する。待機中のゴールと観測結果が得られない場合の扱いは [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。送信成功やタスクの終了だけで実装・QAの合格と扱わない。完了報告には変更範囲、検証結果、dev内レビュー結果、起動方法、未解決事項を含める。
-実装中は会話側で同じファイルを編集しない。Agent QAの開始前に実装タスクの編集が止まったことを確認し、差分と対象版を固定してQAする。不具合は再現手順・期待と実際・証拠とともに同じタスクへ返し、修正終了後に再検証する。実装担当が返したテスト結果を独立したAgent QAの代わりにしない。
-質問は会話側が既存の合意で答え、仕様・権限を変える判断だけ人へ確認する。実装タスクの失敗・利用不能時は未完了として報告し、独断で別タスクを重ねない。利用者の停止・範囲変更は実装タスクにも伝え、停止を確認する。次のIssueへは今回の実行範囲と終了条件に従って進む。
-## 完了後の整理
-会話側のCodexが、合意した終了条件への到達、成果・検証結果・未実施事項の記録、その実装タスクで続ける作業がないことを確認してから、専用の実装タスクだけをアーカイブする。実装担当の完了報告や、IssueのDone・ゴールの完了だけでは、この確認の代わりにならない。修正・QA・コミットなどの続きがあるタスク、停止中・ブロッカー待ちのタスク、人との窓口や他の作業と共有しているタスクは保持する。
-アーカイブには、整理まで含む今回の利用者の明示合意、または対象・条件を確認できる記録済みの継続合意が必要。`codex_task` の許可だけからは推測せず、ツール固有の明示依頼条件も満たす。合意がない場合はタスクを保持し、整理が未実施であることを報告する。
-1. ローカル作業記録の確定済み `threadId`・`hostId` とIssue・checkout・branchの対応を確認する。対象を確定できなければ操作しない。
-2. `set_thread_archived` に、その `threadId`・`hostId` と `archived: true` を明示して実行する。IDを省略して呼出元を対象にしない。
-3. 結果を確認し、対象と成否を作業記録に残す。結果が不明なら `list_threads`・`list_archived_threads`・`read_thread` など利用可能な読取手段で同じ対象の状態を確認する。一覧に見当たらないだけで成功と扱わず、状態を確定できない場合は重複操作せず未整理として報告する。ツールが利用不能・失敗の場合も、未整理の対象と理由を報告する。
-この整理はブランチやworktreeの削除を含まない。タスク整理の成否は、終了地点への到達・IssueのDone・ゴールの状態と分けて記録する。

package/plugins/shinaps-codex/references/linear/managed-session.md DELETED Viewed

@@ -1,144 +0,0 @@
-# Managedセッション
-作業先の設定の `implementation_skill` が `dev-managed-cc` のときに、IssueごとのClaude Managed Agentsセッションへ実装・修正を依頼し、結果を受け取る手順。進行役は、linear-executeを実行している会話（ClaudeまたはCodex）である（[担当と工程](workflow.md)の「担当と窓口」）。
-## 適用と前提
-- 必要な許可は [configuration.md](configuration.md) の「許可」に従う。
-- `ant auth login` とvaultの登録は人が行う。AIは認証情報の値を扱わない。
-- 人への確認と待ち方は、runtimeごとのlinear-executeの手順に従う。
-- `beta:` で始まる `ant` のコマンドには `--beta managed-agents-2026-04-01` を付ける（以下の例では省く）。
-## 未完了の扱い
-IDの取得から適用・展開までのどこかで、完了の条件（最後のメッセージが `状態: 完了`、`出力:` のファイルが揃い、patchとtarが「確認・適用・展開」の確認を通って適用できる）を満たさなかった場合は、すべて同じ扱いにする（例: IDの取得・アップロード・作成・予算の引き上げなど `ant` の失敗、`budget_reached` などでの停止やセッションの終了、状態行がない・`状態: 未完了`、ファイルが揃わない、範囲外の変更、確認や適用の失敗）。`状態: 質問` は「質問への応答」で扱う。
-原因、`stop_reason`（あれば）、累計の費用（セッションがあれば、最新の `session.usage` のlist_cost）、leadの報告（あれば）を作業記録に残す。そのうえで、状況に合う選択肢を示して次の対応を一問だけ利用者に確認する（例: 予算の引き上げ額を示して再開、修正依頼、準備を整えて再開、新しいセッションで再開、中止）。
-予算の引き上げに合意を得たら、`ant beta:sessions update --session-id <session> --budget '{type: limit, max_list_cost: {amount: "<セント>", currency: USD}}'` を実行し、user.messageで再開を伝える。ブロッカーを報告しただけでは完了にしない（[execution.md](execution.md) の「継続と待機」）。
-## 作業ブランチと持ち込み
-1. 進行役が、作業先の規約に従った名前で、合意した土台からブランチを切る。
-2. 作業ツリーにHEADとの差（ignoreされていない未追跡ファイルを含む）があれば開始せず、利用者に一問で確認する。
-3. `git bundle create <記録先>/<repo>.bundle <branch>` を作る。この時点の `git rev-parse HEAD` が比較元になる。記録先は進行役の作業記録のディレクトリとする。
-4. 同じセッションを続けて使う間は、進行役による適用と展開を除き、ローカルのHEADと作業ツリーを変えない。変わった後の扱いは「QAと修正」に従う。
-## IDの取得、アップロードと作成
-一覧は `--max-items -1 --format jsonl` で全件を取り、jqで名前を照合する。
-- lead: `ant beta:agents list` の `name` が `shinaps-<入口名>`（例 `shinaps-dev-managed-cc`）
-- environment: `ant beta:environments list` の `name` が `shinaps-dev`
-- vault: `ant beta:vaults list` の `display_name` が `shinaps-ai`
-leadとenvironmentが一件に定まらなければ「未完了の扱い」に従う。vaultは一件に定まる場合だけ `--vault-id` で渡し、定まらなければ渡さずに「規約照合は未確認」と記録して進める。vaultはセッションの作成時にしか渡せない。
-bundleと、`~/.claude/CLAUDE.md` があればそれも、`ant files upload --file <パス> --expires-in-seconds 604800 --transform id --raw-output` でアップロードし、返されたfile_idを記録する。
-セッションは次のように作る。予算は許可の値（USD）の100倍を、セント単位の文字列で書く。CLAUDE.mdがなければ、resourcesはbundleの1つだけにする。
-```sh
-ant beta:sessions create --agent <lead> --environment-id <environment> [--vault-id <vault>] \
-  --title "<IssueのID> <題名>" --transform id --raw-output <<'YAML'
-budget: {type: limit, max_list_cost: {amount: "<セント>", currency: USD}}
-resources:
-  - {type: file, file_id: <bundleのfile_id>, mount_path: /<repo>.bundle}
-  - {type: file, file_id: <CLAUDE.mdのfile_id>, mount_path: /CLAUDE.md}
-initial_events:
-  - type: user.message
-    content:
-      - type: text
-        text: |
-          <初回メッセージ>
-YAML
-```
-作業記録には、Issue、session_id、入口、ブランチ、比較元、file_id、vaultの有無、予算を残す。
-## 観測と判定
-判定の境界の時刻tは、最後に送ったuser.messageの `processed_at` とする。
-- 送信の結果に送ったeventのIDがあれば、`ant beta:sessions:events list --session-id <session> --type user.message --max-items -1 --format jsonl` からそのIDのeventを探し、`processed_at` が入った時点の値をtとする。
-- IDがない場合（作成時を含む）は、送る前に `processed_at` の入ったuser.messageの件数Nを数えておき、送った後に `processed_at` の入ったuser.messageがN+1件になるまで待つ。そのうえで、それらの最新の `processed_at` をtとする（作成時はN=0）。
-idle、`agent.message`、出力ファイルは、すべてtより後のものだけで判定する。
-- 待ちを終える条件は、tより後の `session.status_idle` または `session.status_terminated` が現れること。`--type session.status_idle --type session.status_terminated --created-at-gt <t> --max-items 1` で取り、なければ待ち続ける。待つ時間の上限は設けない（費用の上限は予算が担う）。`session.status_terminated` なら「未完了の扱い」に従う。
-- スレッド単位の `session.thread_status_idle` と、再試行中の `session.error` は判定に使わない。担当のスレッドはleadの作業中にも個別にidleになり、再試行中のerrorの後もセッションは続くため。
-idleの `stop_reason.type` が `end_turn` なら、tより後の最新の `agent.message` の1行目で分ける。`end_turn` 以外なら「未完了の扱い」に従う。
-- `状態: 完了` なら「取り出し」へ進む。
-- `状態: 質問` なら「質問への応答」へ進む。
-- それ以外は「未完了の扱い」に従う。
-## 質問への応答
-既存の合意で答えられる質問には、一問ずつ答えて「観測と判定」に戻る。仕様・権限を変える判断は人に確認してから答える。
-```sh
-ant beta:sessions:events send --session-id <session> --format json <<'YAML'
-events:
-  - type: user.message
-    content:
-      - type: text
-        text: |
-          <回答>
-YAML
-```
-## 取り出し
-1. `ant beta:files list --scope-id <session> --beta managed-agents-2026-04-01 --max-items -1 --format jsonl` から、`出力:` 行の各名前について、tより後に作られた最新の1件を選ぶ。`--beta` がないと `scope_id: unknown field` で拒否される。
-2. 進行役の作業記録の、ラウンドごとのディレクトリへ `ant files download --file-id <file_id> -o <保存先>` で保存する。
-一覧への表示が数秒遅れることがあるので、名前が揃わなければ最大30秒待って1回だけ読み直す。それでも揃わなければ「未完了の扱い」に従う。
-## 確認・適用・展開
-作業先のルートで、次の順に行う。
-1. `tar -tvzf <作業記録のtar.gz>` の一覧で、全項目が作業記録の名前の形（`{YYYYMMDD-HHMMSS}-{slug}`）の一つのディレクトリの下にある普通のファイルかディレクトリで、`..` と絶対パスを含まないことを確かめる。そのディレクトリが `.shinaps/work/` に既にある場合は、同じセッションで前回展開したleadの記録のときだけ可とする。セッションから取得したtarを展開して、進行役や他の作業記録を上書きしないため。
-2. `git apply --numstat <patch>` と `git apply --summary <patch>` で、変更されるパスとmodeをIssueの範囲と照合する。範囲の外があれば「未完了の扱い」に従う。
-3. 今回のpatchが比較元に適用できることを、作業ツリーを変えずに確かめてから適用する。前回のpatchを外した後に今回が適用できないと、作業ツリーがどちらの状態でもなくなるため。
-   - 確認: `idx=$(mktemp)` を実行し、`GIT_INDEX_FILE="$idx" git read-tree <比較元> && GIT_INDEX_FILE="$idx" git apply --cached --check <今回のpatch>` で確かめ、終わったら `rm -f "$idx"` を実行する。
-   - 確認が通ったら、このセッションで前回適用したpatchがあれば `git apply -R <前回のpatch>` を実行し、続けて `git apply <今回のpatch>` を実行する。
-   - 確認や適用が失敗したら、作業先をそのままにして「未完了の扱い」に従う。
-4. `tar -xzf <作業記録のtar.gz> -C .shinaps/work` で展開し、leadの記録のディレクトリ名を作業記録に残す。
-5. 検証コマンドは、この後に実行する。
-## QAと修正
-適用した時点を「差分と対象版の固定」とし、[codex-task.md](codex-task.md) の「待機・QA・修正」と同じように扱う。不合格なら修正を依頼する。
-- 前回の適用の後に、進行役による適用と展開のほかに作業ツリーが変わっておらず、比較元の後にコミットもしていない場合は、下の修正依頼を同じセッションへ送り、「観測と判定」に戻る。
-- コミットの後で、作業ツリーにHEADとの差（進行役が展開した作業記録を除く）がない場合は、同じセッションへ送らない。leadの差分と今の作業ツリーが合わなくなるため。「作業ブランチと持ち込み」の手順2から（ブランチはそのまま使う）、現在のHEADでbundleと比較元を作り直し、新しいセッションを作る。予算は許可の上限まで改めて設定する。初回メッセージの「タスク」には、不具合と前回までの経緯を書く（前回のleadの作業記録はbundleに含まれない）。
-- それ以外（コミットされていない人の修正がある）は、新しいセッションを作らず「未完了の扱い」に従う（選択肢の例: 人がコミットしてから新しいセッションで再開、中止）。
-## Managed固有の読み替えと記録
-- [単位案からコミット完了まで](workflow.md#単位案からコミット完了まで)の手順2は、依頼を送らず、進行役が許可と記録の一致を確かめる手順として読む。手順3は、進行役が `commit` に従い、autoなら独立レビュー・QA後にstage・commitし、manualなら安全なstash・stage・提示を行い、人のレビュー・修正・commitと復元確認を待つ。
-- 各idleでの累計の費用と最終の費用を、作業記録とIssueの記録に残す。
-## 初回メッセージと修正依頼
-初回メッセージ:
-```text
-初期体制: <役割別人数・根拠・専任なしの責任者・必須検証。leadは現物と照合し、必要な増員を予算と許可内で行い報告する>
-Linear進行の実装依頼として、skill dev-managed-cc の工程と起動手順に従ってください。
-作業先: /mnt/session/uploads/<repo>.bundle をブランチ <branch> で /workspace/<repo> に用意する。比較元 <SHA>。
-タスク: <Issueの識別子とリンク>。<範囲・受入条件・範囲外・仕様や調査成果物の本文。leadはLinearを読めない>。必要な検証: <references.validation に従うコマンド>。
-設定: 保存方式 <shared|local>。正本 <作業先の .shinaps/linear.json。bundleに含まれるか>。読む補足 <references のうち工程に必要なもの>。正本や補足がbundleに含まれない場合（`local` など）は、その本文をこの欄に写す。
-前提: <CLAUDE.mdを添付した場合だけ: 利用者共通方針は /mnt/session/uploads/CLAUDE.md>。規約照合: <vaultあり | vaultなし。取得できなければ未確認として進める>。許可範囲: devの入口の中の委託（dev_delegation）。コミット・push・PR作成・Issueの更新・ant apply はしない。仕様・権限の不明点は一問ずつ質問してターンを終える。通常の実装判断は任せる。
-報告: 最終報告に、変更範囲、検証結果、dev内レビューの結果と未解決の指摘、起動方法、未解決事項、コミット単位案と単位ごとの予定差分（references/linear/workflow.md「単位案からコミット完了まで」の1）を含める。
-```
-修正依頼（同じセッションへのuser.message）:
-```text
-Local Agent QAで不合格。skill <入口> の工程で、修正依頼として Phase 1 から進める。前回の作業記録 .shinaps/work/<dir>/ を引き継ぎ資料とする。比較元 <SHA>。
-不具合: <再現手順・期待と実際・対象差分・証拠>
-```

package/plugins/shinaps-codex/skills/dev-codex/SKILL.md DELETED Viewed

@@ -1,10 +0,0 @@
----
-name: dev-codex
-description: 実装の不確実性・影響範囲・失敗時の影響から必要な担当と人数を決め、計画・実装・検証・独立レビューを進める。途中の新しい根拠で体制を追加する。コミットは許可に従い、Linear進行ではQAへ結果を返す。
----
-# 作業に応じた体制で開発する
-[体制の判断](../../references/dev/staffing.md)・[工程](../../references/dev/workflow.md)・[起動手順](../../references/dev/launch.md)を読む。人数を入口名で固定しない。linear-executeから渡された初期体制を引き継ぎ、なければメインが関連コードを確認して設計前に決める。途中でも必要な役割・人数を追加する。
-依頼や成果物からタスクが確定していれば、形式的な引数の再入力を求めずPhase 1から進める。