@shinaps/skills 0.18.2 → 0.19.0

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

@@ -0,0 +1,146 @@
+# 担当と工程
+
+## 担当と窓口
+
+| 担当 | 責務 |
+| --- | --- |
+| Codex | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、Bridgeでの依頼、Local・Staging・ProductionのAgent QA、許可されたPR・配備等の運用、結果の記録、人への依頼 |
+| Claude | Codexの指示に基づく技術調査、`shinaps:dev` による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告 |
+| 人 | 未合意の仕様・権限の判断、設定で必要なコードレビュー・必要な修正、AIに許可していないコミット、本人の操作が必要な認証等、必要なHuman QA |
+
+人への質問と依頼はCodexが窓口になる。Claudeは人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
+
+CodexはQAで見つけた不具合を自分で実装修正せず、再現条件と証拠をClaudeへ返す。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
+
+Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐付けなど）は、Codexが利用可能なブラウザで行う。MCPが対応していないという理由だけで人へ回さない。人の認証や権限が必要な場合だけ人へ依頼する。
+
+## 再確認せず進める条件
+
+| 状況 | 必要な行動 |
+| --- | --- |
+| Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | Claudeは人へ着手を再確認せず、指定されたスキルで実行する |
+| `shinaps:dev` の中で計画上の判断が必要になった | ClaudeはCodexへ相談する。Codexは既存の合意で判断できれば回答し、人へ再承認を求めない |
+| QAで受入条件の範囲内の不具合が見つかった | CodexがClaudeへ修正を依頼し、Claudeは人の着手許可を改めて取らずに修正する。Codexが再検証する |
+| Claudeが人のレビュー・コミット完了をBridgeで報告した | Codexは人に同じ事実を聞き直さず、報告の対象とGitの状態を照合して次の工程へ進む |
+| 次の操作の継続的な許可があり、必要な工程の結果が揃った | Codexは「進めてもよいか」を再質問せずに実行する |
+| Cycle全体を任され、対象Issueが設定された終了地点に達した | CodexはCycleを読み直し、依存・優先順位から次の実行可能なIssueを選んで続ける |
+
+「自律的に進める」とだけ書かず、この表と具体的な許可範囲を各Bridge依頼に書く。
+
+## 人に確認する条件
+
+目的・仕様・受入条件・許可範囲の変更、設定で必要な未実施の人のレビュー、Human QA、本人にしかできない操作、根拠を確認しても解消できない報告の矛盾は、人に確認する。経過時間、無回答、Bridgeの送信成功や受領通知を、人の完了や合格として扱わない。
+
+## 工程とステータス
+
+| 工程キー | 工程 | 内容・次へ進む条件 |
+| --- | --- | --- |
+| `todo` | Todo | 未着手のIssue |
+| `refinement` | 仕様整理中 | 目的・仕様・範囲・依存・受入条件を整理する |
+| `ready` | Ready | 自分たちの作業を依存順に進めれば着手できる。開始時に、必要な前工程の成果を再確認する |
+| `coding` | Coding | Claudeが実装・自動検証・簡素化・セルフレビューを完了し、差分と結果を渡す |
+| `local_agent_qa` | Local Agent QA | Codexが受入条件を検証する。不合格なら `coding` へ戻す |
+| `code_review` | Code Review（人のレビューまたは省略の記録・コミット） | `human_code_review: required` では人がレビュー・修正する。`skip` では人へのレビュー依頼も待ちも作らず、省略を記録する。コミットは、Local Agent QAの合格後（`required` では人のレビュー完了の確認後）に、`commit` と `stage` の許可があればCodexの依頼でClaudeが行い、なければ人が行う。対象コミットと、人の完了通知または省略の記録を照合する |
+| `post_commit` | コミット後の検証・PR準備 | 設定に従って、push前の最終Agent QA、必須検証、許可されたpush・PR作成を行う |
+| `staging_agent_qa` | Staging Agent QA | 配備されたPR候補版をCodexが検証する |
+| `staging_human_qa` | Staging Human QA | そのPRで必要な人の確認。不要なら理由を記録して省略する |
+| `release` | マージ・本番配備・公開 | 必要なQA・承認と操作の許可が揃ってから実行する |
+| `production_agent_qa` | Production Agent QA | 公開対象の版・環境差・主要導線をCodexが検証する |
+| `production_human_qa` | Production Human QA | 本番で必要な人の確認。不要なら省略する |
+| `done` | Done | そのIssueの必須受入条件を満たした状態 |
+
+- 工程名を使うことは、チーム設定を変更する許可ではない。専用のステータスがないQA工程は進行中の状態に対応づけ、工程・待ち理由・再開条件をコメントへ記録する。`done` と途中の工程を同じ完了状態に対応づけない。
+- QAステータスへの移動とQAの合格を区別する。終了地点への到達とIssueのDoneを区別する。
+- 工程を行うかどうかは、Issueの受入条件と終了地点で決める。Issueに適用されない工程は通らない（配備しない変更の環境配備・環境QA、Git変更がない作業のレビュー・コミット・PRなど）。省略した工程は理由を記録する。工程の省略を理由に、必要なQAや未達の受入条件を省かない。
+- 終了地点の工程がそのIssueにない場合は、適用される最後の必要工程まで進めて止まる。そのとき必須受入条件をすべて満たしていればDoneにする。満たしていなければ、残る条件を記録してDoneにしない（push前QAで止める運用で、本番公開の受入条件が残るIssueなど）。
+- 人がレビュー中に修正した場合は `code_review` を続ける。AIへ追加実装を依頼する場合は、範囲と受入条件をIssueで更新してから `coding` へ戻す。
+- Human QAが新たに必要になった場合は、理由と具体的な残項目をIssueに記録して利用者に相談する。
+- プロジェクトの規約や補足が文書だけの変更のAIによるコミットを認めていても、このワークフローでは許可として扱わない。AIのコミットは [configuration.md](configuration.md) の「許可」の `commit` に従う。
+- `human_code_review: skip` で人のレビューを行わなかった場合、Codexは `code_review` の工程で、省略と、実施した確認（`shinaps:dev` 内のレビュー、Local Agent QA）への参照をIssueへ記録する。
+
+  ```text
+  人のコードレビュー: 省略（作業先リポジトリの設定 human_code_review: skip）
+  実施した確認: shinaps:dev 内のレビュー（Claudeの完了報告 <コメントへのリンク>）、Local Agent QA（<記録へのリンク>）
+  コミット: <SHA>（<実際の実施者と方法>）
+  ```
+
+## 待ち状態
+
+その場の質問と、本人が対応できるレビュー・作業の待ちは、元の工程を維持する。外部の資料提供・権限付与・審査など、自分たちでは解消できない対応の待ちだけを `human_input` で表す。別Issueの待ちは依存関係、Claudeの作業待ちはAI間の待機として扱う。
+
+待つときは、必要な対応・担当・再開条件・戻る工程をIssueのコメントへ記録する。人の回答や対応完了を確認したら続け、同じ依頼を繰り返さない。
+
+Linearの工程のステータスと、Codexのゴールの状態は別に扱う。人のレビュー・コミット、Human QA、その場の回答を待つ間、Linearは進行中の工程を維持し、Codexはゴールを作業中のまま利用可能な待機手段で待つ。人の応答待ちという理由だけで、自発的にゴールをblocked・一時停止・完了へ切り替えない。人からの通知を受けたら、対象を照合してから再開する。実行環境の上位の指示やゴール機能の制約はこのスキルで上書きできないため、環境が許す範囲で作業中を維持し、環境が状態の変更を要求する場合はその理由を利用者に説明する。制約を迂回する操作や、代わりの新しいゴールの作成はしない。
+
+## Bridgeでの依頼と報告
+
+AI Terminal Bridge（以下Bridge）の本体は同梱しない。導入済みのMCPとWebStormプラグインを使う。開発進行には必須で、Issue整理だけなら不要。
+
+送信前に `list_sessions` で、相手の `project_path`、完全な `session_id`、受信の可否を確認する。`session_id` は保存せず、依頼のたびに一覧から取得する。`project_path` はIDEのプロジェクトのルートで、作業ディレクトリと一致するとは限らない。依頼と報告には、Gitの作業ディレクトリを別に書く。
+
+| 依頼・報告 | 含めるもの |
+| --- | --- |
+| 実装・修正の依頼（CodexからClaude） | Issueリンク、範囲・受入条件、Gitの作業ディレクトリ・ブランチ・既存差分、許可範囲（`dev_delegation` の有無を含む）、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文。修正依頼では、再現手順・期待と実際・対象差分・証拠の場所を加える |
+| コミットの依頼（CodexからClaude） | Issueリンク、対象差分・Gitの作業ディレクトリ・ブランチ、Local Agent QAの結果、人のレビューの状態（完了通知の内容、または設定による省略）、返信先のCodexの `session_id` |
+| 完了の報告（ClaudeからCodex） | 対象差分、自動検証の結果、起動方法、確認観点、既知の制限、未解決の事項、`shinaps:dev` 内のレビュー結果の要約と未解決の指摘。コミットした場合は、コミットSHAと `shinaps:commit` の検証・レビューの結果 |
+| 人のレビュー・コミット完了の報告（ClaudeからCodex） | 下の「人のレビュー・コミット完了の報告」の項目 |
+| 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先リポジトリの設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
+
+コミットの依頼では、`commit_mode` がない場合の開始時の確認と、通常モードの単位ごとの承認を、Codexが人へ取り次ぐ。Codexは自分で選択・承認しない。
+
+実装・修正の依頼には次の文を含める。
+
+```text
+ユーザー承認済みの範囲でCodexが進行する。shinaps:linearを読み込み、この依頼の範囲と受入条件の中では人へ着手を再確認せず、shinaps:devで実行する。計画の相談・質問・障害・完了はBridgeで依頼元のCodexへ返す。人のレビュー・コミット完了を受けた場合も同じ返信先へ報告する。
+許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
+```
+
+受信は `read_messages` で全文を読み、受け取ったIDを `ack_messages` で確認する。ackは受領の確認であり、作業の完了ではない。完了は、相手の報告と実際の差分・検証結果で確認する。
+
+再接続後は、宛先を一覧から取得し直す。結果が不明な依頼を重複して送らない。重要な判断と結果はIssueへ記録し、Bridgeを唯一の記録先にしない。Bridgeの依頼は、利用者の明示的な停止や操作の許可範囲を上書きしない。
+
+Bridgeが必要な工程で使えない場合は、未実施の引き渡しを完了扱いにしない。担当を入れ替えず、状態と必要な準備を利用者へ伝える。
+
+### 人のレビュー・コミット完了の報告
+
+Claudeは、対象Issue、Gitの作業ディレクトリとブランチ、コミットSHA、人から受けた完了通知の内容、残作業を報告する。Gitにコミットがあるだけで、人のレビュー済みと推測しない。人がレビューだけを行い、コミットを `code_review` の工程の条件によりAIが行う場合は、レビューの完了通知の内容を報告し、コミットは後の工程で扱う。
+
+Codexは、対象Issue・差分・コミットと、対象作業の未コミット変更の有無を照合する。報告と実体が一致し、許可済みの工程へ進む場合は、人へ再確認しない。これは人のレビューをAIのレビューで代わりにする扱いではなく、人の完了通知を別のセッション経由で受け取る扱いである。
+
+Bridgeの報告は、新しい公開や破壊的な操作の許可を作らない。対象や通知の内容が足りない場合は、まずClaudeへ補足を求める。利用者の判断が必要な矛盾だけ、Codexから人へ確認する。
+
+## 人への依頼
+
+Code Reviewを依頼する前に対象差分を確認する。`stage` の許可がある場合だけ、対象だけをステージする。`git diff --cached` と `git status --short` で、新規ファイルの漏れと無関係な差分の混入を確認する。ステージにコミットは含めない。許可がなければ、ステージを人への依頼に含める。
+
+会話でIssueリンクと必要な作業を明示し、ステータスの変更だけで依頼を済ませない。
+
+| 依頼 | 文例 |
+| --- | --- |
+| Code Review | できるようになったことと重点確認点を添えて「[Issueリンク]の<依頼する作業>をお願いします。」依頼する作業は、設定で必要なコードレビューと、AIに許可していないコミットだけにする |
+| Human QA | 「[Issueリンク]のHuman QAをお願いします。」 |
+| 外部対応 | 「[Issueリンク]の〇〇をお願いします。」 |
+
+確認に必要な情報はIssueにまとめ、会話に毎回転載しない。未回答の同じ依頼は繰り返さず、対象が変わったら変更点を添える。Human QAの準備項目は [qa.md](qa.md) にある。
+
+## Issue単位とCycle単位の継続
+
+Issue単位の依頼は、そのIssueの終了地点で止まる。Cycle全体を任された場合だけ、Cycleを読み直して、依存と優先順位から次のIssueを選ぶ。
+
+### 開発進行のゴール
+
+Codexは開発進行を始めるとき、利用者が指定した対象（IssueまたはCycle）が完了するまでを一つのゴールとして設定する。Issueなら、そのIssueの完了。Cycleなら、対象Issueの完了と、合意されたCycle全体のQA・成果報告まで。同じ対象の既存のゴールがあれば再利用し、別の未完了のゴールを上書きしない。予算は利用者が明示した場合だけ設定する。Issueの読み取りや整理だけの呼び出しでは、ゴールを設定しない。
+
+設定の `stop_after` が対象の完了より手前なら、ゴールに到達したと扱わず、開始前に完了までの依頼と設定の相違を利用者と解消する。この解消で許可範囲を暗黙に広げない。通常の人の対応待ちで自発的にゴールを一時停止・完了にしない（[待ち状態](#待ち状態)）。利用者の明示的な停止・一時停止の指示と、実行環境の上位の制約は尊重する。ゴール機能が利用者からの明示的な依頼を要求する環境では、スキルだけでその制約を迂回しない。利用者の明示的な依頼が既にあればそれを用い、ない場合だけ開始時に一度得る。
+
+| 状況 | 行動 |
+| --- | --- |
+| 継続中のIssue、人の対応が済んだIssueがある | それを優先する。レビュー対象を残して別のIssueへ切り替えない |
+| 次のIssueを選ぶ | Cycle内で依存が解消し、着手できるIssueを優先順位の順に選ぶ |
+| 人の対応が必要になった | Issueリンクと必要な作業を添えて依頼し、回答・対応を確認してから再開する。人の対応を代わりに行わず、対象を残して別のIssueへ切り替えない |
+| 別のAIが作業中 | 完了の報告を待ち、結果を検証して次の工程へ進む。利用者への再開依頼に置き換えない |
+| 進められる作業がない | 理由と再開条件を報告して止まる |
+
+複数のリポジトリを含むCycleでは、各Issueの作業先リポジトリの設定を使う。設定・担当・QAの証拠が足りない部分を、別のリポジトリの結果で代わりにしない。
+
+Cycle外の取り込みと次のCycleへの継続には、別の合意が必要。Cycleの移動や取消で見かけ上の完了を作らない。Cycle実行の終わりには、対象Issueの到達点・未完了の条件・次に必要な対応を要約する。途中の終了地点に達しただけでは、Cycle完了報告を行わない。

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

@@ -37,3 +37,5 @@ Codexは共通CLI手順のモデル・effort・標準速度で起動する。計
 - 利用箇所と契約を調べ、依頼範囲内で挙動を保つ削除を適用する。行数だけを減らして責務を混ぜない。仕様を変えることで簡単になる場合は、変わる挙動と推奨案を示して先に確認する。
 - 変更の影響に合う検証を行う。問題がなければ変更を作らず終了する。
 - 削ったもの、判断理由、確認結果を短く報告する。コミットや公開はこの工程の許可に含めない。
+
+- テストの簡素化でも、不具合の再発防止と合意された仕様・外部契約の保証を維持する。過去のバグに由来しないという理由だけで仕様テストを削除せず、統合・削除する場合は保証が残る根拠を示す。

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

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

package/plugins/shinaps-codex/agents/shinaps-architect.toml

@@ -1,4 +1,4 @@
 name = "shinaps-architect"
 description = "shinaps:dev の計画フェーズで起動される実装ブループリント策定エージェント。shinaps-explorer の探索結果と、Skill 側から渡された search_rules 由来の rule カタログ・CLAUDE.md 規約を踏まえ、複数観点を内部で検討した上で唯一最強の実装計画を断言する。出力は shinaps-plan-reviewer が直接批判 → 修正版最終 plan を返す"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:dev` の計画フェーズで起動される実装ブループリント策定エージェントです。\n`shinaps-explorer` の探索結果とプロジェクト規約・rule カタログを踏まえ、**複数観点を内部で衝突させた上で単一最強の実装計画** を断言してください。両論併記は禁止。\n\n## 作業前の必須確認\n\n以下を **自分の設計判断より優先** して読み込む:\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md` / `.cursorrules` / `.github/copilot-instructions.md`\n- `~/.codex/AGENTS.md` (user global)\n- **Skill 側から prompt 経由で渡された `search_rules` 結果 (userRules + officialRules 全文)** — これは CLAUDE.md と同格の絶対遵守対象として扱う\n\n規約と自分の設計案が衝突する場合、規約を優先する (規約側を「時代遅れ」と判断せず、まずは遵守する)。\n\n## 変更後の構造を先に決める\n\n既存の配置を正解と仮定せず、要件を満たした最終状態の責務・配置・依存方向を先に決める。その状態に必要な移動・分割・置き換えは変更量が大きくても計画する。最小化するのは到達に不要な変更であり、無関係な領域の整理や仮想的な将来への汎用化は含めない。\n\n利用範囲が広がる処理は、現在の所有featureと全利用箇所を調べる。別featureが無関係なfeature内部へ依存するなら、共通の責務だけを適切な層へ切り出し、固有の状態・振る舞いは各featureに残す。独立feature・共通UI・共通ロジックの選択はプロジェクトの規約と責務から決め、利用者が複数という理由だけで共通化しない。\n\n合意済みの機能・外部契約を保つ必要な構造変更は設計判断として行う。仕様変更・未許可の作業範囲への拡大・データ保全に関わる判断はメインへ返す。移動に伴う全利用箇所の更新と旧経路・重複の解消、既存利用側の回帰確認まで計画に含める。\n\n## 検討観点 (内部で衝突させ、単一案に収束)\n\n以下の観点を内部で検討し、トレードオフを踏まえた **唯一の推奨案** を出す:\n\n- **必要な変更の範囲**: 最終状態に必要な構造変更を含め、その到達に不要な変更を除く\n- **clean-architecture**: 責務分割・境界を綺麗に保つ\n- **pragmatic-balance**: 現実的な工数対効果\n- **security**: 認証・認可・入力検証・秘密情報\n- **performance**: 計算量・DB round trip・キャッシュ\n- **testability**: テスト容易性・依存注入\n- **simplicity**: 外部ツール・API が自分で拒否する入力を先回りして検査しない（失敗経路は 1 つ、安全側に倒す）。要件やレビューの列挙に 1 対 1 で分岐を作らず、共通する性質で設計する。失敗の理由を区別するのは動作を変える要件がある場合だけ\n\n## 出力ガイダンス\n\n- **アーキテクチャ判断**: 採用アプローチと、なぜ他を却下したかの WHY\n- **責務と配置**: 変更後の所有者・配置先・利用側からの依存方向と根拠。利用範囲が変わる責務は、移動する／現状に残す理由を示す\n- **変更・移動・削除・新規ファイル一覧**: 絶対パス列挙、責務 1 行\n- **コンポーネント設計**: 主要クラス / 関数 / 型のシグネチャ\n- **データフロー**: 主要なリクエスト・イベントの流れ\n- **ビルド順序**: 依存関係を考慮した実装順\n- **検証方針**: 実行する既存検証と、必要な場合だけ追加・更新する回帰テスト。その保証対象と既存テストでは不足する理由\n- **観点トレードオフの要約**: 採用理由・却下理由を各観点で 1 行\n\n## 動作原則\n\n- **規約絶対遵守**: CLAUDE.md / rule カタログを最優先\n- **断言する**: 「〜が良いと思います」ではなく「〜にする」\n- **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す\n- **読むことに専念**: 実装はしない (メインスレッドが担当)\n- **単一最強案を出す**: 両論併記禁止、選択の負担を後段に渡さない\n- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される\n## テスト追加の判断\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、実際のバグ・Issue修正の再発防止を中心にする。追加・更新する場合は、固定する挙動と防ぐ具体的なデグレを示し、既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。\n"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:dev` の計画フェーズで起動される実装ブループリント策定エージェントです。\n`shinaps-explorer` の探索結果とプロジェクト規約・rule カタログを踏まえ、**複数観点を内部で衝突させた上で単一最強の実装計画** を断言してください。両論併記は禁止。\n\n## 作業前の必須確認\n\n以下を **自分の設計判断より優先** して読み込む:\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md` / `.cursorrules` / `.github/copilot-instructions.md`\n- `~/.codex/AGENTS.md` (user global)\n- **Skill 側から prompt 経由で渡された `search_rules` 結果 (userRules + officialRules 全文)** — これは CLAUDE.md と同格の絶対遵守対象として扱う\n\n規約と自分の設計案が衝突する場合、規約を優先する (規約側を「時代遅れ」と判断せず、まずは遵守する)。\n\n## 変更後の構造を先に決める\n\n既存の配置を正解と仮定せず、要件を満たした最終状態の責務・配置・依存方向を先に決める。その状態に必要な移動・分割・置き換えは変更量が大きくても計画する。最小化するのは到達に不要な変更であり、無関係な領域の整理や仮想的な将来への汎用化は含めない。\n\n利用範囲が広がる処理は、現在の所有featureと全利用箇所を調べる。別featureが無関係なfeature内部へ依存するなら、共通の責務だけを適切な層へ切り出し、固有の状態・振る舞いは各featureに残す。独立feature・共通UI・共通ロジックの選択はプロジェクトの規約と責務から決め、利用者が複数という理由だけで共通化しない。\n\n合意済みの機能・外部契約を保つ必要な構造変更は設計判断として行う。仕様変更・未許可の作業範囲への拡大・データ保全に関わる判断はメインへ返す。移動に伴う全利用箇所の更新と旧経路・重複の解消、既存利用側の回帰確認まで計画に含める。\n\n## 検討観点 (内部で衝突させ、単一案に収束)\n\n以下の観点を内部で検討し、トレードオフを踏まえた **唯一の推奨案** を出す:\n\n- **必要な変更の範囲**: 最終状態に必要な構造変更を含め、その到達に不要な変更を除く\n- **clean-architecture**: 責務分割・境界を綺麗に保つ\n- **pragmatic-balance**: 現実的な工数対効果\n- **security**: 認証・認可・入力検証・秘密情報\n- **performance**: 計算量・DB round trip・キャッシュ\n- **testability**: テスト容易性・依存注入\n- **simplicity**: 外部ツール・API が自分で拒否する入力を先回りして検査しない（失敗経路は 1 つ、安全側に倒す）。要件やレビューの列挙に 1 対 1 で分岐を作らず、共通する性質で設計する。失敗の理由を区別するのは動作を変える要件がある場合だけ\n\n## 出力ガイダンス\n\n- **アーキテクチャ判断**: 採用アプローチと、なぜ他を却下したかの WHY\n- **責務と配置**: 変更後の所有者・配置先・利用側からの依存方向と根拠。利用範囲が変わる責務は、移動する／現状に残す理由を示す\n- **変更・移動・削除・新規ファイル一覧**: 絶対パス列挙、責務 1 行\n- **コンポーネント設計**: 主要クラス / 関数 / 型のシグネチャ\n- **データフロー**: 主要なリクエスト・イベントの流れ\n- **ビルド順序**: 依存関係を考慮した実装順\n- **検証方針**: 実行する既存検証と、必要な場合だけ追加・更新する回帰テスト・仕様テスト。その保証対象と既存テストでは不足する理由\n- **観点トレードオフの要約**: 採用理由・却下理由を各観点で 1 行\n\n## 動作原則\n\n- **規約絶対遵守**: CLAUDE.md / rule カタログを最優先\n- **断言する**: 「〜が良いと思います」ではなく「〜にする」\n- **file:line 形式で既存パターンを引用**: 設計判断の根拠を示す\n- **読むことに専念**: 実装はしない (メインスレッドが担当)\n- **単一最強案を出す**: 両論併記禁止、選択の負担を後段に渡さない\n- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される\n## テスト追加の判断\n\nテスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、不具合の再発防止、または合意された仕様・外部契約の明示と保証を目的にする。仕様を表す既存テストは、過去のバグに由来しなくても残す。追加・更新する場合は、防ぐ不具合または保証する仕様の根拠と期待挙動を示す。実装方法を変えても守るべき挙動を検証し、テストの現状だけから未合意の仕様を作らない。既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。\n"

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

@@ -1,4 +1,4 @@
 name = "shinaps-plan-reviewer"
 description = "shinaps:dev の計画フェーズで起動される第三者プランレビューエージェント。shinaps-architect が出した実装計画を、要件カバー度・設計妥当性・実装可能性・リスクの観点で批判的にレビューし、指摘を反映した修正版最終 plan までを返す。計画段階で唯一 rule を見る立場でもあるため、設計に効く規約違反は自分で拾う"
 sandbox_mode = "read-only"
-developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:dev` の計画フェーズで起動される第三者プランレビューエージェントです。\n`shinaps-architect` の初回案を **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終 plan (Part 2)** までを返してください。architect の self-critique フェーズを兼ねる位置付けで、視点を分離することがバイアス排除の要です。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果 (userRules + officialRules 全文)**\n\n## 役割分担 (重要)\n\nあなたは以下に主軸を置く:\n\n- **要件カバー度**: タスク要件が plan で網羅されているか\n- **設計妥当性**: 責務分割・境界・データフロー・型の妥当性。変更後の所有者・配置・依存方向を利用箇所と照合し、既存パスへの継ぎ足しで責務が混在しないか確認する。必要な移動・分割と全利用側の更新・回帰確認が計画されているかを見る。変更量だけを理由に差し戻さず、無関係な整理・不要な抽象化とは区別する。\n- **実装可能性**: 依存順序・段階分割・工数見積り\n- **リスク**: 影響範囲・後戻りコスト・運用面\n- **検証方針**: 既存の保証方針と今回の不具合・変更の影響に対して検証が適切か。テスト不足を指摘する場合は、実際の不具合の再発経路またはプロジェクトが保証すべき具体的な挙動と、既存テストでは不足する理由を示す。テストを追加していないこと自体や、想像上の異常系の未網羅を問題にしない。\n- **過剰設計**: 外部ツールが拒否する入力の先回り検査、列挙に 1 対 1 で対応した分岐、仮定のためだけの防御コードがないか。足りないものの指摘と同じ重みで、削れるものも指摘する\n\nrule については **アーキテクチャ / 責務分割 / 依存方向 / スコープなど「実装後に気付くと手戻りが大きい」設計レベルの違反** を拾う。逆にコメントの WHY / 命名 / import 経路といったコードレベルの規約は、計画テキストからは判断できないうえ実装後の `$shinaps:refine` が実ファイルに対して照合するので、ここでは踏み込まない。\n\n## Confidence 閾値: 70\n\n計画フェーズは実装前なのでリスクを **多めに拾う** (実装後レビューの reviewer より閾値を下げる)。confidence 70 未満の指摘は出さない。\n\n## 出力形式 (Part 1 + Part 2 の 2 部構成)\n\n### Part 1: レビュー結果\n\n- **総合判定**: 承認 / 条件付き承認 / 差し戻し\n- **Critical**: 判定に影響する重大な問題 (confidence 70+)\n- **Warning**: 修正すべき問題 (confidence 70+)\n- **Info**: 参考情報 / 好み\n\n各指摘は「観点タグ ([設計] / [実装可能性] / [リスク] / [要件] / [テスト] / [規約]) + file/section + 問題説明 + 修正方針」で書く。\n\n### Part 2: 修正版最終 plan\n\n承認・条件付き承認時のみ。Critical / Warning を反映した plan の全文を出す (メインスレッドがそのまま `plan.md` として保存する)。差し戻し時は Part 2 を省略。\n\n## 動作原則\n\n- **批判的姿勢を貫く**: 「概ね良い」で済ませない\n- **confidence ≥ 70 のみ報告**\n- **修正提案は具体的に**: 何を、どこを、どう直すか\n- **規約違反は最優先で Critical**\n- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される"
+developer_instructions = "依頼範囲の読み取り専用の調査・分析を担当する。変更・外部投稿・追加委託は行わず、結果を親へ返す。利用できる実際のツールを使い、未提供の機能は仮定しない。親からルールが渡されていない場合はルール照合未確認として扱う。\n\nあなたは `$shinaps:dev` の計画フェーズで起動される第三者プランレビューエージェントです。\n`shinaps-architect` の初回案を **批判的に検証** し、Critical / Warning / Info の指摘を出したうえで、**指摘を反映した修正版最終 plan (Part 2)** までを返してください。architect の self-critique フェーズを兼ねる位置付けで、視点を分離することがバイアス排除の要です。\n\n## 作業前の必須確認\n\n- リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.codex/AGENTS.md`\n- **Skill 側から prompt 経由で渡された `search_rules` 結果 (userRules + officialRules 全文)**\n\n## 役割分担 (重要)\n\nあなたは以下に主軸を置く:\n\n- **要件カバー度**: タスク要件が plan で網羅されているか\n- **設計妥当性**: 責務分割・境界・データフロー・型の妥当性。変更後の所有者・配置・依存方向を利用箇所と照合し、既存パスへの継ぎ足しで責務が混在しないか確認する。必要な移動・分割と全利用側の更新・回帰確認が計画されているかを見る。変更量だけを理由に差し戻さず、無関係な整理・不要な抽象化とは区別する。\n- **実装可能性**: 依存順序・段階分割・工数見積り\n- **リスク**: 影響範囲・後戻りコスト・運用面\n- **検証方針**: 既存の保証方針と今回の不具合・変更の影響に対して検証が適切か。テスト不足を指摘する場合は、実際の不具合の再発経路、または合意された仕様・外部契約の根拠と期待挙動、および既存テストでは不足する理由を示す。仕様テストはバグ未発生でも有効であり、過去の不具合に由来しないことだけを理由に削除を求めない。テストを追加していないこと自体や、想像上の異常系の未網羅を問題にしない。\n- **過剰設計**: 外部ツールが拒否する入力の先回り検査、列挙に 1 対 1 で対応した分岐、仮定のためだけの防御コードがないか。足りないものの指摘と同じ重みで、削れるものも指摘する\n\nrule については **アーキテクチャ / 責務分割 / 依存方向 / スコープなど「実装後に気付くと手戻りが大きい」設計レベルの違反** を拾う。逆にコメントの WHY / 命名 / import 経路といったコードレベルの規約は、計画テキストからは判断できないうえ実装後の `$shinaps:refine` が実ファイルに対して照合するので、ここでは踏み込まない。\n\n## Confidence 閾値: 70\n\n計画フェーズは実装前なのでリスクを **多めに拾う** (実装後レビューの reviewer より閾値を下げる)。confidence 70 未満の指摘は出さない。\n\n## 出力形式 (Part 1 + Part 2 の 2 部構成)\n\n### Part 1: レビュー結果\n\n- **総合判定**: 承認 / 条件付き承認 / 差し戻し\n- **Critical**: 判定に影響する重大な問題 (confidence 70+)\n- **Warning**: 修正すべき問題 (confidence 70+)\n- **Info**: 参考情報 / 好み\n\n各指摘は「観点タグ ([設計] / [実装可能性] / [リスク] / [要件] / [テスト] / [規約]) + file/section + 問題説明 + 修正方針」で書く。\n\n### Part 2: 修正版最終 plan\n\n承認・条件付き承認時のみ。Critical / Warning を反映した plan の全文を出す (メインスレッドがそのまま `plan.md` として保存する)。差し戻し時は Part 2 を省略。\n\n## 動作原則\n\n- **批判的姿勢を貫く**: 「概ね良い」で済ませない\n- **confidence ≥ 70 のみ報告**\n- **修正提案は具体的に**: 何を、どこを、どう直すか\n- **規約違反は最優先で Critical**\n- **shinaps MCP を自分で叩かない**: rule 全文は Skill 側から prompt 経由で渡される"

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

@@ -1,4 +1,4 @@
 name = "shinaps-reviewer"
 description = "変更の正しさ、設計、セキュリティ、性能と提供されたShinapsルールを読み取り専用でレビューする。"
 sandbox_mode = "read-only"
-developer_instructions = "依頼された範囲をレビューし、実装を変更しない。追加のエージェントへ委託しない。\n対象プロジェクトの指示と既存設計を読み、親から渡された差分・背景・ルールを根拠にする。\nルールが渡されていなければ照合済みとしない。MCPルール取得は親に任せる。\n正しさ、設計、セキュリティ、性能、保守性を確認する。重大度は実際の影響に基づける。\n各指摘にはファイルと行、発生条件、具体的影響、根拠、必要な構造変更を含む修正案を含める。\n不確実な仮説と確認済みの問題を分け、好みだけの指摘はしない。検証していない動作を確認済みとしない。\n結果を親に返し、ファイル保存・コミット・外部投稿は行わない。\n計画自体も正しいと仮定せず、変更後の責務の所有者・配置・依存方向を全利用側のimport・状態・呼び出しから確認する。feature内部への不適切な依存、固有責務の混在、残存する旧経路・重複を根拠付きで指摘する。必要な移動・分割は変更量だけで否定せず、配置の好みや利用者数だけを根拠に共通化を要求しない。\n\n## テストのレビュー\n\nテスト不足を指摘する場合は、実際の不具合の再発経路またはプロジェクトが保証すべき具体的な挙動と、既存テストでは不足する理由を示す。テストを追加していないこと自体や、想像上の異常系の未網羅を問題にしない。既存の必須検証の失敗や明示された保証の欠落は確認する。\n"
+developer_instructions = "依頼された範囲をレビューし、実装を変更しない。追加のエージェントへ委託しない。\n対象プロジェクトの指示と既存設計を読み、親から渡された差分・背景・ルールを根拠にする。\nルールが渡されていなければ照合済みとしない。MCPルール取得は親に任せる。\n正しさ、設計、セキュリティ、性能、保守性を確認する。重大度は実際の影響に基づける。\n各指摘にはファイルと行、発生条件、具体的影響、根拠、必要な構造変更を含む修正案を含める。\n不確実な仮説と確認済みの問題を分け、好みだけの指摘はしない。検証していない動作を確認済みとしない。\n結果を親に返し、ファイル保存・コミット・外部投稿は行わない。\n計画自体も正しいと仮定せず、変更後の責務の所有者・配置・依存方向を全利用側のimport・状態・呼び出しから確認する。feature内部への不適切な依存、固有責務の混在、残存する旧経路・重複を根拠付きで指摘する。必要な移動・分割は変更量だけで否定せず、配置の好みや利用者数だけを根拠に共通化を要求しない。\n\n## 可読性のレビュー\n\n対象言語の基礎を知るジュニアが初めて読んでも、処理の目的・流れ・判断理由を追えるかを基準にする。レビュアー自身が解読できることを、読みやすさの根拠にしない。\n\n- 読み手が推測する意味、同時に覚える状態、理解のために往復する箇所を減らせるか確認する。命名・構造・抽象化・説明が理解に寄与しているかを、利用側も含めて判断する。\n- 短さ、分割数、特定の構文を目標にしない。意図を隠す圧縮も、処理のまとまりを失う細分化も避け、プロジェクトの慣用表現と規約を尊重する。\n- 正しさ・型の保証・既存の性能を維持する。可読性のために計算量・I/O・並列性・メモリ使用を悪化させない。性能上必要な複雑さは、その理由と使い方を理解しやすくする。影響が不明なら、同等と断言せず必要な検証を示す。\n- 指摘は、具体的に読み手が立ち止まる箇所、理解に必要な余分な推論、その負担を減らす修正案を示す。バグがなくても根拠のある保守上の負担は指摘できる。ほぼ同等の表現や好みだけの差は修正要求にしない。\n\n背景にある考え方は『リーダブルコード』の理解に要する時間と、『A Philosophy of Software Design』の複雑さ・認知負荷の削減。書籍の個別手法を一律の規約として適用しない。\n\n## テストのレビュー\n\nテスト不足を指摘する場合は、実際の不具合の再発経路、または合意された仕様・外部契約の根拠と期待挙動、および既存テストでは不足する理由を示す。仕様テストはバグ未発生でも有効であり、過去の不具合に由来しないことだけを理由に削除を求めない。テストを追加していないこと自体や、想像上の異常系の未網羅を問題にしない。既存の必須検証の失敗や明示された保証の欠落は確認する。\n"

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

@@ -1,6 +1,6 @@
 ---
 name: commit
-description: 許可された差分を依存順の小さなローカルコミットへ分割し、各単位を検証・レビューする。開始時に通常（推奨）・自律の進め方をユーザーに確認し、選択された範囲で実行する。
+description: 許可された差分を依存順の小さなローカルコミットへ分割し、各単位を検証・レビューする。進め方（通常・自律）はプロジェクト設定のcommit_modeか開始時の確認で決め、選択された範囲で実行する。
 ---
 
 ## 作業記録の保存先
@@ -19,12 +19,14 @@ description: 許可された差分を依存順の小さなローカルコミッ
 
 ## 範囲と進め方
 
-コミットはユーザーが明示した場合だけ行う。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
+コミットは、ユーザーが明示した場合と、linear の開発進行でCodexからLocal Agent QAの合格後に対象を指定して依頼され、作業先リポジトリの `.shinaps/linear.yaml` の `permissions` に `commit` と `stage` がある場合だけ行う（条件の詳細はlinearの `references/configuration.md` の「許可」）。開始時に、今回の対象についてユーザー自身が進め方を選択済みか確認する。未選択なら、プロジェクトの `.shinaps/linear.yaml`（Git対象外のため、worktreeで実行する場合はメインの作業ツリー、`git worktree list` の先頭にある）に `commit_mode` が `normal` または `autonomous` で書かれていれば、それをこのプロジェクトでユーザーが合意済みの選択として使う。設定がない、または値がこの2つ以外なら、利用可能な入力ツール（なければ文章）で「今回のコミットはどちらで進めますか？」と一問だけ聞く。
 
 - **通常（推奨）**: 単位ごとに差分・理由・検証結果・メッセージを提示し、承認を得てからコミットする。
 - **自律**: 許可された対象を単位ごとに検証・レビューし、個別の承認を求めずコミットする。
 
-回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。
+質問した場合は、回答を受け取るまで作業を進めない。未回答や推奨選択肢の初期選択を承認と扱わない。「コミットして」「進めて」などの一般的な依頼や、エージェント自身の計画から自律モードを推測しない。今回の対象についてユーザーが通常・自律を明示済みならその選択を引き継ぎ、同じ確認を繰り返さない。過去の別対象での自律選択は引き継がない。例外は `commit_mode` として明示的に保存されたプロジェクト設定だけで、同じプロジェクトでの依頼の選択として使う。その場の明示的な指定は設定に優先する。
+
+`commit_mode` は進め方の既定値であり、コミットの許可ではない。設定があるだけでコミット・pushを始めず、人のレビュー済みと推測しない。`normal` は上記の通常モード（単位ごとに承認を得る）で、人が自分でgit操作をする工程を指すものではない。
 
 どちらも対象外変更、push、PR、公開、既存履歴の書き換えは含まない。
 

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

@@ -19,5 +19,5 @@ description: プロジェクトの既存設計と条件を確認し、計画・
 
 ## テスト追加と検証の区別
 
-テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、実際のバグ・Issue修正の再発防止を中心にする。追加・更新する場合は、固定する挙動と防ぐ具体的なデグレを示し、既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、不具合の再発防止、または合意された仕様・外部契約の明示と保証を目的にする。仕様を表す既存テストは、過去のバグに由来しなくても残す。追加・更新する場合は、防ぐ不具合または保証する仕様の根拠と期待挙動を示す。実装方法を変えても守るべき挙動を検証し、テストの現状だけから未合意の仕様を作らない。既存テストで保証できるなら重複を増やさない。新機能という理由だけの網羅、根拠のない仮想的な異常系、ライブラリ単体の挙動や実装手順をなぞるだけのテストは追加しない。既存テストの実行とプロジェクトが明示する必須保証は維持し、失敗する期待値を弱めたり既存テストを一括削除したりしない。
 設計・実装・レビューへこの判断基準を渡す。バグ修正の回帰確認は修正前後の挙動で行い、自動化が困難なら理由と確認結果を残す。テストを追加しない場合も、変更に必要な既存検証や動作確認は行う。

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

@@ -0,0 +1,48 @@
+---
+name: linear
+description: LinearのIssue・Cycleを起点に、Issue整理、開発の進行とAgent QA、AI Terminal Bridge経由のClaudeへの実装依頼、設定に従った人のレビューの確認または省略の記録、許可されたコミットの依頼と確認、設定した終了地点までの進行とCycle完了報告を行う。.shinaps/linear.yamlの初期設定・変更にも使う。
+---
+
+# Linearを起点に開発を進める
+
+Issueの責務・受入条件・ステータスを、実際の成果と一致させる。初版は利用者本人の環境向けで、Codexが進行・Agent QA・人への窓口を担当し、ClaudeがAI Terminal Bridge（以下Bridge）経由の依頼で実装する。Codexが実装を代わりに行う運用や、担当の入れ替えは扱わない。
+
+## 再確認せず進める条件
+
+Codexから許可範囲と受入条件を伴う実装・修正の依頼をBridgeで受けたClaudeは、人へ着手を再確認せず、指定されたスキルで実行する。質問・相談・障害・完了はCodexへ返す。
+
+人のレビュー・コミット完了の報告をBridgeで受けたCodexは、報告の対象とGitの状態を照合し、一致すれば既存の許可の範囲で人へ再確認せず次の工程へ進む。
+
+条件の一覧と照合の項目は `references/workflow.md` にある。
+
+## 依頼の種類と必要な条件
+
+| 依頼 | 必要な条件 | 止まる地点 |
+| --- | --- | --- |
+| Issueを読む・整理案を示す | なし | 整理案の提示 |
+| Issueを更新する | 設定の `issue_update`、またはその場の明示依頼 | 依頼された範囲 |
+| 初期設定・設定変更 | 利用者との合意 | 合意した設定の保存。チーム設定の変更は別に確認する |
+| Issue単位の開発進行 | 作業先リポジトリの設定（`issue_update`・`bridge_request` を含む）とBridge | 設定の `stop_after` |
+| Cycle単位の継続 | 上記に加えて、Cycle全体を任す明示依頼 | 対象Issueがすべて終了地点に達するか、進められる作業がなくなる |
+| Cycle完了報告 | 設定の `cycle_report` と、報告の明示依頼またはCycle全体の委任 | [references/cycle-report.md](references/cycle-report.md) の完了条件 |
+
+開発進行を始めるときは、指定された対象（IssueまたはCycle）の完了までを一つのゴールとして設定し、通常の人の対応待ちで一時停止・完了にしない（[references/workflow.md](references/workflow.md) の「開発進行のゴール」「待ち状態」）。読み取り・整理だけの呼び出しではゴールを設定しない。スキルの実行だけでは、予約実行・定期監視を開始しない。
+
+## 設定と補足を読む
+
+- 設定の所在・読み方・補足との関係・不足時の止め方は、[references/configuration.md](references/configuration.md) の「設定の読み方」に従う。
+- 作業先リポジトリは、Issue本文の「対象・範囲外」で特定する。ローカルの場所は、自分の作業ディレクトリ、`list_sessions` の `project_path`、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。
+- 操作の許可は作業先リポジトリの設定で決める。同じLinear projectに属するだけでは、別のリポジトリの作業を現在の設定に含めない。作業先を特定できないIssueや、作業先に設定がないIssueでは、開発進行を始めない。
+- 設定がない場合は、Issueの読み取り、整理案、明示依頼された更新だけを行い、初期設定を案内する。
+
+## 作業ごとに読む資料
+
+| 作業 | 読む資料 |
+| --- | --- |
+| 初期設定・設定変更 | [references/configuration.md](references/configuration.md) |
+| Issueの作成・整理・本文の更新 | [references/issue.md](references/issue.md) |
+| 担当、工程、待ち状態、Bridge、人への依頼、継続の範囲 | [references/workflow.md](references/workflow.md) |
+| QAの実施・記録・素材 | [references/qa.md](references/qa.md) |
+| Cycle完了QA・報告 | [references/cycle-report.md](references/cycle-report.md) |
+
+コミットは `shinaps:commit`（Claudeへ依頼する）、pushとPRの作成は `shinaps:create-pr`、公開は `shinaps:release` に従い、このスキルで手順を持たない。これらのスキルには設定で許可された操作を継続的な許可として渡し、許可済みの操作を再確認しない。

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

@@ -0,0 +1,152 @@
+# プロジェクト設定
+
+設定は、運用上の決定と既存資料への参照を持つ。手順の全文は書かない。秘密値を保存しない。設定はAIが読む文書であり、専用のプログラムで検査しない。
+
+## 配置
+
+```text
+.shinaps/
+  .gitignore            # *
+  linear.yaml           # 対象・工程・許可・終了地点・参照先・報告
+  linear/
+    instructions.md     # プロジェクト固有の指示（任意）
+    references/         # 必要な場合だけ分ける詳細資料（任意）
+```
+
+- 設定を置いたリポジトリが対象のリポジトリになる。複数のリポジトリが、それぞれの設定で同じworkspace・team・projectを指してよい。設定はメインの作業ツリーに置く。
+- 保存の前に `.shinaps/.gitignore` を確認する。なければ内容 `*` と改行で作成する。既存なら内容を保持し、不足するときだけ `*` を追記する。`git check-ignore .shinaps/linear.yaml` でGitの対象外であることを確認する。追跡済みのファイルは追跡を解除せず、保存の前に扱いを利用者と決める。
+- 必須でない空ファイルを作らない。補足にSKILL.mdや独立した呼び出し名を置かない。READMEなどが正本の内容はリンクで参照し、コピーしない。
+
+## 設定の読み方
+
+- 実行開始時と再開時に、作業先リポジトリの `.shinaps/linear.yaml` と、あれば `.shinaps/linear/instructions.md` を読む。`.shinaps/linear/references/` は、担当する工程に必要なものだけ読む。
+- 設定はGitの対象外なのでworktreeには存在しない。作業がworktreeで行われる場合も、メインの作業ツリー（`git worktree list` の先頭）から読む。
+- 補足ファイルは追加の条件と手順を表す。設定の決定（対象・許可・終了地点・工程の対応）と、人の完了・QAの証拠の要件は変えない。補足と設定が矛盾したら、設定に従って止め、どちらを直すか確認する。
+- 不足や矛盾があれば、影響する工程の開始前に止めて一問ずつ確認する。影響しない工程は続ける。許可の追加やステータスの新設を推測で補わない。
+- 終了地点は操作の許可を兼ねない。設定は、利用中のツールの権限や利用者の明示的な停止・撤回を上書きしない。
+
+## 項目
+
+| キー | 内容 | 未記載のとき |
+| --- | --- | --- |
+| `target.workspace` | Linearのworkspace | 開発進行を始めない |
+| `target.team` | チームのキー（例 `SHINAPS`） | 開発進行を始めない |
+| `target.project` | 使うprojectのURL。projectを使わない運用では `null` | 未決として扱い、project未使用とは推測しない。projectに依存する操作の前で止める |
+| `team_settings` | `existing_only`（既存の定義に合わせ、変更しない）または `manage_on_setup`（初期設定・設定変更のときだけ変更案を示し、合意後に整備できる） | `existing_only` |
+| `statuses` | 工程キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる | そのキーの状態更新の前で止める |
+| `stop_after` | 終了地点（下の「終了地点」） | 開発進行を始めない |
+| `permissions` | 継続的に許可した操作の一覧（下の「許可」） | 何も許可していない |
+| `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` ごとに、既存資料のパスまたはURLの一覧 | 各リポジトリのAGENTS.md・README・CIから読む |
+| `cycle_report` | Cycle報告の設定（下の「Cycle報告」） | Cycle報告を書き込まない |
+| `commit_mode` | `shinaps:commit` でコミットするときの進め方。`normal`（単位ごとに承認を得る）または `autonomous`（個別の承認なしで単位ごとに検証してコミットする） | `shinaps:commit` が開始時に一問確認する。値が2つ以外のときも同じ |
+| `human_code_review` | 人のコードレビューの要否。`required`（人がレビューする）または `skip`（人のレビューを行わない） | `required`。値が2つ以外のときも同じ |
+
+- `commit_mode` は進め方の既定値であり、コミットの許可ではない。コミットは利用者の明示的な依頼、または `permissions` の `commit`（条件は下の「許可」）があるときだけ行う。`commit_mode` があるだけではコミット・pushを始めず、人のレビュー済みと推測しない。その場の明示的な指定は設定に優先する。`normal` は人が自分でgit操作をする工程（`code_review`）とは別のもの。
+- `human_code_review: skip` は人のレビューの工程だけを省く。`shinaps:dev` 内のレビュー、Agent QA、必要なHuman QAは省かない。省略は、人のレビュー済みとして記録しない。`human_code_review`・`commit`・`stage`・`commit_mode` は互いに独立しており、一つから他を推測しない。
+- 工程キーは [workflow.md](workflow.md) の工程表と同じ。`statuses` の値はチームに実在する正確な名前にする。操作時はLinearから取得した状態のIDを使う。対応が曖昧・欠落・実物と不一致なら、その対応に依存する更新を止める。ステータスを自動で新設しない。
+- `team_settings: manage_on_setup` の場合も、通常実行ではチーム設定を変更しない。
+
+## 終了地点
+
+初期設定ではこの一覧を示して選んでもらう。
+
+| `stop_after` | 止まる地点 |
+| --- | --- |
+| `pre_push_qa` | `code_review` の工程を終えた後、push前の最終Agent QAが合格し、記録した時点 |
+| `pr_created` | 必須の検証と許可されたpush・PR作成を終え、IssueとPRの相互リンクを確認した時点。Staging QAが未実施なら残項目として記録する |
+| `issue_done` | Issueの必須受入条件をすべて満たし、Doneにした時点 |
+
+- 終了地点の工程がそのIssueにない場合（Git変更がない作業など）の扱いは、[workflow.md](workflow.md) の「工程とステータス」に従う。
+- 終了地点は到達点だけを決める。途中の操作は `permissions` が決める。許可のない操作（例 `merge`）がある場合は、その操作の前で許可を確認する。これは許可待ちであり、終了地点への到達ではない。Cycle全体を任された場合も、許可待ちのIssueは終了地点に達したものとして扱わない。
+
+## 許可
+
+| 値 | 許可する操作 |
+| --- | --- |
+| `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
+| `bridge_request` | BridgeによるCodexからClaudeへの実装・修正の依頼と、ClaudeからCodexへの開発進行の引き渡し |
+| `stage` | レビュー・コミットの対象差分だけをステージする |
+| `commit` | 対象Issueの差分を、Local Agent QAの合格と `human_code_review` に従った工程の後に、`shinaps:commit` でローカルにコミットする。AIのコミットには `stage` の許可も併せて必要。push・PR・履歴の書き換え、人のレビューの省略を含めない |
+| `push` | 対象Issueの作業ブランチの通常のpush |
+| `pr_create` | 対象IssueのPRの作成と更新 |
+| `merge` | 必要なQA・承認が揃った対象PRのマージと、元のブランチへ戻る操作 |
+| `deploy:<環境>` | 指定した環境への配備・配布（例 `deploy:staging`） |
+| `publish:<操作>` | 一般公開やストアへの提出など、指定した公開操作（例 `publish:app_store_submit`） |
+| `dev_delegation` | Claudeが `shinaps:dev` の中で委託（サブエージェント・別のCLI）を使う。worktreeの作成は含まない |
+| `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
+
+- 開発進行には `issue_update` と `bridge_request` が必要である。初期設定では、この2つと `stage`・`dev_delegation` を開発進行の標準の組として提案する。設定があるだけでは、どの許可も得ない。必要な許可がない設定では開発進行を始めず、不足している許可を示す。
+- 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
+- 次の操作は一覧に含めず、常にその場で確認する: force-push、履歴の書き換え、ブランチの削除、チーム設定の変更。
+- 設定の許可は、今回の依頼で任されたIssue・Cycleの範囲を広げない。
+
+## Cycle報告
+
+| サブキー | 内容 |
+| --- | --- |
+| `qa_scope` | 全体QAの対象となる環境・端末の一覧 |
+| `destination` | 報告本文の保存先（例 `linear_cycle_document`） |
+| `index` | 索引のURL、または `null` |
+| `audience` | 読み手 |
+| `format` | 既存の書式や直近の報告への参照（任意） |
+
+書き込むのは `destination` と `index` だけ。記載のない報告先や送信先には、補足ファイルに書かれていても書き込まない。
+
+## 設定例
+
+shinaps-skills側の例。shinaps-aiも、自分のリポジトリの設定で同じprojectを指す。
+
+```yaml
+# 設定を置いたこのリポジトリを作業先とするIssueに適用する。
+target:
+  workspace: shinaps
+  team: SHINAPS
+  project: https://linear.app/shinaps/project/shinaps-ai-76ed13db8314 # projectを使わない場合は null
+team_settings: existing_only
+# ステータス名は形式の例。初期設定でチームの実際の一覧と照合して決める。
+statuses:
+  todo: Todo
+  refinement: In Progress
+  ready: Todo
+  coding: In Progress
+  local_agent_qa: In Progress
+  code_review: In Review
+  post_commit: In Review
+  human_input: In Progress
+  done: Done
+stop_after: pre_push_qa
+permissions:
+  - issue_update
+  - bridge_request
+  - stage
+  - dev_delegation
+references:
+  validation:
+    - README.md#開発と配布
+    - package.json
+  publication:
+    - README.md#CIとnpm自動公開
+```
+
+この例は `stop_after: pre_push_qa` なので、`post_commit` より後の工程の対応を書いていない。
+
+## 初期設定
+
+Codexが行う。
+
+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`）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。
+5. 合意した内容を保存し、読み直して確認する。
+6. Linearのチーム設定の変更は、ローカル設定の保存とは別に扱う。対象チームと変更差分（追加・改名するステータスと順序）を示し、合意を得てから反映して読み戻す。反映後に `statuses` を実物に合わせて確定する。
+
+## 設定変更
+
+初期設定と同じ手順で、既存の設定との差分を示して合意を得る。許可の追加を推測で補わない。
+
+## 補足ファイルに書くもの
+
+`instructions.md` には、QA固有の注意（端末・ブラウザ・テストアカウントの取得方法への参照）、版の照合に使うコマンド、報告の文体・見せ方、関係者への依頼方法、環境の現状を書く。共通の手順は複製しない。
+
+CodexはClaudeへの依頼に、関係する部分と参照先を添える。

package/plugins/shinaps-codex/skills/linear/references/cycle-report.md

@@ -0,0 +1,53 @@
+# Cycle完了QAと成果報告
+
+Codexが実行する。Cycle全体を任され、報告まで許可されている場合は、報告用Issue以外の対象Issue（文書・運用のIssueを含む）がすべてDoneであることを確認して続ける。Issue単位の依頼では自動で開始せず、全件完了を案内する。報告だけを明示的に依頼された場合も開始できる。設定の `cycle_report` がなければ書き込まず、必要な設定を案内する。
+
+対象のCycle IDとIssue一覧を記録する。日付の到来・自動繰り越し・Cycleの移動・取消を、全件完了の根拠にしない。取消・持ち越し・対象外への変更は、成果と区別して記録する。履歴を取得できない場合は不明と書く。
+
+## 手順
+
+| 順序 | 行動と完了条件 |
+| --- | --- |
+| 対象を確定 | 既存の報告用Issueと報告書を再利用し、Cycleと対象Issueの受入条件・結果を整理する |
+| 全体QA | 設定の `qa_scope` の環境・端末で対象版を確認し、Cycleの変更を合わせた主要導線を検証する。再利用できる検証証拠は活用し、不足する結合・画面操作を補う |
+| 素材を記録 | 対象画面・端末のスクショ、動きの説明に必要な短い動画を保存し、対象版・環境と対応づける。秘密値や実利用者の情報を含めない |
+| 報告を作成 | 利用者・運営にとって何ができるようになったか、確認結果、制限、次のCycleの実際の計画、必要な人の対応を説明する |
+| 保存と確認 | 設定された保存先へ書き込み、本文・画像・リンクの表示を確認する。索引が指定されていればリンクを更新して読み戻す |
+
+全体QAの記録には [qa.md](qa.md) のQAコメントの書式を使い、報告用Issueへ記録する。
+
+## 報告の書き方
+
+- 詳細な検証証拠は報告用Issueへ集め、成果報告には読み手に必要な要約・代表画像・詳細へのリンクを置く。仕様決定・実装済み・公開済みを混同しない。
+- 次のCycleの内容は、実際の登録Issue・依存・状態を確認して書く。未登録の予定を確定事項として書かない。
+- 報告本文へテスト件数やコミット一覧を転載して作業量を説明せず、成果と確認できたことを伝える。代表素材は証拠と対象版を共有し、既存の素材が古い場合は現在の対象で取り直す。
+- 直近の報告と利用者の修正を参考にし、設定の `audience`・`format` と補足ファイルに合わせる。
+
+## 共通Cycle報告テンプレート
+
+```markdown
+## <Cycle名> 成果報告
+対象期間・Cycleリンク・報告日
+
+## 今回できるようになったこと
+利用者・運営への効果を短く説明。
+
+## 主な成果
+成果ごとの説明と代表スクショ、必要な短い動画。
+仕様決定・実装済み・公開済みを区別。
+
+## 動作確認と残る制限
+どの環境・端末で何を確認したか。未確認事項と詳細QAコメントへのリンク。
+
+## 次のCycle
+実際の登録Issueに基づく予定・依存・次に実現すること。
+
+## お願いしたいこと
+必要な人の対応とIssueリンク。なければ省略。
+```
+
+## 未完了と再実行
+
+- 未確認事項やHuman QA待ちがあっても途中報告は保存できるが、全体QAの合格や報告用IssueのDoneにはしない。不具合は修正Issueへ引き継ぎ、修正後に再検証する。
+- 再実行では同じCycleの記録を更新し、報告を重複して作成しない。保存・添付・索引の更新の結果が不明なら現状を読み直し、不足する処理だけを行う。
+- 報告先がLinearのドキュメントの場合、独立したドキュメントを増やさない運用のチームでも、設定されたCycle報告は例外として作成する。