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

@shinaps/skills 0.30.0 → 0.32.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 (40) hide show

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

@@ -7,13 +7,17 @@ description: Linearの開発で、Codexから受けた実装・修正・コミ
 開発進行を依頼されたら、まず[設定の読み方](../../references/linear/configuration.md#設定の読み方)で作業先の設定を読み、`implementation_skill` で役割を決める。設定が真に未設定なら、下の「Codexの依頼なしで起動された場合」の初期設定へ進む。
-- Claudeの入口（`dev-claude`）では、Codexが進行・Agent QA・人への窓口を担当する。ClaudeはAI Terminal Bridge（以下Bridge）の受け手として、技術調査と実装・修正を担当し、「読む資料」「依頼を受けて実行する」「結果と人の対応を報告する」に従う。担当を入れ替えない。
+- Claudeの入口（`dev-claude`）では、Codexが進行・Agent QA・人への窓口を担当する。ClaudeはローカルClaude CLIの受け手として、技術調査と実装・修正を担当し、「読む資料」「依頼を受けて実行する」「結果と人の対応を報告する」に従う。担当を入れ替えない。
 - Managedの入口（`dev-managed-cc`）の開発進行では、Claudeが進行役になり、「Managedの入口で進行する」にだけ従う。
 - Codexの入口（`dev-codex`）では、開発進行をCodexへ引き渡す。
+## 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報告は照合入力として扱う。
 ## 再確認せず進める条件
-Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridgeで受けたClaudeは、人へ着手を再確認せず、指定されたスキルで実行する。質問・相談・障害・完了はCodexへ返す。
+Codexから許可範囲と受入条件を伴う実装・修正の依頼をCLIで受けたClaudeは、人へ着手を再確認せず、指定されたスキルで実行する。質問・相談・障害・完了はCodexへ返す。
 人のレビュー・コミット完了の報告をBridgeで受けたCodexは、報告の対象とGitの状態を照合し、一致すれば既存の許可の範囲で人へ再確認せず次の工程へ進む。
@@ -21,7 +25,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 ## 読む資料
-依頼を受けたら、[references/workflow.md](../../references/linear/workflow.md) の「担当と窓口」「再確認せず進める条件」「Bridgeでの依頼と報告」を読む。依頼に添えられたプロジェクトの補足と参照先も読む。
+依頼を受けたら、[references/workflow.md](../../references/linear/workflow.md) の「担当と窓口」「再確認せず進める条件」「Bridgeでの任意の引き渡し・報告」を読む。依頼に添えられたプロジェクトの補足と参照先も読む。
 他の資料は次の場合だけ読む: 依頼で指示された場合、Issue整理を依頼された場合（[references/issue.md](../../references/linear/issue.md)）、Codexの依頼なしで実作業を依頼された場合（[references/issue.md](../../references/linear/issue.md) の「着手前に作業をIssueへ紐づける」）、設定を読む必要がある場合（[references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」）。
@@ -34,11 +38,11 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 - devの入口が利用者に確認する場面（計画の判断、不明点、承認）では、人ではなくCodexへ相談する。Codexが既存の合意で答えた内容を人へ再確認しない。仕様・受入条件・許可範囲の変更が必要な場合は、Codexが人に確認する。
 - QAで見つかった不具合の修正依頼も同じ扱いにし、人の着手許可を改めて取らない。
 - 同じ作業ツリーをCodexや人と同時に編集しない。人や他のAIの変更を保持する。
-- コミットの許可は[共通設定](../../references/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の `code_review` に従う。実装完了の直後に先行してコミットせず、進行役へ結果を返す。条件を満たす依頼を受けたら `shinaps:commit` を使い、許可済みの操作を再確認しない。確認と承認の取り次ぎは同じ文書の「Bridgeでの依頼と報告」に従う。
+- コミットの許可は[共通設定](../../references/linear/configuration.md)、担当とQA後の条件は[担当と工程](../../references/linear/workflow.md)の `code_review` に従う。実装完了の直後に先行してコミットせず、進行役へ結果を返す。条件を満たす依頼を受けたら `shinaps:commit` を使い、許可済みの操作を再確認しない。質問の取り次ぎは両modeともClaude CLIのresultへ返す。
 ## 結果と人の対応を報告する
-- 完了の報告と、人のレビュー・コミット完了の報告に含める項目は、[references/workflow.md](../../references/linear/workflow.md) の「Bridgeでの依頼と報告」に従う。
+- 完了の報告と、人のレビュー・コミット完了の報告に含める項目は、[references/workflow.md](../../references/linear/workflow.md) に従う。両modeとも [Claude CLI](../../references/linear/claude-cli.md) のresultへ返す。
 - 人へ着手の確認やコミットの依頼をしない。人がClaudeへ直接伝えた指示や結果は保持し、Codexへ報告する。Gitにコミットがあるだけで、人のレビュー済みと報告しない。設定で人のレビューを省略した場合は、省略と報告する。
 ## Managedの入口で進行する
@@ -58,7 +62,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 | QAの実施・記録・素材 | [references/qa.md](../../references/linear/qa.md) |
 | Cycle完了QA・報告 | [references/cycle-report.md](../../references/linear/cycle-report.md) |
-コミットは `shinaps:commit`、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、Claudeが自分で行う。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで続ける。
+コミットは `shinaps:commit`、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、進行役のClaudeが行う。コミットはautoならAI、manualなら人が行う。これらのスキルには[共通設定](../../references/linear/configuration.md)の許可と前工程の結果を渡す。必要な条件が揃えば再確認せずに進み、個別スキルの完了だけで進行を終えず、[終了条件](../../references/linear/execution.md)まで続ける。
 ## Codexの依頼なしで起動された場合
@@ -66,7 +70,7 @@ Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridge
 - 利用者から直接依頼された実作業（開発進行の依頼を除く）は、着手前に [references/issue.md](../../references/linear/issue.md) の「着手前に作業をIssueへ紐づける」に従う。Issueの作成は利用者がその場で依頼した場合だけ行い、設定の `issue_update` を根拠にしない。
 - 利用者から明示的にIssueの整理を依頼された場合は、[references/issue.md](../../references/linear/issue.md) に従って整理する。Issueの更新は、依頼で指定された範囲だけにする（設定の有無にかかわらない）。
-- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、設定の `implementation_skill` がManagedの入口なら「Managedの入口で進行する」に従う。それ以外の入口では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の導入）を利用者へ案内する。
+- 開発進行（実装からQAを経て終了地点までの進行）を依頼された場合、設定の `implementation_skill` がManagedの入口なら「Managedの入口で進行する」に従う。それ以外の入口ではClaudeは進行役を兼ねない。[設定の読み方](../../references/linear/configuration.md#設定の読み方)で真に未設定と確認した場合だけ、同じセッションで `shinaps:linear-plan` の初期設定ヒアリングに進み、保存・確認後に元の依頼の引き渡しへ戻る。両modeともCLIを起動するCodex側へ依頼内容を返して開始を案内する。任意の引き渡しとして `bridge_request` が許可され、BridgeでCodexのセッションを特定できる場合は、[references/workflow.md](../../references/linear/workflow.md) の「開発進行の引き渡し」の項目を添えてCodexへ引き渡す。設定は [references/configuration.md](../../references/linear/configuration.md) の「設定の読み方」に従って読む。許可や相手のセッションがない場合は、必要な準備（設定、CodexセッションとClaude CLIの起動）を利用者へ案内する。
 ## 初期体制と途中の増員

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

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

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

@@ -4,6 +4,11 @@ description: 差分・PR・既存コードをレビューし、指摘の検証
 argument-hint: <なし | PR番号 | ファイル/ディレクトリパス>
 ---
+## 質問の実行経路（全工程に優先）
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
 ## 作業記録の保存先
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -144,3 +149,5 @@ Skill(skill="shinaps:dev-claude", args="以下のレビュー指摘を修正す
 - **PR コメント投稿は要承認**: 外部影響のある操作は必ず本文確認
 - **diff が空ならエラー終了**: 何もしない旨を明示
 - **テストの判断**: [テスト方針](../../references/testing.md) に従う
+Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。

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

@@ -4,6 +4,11 @@ description: 大まかな要望を入力に、対話的なヒアリング + 既
 argument-hint: <大まかな要望（省略可）>
 ---
+## 質問の実行経路（全工程に優先）
+対話セッションでは利用可能な質問UIで一問ずつ回答を受ける。CodexからローカルClaude CLIで呼び出された場合、以下の `AskUserQuestion`・確認・回答待ちの指示はすべて、質問一問・判断に必要な情報・再開する工程を最終resultへ返してターンを終了する手順に読み替える。CLI内で `AskUserQuestion` を呼んだり人の入力を待ち続けたりしない。Codexが回答を取り次ぎ、同じsessionをresumeして指定の工程から再開する。回答が必要な作業を先に進めず、終了を完了と報告しない。単独commitのflow選択にも同じ規則を適用する。
 ## 作業記録の保存先
 作業記録は現在の作業先の `.shinaps/work/` 以下へ保存する。初期化と保全は [作業記録の共通手順](../../references/work-records.md) に従う。
@@ -203,3 +208,5 @@ Skill(skill="shinaps:dev-claude", args="以下の仕様書を実装する。詳
 - **subagent は文字列応答のみ**: ファイル書き込みは必ずメインが担当
 - **フィジビリティ調査は spec で済ませる**: dev での差し戻しを減らすため、Phase 3/4 の調査を惜しまない
 - **rule カタログを制約に反映**: `search_rules` 結果を spec.md の制約セクションに集約
+Linear進行への成果引き渡しでは、確定済みの実装経路を維持する。Claudeのauto/manual両modeは [Claude CLI](../../references/linear/claude-cli.md) の同じsessionへの依頼・resultで返し。Codex・Managedは既存の返却先を使い、調査スキルから経路を切り替えない。

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

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

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

@@ -1,4 +1,4 @@
 name = "shinaps-split-reviewer"
-description = "shinaps:commit の通常モードで、人が単位ごとに承認する前に分割計画を確認するレビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない"
+description = "shinaps:commit のmanualで、人が単位ごとにレビュー・修正・コミットする前に分割計画を確認するレビューエージェント。メインスレッドが提案したコミット単位の分割を、各単位の diff だけを読んで変更の妥当性を判断できるか (下限) / 一言で説明できる範囲か (上限) / 依存順 / 網羅性の観点で批判的にレビューし、指摘を反映した修正版最終分割計画までを返す。worktree は read-only で扱い、stash / add / checkout / Edit は一切行わない"
 sandbox_mode = "read-only"
-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 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:commit` のmanualで、人が単位ごとにレビュー・修正・コミットする前に分割計画を確認するレビューエージェントです。\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/references/dev/workflow.md CHANGED Viewed

@@ -105,7 +105,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 初期体制と変更理由、実際の担当・確認範囲、計画と実装後のレビュー回数、採否・修正、検証結果、未実施・未照合・未解決事項を報告する。
-linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、QA後のコミット依頼を受ける。
+linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、QA後のcommit工程の依頼を受け、autoはAIコミット、manualは人への提示準備を行う。Claudeのauto/manual両modeは [Claude CLI](../linear/claude-cli.md) のresultへ報告し、同じsessionのresumeで質問・修正を受ける。manualの提示はprocess終了後に実効 `review_flow.tool` で行う。Codex・Managedはそれぞれの既存返却経路を使う。
 単独のdevではコミットが許可されている場合だけ範囲とモードを `commit` へ渡す。許可がなければ未コミットで返し、形式的な許可確認を追加しない。PR・リリースも許可された範囲で各スキルへ渡す。単独devにLinear進行・新しいゴールを必須にしない。

package/plugins/shinaps-codex/references/human-review.md CHANGED Viewed

@@ -1,24 +1,32 @@
 # 人レビューの差分提示
-人のコードレビューが必要な場合、またはコミット単位の承認を求める場合に使う。人レビューの要否・操作許可・コミットモードは、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+manualで人がレビュー・修正・commitする場合に使う。review_flow・操作許可は、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+実装runtimeによらず、実効 `review_flow.tool` が `plasma` ならPlasma、`webstorm` ならWebStormを使う。UIの指定がない場合は提示前に一問で確認する。設定のmanualでtoolが欠落していれば設定を修正する。CLIのprocess終了を確認してから提示し、人の操作と実装処理を並行しない。
 ## 対象の準備
 レビュー対象のcheckoutの絶対パス、ブランチ、比較元のcommit、対象ファイルと完全な差分、検証結果を確定する。未追跡ファイルも対象に含める。stageは許可された範囲だけで行い、無関係な差分や既存のステージ境界を変更しない。対象差分と比較元は作業記録へ残し、後で承認対象と照合できるようにする。
-## CodexではPlasmaで開く
+## plasmaではPlasmaで開く
-人への窓口がCodexの場合は、実装担当がCodexかClaudeかによらず、レビューを依頼する会話でPlasmaを開く。人への窓口がClaudeの場合は既存の差分提示方法を使い、Plasmaのためだけに別のCodexタスクを作らない。
+レビューを依頼する進行役の会話でPlasmaを開く。必要なツールが利用不能なら止め、runtimeから別UIを推測しない。
 1. 利用可能なPlasmaの`open_workbench`ツールと現在の入力仕様を確認する。ファイルを開く`route`が使える場合は、対象checkoutの絶対パスとレビュー対象のファイルを指定する。現在の形式は`/open?project=ABSOLUTE_PATH&file=RELATIVE_PATH&line=START&endLine=END`で、各値をURLエンコードする。存在するファイルを使い、適切なファイルがない場合はプロジェクト選択画面から対象checkoutを選ぶ。
 2. ファイルを開くことと差分を表示することを区別する。ファイル用routeに差分モードの未定義パラメーターを足さない。利用可能なUI操作ツールでPlasmaのGit画面を確認し、レビュー対象に合う比較を選ぶ。UI操作が使えない場合は、対象プロジェクト・比較方法・ファイル一覧を示して利用者に選択を依頼する。
 3. 表示中のcheckout・比較元・対象範囲をGitで確定した差分と照合する。ステージ済みの単位なら`git diff --cached`を基準にする。作業ツリー全体や別ブランチの差分を、その単位の差分として提示しない。対象全体を表示できない場合は、未表示の範囲を明示し、完全な差分を確認できる方法を利用者と決める。
-4. 会話に変更の目的、確認してほしい点、検証結果、対象単位を示し、修正指示またはレビュー完了を依頼する。Linear進行ではIssueも示す。Plasma内の注釈は指摘として扱い、画面を開いたことや操作の終了を承認とみなさない。
+4. 会話に変更の目的、確認してほしい点、検証結果、対象単位を示し、レビュー・必要な修正・コミット完了を依頼する。Linear進行ではIssueも示す。Plasma内の注釈は指摘として扱い、画面を開いたことや操作の終了を承認とみなさない。
+Plasmaが未導入・起動失敗の場合は、その状態を伝えて止める。別UIを使う場合はtoolの変更を合意してから同じ対象を提示する。無断でインストールや設定変更を行わず、表示できていないレビューを完了扱いにしない。
+## webstormではWebStormで開く
+`webstorm <checkoutの絶対パス>` で対象を開く。checkout・branch・比較元を確認し、対象単位のstaged差分（`git diff --cached`）を提示する。単にファイルを開いたことを差分表示の完了と扱わない。会話に目的・確認点・検証結果・対象単位を示し、人のレビュー・修正・commit完了を待つ。ツールがない、起動できない、対象差分を確認できない場合は止め、無断fallbackしない。
-Plasmaが未導入・起動失敗の場合は、その状態を伝え、Codexの差分表示など利用者が選んだ方法で同じ対象を提示する。無断でインストールや設定変更を行わず、表示できていないレビューを完了扱いにしない。
+## 人のレビュー・コミット完了後の照合
-## 承認後の照合
+利用者の明示的なレビュー・修正・コミット完了通知を、対象単位と対応付けて記録する。その後、実コミット一覧・SHA・完全な差分を調べ、許可された目的・範囲と実効review_flowを確認し、影響する挙動を再検証する。Gitにcommitがあるだけでは完了としない。
-利用者の明示的なレビュー完了を、対象単位と対応付けて記録する。修正した場合は必要な検証を行い、更新した差分を再提示して再確認を受ける。待機中に対象が変わった場合も、古い承認をそのまま適用しない。
+本人が明示確認した正当な修正は確定単位と全体期待差分に反映する。元の予定差分を保持し、完了通知・修正理由・確定差分・実コミットの対応を記録する。その修正だけを理由に再提示・再承認を要求しない。目的や範囲が不明、対象外変更が混入、適用flowが未解決の場合は人へ確認し、次工程を止める。最終照合は確定済みの期待差分を使い、元の差分との機械的な一致を要求しない。
-コミット直前に実際のコミット対象と承認対象の完全な差分を照合する。不一致ならコミットせず、変更後の対象を提示する。Plasmaを開くことはstage・commit・pushの許可を追加しない。具体的なコミット操作は`commit`に従う。
+stashの復元では人の修正を保持し、古い対象パッチで上書きしない。具体的な単位照合・復元は `commit` に従う。表示UIを開くことはstage・commit・pushの許可を追加しない。

package/plugins/shinaps-codex/references/linear/claude-cli.md ADDED Viewed

@@ -0,0 +1,37 @@
+# ローカルClaude CLIによる実装
+`dev-claude` はauto/manualとも、Codexが作業先でローカル `claude -p` を起動する。初回実装前に正確なcheckout・branch・HEAD・既存差分と `claude_cli` の許可（または今回の明示依頼）を確定する。CodexとManagedの既存経路は変更しない。
+パス例外はコミット単位のreview_flowを全体置換し、実装sessionを途中で切り替えない。manual単位ではstash・stageまで準備したCLIのprocess終了を確認し、進行役が同じcheckoutを実効 `review_flow.tool`（plasma / webstorm）で提示する。[人レビュー](../human-review.md)に従って人のレビュー・修正・commit完了を受け取り、単位差分・SHAと照合する。その後は変更後のHEADと差分を添えて同じCLI sessionをresumeする。人の操作中にCLIを並行実行しない。UI不足時は止め、別UIやBridgeへ無断で切り替えない。
+## 起動と観測
+通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。model・effort・plugin構成を指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
+依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。必要なSkill/Agent・Read/Edit・検証コマンド等の `--allowedTools` は依頼の許可と範囲から個別に追加する。たとえばcommit段階の `Bash(git add <対象パス>)` と `Bash(git commit -m <確定メッセージ>)` は実際の引数に限定し、初回実装にはcommit権限を渡さない。広範な既存allow設定がある場合も対象外操作の許可とは扱わない。
+```sh
+claude -p --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
+```
+途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は同じprocessを短い待機（最大60秒）で観測し、終了コードを取得する。新しいCLIを並行起動せず、進捗を会話へ返す。stream-jsonはイベントを読み、最終resultがない途中出力を完了と扱わない。
+jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、stream-jsonではsession初期化と最終resultを照合する。session_idをIssueとcwdに紐づけてローカル作業記録に保持する。終了コード0だけで成功にせず、エラー・拒否・質問・成果を確認して実差分と検証結果を独立QAする。ID欠落、異常終了、出力欠落なら停止してprocessと記録を調べる。結果不明のまま新規セッションを起動したり同じ依頼を再送したりしない。
+## 依頼・質問・修正・コミット
+promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、初期体制、exact cwd・branch・HEAD・既存差分、許可・禁止操作、規約と参照先、返却条件を含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。CLIからBridge送信や人の対話入力を待たせない。
+回答・QA修正・QA後のautoコミット依頼は、元のprocess終了後、記録済みの正確なIDで同じセッションをresumeする。`--continue` で別セッションを推測しない。
+```sh
+claude -p --resume '<recorded-session-id>' --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
+```
+resumeにも同じcwdと許可境界を指定し、外部で変化したHEAD・差分を渡す。commit依頼にはLocal Agent QA結果、独立レビュー、単位案と全差分、実効review_flowと合意根拠を含める。完了報告は変更範囲、検証、未解決事項、単位案、commitした場合はSHA・単位照合・残差分・stash復元結果を含める。復帰不能時は理由を報告し、黙って別sessionに作り直さない。
+## 操作権限
+`review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動では `--permission-mode dontAsk` を明示し、既存設定がbypassでも継承しない。model・effort・pluginsは保持し、操作許可は既存の個別allow設定と今回の範囲に限定する。`--permission-prompts none` は対話できないpromptを拒否として返すためであり、許可を付与しない。permission_denialsがあれば操作と必要な権限を報告し、既存の明示許可が対象を満たすか確認する。満たす場合だけ必要なSkill/Agentや対象を限定した `--allowedTools` を明示し、同じsessionへ明示的に再依頼する。新しい権限が必要ならCodexが人へ確認する。`--allowedTools` を使う場合も対象・操作に限定し、無条件の `Bash(*)`、bypassPermissions、dangerously-skip-permissionsを使わない。拒否を隠すsilent retryをしない。会話上の許可はCLIの権限チェックを消さない。
+CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応なら状態を報告して停止し、権限回避へ切り替えない。