@shinaps/skills 0.11.0

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

@@ -0,0 +1,145 @@
+---
+name: review
+description: shinaps-reviewer + shinaps-review-validator で精度の高い単独レビューを行うスキル。差分・PR・既存コードを引数で切り替え。rule カタログとの照合を reviewer prompt に埋め込むことで、指摘の rule 起点タグ付けを bake する。確定指摘があればそのまま /shinaps:dev へ橋渡しして修正計画 + 実装まで進められる
+argument-hint: <なし | PR番号 | ファイル/ディレクトリパス>
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+
+## 実行環境とプロジェクト条件
+
+この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・許可を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
+
+Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用できる場合は対応するツールを使う。現在のセッションで提供されていないツールは仮定しない。質問は一問ずつ確認して回答を待つ。
+
+別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名はClaudeのpluginで公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
+
+## 引数仕様
+
+| 呼び出し | モード | 動作 |
+|---|---|---|
+| `/shinaps:review` | branch | `git diff <base>...HEAD` を取得してレビュー |
+| `/shinaps:review <PR番号>` | PR | GitHub PR の diff をフェッチしてレビュー |
+| `/shinaps:review <path>` | path | 指定パス配下のファイルをフルコードレビュー |
+
+引数の型判定: 引数なし → branch、数字のみ → PR、それ以外 → path。
+
+## 使用エージェント
+
+| エージェント | subagent_type | 役割 |
+|---|---|---|
+| Shinaps Reviewer | `shinaps-reviewer` | logic / design / security / performance / maintainability / rule の統合観点 |
+| Shinaps Tech Surveyor | `shinaps-tech-surveyor` | 毎回起動、採用 API / library / 言語機能の現代性・代替・落とし穴を外部調査 |
+| Shinaps Survey Validator | `shinaps-survey-validator` | tech-surveyor が具体推奨を出した場合のみ起動、出典を再確認 |
+| Shinaps Review Validator | `shinaps-review-validator` | reviewer 指摘の妥当性検証 + tech-survey 統合 |
+
+## ディレクトリ規約
+
+```
+.shinaps/work/reviews/{YYYYMMDD-HHMMSS}-{mode}/
+├── input.md                  ← レビュー対象のサマリ
+├── review.md                 ← shinaps-reviewer の生レポート
+├── tech-survey.md            ← shinaps-tech-surveyor の生レポート
+├── tech-survey-validated.md  ← shinaps-survey-validator の検証済みレポート (surveyor が具体推奨を出した場合のみ)
+└── review-validated.md       ← shinaps-review-validator の検証済み指摘リスト (dev にはこのパスを直接渡す)
+```
+
+`{mode}` は `branch` / `pr-{N}` / `path-{slug}`。
+
+## 実行フロー
+
+### Phase 1: 引数判定とレビュー対象の取得
+
+- 今回の依頼に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。既存成果物がなければ追加取得は不要。
+- **branch モード**: ベースブランチ判定 → `git diff <base>...HEAD` を取得。空ならエラー終了 (「差分がありません」)
+- **PR モード**: `gh pr view <番号>` で PR 情報、`gh pr diff <番号>` で diff を取得
+- **path モード**: 存在確認 → Read。50 ファイル超えたら `AskUserQuestion` で「全部レビューする / 主要ファイルに絞る / 中断」を確認
+
+### Phase 2: 入力サマリ保存
+
+メインが Write で `input.md` に以下を保存:
+- モード / 取得時刻 / 対象情報
+- 変更ファイル一覧
+- diff 全文 (branch / PR) または コード本体一覧 (path)
+
+### Phase 3: reviewer + tech-surveyor を並列起動 (一次レビュー)
+
+**1 メッセージ内で 2 subagent を並列 spawn する** (Agent tool を 1 メッセージ内で複数呼び出す)。
+
+#### 前準備 (メインスレッド)
+
+`list_search_facets()` + `search_rules({ repoOwner, repoName, ...推定 facet })` を実行して rule カタログを確保。
+
+#### shinaps-reviewer プロンプト
+
+- レビューモード (branch / pr / path)
+- `input.md` 全文
+- **Phase 1 で作成した既存成果物の要約**
+- **前準備の `search_rules` 結果 (userRules + officialRules 全文)**
+- モード別追加指示 (branch なら base branch との差分の背景、PR なら PR description、path ならファイル配下の責務)
+- 「confidence ≥ 80 のみ報告、rule 違反は必ず Critical タグ」
+
+#### shinaps-tech-surveyor プロンプト
+
+- `input.md` 全文
+- **Phase 1 で作成した既存成果物の要約**
+- **前準備の `search_rules` 結果**
+- 「(a) 採用 API / library / 言語機能は現代的か、(b) より良い代替があるか、(c) 既知の落とし穴、(d) 採用バージョンの安全性、を WebSearch / WebFetch で調査せよ。既存スタック + rule カタログ整合性を予選条件に」
+
+**記録先**: メインが Write で `review.md` / `tech-survey.md` に全文保存
+
+### Phase 3.5: shinaps-survey-validator 起動 (条件付き)
+
+tech-surveyor が「特筆事項なし」以外を返した場合のみ起動。
+
+**プロンプト**:
+- `tech-survey.md` 全文
+- 前準備の `search_rules` 結果
+- 「全ての出典 URL を WebFetch で再確認せよ」
+
+**記録先**: メインが Write で `tech-survey-validated.md`
+
+### Phase 4: shinaps-review-validator 起動
+
+**プロンプト**:
+- `input.md` 全文
+- `review.md` 全文
+- **前準備の `search_rules` 結果**
+- `tech-survey-validated.md` 全文 (Phase 3.5 実施時のみ、なければ tech-survey.md を渡す)
+- 「指摘ごとに該当コードを Read で確認し、confirmed / false positive / partial / out-of-scope に分類せよ。rule 起点の追加発見は積極的に報告」
+
+**記録先**: メインが Write で `review-validated.md`
+
+### Phase 5: 次アクション選択
+
+確定指摘が 1 件以上あれば `AskUserQuestion` で:
+- **修正実装に進む** (`/shinaps:dev` へ橋渡し) (推奨)
+- **PR にコメント投稿する** (PR モードのみ)
+- **ローカル保存のみで終了**
+
+**修正実装選択時 (Phase 6 前) に ローカル成果物（implementation.md / 調査・レビューレポート）** で修正方針決定の記録を残す。
+
+### Phase 6: /shinaps:dev への橋渡し (修正実装選択時)
+
+```
+Skill(skill="shinaps:dev", args="以下のレビュー指摘を修正する。詳細は .shinaps/work/reviews/{ts}-{mode}/review-validated.md を参照: {修正タスクの 1 行サマリ}")
+```
+
+### Phase 7: PR コメント投稿 (PR モードかつ選択時)
+
+`gh pr review <番号> --comment --body-file <review-validated.md>` で投稿。**投稿前に本文確認必須** (`AskUserQuestion` で「投稿する / 本文を編集する / 中断」)。
+
+## 動作原則
+
+- **並列 + 検証パイプライン**: reviewer + tech-surveyor を並列、その結果を review-validator が統合
+- **tech-surveyor は毎回起動**: 現代的な代替や落とし穴を必ずチェック
+- **survey-validator は省略可**: tech-surveyor が「特筆事項なし」なら起動しない
+- **rule 照合を reviewer / review-validator に bake**: `search_rules` 結果を prompt に埋め込む
+- **subagent は文字列応答のみ**: raw/*.md への Write / Edit は必ずメインが担当
+- **生レポート保存厳守**: すべての subagent 応答を全文保存
+- **PR コメント投稿は要承認**: 外部影響のある操作は必ず本文確認
+- **diff が空ならエラー終了**: 何もしない旨を明示

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

@@ -0,0 +1,26 @@
+---
+name: simplify
+description: 実装・設計・手順を目的と必要条件から見直し、不要な要素を削除して簡素化する。実装後のセルフレビュー前や、複雑さの見直しを求められたときに使う。
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+
+# 目的から見直して減らす
+
+## プロジェクトの条件を読む
+
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
+
+既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+
+## 判断と実行
+
+- 目的、守る外部契約、現在の実装方法を区別する。今の構造を要件として正当化しない。
+- 根拠の弱い前提、不要な分岐・互換層・重複、丸ごと消せる手順を実物から探す。削除 → 簡素化 → 最適化 → 自動化の順で考え、必要な段階だけ実施する。
+- 利用箇所と契約を調べ、依頼範囲内で挙動を保つ削除を適用する。行数だけを減らして責務を混ぜない。仕様を変えることで簡単になる場合は、変わる挙動と推奨案を示して先に確認する。
+- 変更の影響に合う検証を行う。問題がなければ変更を作らず終了する。
+- 削ったもの、判断理由、確認結果を短く報告する。コミットや公開はこの工程の許可に含めない。

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

@@ -0,0 +1,207 @@
+---
+name: spec
+description: ざっくりした要望を入力に、対話的なヒアリング + 既存実装調査 (shinaps-explorer) + フィジビリティ調査 (shinaps-tech-surveyor で外部情報 + shinaps-survey-validator で出典検証 + 採用候補決定 + 必要ならプロトタイプ実装) + 技術選定を行い、「ほぼ実現できる」と確信できるレベルまで仕様を詰めて仕様書 (spec.md) を作成するスキル。spec 段階で実現可能性をしっかり検証することで /shinaps:dev での差し戻しをほぼゼロにする。shinaps-spec-writer で構造化し、そのまま /shinaps:dev へ橋渡しできる
+argument-hint: <ざっくりした要望（省略可）>
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+
+## 実行環境とプロジェクト条件
+
+この節は以下の工程全体に適用する。適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから今回の条件を読み、明示された依頼・許可を引き継ぐ。仕様に影響する不足だけ一問ずつ確認する。新しい恒久方針の保存はユーザーの了承を得てプロジェクト側へ行う。
+
+Claude Codeの `Skill`・`Agent`・`AskUserQuestion`・`TaskCreate` を利用できる場合は対応するツールを使う。現在のセッションで提供されていないツールは仮定しない。質問は一問ずつ確認して回答を待つ。
+
+別セッションへの委託・新しいworktreeは明示された許可がある場合だけ行う。委託不可なら現在のセッションで調査・計画・レビューの観点を順に確認し、独立レビューとは報告しない。独立レビューがプロジェクトの必須条件なら未完了として扱う。Shinapsのエージェント名はClaudeのpluginで公開された名前を使う。サービスのrule照合が必要な工程でMCPを利用できなければ、その工程を未確認として報告し、照合済みとしない。
+
+## 引数仕様
+
+| 呼び出し | 動作 |
+|---|---|
+| `/shinaps:spec <要望>` | 引数を初期要望として受領、ヒアリング開始 |
+| `/shinaps:spec` | 引数なしの場合は `AskUserQuestion` でまず「何がしたいか」を聞く |
+
+## 使用エージェント
+
+| エージェント | subagent_type | 役割 |
+|---|---|---|
+| Shinaps Explorer | `shinaps-explorer` | 既存コードベース調査 |
+| Shinaps Tech Surveyor | `shinaps-tech-surveyor` | フィジビリティ調査 (外部情報 + 候補比較) |
+| Shinaps Survey Validator | `shinaps-survey-validator` | tech-surveyor の主張を出典 URL で検証 |
+| Shinaps Spec Writer | `shinaps-spec-writer` | ヒアリング + 調査結果を構造化 spec.md に整理 |
+
+ヒアリング自体はメインエージェントが `AskUserQuestion` を使って進める。
+
+## ディレクトリ規約
+
+```
+.shinaps/work/specs/{YYYYMMDD-HHMMSS}-{slug}/
+├── spec.md                ← shinaps-spec-writer が作成 (dev には spec.md パスを直接渡す)
+├── interview-log.md       ← ヒアリングのやりとり記録
+├── raw/                   ← 調査エージェントの生レポート (dev が再利用)
+│   ├── explorer.md        ← 既存実装調査 (実施時のみ、dev が再利用)
+│   ├── survey.md          ← フィジビリティ調査一次レポート (実施時のみ)
+│   └── survey-validated.md ← 検証済み調査 (実施時のみ)
+└── prototype/             ← プロトタイプ実装 (実施時のみ、隔離スペース)
+    ├── {試したコード一式}
+    └── prototype-report.md ← 実験結果サマリ
+```
+
+`{slug}` は要望の短い英語スラッグ (kebab-case, 30 文字以内)。
+
+## 実行フロー
+
+### Phase 1: 初期要望の受領
+
+1. 引数があればそのまま初期要望として受領
+2. 引数がなければ `AskUserQuestion` で「どんなことを実現したいか」を聞く
+3. 今回の依頼に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。既存成果物がなければ追加取得は不要。
+4. 受領した要望を `interview-log.md` の冒頭に Write
+
+### Phase 2: 段階的ヒアリング
+
+**ヒアリング前の準備**: `list_search_facets()` + 予備 `search_rules({ repoOwner, repoName, ...推定 facet })` を呼び、rule カタログを頭に入れる (制約セクションを rule 起点で組み立てるため)。
+
+メインエージェントがインタビュアーとして、以下の観点を順次 `AskUserQuestion` で確認する。**1 観点ずつ**、回答を踏まえて次の質問を決める。回数に制限なし、不明な点は必ず聞く。
+
+#### ヒアリング観点 (順序)
+
+1. **機能要件の核**: 「具体的にどういう操作・機能が必要か」
+2. **想定ユーザー**: 「誰が使うのか (役割・知識レベル)」
+3. **スコープの境界**: 「どこまでをやり、どこからはやらないか」
+4. **優先度**: 「必須 / 重要 / あると良い をどう分けるか」
+5. **制約**: 「技術スタック / 期限 / 既存システムとの関係 など」
+6. **非機能要件**: 「パフォーマンス・セキュリティ・可用性で気にする点はあるか」 (該当時のみ)
+7. **受け入れ条件**: 「どうなったら完成と言えるか」。場合の列挙（A を扱う・B を扱う…）ではなく、「〜のとき〜である」という性質（不変条件）に言い換えて確認する
+
+#### ヒアリングの進め方
+
+- 各回答を `interview-log.md` に追記する
+- 既に明確な観点はスキップ
+- 回答が曖昧 / 追加情報が必要な場合は深掘り質問を遠慮なく重ねる
+- ユーザーが「お任せ」を選んだ項目は仕様書で `[未解決]` マークを付ける
+- ユーザーから「もう十分」と意思表示があれば Phase 3 へ
+- 観点 1〜7 を一通り終えたら自動的に Phase 3 へ
+
+### Phase 3: 既存実装調査 (フィジビリ調査)
+
+`AskUserQuestion` で「既存コードベースを調査するか」を確認 (Recommended: Yes)。
+スキップする選択肢: 「新規プロジェクト / 既存に関連実装が無いことが明白」な場合。
+
+実施する場合:
+
+1. `shinaps-explorer` を起動 (必要なら領域を分けて複数並列)
+2. **プロンプトに含める情報**:
+   - Phase 1-2 で確定した要望と機能要件
+   - **Phase 1 で作成した既存成果物の要約**
+   - 「実装したい機能に関連する既存コード・抽象化レイヤー・規約を調査せよ。**仕様策定の参考になる範囲で深さ重視**」
+3. 生レポートをメインが Write で `raw/explorer.md` (並列時は `raw/explorer-{n}.md`) に全文保存
+4. 結果を踏まえて Phase 2 に戻って追加ヒアリングが必要か判断
+   - 既存パターンと食い違う要望があれば `AskUserQuestion` で「合わせる / 上書きする」を確認
+
+### Phase 4: フィジビリティ調査 (外部情報 + 必要ならプロトタイプ)
+
+「実現できそうか」「どんなアプローチがあるか」「ハマりどころは何か」を確認するフェーズ。2 段階に分かれる。
+
+#### 4-A: 外部情報調査 + 技術選定
+
+`AskUserQuestion` で「外部情報を調査するか」を確認 (Recommended: Yes)。スキップする選択肢: 「既存スタック内で完結 / 自明な実装」な場合。
+
+このフェーズはフィジビリティ調査と技術選定の両方を担う。
+
+実施する場合:
+
+1. `shinaps-tech-surveyor` を起動
+2. **プロンプトに含める情報**:
+   - Phase 1-2 の要望と機能要件
+   - Phase 3 の explorer 結果 (実施した場合)
+   - プロジェクト `CLAUDE.md` の関連抜粋 (既存スタック制約があれば)
+   - **Phase 2 前準備で取得した `search_rules` 結果 (userRules + officialRules 全文)**
+   - 「この機能を実装する際の関連ライブラリ / 公式推奨パターン / 知られた落とし穴 / 似たユースケースの実装例を WebSearch / WebFetch で調査せよ。**実現可能性を判断する材料を集めると同時に、複数候補がある場合は観点別に比較すること**。既存スタック + rule カタログ整合性を最初の予選条件に」
+3. 生レポートをメインが Write で `raw/survey.md` に全文保存
+4. `shinaps-survey-validator` を起動 (プロンプトに search_rules 結果も渡す)、メインが Write で `raw/survey-validated.md` に全文保存
+5. **採用候補の決定**:
+   - 候補が 1 つしかない / 推奨が明確 → そのまま採用としてメインが採用理由・注意点を整理
+   - 候補が複数で判断が割れる → `AskUserQuestion` で「どの候補を採用するか」を選ばせる
+6. 採用が決まったら、Phase 6 で spec.md に反映するための情報をメモしておく:
+   - 採用候補名 + バージョン
+   - 選定理由 (要件・制約に照らした 1〜2 文)
+   - 採用時の注意点 (バージョン互換性、依存、ライセンス、運用上の注意など)
+
+#### 4-B: プロトタイプ実装 (任意)
+
+`AskUserQuestion` で「実現可能性を確かめるプロトタイプを試すか」を確認 (Recommended: No、ただし以下に該当するなら Yes 推奨):
+- 不確定な技術要素がある (新規ライブラリ / 試したことのない API / パフォーマンス懸念)
+- 4-A で「実装パターンが複数提示されたがどれが筋か不明」
+- 「動かしてみないと分からない」と感じる論点がある
+
+実施する場合:
+
+1. **隔離スペース** `.shinaps/work/specs/{ts}-{slug}/prototype/` を作成 (既存コードベースを汚さない)
+2. 必要最小限のコードを書いて動かす:
+   - 既存コードベースに統合する必要があれば最小の touch のみ
+   - 主目的は「動くか / 期待した振る舞いか / どこで詰まるか」を確認すること
+3. 結果を `prototype/prototype-report.md` に記録
+
+4-A / 4-B どちらかでも実施した場合、結果を踏まえて Phase 2 に戻って追加ヒアリングが必要か判断:
+- フィジビリ調査で「ユーザー要望が実現困難 / 想定より大規模」と分かれば `AskUserQuestion` で「スコープ縮小 / 別アプローチ / そのまま進める」を確認
+
+### Phase 5: ヒアリングログ整理
+
+`interview-log.md` を最終形式に整える (Q&A 形式で、元の要望 / 質問 / 回答 / 調査結果パスを含む)。
+
+### Phase 6: shinaps-spec-writer 起動
+
+`shinaps-spec-writer` を 1 体起動。
+
+**プロンプトに含める情報**:
+- 元の要望
+- `interview-log.md` 全文
+- `raw/explorer.md` 全文 (実施時のみ)
+- `raw/survey-validated.md` 全文 (実施時のみ)
+- Phase 4-A で決定した採用候補・選定理由・注意点 (実施時のみ)
+- プロジェクトコンテキスト (CLAUDE.md の関連部分)
+- **Phase 2 前準備で取得した `search_rules` 結果 (userRules + officialRules 全文)**
+- 「ヒアリングと調査結果を統合した構造化された仕様書を作成せよ。既存実装の状況・技術的方向性・採用技術 (あれば) も spec.md に反映すること。CLAUDE.md + rule カタログを制約セクションに集約すること」
+
+**記録先**: メインが Write で `.shinaps/work/specs/{ts}-{slug}/spec.md`
+
+### Phase 7: 仕様書サマリ提示
+
+`spec.md` の主要セクション (要望の本質 / 機能要件 / スコープ / 制約 / 受け入れ条件 / 未解決の論点) を要約してテキスト出力する。
+
+ユーザーから修正要望があれば Phase 2 または Phase 3 / 4 に戻る。
+修正要望が無ければ Phase 8 へ。
+
+### Phase 8: 次アクション選択
+
+`AskUserQuestion` で次のアクションを確認:
+
+- **`/shinaps:dev` に進む (橋渡し)**: 仕様書を入力に「計画策定 → 実装 → セルフレビュー」を一気通貫実行
+- **ローカル保存のみで終了**
+
+### Phase 9: /shinaps:dev への橋渡し (選択時)
+
+中間ファイル (旧 `plan-handoff.md`) は生成しない。`Skill` ツールで `shinaps:dev` を起動し、引数に **`spec.md` のパスを直接渡す**。
+
+dev 側の Phase 1 で spec.md を Read してタスク詳細・採用技術・既存実装との関係を取り込み、Phase 2 で同ディレクトリ配下の `raw/explorer.md` をそのまま再利用する (= dev は explorer を改めて起動しない)。これにより spec ↔ dev の二重 explorer を削減する。
+
+引数例:
+
+```
+Skill(skill="shinaps:dev", args="以下の仕様書を実装する。詳細は .shinaps/work/specs/{ts}-{slug}/spec.md を参照: {1 行サマリ}")
+```
+
+## 動作原則
+
+- **EnterPlanMode は使わない**: bypassPermissions モードと両立させるため
+- **不明な論点は必ず AskUserQuestion で確認**: 回数に制限なし
+- **未解決は隠さない**: 答えが出なかった項目は仕様書で `[未解決]` 明示
+- **生レポート保存厳守**: ヒアリングログ・仕様書・調査結果は全文保存 (メインが Write)
+- **subagent は文字列応答のみ**: ファイル書き込みは必ずメインが担当
+- **フィジビリ調査は spec で済ませる**: dev での差し戻しを減らすため、Phase 3/4 の調査を惜しまない
+- **rule カタログを制約に反映**: `search_rules` 結果を spec.md の制約セクションに集約

package/plugins/shinaps/skills/verify-ui/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: verify-ui
+description: UI変更を対象プロジェクトの対応環境で実際に操作し、見た目と挙動を検証する。UI実装後や画面の動作確認を求められたときに使う。
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+
+# UIを使って検証する
+
+## プロジェクトの条件を読む
+
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
+
+既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+
+## 検証範囲を決める
+
+対応ブラウザ・端末、変更する操作、期待する性質、必須の証拠を既存仕様から決める。受入条件はケースの列挙ではなく「再表示しても保存した選択を保つ」のような性質で書き、代表的な操作で確かめる。
+
+特定ブラウザ、実機、Simulator、複数OSバージョンを一律に必須にしない。プロジェクトがPCブラウザのみを対象にするならその範囲で検証する。エンジン差・ハードウェア・入力方式が結果を左右する変更なら、その差を確認できる環境を選ぶ。必要な環境が使えない場合、別環境で通ったことを代替証拠にせず未確認として残す。対応範囲自体が不明で結論を左右する場合だけ確認する。
+
+## 実行と証拠
+
+1. 現在の画面と実装を確認する。余白や入力の問題がアプリ・ブラウザ・端末のどこに属するか切り分ける。
+2. プロジェクトが必要とする自動検証を実行し、対象の実画面で主要操作と関連する状態遷移を確かめる。DOMや内部状態の注入を操作成功の証拠にしない。
+3. レイアウトの欠け、重なり、フォーカス、再操作、保存・再表示など変更の影響する性質を確認する。動画や計測を必要とする動き・性能は静止画だけで合格にしない。
+4. 視覚的な判定にはスクリーンショットを残し、環境・操作・期待・観測結果を対応づける。明示された証拠の納品先がなければ `.shinaps/work/` 以下の今回の作業ディレクトリを使う。
+5. 発見した問題を直した場合は影響部分を再確認する。独立レビューは利用可能で許可され、効果がある場合に限る。
+
+## 完了
+
+定めた範囲で期待する性質を実画面から確認できたことを報告する。自動テストのみ・画面を開いただけ・スクリーンショットのみで操作を確認済みにしない。未確認事項と理由は完了範囲から区別する。実装・修正が依頼されていなければ、検証の依頼から変更許可を推測しない。

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

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

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

@@ -0,0 +1,47 @@
+---
+name: commit
+description: 許可された差分を依存順の小さなローカルコミットへ分割し、各単位を検証・レビューする。通常は単位ごとに確認し、自律コミットを明示された場合はその許可範囲で続行する。
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+
+# 検証できる単位でコミットする
+
+## プロジェクトの条件を読む
+
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
+
+既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+
+## 範囲と進め方
+
+コミットはユーザーが明示した場合だけ行う。通常は単位の差分・理由・検証結果・メッセージを提示して可否を確認する。「自律的にレビューしてコミットまで」の明示依頼がある場合は、同じ対象について単位ごとの再確認を省略する。どちらも対象外変更、push、PR、公開、既存履歴の書き換えは含まない。
+
+Git操作と修正は現在のセッションが行う。独立レビューは利用可能かつ許可された場合に使う。指定のエージェントがなければ、その役割の観点でレビューする。独立レビューがプロジェクトの必須条件なのに実行できなければ、セルフレビューを同等と称さず止める。別worktreeの作成や別セッションへの委託を、このスキルから許可しない。
+
+## 回復できる状態を作る
+
+- `git status`、staged・unstaged差分、untracked、HEAD、branch、stash一覧とSHAを確認する。進行中のmerge等があれば混ぜない。
+- 対象範囲を確定し、無関係な変更や秘密情報を除く。既存indexと作業ファイルが違う場合、ステージ境界を無断で捨てない。
+- 検証コマンドはCI・スクリプト・規約から特定する。変更前からの失敗を今回の成功に混ぜない。
+- 退避が必要なら復元可能な差分・untrackedの控えをリポジトリ外の作業領域へ保存する。控えは復元が確認できるまで残す。
+
+## 分割・検証・レビュー
+
+1. 一つの意図を説明でき、適用済みの前の単位と既存コードだけで成立するよう依存順に分ける。実装と必要なテスト・生成物を切り離さない。行数やファイル階層だけで分割しない。
+2. 分割案を短く示す。許可された独立レビュアーがいれば差分自体から妥当性を確認させる。結論はメインが検証する。
+3. 現在のcheckoutで対象単位を隔離する。対象外を一意な名前のstashへ退避し、新しく作成された場合だけそのSHAを記録する。既存stashの先頭を自分のものと決めつけない。共有ファイルのhunk分割は保存したパッチから行い、検証対象とindexの内容を一致させる。
+4. 後続の未コミット変更なしで、その単位に必要な検証を行う。後続への依存で失敗するなら退避分を戻して分割を見直す。全差分がある状態で通ったテストを単位の検証としない。
+5. 対象だけをステージし、完全なcached diffと影響するファイルをレビューする。指摘は実物で確認し、依頼範囲の修正後は再ステージ・再検証する。外部仕様の調査は変更がそこに依存するときに行う。
+6. 必須検証が通り、確定した阻害指摘がなく、通常モードなら単位の承認を得てから `git commit` を単独で実行する。メッセージはリポジトリ規約に従う。`git add` と連結しない。
+7. 記録したSHAのstashをapplyし、退避パッチも復元する。復元を確認してから該当stashをdropする。曖昧な競合は推測で捨てず、回復資料を残して確認する。残差分とHEADを確認して次へ進む。
+
+## 終了・中断
+
+branch・HEAD・対象外ファイルの予期しない変更、復元の曖昧さ、仕様判断が必要な指摘では安全な状態を保って止める。検証の失敗を省略で解決しない。修正で過去のコミットを変えず、後続単位にする。
+
+コミット一覧、検証・レビューの範囲、残差分、復元状態を報告する。元からあったstashを保持し、今回のstashに残りがあれば回復方法を示す。未確認の独立性や検証を成功と報告しない。

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

@@ -0,0 +1,36 @@
+---
+name: create-pr
+description: ブランチの変更意図と検証結果を整理し、リポジトリの規約に合ったGitHub PRを作成する。PR作成・公開を依頼されたときに使う。
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.shinaps/work/` 以下へ保存する。最初に記録を作るとき、`.shinaps/` を作成し、`.shinaps/.gitignore` がなければ内容 `*` と改行で作成する。既存ファイルは上書きせず、除外が不足する場合だけ `*` を追記する。ユーザーのグローバルignoreやルートの `.gitignore` の編集は不要。Git管理下では `git check-ignore` と `git status --short --untracked-files=all` で記録が未追跡変更に出ないことを確認する。既存の追跡済みファイルは自動で追跡解除しない。
+
+既存の `.claude/shinaps/` 等の記録は渡されたパスから読み、無断で移動・削除しない。新規記録は新しい保存先を使う。共有する仕様書などを `docs/` 等へ出す場合は、明示された成果物の保存先に従う。秘密情報は記録しない。
+
+# 変更をレビューできるPRにする
+
+## プロジェクトの条件を読む
+
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、README、CI、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
+
+既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+
+## 差分と宛先
+
+プロジェクトルート、Git状態、remote、対象アカウント、base・headを確認する。ユーザーの指定を優先し、base未指定ならGitHubのdefault branchを取得する。比較には取得したリモートのbase refを使い、古いローカルブランチだけで判断しない。
+
+対象ブランチの全コミット・baseとの全差分・未コミット差分を区別して読む。未コミット変更は自動でコミットせず、既存のコミット指示に従う。PR対象が不明な場合だけ一問確認する。既存PRがあれば重複作成せず、その状態を示す。更新を依頼されている場合は同じPRを更新する。
+
+## タイトルと本文
+
+リポジトリのテンプレート・言語・レビュー規約に従う。指定がなければ会話の言語で、具体的な問題と変更後の挙動を先に述べる。必要な設計判断、検証した内容と限界を添える。ファイル一覧の言い換え、作業日記、今回扱っていない別の論点を増やさない。見出しや敬体、日本語、文字数を全プロジェクトに強制しない。
+
+## 作成と確認
+
+- 完成したタイトルと本文を提示し、すでに許可された公開を進める。ドラフトの指定と対象ブランチを守る。
+- 必要なpushは通常のpushを単独コマンドで行う。force-pushや履歴書き換えに広げない。
+- 本文は一時ファイルに保存し、`gh pr create --base <base> --head <head> --title <title> --body-file <file>` で渡す。本文をシェルのコマンド置換に埋め込まない。
+- 作成結果が不明な失敗は、再作成の前に同じheadのPRを読み戻す。URL、タイトル、base・head、draft状態を確認する。
+- タスクへのPR添付ツールがある環境では作成したPRを添付し、URLを報告する。作成をマージ・デプロイまで拡大しない。

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

@@ -0,0 +1,16 @@
+---
+name: debug
+description: 再現手順、コード、ログと必要な外部情報から不具合の根本原因を調べ、仮説を実際の証拠で検証する。
+---
+
+# 原因調査
+
+症状・期待する挙動・発生条件を依頼と既存情報から確定する。不足は一問ずつ確認する。プロジェクトの指示と過去の調査を読み、関係するコードとログを追う。再現が必要なら許可された環境を使い、本番データを変更しない。
+
+仮説ごとに支持する証拠と反証を調べ、根本原因・寄与要因・否定済み・再現待ちを区別する。外部ライブラリが関係する場合だけ公式資料や既知のIssueを確認する。対症療法だけで根本原因が確定したと報告しない。
+
+委託が許可され登録されている場合はshinaps-debuggerで仮説を立て、shinaps-debug-validatorで実コードを検証する。外部調査にはshinaps-tech-surveyorとshinaps-survey-validatorを必要に応じて使う。取得済みのShinapsルールは親が担当へ渡す。MCP不可ならルール照合未確認とする。
+
+結論、証拠、再現状況、最小の修正方針と未確認を報告する。修正まで依頼されている場合は$shinaps:devへ引き継ぐ。調査だけなら変更しない。
+
+必要な記録は.shinaps/work/debug/へ保存し、.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定する。秘密情報・既存記録の削除・外部投稿は含めない。

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

@@ -0,0 +1,18 @@
+---
+name: dev
+description: プロジェクトの既存設計と条件を確認し、計画・実装・簡素化・検証・レビューまで進める。機能追加や修正の実装依頼に使う。
+---
+
+# 開発
+
+1. 対象のAGENTS.md、既存構造、CIと関連する仕様・調査記録を読む。追加より設計変更が適切でないか検討し、受入条件を性質としてまとめる。仕様を変える判断だけ確認する。
+2. Shinaps AIのルール検索が利用できれば、リポジトリと変更領域に関係するルールを取得する。使えない場合はルール照合未確認として明記し、可能な実装を進める。
+3. 複雑な調査・設計では、委託を許可されている場合に登録済みのshinaps-explorer、shinaps-architect、shinaps-plan-reviewerへ対象と期待する結果を渡す。担当の結論を自分で検証する。委託不可なら同じ観点を現在のセッションで確認する。worktree作成は別途許可が必要。
+4. 計画を必要な単位に分けて実装する。利用できる計画ツールで進捗を管理する。既存の無関係な変更を保ち、公開契約を変える必要が出たら理由と案を確認する。
+5. $shinaps:simplifyを読み、仕様を保つ削除・統合を行う。CIや既存スクリプトから変更に必要な検証を実行する。UIが関係する場合は$shinaps:verify-uiを使い、対象プロジェクトで必要な実画面を確認する。
+6. $shinaps:refineによるルール照合が可能なら行い、$shinaps:reviewで最終差分をレビューする。確定した今回の不具合を修正し、影響範囲を再検証する。依頼外の既存問題は混ぜず報告する。
+7. 変更後の挙動、主要な検証と未確認事項を報告する。コミット・PR・公開は別途依頼された場合だけ進める。
+
+受け取った仕様書や調査記録は、現在の依頼との整合性を確認して引き継ぐ。ツールやスキルが未提供なら存在を仮定せず、その制約を示す。質問には現在利用できる入力ツールを使い、一問ずつ回答を待つ。
+
+記録は必要な場合に.shinaps/work/へ保存する。.shinaps/.gitignoreは未作成なら`*`と改行で作成し、既存の場合は内容を保持して必要な除外だけ追加する。追跡済みファイルや既存記録は削除しない。

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

@@ -0,0 +1,14 @@
+---
+name: explore
+description: 既存挙動の理由、実装方針、変更の影響を対話しながら読み取り専用で調べる。ユーザーが理解してから実装を決めたい場合に使う。
+---
+
+# 対話的な調査
+
+現在の質問を一つに絞り、プロジェクトの指示と関連コード・テスト・設定・履歴を読む。既存の調査記録と利用可能なShinapsルールを使い、確認済みの事実・推測・未確認を分けて説明する。ファイルと行、再現結果、必要な公式資料を根拠にする。
+
+委託を許可されている場合は登録済みのshinaps-investigatorに現在の質問と対象範囲を渡せる。許可がなければ現在のセッションで調べる。調査依頼を実装・設定変更・外部投稿の許可として扱わない。
+
+質問が曖昧なら結果を左右する点だけ一問確認する。回答後に新たな質問が来たら続け、仕様策定や修正へ自動で進まない。理解が揃い実装を依頼されたら、目的・合意事項・未確認事項・関連ファイルを引き継ぎ、$shinaps:devを読む。
+
+継続用の記録が必要なら.shinaps/work/explorations/へ保存する。.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定し、秘密情報や無関係な記録を持ち込まない。MCPが使えないときはルール照合未確認と明記する。

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

@@ -0,0 +1,16 @@
+---
+name: extract-rules
+description: GitHubの過去PRレビューから繰り返し適用できる規約を抽出し、Shinaps AIへ登録する。ルール抽出・登録を依頼された場合に使う。
+---
+
+# PRレビューからルールを抽出する
+
+対象リポジトリと期間、Shinaps AIへの登録範囲を依頼・Git設定から確定する。不足は一問ずつ確認する。新しいリポジトリだからという理由だけで登録を開始しない。MCP接続と認証が必要であり、使えない場合はアカウント作成・認証を案内し、保存したと報告しない。
+
+1. `gh`で期間内のマージ済みPRを取得する。ページングし、並び順と日付フィルターの関係を守る。更新日時順の一覧で古いマージ日時を一件見つけても、それ以降の取得を打ち切らない。
+2. PRのreview本文・inline comment・conversation commentを取得する。PR descriptionはレビュー指摘として扱わない。APIのBot種別は除外し、判断が必要な投稿者は確認する。認証情報やリポジトリ全体をサービスへ送信しない。
+3. 利用可能なShinaps MCPのルール検索で既存ルールを取得する。複数のレビューで繰り返され、適用条件とWHYが説明できる規約を候補にする。根拠のない例・URLを作らず、レビューコメントの出典を付ける。
+4. 新規候補だけを対象repoのスコープへ、実際のMCPツールのスキーマに従って登録する。全プロジェクト共通へ広げる場合は利用者の判断を確認する。既存ルールの変更は差分を提示して許可を得る。
+5. 大量処理は100 PR程度のまとまりで結果を報告し、継続範囲を確認する。結果が不明な保存失敗では再投入の前に読み戻し、重複を避ける。
+
+終了時は処理したPR・コメント数、新規登録・更新・除外・未処理の件数と根拠を示す。取得・保存が部分的ならその範囲を明記する。記録する場合は.shinaps/work/を使い、.shinaps/.gitignoreに`*`の除外を既存内容を保持して設定する。

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

@@ -0,0 +1,14 @@
+---
+name: refine
+description: 対象ファイルとShinaps AIのルールを照合し、違反・改善・判断が必要な点を整理する。実装後のルール照合に使う。
+---
+
+# ルール照合
+
+指定されたパス・PR・コミット範囲から対象を決める。作業中の変更ならstaged、unstaged、関連するuntrackedを含める。適用されるプロジェクトの指示を読み、利用可能なShinaps MCPのルール検索で対象に合うルールを取得する。MCPが使えない場合は照合を実施できないと報告し、推測でルールを作らない。アカウント作成・接続は利用者の標準認証フローを案内する。
+
+対象ファイルの現状全文を読み、ルールごとに適用条件と実際のコードを比較する。指摘には根拠となるルール、該当箇所、影響と修正案を付ける。違反・改善・仕様判断を区別し、今回の変更と元からある問題を分ける。
+
+委託を許可されている場合は登録済みのshinaps-refine-agentへ重ならない範囲とルール全文を渡せる。結果は現在のコードで検証し重複をまとめる。独立検証をしなければそのように報告する。
+
+修正が依頼範囲に含まれる場合、今回の変更の自明な修正を適用し、必要な検証を行う。既存箇所や仕様に関係する判断は一問ずつ確認する。ルール自体の書き換え・外部Issueの作成を無断で行わない。未処理事項を残し、照合結果と未確認を報告する。