@shinaps/skills 0.11.0

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

@@ -0,0 +1,217 @@
+---
+name: explore
+description: バグか確定していない違和感、既存挙動の「なぜ」、実装方針や変更影響について、人間が理解・納得できるまで質問を重ねる対話型 read-only 調査スキル。質問ごとにコード、テスト、設定、git history、必要な公式情報を調べ、confirmed / inference / unknown を分けて根拠付きで回答する。debug のように根本原因確定を急がず、spec のように仕様策定を目的にせず、実装は行わない。理解が揃い実装内容に合意したら exploration.md を /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を利用できなければ、その工程を未確認として報告し、照合済みとしない。
+
+## このスキルの責務
+
+人間を質問の主体にして、1 つの疑問を調査して答えるサイクルを、本人が理解できたと明示するまで繰り返す。
+
+| スキル | 主目的 | 終了成果物 |
+|---|---|---|
+| `shinaps:explore` | 現状・因果・選択肢を対話で理解する | `exploration.md` |
+| `shinaps:debug` | 具体的な不具合の根本原因を仮説検証で確定する | `debug-validated.md` |
+| `shinaps:spec` | 要望と受け入れ条件を確定する | `spec.md` |
+| `shinaps:dev` | 計画し、実装・検証・セルフレビューする | コード + `implementation.md` |
+
+`explore` では最初から「バグ」「採用案」「修正対象」を決めつけない。調査中に不具合らしさが高まっても、自動で `debug` や `dev` へ移らず、人間の質問に答え続ける。
+
+## 引数仕様
+
+| 呼び出し | 動作 |
+|---|---|
+| `/shinaps:explore <疑問・違和感・調べたい実装>` | 記述を最初の質問として調査を開始する |
+| `/shinaps:explore <ファイルパス>` | 指定ファイルを起点に「何を理解したいか」を 1 問だけ確認して開始する |
+| `/shinaps:explore` | `AskUserQuestion` で最初に理解したいことを確認する |
+
+引数は完成したバグ報告や要件でなくてよい。「この辺がよく分からない」「本当にこの設計でよい？」のような未整理の疑問を受け付ける。
+
+引数なしでは「現在の挙動・バグの可能性 / 実装構造・データフロー / 変更案・影響範囲」の 3 択を、ファイルパスだけなら「責務と呼び出し元 / 特定挙動との関係 / 変更時の影響」の 3 択を提示する。`Other` の自由記述を、人間自身の最初の質問として扱う。
+
+## 使用エージェント
+
+| エージェント | subagent_type | 役割 |
+|---|---|---|
+| Shinaps Investigator | `shinaps-investigator` | そのラウンドの質問だけを、コード・テスト・設定・履歴から read-only で調べて回答する |
+| Shinaps Tech Surveyor | `shinaps-tech-surveyor` | 外部仕様やライブラリ挙動が結論を左右するときだけ調査する |
+| Shinaps Survey Validator | `shinaps-survey-validator` | 外部情報に依存する重要な主張を出典で再確認する |
+
+対話、主要根拠の再確認、成果物の更新、次アクションの判断はメインスレッドが担当する。subagent は文字列応答のみ返し、ファイルを書かない。
+
+## ディレクトリ規約
+
+```
+.shinaps/work/explorations/{YYYYMMDD-HHMMSS}-{slug}/
+├── exploration.md                 ← 現在の理解と dev handoff 契約を保つ living document
+├── question-log.md                ← 質問と回答の要約。会話の逐語録にはしない
+└── raw/
+    ├── investigation-001.md       ← 各ラウンドの investigator 生レポート
+    ├── investigation-002.md
+    ├── survey-002.md              ← 外部調査を行ったラウンドのみ
+    └── survey-validated-002.md
+```
+
+`{slug}` は最初の論点を表す短い英語スラッグ (kebab-case、30 文字以内)。途中で論点が深まっても同じディレクトリを使う。別機能へ完全に移った場合だけ、新しい explore を開始するかを確認する。
+
+## 実行フロー
+
+### Phase 1: セッション初期化
+
+1. 最初の質問を受領する。引数が空、またはファイルパスだけなら、理解したいことを `AskUserQuestion` で 1 問だけ確認する
+2. git remoteから `repoOwner` / `repoName` を解決する。今回の依頼に関連する既存の spec・調査レポート・Git の変更履歴を確認し、引き継ぐ決定と根拠を要約する。既存成果物がなければ追加取得は不要。
+3. `list_search_facets()` と、最初の質問に対応する `search_rules({ repoOwner, repoName, ...推定 facet })` を呼ぶ。論点が別領域へ移ったら、その時点で facet を取り直す
+4. リポジトリの `CLAUDE.md` / `AGENTS.md` / その他の指示ファイルを読む
+5. `git status --short --branch` と HEAD を記録する。調査対象の revision は未コミット変更を含む現在の worktree をデフォルトにし、production / PR / commit が明示された場合は対象 revision を特定して別に記録する。reset / stash / checkout / clean は行わない
+6. 作業ディレクトリを作り、最初の質問と調査基準を `exploration.md` / `question-log.md` に要約して保存する
+
+`explore` が変更してよいのは、この作業ディレクトリ内の調査成果物だけ。プロダクトコード、テスト、設定、依存関係、生成物、git index は変更しない。
+
+### Phase 2: 質問ラウンド
+
+1 ラウンドでは、相互に関係する 1 つの疑問を扱う。人間が複数の独立した質問を一度に出した場合は、質問ごとに investigator を分け、独立なら並列起動する。
+
+#### ラウンド開始時
+
+1. 質問をそのまま `question-log.md` に要約して追記する
+2. `git status --short --branch` を再確認し、confirmed findings の根拠ファイルは保存済み content hash と現在値を比較する。前ラウンドから変わっていれば、古い根拠を流用せず読み直す
+3. 現在の `exploration.md` を読み、既に確認済みの事実と今回の未解決点を分ける
+
+#### `shinaps-investigator` に渡す情報
+
+- 今回の質問。言い換えで論点を狭めすぎず、ユーザーの表現も残す
+- `exploration.md` 全文と、必要な過去ラウンドの要点
+- target revision / environment と、現在の branch / HEAD / worktree 状態
+- 関連する既存成果物の要約
+- `search_rules` の userRules + officialRules 全文
+- 関連するプロジェクト指示
+- 「今回の質問へ直接答え、confirmed / inference / unknown を混ぜない。一般的な設計案や修正案へ先回りしない」
+
+応答全文を `raw/investigation-{NNN}.md` に保存する。
+
+#### 外部情報が必要な場合
+
+ライブラリの現行仕様、既知バグ、OS / runtime 差、公式推奨が答えを左右する場合だけ、`shinaps-tech-surveyor` → `shinaps-survey-validator` を追加で起動する。外部情報は公式 docs、一次資料、upstream issue を優先し、重要な結論は validator を通す。生レポートを同じラウンド番号で保存し、検証済み内容だけを回答へ採用する。
+
+### Phase 3: メインスレッドによる根拠確認
+
+investigator の回答をそのまま転送しない。結論を支える主要な file:line、テスト、設定、git history をメインスレッドでも直接確認する。
+
+- 実行経路の主張は entry point から結果まで因果がつながるか読む
+- HEAD と未コミット差分を混同しない
+- 既存テストや安全なローカル再現で不確実性を大きく減らせるなら、tracked file を変更しないと確認できるコマンドだけ実行し、実行後に worktree 状態を再確認する
+- production deploy、外部データ変更、依存追加など調査を越える操作は行わない
+- 確認できない主張は `inference` または `unknown` に下げ、解消に必要な証拠を示す
+
+### Phase 4: 回答と living document 更新
+
+各ラウンドの回答は次の順で短く提示する。
+
+1. **直接の答え**
+2. **確認できたこと (`confirmed`)** — file:line / test / docs URL を添える
+3. **推測 (`inference`)** — 推測である理由と確信度を添える
+4. **まだ分からないこと (`unknown`)** — 何を見れば確定できるかを添える
+5. **次に掘る価値が高い論点** — 最大 3 件
+
+回答後、`question-log.md` には質問と回答の要約だけを追記し、`exploration.md` を現在の理解へ更新する。confirmed finding を支えるローカルファイルは、現在内容の hash (`git hash-object` など、object を書き込まない read-only 計算) を関連リソースへ記録する。過去の誤った仮説を残す必要がある場合は「却下済み」と明記し、現在の結論と混ぜない。
+
+`exploration.md` は最低限、次を保つ。
+
+- 調査対象と人間が理解したいこと
+- 現在のメンタルモデル / 実行フロー
+- confirmed findings と根拠
+- inference / unknown
+- 意思決定済みの事項と理由
+- 実装する場合の目的・制約・非目標
+- 関連ファイルと raw report の索引
+
+初期化時は次の構造で作り、明示的な実装合意までは `status: not-ready` を維持する。
+
+```markdown
+# Exploration: {topic}
+
+## セッション基準
+- repository / branch / HEAD
+- targetRevision / targetEnvironment
+- initialWorktreeStatus
+- lastVerifiedAt
+- evidenceSnapshot:
+  - `{confirmed 根拠の path}`: `{contentHash}`
+  - `{外部資料 URL}`: `checkedAt={timestamp}`
+
+## 調査対象
+## 現在のメンタルモデル
+## Confirmed findings
+## Inference
+## Unknown
+## 意思決定
+## 関連リソース
+
+## 実装 handoff
+- status: not-ready
+- objective:
+- expectedBehavior:
+- constraints:
+- nonGoals:
+- unresolvedRisks:
+```
+
+### Phase 5: 理解チェックポイント
+
+1 回答しただけで自動終了・自動実装しない。人間が次の質問を直接入力した場合は、そのまま Phase 2 に戻る。次の質問がまだ無い場合は `AskUserQuestion` で、状況に合わせた相互排他的な 3 択を提示する。
+
+- **次の論点を調べる (Recommended)** — Phase 4 で挙げた最重要の未解決点を具体名で示す
+- **実装へ進む** — 実装したい変更が合意済みの場合だけ提示する
+- **保存して終了** — 現在の理解を残して終了する
+
+自由記述の `Other` は、人間自身の次の質問として扱う。ラウンド数に上限を設けず、「十分理解できた」「実装へ進みたい」「終了したい」のいずれかを人間が明示するまで調査を続ける。
+
+実装内容がまだ曖昧な状態で「実装へ進む」が選ばれたら、望む変更を 1 問ずつ確認する。未解決点が残る場合は、残したまま実装するか調査を続けるかを選んでもらう。
+
+### Phase 6: `/shinaps:dev` への橋渡し
+
+実装へ進む前に `exploration.md` の「実装 handoff」セクションを確定する。
+
+- 実装目的と期待する挙動
+- confirmed な現状と問題
+- 合意した変更、制約、非目標
+- 関連 entry point / data flow / tests
+- 未解決点と受容したリスク
+- 再利用すべき `raw/investigation-*.md` の一覧
+
+handoff 直前に confirmed 根拠の content hash を再計算し、`evidenceSnapshot` を最新化する。人間が内容を確認した後にだけ `status: ready` へ更新する。説明を理解して終了するだけのセッションや、望む変更が曖昧なセッションは `not-ready` のまま残す。
+
+安定した設計判断や再利用価値のある発見だけをローカル成果物（implementation.md / 調査・レビューレポート）へ短く記録する。質問ログや長いコード引用は記録しない。
+
+中間 handoff ファイルは作らず、`exploration.md` のパスを直接渡す。
+
+```
+Skill(skill="shinaps:dev", args="以下の対話調査で合意した変更を実装する。詳細は .shinaps/work/explorations/{ts}-{slug}/exploration.md を参照: {実装目的の 1 行サマリ}")
+```
+
+dev は `exploration.md` と同ディレクトリの `raw/investigation-*.md` を既存実装調査として再利用し、情報が不足・陳腐化している場合だけ `shinaps-explorer` で補完する。
+
+## 動作原則
+
+- **人間が質問の主体**: 固定チェックリストを一方的に消化せず、その人が納得するための次の疑問を優先する
+- **実装を急がない**: 明示的な handoff までは read-only 調査に徹する
+- **事実・推測・未知を分離**: もっともらしい説明を confirmed として扱わない
+- **調査対象を固定する**: デフォルトの現在 worktree、HEAD、PR、指定 commit、production のどれを説明しているかを明示し、未コミット変更も無視しない
+- **質問ごとに調査する**: 過去の一般論だけで即答せず、そのラウンドの問いに必要な証拠を取り直す
+- **理解完了を代行しない**: 終了判定は人間が行う。回数制限を設けない
+- **生レポートを保存する**: subagent 応答は全文保存し、会話ログは要約だけ残す
+- **shinaps MCP はメインだけが呼ぶ**: subagent は `search_rules` / `list_search_facets` を直接呼ばない

package/plugins/shinaps/skills/explore/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Shinaps Explore"
+  short_description: "コードと履歴を根拠に、人間が納得するまで対話で深く調査する"
+  default_prompt: "Use $explore to investigate this bug or implementation question interactively until I understand it."

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

@@ -0,0 +1,115 @@
+---
+name: extract-rules
+description: 過去 PR のレビューコメントから shinaps-ai の rules を bulk 生成する skill。新規リポジトリ着手時、または search_rules の userRules が空 / 少ない (5 件未満) ときに提案・起動。owner / repo / since を確認し、bot 除外 + gh api pulls で 100 PR ブロック単位に fetch → LLM で規約抽出 → record_rules で投入 → 続行確認 → 完了 report まで完走。shinaps-ai server 未登録時は search_rules 呼び出しが自動で失敗して abort する。
+argument-hint: (引数なし、対話で owner-repo / since を確認)
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.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:extract-rules — 過去 PR review から rules を bulk 生成
+
+新規リポジトリ着手時、または既存 userRules が薄いときに、過去 PR のレビューコメントから規約を bulk import する skill。shinaps-ai サーバは GitHub API も LLM も呼ばず、すべて Claude Code 側のあなた (= AI) が `gh` / 既存 MCP tools 経由で実行する (token / repo 内容をサーバ境界に置かない)。
+
+## Step 0. 対象 repo を環境から決定する (MUST)
+
+引数は受け取らない。以下の順で対象 `<owner>/<repo>` を解決:
+
+1. `gh repo view --json owner,name` を実行 → `owner.login` と `name` を組み合わせる
+2. 失敗したら `git remote get-url origin` を parse (`github.com/<owner>/<repo>(.git)?` 形式)
+3. それでも決まらないなら **ユーザーにチャットで確認** (「対象は `<owner>/<repo>` でいいですか?」)
+
+解決した `<owner>/<repo>` をユーザーに **必ず提示** し、誤りなら別の repo を入力してもらう。
+
+## Step 1. since (期間) をチャットで確認
+
+デフォルトは **直近 6 ヶ月**。「直近 6 ヶ月の merged PR を対象にしますか? それとも別の期間 (例: 3 ヶ月 / 1 年 / 特定日付以降) を指定しますか?」とユーザーに聞く。回答に応じて以下のように扱う:
+
+- 「6 ヶ月で OK」「お任せ」 → 直近 6 ヶ月 (= 現在日から 6 ヶ月遡る)
+- ISO 8601 (例: `2026-01-01`) → そのまま使用
+- 相対 (例: `3 months ago`) → 現在日から相対計算
+
+## Step 2. ignore_logins (除外する commenter) のポリシー
+
+- GitHub API が返す `user.type === "Bot"` のコメントは **自動で除外**
+- それ以外の Bot 疑い User (CodeRabbit / SonarCloud / login に "bot" / "ai" / "review" を含むアカウント) は、PR を眺める中で発見次第ユーザーに **「これも Bot 扱いしますか?」** と確認 → 確定したら以降の処理で除外
+
+## Step 3. merged PR の fetch
+
+`gh api 'repos/<owner>/<repo>/pulls?state=closed&sort=updated&direction=desc&per_page=100'` で closed PR を最新順に取得する。`merged_at IS NOT NULL` でフィルタして **merged 済の PR だけ** に絞り込む (closed-without-merge は対象外)。`Link` ヘッダの `rel="next"` を follow して pagination する。`merged_at` が Step 1 で確定した since を下回った時点で fetch 停止。
+
+## Step 4. コメント収集
+
+各 PR について、以下の 3 source を **すべて** 取得して flatten する:
+
+- `gh api 'repos/<owner>/<repo>/pulls/{n}/reviews'` — PR Review 本文
+- `gh api 'repos/<owner>/<repo>/pulls/{n}/comments'` — Files Changed タブの inline review comment
+- `gh api 'repos/<owner>/<repo>/issues/{n}/comments'` — PR 本文下の Conversation スレッド一般コメント
+
+PR description (本文) は対象外。あくまで「レビュー観点」を抽出するため。
+
+## Step 5. Bot 除外
+
+`user.type === "Bot"` のコメントは自動で除外。Step 2 で確定済の suspicious User もここで除外。新規の Bot 疑い login が出てきたら Step 2 のルールで都度ユーザー確認。
+
+## Step 6. 既存 rules 把握
+
+100 PR を 1 ブロックとして処理する。ブロックの開始時に必ず shinaps-ai MCP server の `search_rules({ repoOwner, repoName })` を呼んで、既存 userRules を取得する (facet を渡さないので officialRules は空、userRules は継承マージで scope=user / repo_owner / repo の全件、最大 200)。これを「新規 (= `record_rules` の投入対象に含める) か、既存に被せる `update_rule` か」を判断する material にする。
+
+## Step 7. rules 生成と投入
+
+各 PR ブロックから rules 候補を抽出する基準:
+
+- 複数 PR / 複数 reviewer で繰り返し言及されている指摘 (1 回限りの軽い指摘は採用しない)
+- DO/DON'T が明確で、再現可能な規約として書き下せる粒度のもの
+- WHY (なぜそうするか) を 1-3 文で要約できる材料があるもの
+
+Good/Bad サンプルコード (examples) の付け方:
+
+- レビューコメントや diff から Good/Bad ペアを構成できる rule にのみ `examples: { good, bad, language }` を付ける。**素材が無い rule に捏造しない** (プロジェクト固有の識別子を一般名に置換する・最小化する程度の編集は可)
+- good / bad は各 1000 文字以内・5〜15 行目安の短いコード片。language は shiki の言語 id 小文字 (`typescript` / `tsx` / `python` / `go` 等)
+- good / bad / language は 3 つセットでしか登録できない (片方だけは INPUT_INVALID)
+
+出典 URL (sourceUrls) の付け方:
+
+- 根拠になったレビューコメントの HTML URL (`#discussion_r...` / `#issuecomment-...`) を優先し、特定できなければ PR URL にフォールバック。最大 10 件・各 500 文字・http(s) のみ
+- **出典素材が無い rule に URL を捏造しない** (省略可 = 出典なしで保存される)
+
+投入手順:
+
+- 候補を既存 rules と照合し、**新規** (該当 rule 不在) だけを集めて `record_rules({ scope: 'repo', repoOwner, repoName, rules: [{ title, why, recommend?, avoid?, kind?, labels?, examples?, sourceUrls? }, ...] })` で **1 call bulk 投入** する。`labels` は language / platform / framework / topic の slug 配列 (`list_search_facets` の master 登録済みのみ、language/platform/framework は 1 rule に各 1 つまで) (1 call 最大 100 件、超えたら分割。同一 title の重複は入力段階で INPUT_INVALID)。extract-rules は対象 repo の PR レビューから抽出する性質上 scope=repo (当該 repo 限定) がデフォルト。横断ルールとして残したい場合だけユーザー判断で `scope: 'user'` に格上げ。**格上げするときは why / recommend / avoid / examples を当該 repo の固有文脈 (内部 API 名・モジュール構成・ドメイン固有の識別子) から切り離し、他プロジェクトでも適用イメージが湧く汎用的な表現・汎用サンプルに解釈し直してから登録する** (scope=repo のままなら repo 固有の具体的な記述・コード片で良い)。title は 200 字以内、規約本文は why (必須、なぜこの規約か、2000 字以内) / recommend (推奨行動、任意、1000 字以内) / avoid (避けるべきこと、任意、1000 字以内) の 3 フィールドに構造化する
+- 戻り値の `skipped: { title, existingRuleId, existingWhy, existingRecommend, existingAvoid, existingLabels, existingExamples, existingSourceUrls }[]` は「既存と title 重複して投入されなかった候補」。新しい why/recommend/avoid と existing* が異なるなら **ユーザーに diff を提示して同意を取る** (examples / sourceUrls の差分も同様):
+
+> 既存 rule "no-unused-vars" が見つかりました。why/recommend/avoid の差分:
+> ```
+> - 旧 why: ...
+> + 新 why: ...
+> ```
+> 上書きしますか? (yes / no / skip-all)
+
+- 同意なら `update_rule({ id: existingRuleId, why?, recommend?, avoid?, examples?, sourceUrls? })` を実行。`skip-all` を選ばれたら以降の skipped に対して確認をスキップする
+
+## Step 8. 100 PR ブロック確認
+
+100 PR ブロックの処理が終わるたびに、ユーザーに **「次の 100 PR ブロックに進むか」を確認** する (LLM のコンテキスト窓保護と判断点の挿入)。「続ける」なら次ブロックの fetch + コメント収集 + 既存 rules 再取得 + 抽出 + 投入を繰り返す。「やめる」なら現時点までの結果でレポートに進む。
+
+## Step 9. 完了レポート
+
+since 期間内の merged PR を消化し終えたら、以下を user に報告:
+
+- 処理した PR 件数 / コメント件数
+- 自動 Bot 除外 + ユーザー確認で除外した login 一覧
+- `record_rules` で新規投入した rule 件数 (inserted 合計) + タイトル一覧
+- `update_rule` で更新した rule 件数 + タイトル一覧
+- skip-all で残した候補件数 (あれば)

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

@@ -0,0 +1,222 @@
+---
+name: refine
+description: 対象ファイルの現状全文を search_rules と 1 件ずつ照合し、Violation / Improvement / Question に分類する skill。対象ファイルは引数の path 指定、または変更ファイル一覧 (`git diff --name-only HEAD` / PR / commit range) から決まる。3-5 カテゴリに束ねて Agent tool で shinaps-refine-agent を並列 dispatch → findings 集約 → 今回の変更箇所の自明な修正を Edit で自動適用し、既存箇所の指摘と判断要は 4 択 AskUserQuestion (修正する / 許容する / ルール側を直す / 後回し) で処理。セルフレビュー直前に発火。shinaps-ai server 未登録時は search_rules 呼び出しが自動で失敗して abort する。
+argument-hint: "[<file/dir path> | <PR URL> | <commit SHA> | <range>] (省略時は git diff HEAD の変更ファイル)"
+---
+
+## 作業記録の保存先
+
+作業記録はプロジェクトルートの `.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:refine — 規約照合の checkpoint
+
+このスキルは「commit / report 直前の self-review」を確実にやるためのバッチ照合手順書。CLAUDE.md に「セルフレビュー直前 → search_rules で規約照合」と書かれていても AI (あなた) が頻繁にスキップする現実への対症療法として、ユーザーが手動で発火するためにある。
+
+照合対象は **ファイルの現状全文** であって diff ではない。diff の hunk だけでは「この関数全体の責務が正しいか」「この命名は周囲と揃っているか」「規約が要求する構造がファイル内に揃っているか」を判断できず、追加行だけ見て規約準拠に見えても、ファイル全体としては規約から外れているケースを取り逃すため。git は **どのファイルを見るか** を決める用途と、finding が **今回の変更に含まれる箇所か** を判定する用途に使う。
+
+計画段階では発火しない。rule の大半はコメントの WHY / 命名 / import 経路といったコードレベルの規約で、自然言語の計画テキストからは検出できないため。計画段階で拾う価値がある設計レベルの規約違反は `shinaps-plan-reviewer` が担当する。
+
+shinaps-ai サーバは git / file / AI 推論を一切呼ばない。すべて Claude Code 側のあなたが手元の `git` / `Read` / 既存 MCP tools で実行する (private repo の内容をサーバ境界に渡さない設計)。
+
+## 全体アーキテクチャ
+
+メインスレッド (あなた) は **オーケストレータ** に徹する:
+
+1. 対象ファイル集合の確定、規約カタログの集約 (Step 0-1)
+2. 規約を意味論的に 3〜5 カテゴリに束ねる (Step 2)
+3. カテゴリごとに `shinaps-refine-agent` を **並列 dispatch** し、各 agent は担当カテゴリに関係するファイルだけを現状全文で読みに行く (Step 3)
+4. 返ってきた findings を集約 → 変更箇所 / 既存箇所で振り分け (Step 4-5)
+
+こうすることで、rule 数が増えても 1 パスの照合密度が落ちない (各 agent は担当カテゴリのルールにフォーカスする) 上に、メインスレッドの context にファイル全文を積まずに済む (対象は agent 側で必要なものだけ取得する)。
+
+## Step 0. 対象ファイルを確定する (MUST)
+
+以下の優先順位で **対象ファイル集合** を決める:
+
+1. **ユーザーが対象を明示していたらそれを最優先**。`/shinaps:refine` と一緒に以下を書いてくることがある:
+   - **ファイル / ディレクトリ path** (例: `apps/api/src/mcp/`) → その path 配下のファイルをそのまま対象集合にする (変更の有無を問わない)。ディレクトリなら `git ls-files <path>` で列挙する
+   - **PR URL** (例: `https://github.com/owner/repo/pull/123`) → `gh pr diff 123 --repo owner/repo --name-only` で変更ファイル一覧を取得。カレント repo と同じなら `--repo` は省略可
+   - **commit SHA / range** (例: `abc123` / `main..feature` / `HEAD~3..HEAD`) → `git diff --name-only <range>` で変更ファイル一覧を取得
+2. 明示指定がなければ `git diff --name-only HEAD` (= staged + unstaged の合計、ローカルで触ったファイル全部)
+3. それでも 0 件なら **ユーザーに確認**: 「変更がありません。直近の commit (`git diff --name-only HEAD~`) または特定のファイル / commit / PR を対象にしますか?」
+4. 削除されたファイルは対象集合から除く (現状が存在しない)
+
+対象が決まったらユーザーに「以下 N ファイルの現状を refine します」と 1 行で宣言してから先に進む。**Step 3 で各 agent に渡すファイル一覧と「変更範囲の確認コマンド」も、ここで決めた集合に必ず合わせること** (agent が独立に `git diff HEAD` を叩いて対象を取り違えないよう prompt に具体コマンドを埋め込む)。
+
+**ファイル数による一律の上限は設けない**。確定した対象集合を維持し、件数の多さだけを理由に対象の縮小やユーザーへの分割確認を求めない。各カテゴリの担当量が大きい場合は、ファイルの行数・内容量と関連性（ディレクトリ、機能、依存関係）を見て自動的にバッチへ分ける。小規模なら分割は不要。関連ファイルはできるだけ同じバッチにまとめ、バッチをまたぐ契約は集約時に照合する。
+
+## Step 1. 規約と context を集約する (並列取得)
+
+以下を並列で取得:
+
+- shinaps-ai MCP server の `list_search_facets()` で facet master (languages / platforms / frameworks / topics の登録済 slug 空間) を取得 → 対象ファイルの拡張子・パス・内容から関係する facet slug を推定して確定
+- `list_search_facets()` の `versionTargets` と manifest / lockfile / compiler config / deployment target を照合し、確認できたバージョンだけを `projectVersions: [{ targetKind, targetSlug, version }]` に指定する。facet取得後に検索する。targetやバージョンは推測しない。確認できない対象は条件付きルールが除外されるため、共通ルールのみの照合になったことを結果に明記する。
+- shinaps-ai MCP server の `search_rules({ repoOwner, repoName, languages?, platforms?, frameworks?, topics?, kind?, projectVersions? })` を呼ぶ → userRules + officialRules (両方を照合対象にする。userRules は facet に関係なく継承マージ全件、officialRules は admin が保存した rule のうち指定 facet とバージョン適用条件に一致するものへ絞られる（承認操作は不要）)。**repoOwner / repoName は現在の git workspace から必ず渡す** (`gh repo view` or `git remote get-url origin` から取得)。userRules は scope=user (横断) + scope=repo_owner (owner 一致) + scope=repo (owner+name 一致) の継承マージで返る。各 rule に乗る `scope` flag を見て「横断 / owner 限定 / repo 限定」を判別できる。facet を 1 つも指定せずに呼ぶと officialRules は空配列で返るので、必ず推定 facet を 1 つ以上指定すること。`kind` は通常指定しない (対象ファイル全体を rule 集合と広く照合する用途のため、絞り込むと見落としが増える)
+- repo root の `AGENTS.md` / `CLAUDE.md` を Read (プロジェクト規約)
+- AGENTS.md が `docs/` 等を「source of truth」として参照していたら **その docs も Read** (今回触った領域に関連するものに限定して良い)
+- グローバル `~/.claude/CLAUDE.md` の `## コメントルール` `## 実装・設計に関して` 等の節 (一度読んだセッションなら conversation history で代替可)
+- 該当 repo の auto-memory `~/.claude/projects/<slug>/memory/MEMORY.md` がもしあれば Read
+
+これらは「Step 2 でカテゴリ束ねる」ための素材。全文を再 Read で context に積まなくても、必要時に grep / Read で引ければ十分。
+
+## Step 2. 規約を 3〜5 カテゴリに束ねる (意味論分類)
+
+Step 1 で集めた rules と AGENTS.md / CLAUDE.md のガイドラインを **意味論的に 3〜5 個のカテゴリ** に束ねる。カテゴリ数はルール本数と多様性で判断する:
+
+- 目安: rule 10 件未満なら 2〜3 束、10〜30 件なら 3〜4 束、30 件超なら 4〜5 束
+- 上限は 5 束 (超えると agent 起動コストとメインスレッド集約コストが体感を悪化させる)
+- カテゴリ名は動的に命名して良い (例: "naming & readability" / "testing & mocks" / "security & secrets" / "architecture & abstraction" / "commit & workflow")
+- rule が 1 件しか属さないカテゴリは避け、隣接カテゴリに寄せる
+- 逆に 1 カテゴリに rule が偏りすぎたら分割する
+
+AGENTS.md / CLAUDE.md 側の記述も **同じカテゴリ体系に振り分ける** (「コメントルール」節は "naming & readability" に、「実装・設計に関して」は "architecture & abstraction" に、など)。rule と docs をカテゴリ単位でセットにして agent に渡すのがポイント。
+
+分類が終わったら、ユーザーに「以下 N カテゴリで並列レビューします」と 1 行で報告 (どのカテゴリに何件 rule が入ったか)。
+
+## Step 3. カテゴリごとに shinaps-refine-agent を並列 dispatch (MUST)
+
+カテゴリごと（分割した場合はカテゴリ × バッチごと）に `shinaps-refine-agent` を起動する。利用環境の同時実行枠内で独立した担当を並列に進め、残りは順次実行する。カテゴリ数とバッチ数は別に扱い、Step 2 のカテゴリ数の目安を対象ファイル数や総バッチ数の制限にしない。メインは担当一覧と完了状況を保持し、全バッチの結果を集約する。
+
+subagent 側は system prompt で finding severity 解釈 / JSON 返却フォーマット / credit 最適化原則を既に持っているので、Skill 側は必要最小限の情報だけ渡せばよい。
+
+### 各 agent への prompt テンプレ
+
+各 agent には以下を渡す (カテゴリごとに埋める):
+
+- **担当カテゴリ名** と、そのカテゴリに属する **rule 全件** (title / why / recommend / avoid / source_urls を full text で。id も添えて後で update_rule するとき参照できるように)
+- そのカテゴリに関連する **AGENTS.md / CLAUDE.md / docs の該当節** (全文でよい、agent 側で context 消費するので原文をそのまま貼る)
+- **repo root の絶対 path**
+- **担当ファイル一覧とバッチID** (Step 0 の対象集合から割り当てた repo root 相対 path を列挙する。未分割なら対象集合全体を渡す。agent が独立に対象を再決定しないよう明示する)
+- **変更範囲の確認コマンド** (finding を「今回の変更箇所」と「元からある箇所」に切り分けるために使わせる。Step 0 で確定した対象に応じて 1 つを具体コマンドとして埋め込む):
+  - **ローカル**: `git diff HEAD -- <path>`
+  - **commit range**: `git diff <range> -- <path>` (例: `main..feature`, `HEAD~3..HEAD`)
+  - **PR**: `gh pr diff <n> --repo owner/repo -- <path>` (owner/repo 込みで固定して渡す)
+  - **path 指定で変更を伴わない場合**: 「変更範囲の判定は不要、全 finding を `pre-existing` として返せ」と明示する
+
+### 各 agent が踏む手順 (prompt 内に明記する)
+
+1. 渡されたファイル一覧から、担当カテゴリのルールに **関連しそうなファイル** を選ぶ (拡張子 / パスから判断)。カテゴリと明らかに無関係なファイル (例: "testing & mocks" 担当が `docs/*.md` を見る) はスキップして良い
+2. 選んだファイルを `Read` で **現状全文** 取得する (diff の hunk ではなく、いま repo にある状態そのもの)
+3. 「変更範囲の確認コマンド」を `<path>` に差し替えて実行し、そのファイルの **どの行が今回の変更に含まれるか** を把握する
+4. ファイル全体を担当カテゴリのルールと突き合わせ、findings を分類する。**変更行の周辺だけに絞らない** — ファイル全体として規約に反していないかを見る
+5. 各 finding が手順 3 で把握した変更行に該当するかで `scope` を決める (`changed` / `pre-existing`)
+
+**finding 分類基準** (subagent 側の system prompt でも解釈済み):
+
+- **Violation**: 現状のコードが rule に既に反している
+- **Improvement**: 違反ではないが規約の趣旨に沿った改善余地がある
+- **Question**: 規約が曖昧 or 規約に載っていない判断
+
+各 finding には **根拠** を必ず添える (rule id + title / docs 引用)。根拠なしは report しない。
+
+### Agent の返却フォーマット (JSON 構造で返させる)
+
+各 agent には以下の JSON を返すよう prompt 末尾で指示する:
+
+```json
+{
+  "category": "<担当カテゴリ名>",
+  "batch_id": "<割り当てられたバッチID>",
+  "reviewed_files": ["<全文の照合を完了したファイル>"],
+  "skipped_files": [{ "file": "<未照合の担当ファイル>", "reason": "<カテゴリ非該当・読み取り失敗・未完了などの理由>" }],
+  "findings": [
+    {
+      "severity": "violation" | "improvement" | "question",
+      "scope": "changed" | "pre-existing",
+      "file": "<repo root からの相対 path>",
+      "line": <該当行番号 or null。現状ファイル内の行番号>,
+      "summary": "<1 文で何が問題か>",
+      "detail": "<どう直すべきかの提案 (1-3 文)>",
+      "rule_id": "<引用した rule の id (docs だけを根拠にした場合は null)>",
+      "rule_title": "<引用した rule / docs 節のタイトル>",
+      "evidence": "<引用元 rule / docs の該当文 (最大 200 字)>"
+    }
+  ],
+  "notes": "<担当範囲で気になったが finding には昇格しなかった観察 (optional)>"
+}
+```
+
+**Info レベルは含めない** (Critical / Warning 相当だけを扱う)。findings が 0 件でも空配列で返す。
+
+## Step 4. findings を集約する
+
+全 agent の返却を受け取ったら、メインスレッドで以下を実施:
+
+- **対象の照合状況**: カテゴリ × バッチの担当一覧と `reviewed_files` / `skipped_files` を照合する。関連カテゴリで未照合のファイルや報告から抜けたファイルは再割り当てする。読み切れなかった場合は担当量を減らして続きを確認し、findings が空という理由だけで完了扱いにしない。全カテゴリで非該当としたファイルは理由を明記する。分割をまたぐ呼出し元・実装・型などの整合性も必要な担当へ照合を依頼する。
+
+- **重複マージ**: 同じ file + line で意味が重なる finding は 1 件に統合し、根拠を両方併記する (異なるカテゴリの agent が同じ問題を別観点で拾うことがある)
+- **scope 整合**: 同じ箇所を指す finding の `scope` が agent 間で割れていたら `changed` を優先する (変更行に 1 行でも掛かっていれば今回の変更の責任範囲とみなす)
+- **優先度整列**: Violation → Improvement → Question の順に並べ、Violation 内は影響範囲が大きいものから
+- **注意**: Info レベルは元々含まれない前提だが、agent 出力に混じっていたら破棄する
+
+集約結果の総数と内訳を 1 行で報告してから Step 5 に進む (`changed` / `pre-existing` の件数も併記する)。
+
+## Step 5. 自動修正と要確認に振り分ける
+
+集約後の finding を振り分ける。**`scope` が第一の分岐**:
+
+- **`changed`** (今回の変更に含まれる箇所) → 以下の「自明な修正」なら自動適用、それ以外は要確認
+- **`pre-existing`** (今回触っていない既存箇所) → severity を問わず **必ず要確認に回す**。自動修正しない
+
+`pre-existing` を自動修正しないのは、今回の作業と無関係な差分が commit に混入して、レビュアーが「この変更は何のためか」を追えなくなるため。既存箇所の指摘は「別 commit に分ける」「後回しにする」判断がユーザー側にある。
+
+### 自明な修正 (auto-apply、`changed` のみ)
+
+修正方法が一意で設計判断を伴わない finding は、ユーザーに確認せず `Edit` / `Write` で即修正する:
+
+- コメント / 文言 / typo の修正 (規約が指す直し方が一つしかない)
+- 既存パターンへの機械的な追従 (隣接コードと同じ流儀に揃えるだけ)
+- import 経路や命名の規約違反で、直し先が明白なもの
+
+自動修正を終えたら型 / lint / test を回して green を確認する。修正内容は Step 6 のサマリで「何をどう直したか」を file 単位で必ず一覧報告する (ユーザーが事後確認できるように)。
+
+### 判断が必要なもの (要確認)
+
+以下に該当する finding は `AskUserQuestion` で確認する。**迷ったら確認側に倒す**:
+
+- **`scope` が `pre-existing` のもの全般** (今回の変更と切り離して判断すべきなので、自明に見えても確認する)
+- 設計トレードオフがある (複数の修正方針があり得る / 影響範囲が広い / 構造変更を伴う)
+- 規約側が現実と乖離している可能性がある (finding の severity=question 全般)
+- 修正コストが大きく「後回し」が現実的な選択肢になるもの
+
+選択肢は 4 つ:
+
+1. **修正する** — どう直すかを 1-2 文で提案 (agent が返した `detail` を活用)。承認されたら `Edit` / `Write` で実行
+2. **このまま許容する** — 妥当な理由があるとき。理由を今回のローカル成果物（implementation.md / 調査・レビューレポート）に残す (将来の自分が「なぜ違反のままにしたか」を辿れるように)
+3. **ルールの方を修正する** — 規約自体が現実と乖離している場合。shinaps-ai MCP server の `record_rule` (新規) or `update_rule` (既存修正) を実行。新規 record_rule のときは scope (user / repo_owner / repo) も選ばせる (横断的なら user、この repo 限定なら repo)
+4. **後回し** — 別タスクとして扱う。`TaskCreate` で TODO 化し、後の作業セッションで拾えるようにする
+
+**提示順は `changed` を先、`pre-existing` を後**。それぞれの中では Violation → Improvement → Question の順。各 finding には `pre-existing` かどうかを明示して提示する (ユーザーが「今回の commit に混ぜるか」を判断する材料になるため)。件数が少なければ 1 回の `AskUserQuestion` に複数 question をまとめてよい (各 finding には前提説明を添える)。
+
+## Step 6. 完了サマリ
+
+処理が一巡したら、最後にユーザーへ箇条書きでサマリ報告する。
+
+- 対象ファイル数と、その決め方 (`git diff HEAD` の変更ファイル / PR / commit range / path 指定のどれか) を冒頭に明示
+- 走らせたカテゴリ数・バッチ数と各カテゴリの finding 件数、照合済みファイル数、非該当・未完了のファイルと理由
+- 検出 / 処理した finding の総数と内訳 (自動修正 X 件 / 確認の上修正 Y 件 / 許容 Z 件 / rule 更新 W 件 / 後回し V 件)
+- **`changed` と `pre-existing` の内訳** (既存箇所の指摘が何件あり、そのうち何件を今回直したか。今回の変更に無関係な修正がどれだけ混ざったかをユーザーが把握できるように)
+- **自動修正した内容の一覧** (file + 1 行の何をどう直したか。ユーザーが事後確認する唯一の接点なので省略しない)
+- 新しく `record_rule` / `update_rule` した内容があれば「次セッション以降に効きます」と明示
+- まだ未処理の Question / 後回しの TaskCreate id を列挙
+
+この後 user は通常 `git add` / commit に進む想定なので、refine 自体は commit しない (ユーザー操作の自然な境界を奪わない)。
+
+## 注意点
+
+- **Info レベルは report しない**。Critical / Warning 相当だけを扱う。ノイズが多いと「規約照合は手間」というネガティブ印象が定着するため
+- **並列数は利用環境に合わせる**。同時実行枠が少なくても、残りのバッチを順次実行して対象全体を確認する
+- **Agent への rule 受け渡しは full text**。id + title だけを渡して agent 側に search_rules を再取得させると shinaps MCP を N 回叩くことになるため無駄。メインスレッドが 1 度取得したものを prompt に貼る
+- **各 agent の scope 逸脱を防ぐ**: prompt 内で「担当カテゴリ以外の観点で finding を上げない」と明示する。violation と思っても他カテゴリ担当ならスキップする (別 agent が拾う想定)
+- finding 同士が重複していたら Step 4 の集約で統合する (「同じファイルで console.log 3 件、まとめて削除しますか?」等)
+- 規約が 0 件 (= `search_rules` の userRules / officialRules が空) のとき: 「rule が登録されていません。今日の作業で rule 化したい習慣はありますか?」と逆に質問して、`record_rule` を引き出すきっかけにする (この場合 Step 2-4 はスキップ)

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

@@ -0,0 +1,38 @@
+---
+name: release
+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、既存スクリプトから、今回の対象・必須検証・禁止事項を確認する。現在の依頼と合意済みの条件を引き継ぎ、一般的な推奨をプロジェクトの必須条件に格上げしない。条件同士が矛盾し結果を左右する場合だけ一問ずつ確認する。任された実装判断は進める。
+
+既存の情報から決まる内容を再質問しない。確認した新しい恒久方針は、ユーザーが保存を認めた場合だけプロジェクトの指示または参照先へ残す。スキル自身や他プロジェクトのルールへ書き込まない。
+
+## 公開前に条件を確定する
+
+対象環境・配布先・ソースrevision・成果物のバージョンと、成功を判断する操作・証拠を確定する。リポジトリのリリース手順を使い、既存CIや証拠形式があれば再利用する。専用のJSON形式や新しい検証基盤を導入すること自体を必須にしない。
+
+完了条件は公開物の性質と変更の影響から決める。Web、配布アプリ、ライブラリ、CLIで同じ端末検証を強制しない。マイグレーション、バックエンド連携、実機導入、配布ストアの処理、運用ログは、対象に関係する場合の条件として扱う。不要な項目を形式的に増やさず、必要な条件を使えるツールに合わせて弱めない。
+
+公開・認証・破壊的操作の許可はユーザーの依頼と実行環境の規則に従う。リリース依頼から別環境への展開、データ削除、課金変更、対外告知、ストア審査提出の許可を推測しない。
+
+## 実行
+
+1. Git状態、対象revision、必要な検証と公開先を確認する。無関係な未コミット差分を成果物に混ぜない。
+2. プロジェクトが定める検証とビルドを行い、公開する成果物の識別情報を記録する。
+3. 文書化された公開経路を実行する。処理中・配布可能・利用確認済みを区別する。
+4. 同じrevision／バージョンに対して完了条件を確認する。関連システムがある場合は整合も確認し、別revisionの正常応答を今回の成功と扱わない。
+5. 失敗した段階、外部への反映状況、復旧手順を保持する。再試行前に反映状態を確認し、二重公開を避ける。復旧も既存の許可範囲で行う。
+
+## 完了
+
+公開したidentity、配布先、確かめた主要操作・証拠、未確認条件を示す。必要な条件が残れば「公開済み・利用確認未完了」など実態を報告する。人間の確認が必要ならその段階から再開し、完了済みの公開を繰り返さない。証拠には秘密情報を含めない。