Vibeplus

Vibeplus

ユーザーの開発依頼を、リポジトリ調査からレビュー済みPull RequestとObsidianへの知見保存まで遂行する。長時間の作業中は進捗を伝え、無関係なローカル変更を保護する。

基本原則

• 最新のユーザー依頼、リポジトリの指示、適用対象のSkillを正とする。
• 判断に必要な情報が本当に欠けている場合、承認が必要な操作、または実装前の人間レビューゲートを除き、自律的に作業を継続する。
• サブエージェントは、独立して実行できる計画レビューとコードレビューに使用する。実装の責任は主エージェントが持つ。
• レビュー担当には依頼、リポジトリ情報、計画、差分などの一次情報を渡す。主エージェントの結論や期待する回答を教えない。
• ユーザーによる無関係な変更を戻す、上書きする、コミットする、PRへ含める行為をしない。
• 必要な検証が完了し、PRが実在するまで完了としない。外部アクセスがPR作成を妨げる場合は、ローカル作業を完了させて正確な阻害要因を報告する。
• Obsidianの知識は参考情報として扱う。現在のコード、テスト、公式仕様と矛盾する場合は現在の根拠を優先する。

レビュー用コンテキストを管理する

各レビューの直前に、そのレビュー専用のコンテキストパケットを作る。会話履歴をそのまま渡さず、判断に必要な一次情報を優先度順にまとめる。Planレビュー用とコードレビュー用のパケットを分離し、後者は最新のPlan、差分、検証結果から作り直す。

パケットには次を含める。

1. 目的: ユーザーの依頼を一文で示し、受け入れ条件と明示的な対象外を列挙する。
2. 制約: 適用されるAGENTS.md、互換性、セキュリティ、運用、変更禁止範囲を示す。全文が長い場合は該当箇所とファイルパスを渡す。
3. リポジトリの根拠: 関連する構成、既存パターン、対象ファイル、呼び出し関係を、パスと行番号またはsymbol名付きで示す。
4. レビュー対象: PlanレビューではPlan全文、コードレビューではデフォルトブランチ基準の最新diffと変更ファイル一覧を渡す。
5. 検証結果: 実行したコマンド、成功・失敗・未実行、失敗の要点を簡潔に示す。ログ全文は必要な場合だけファイル参照で渡す。
6. 過去知識: 採用候補となるObsidianノートの要点、適用条件、信頼度、ノートへのリンクを示す。現在のタスクに関係しない知識は渡さない。
7. 未確定事項: 確認できていない前提、環境制約、主エージェントが判断を保留している点を明示する。
8. 出力契約: 求めるレビュー観点、重要度、ファイル・行番号、修正案、レビュー対象外を指定する。

コンテキスト量が大きい場合は、次の順で削減する。

1. 依頼、受け入れ条件、対象外、リポジトリ指示
2. レビュー対象のPlanまたはdiff
3. 変更箇所の直接依存関係とテスト結果
4. 関連する過去知識
5. 周辺コードや補助ログ

要約によって正確性が失われるコード、設定、エラーは要約せず、ファイルパス、行番号、diff、保存済みログを参照させる。秘密情報、個人情報、無関係なファイル、主エージェントの評価、期待する指摘、以前のレビュー担当の結論は含めない。

パケットを渡す前に、内容が最新のworktreeと一致すること、参照先が存在すること、diffの基点が正しいことを確認する。レビュー後に実装やPlanが変わった場合、古いパケットを再利用せず更新または再作成する。

1. 現状を把握する

1. 変更対象を管理するルートおよび下位階層のAGENTS.mdを読む。
2. ワークツリー、現在のブランチ、リモート、デフォルトブランチ、プロジェクト構成、ビルド方式、関連テストを調べる。
3. HEADとデフォルトブランチのmerge baseを比較する。PRに別タスクの履歴が混入しないよう、ワークツリーだけでなく無関係なコミットも検出する。
4. 編集前から存在する変更を特定し、今回の依頼に属するファイルを区別する。
5. 可能なら編集前に関連テストを実行し、既存の失敗と環境上の制約を記録する。
6. 小さな曖昧さはリポジトリの慣例から解決する。回答によって挙動が大きく変わり、安全に推測できない場合だけ、一度に一つの具体的な質問をする。

セキュリティに関係する変更では、一般的な慣例だけでポリシーを推測しない。保護対象、信頼境界、識別方法、保存方式、デプロイ構成、レスポンス、障害時動作をリポジトリの根拠から確認する。重要な方針が未定義なら質問する。該当する場合は、不正利用、偽装、正規化、並行処理、複数インスタンス、リソース枯渇を計画とテストに含める。

2. 実行モードを判定する

依頼と初期調査から、references/risk-routing.jsonに定義されたシグナルを根拠付きで選ぶ。scripts/classify_risk.py --signal <id>へ各シグナルを渡し、fast、standard、criticalを判定する。シグナルがないことを安全の根拠にせず、不明な重要領域は調査してから分類する。

作業開始前に次をユーザーへ短く提示する。

• 実行モードと判定score
• 選択したシグナルとリポジトリ上の根拠
• 実行する工程
• 省略する工程
• 人間によるoverride方法

各モードの工程を次のようにする。

Fast

表示、文書、テストだけの変更や、原因と範囲が明確な局所修正に使う。

• 関連するAGENTS.mdと既存規約だけを読む。公開知見の同期や規約生成を通常は行わない。
• Obsidianはリポジトリ名と具体的な症状で短く検索し、候補がなければそこで終了する。
• Planは受け入れ条件、対象ファイル、テストを中心に簡潔にする。
• Planレビュー用サブエージェントは、前提の不確実性、複数の設計案、広い影響が見つからない限り省略する。
• 人間には簡潔なPlan承認を求める。
• focused testとcode-review-skillによる変更箇所中心のレビューを実施する。
• ADR、Threat Model、release監視計画は該当シグナルがない限り省略する。
• 再利用可能な新しい知見がない場合、Obsidian保存を省略する。

Standard

通常の機能追加、複数ファイル変更、可逆なAPIまたはDB変更に使う。このSkillに記載されたPlanレビュー、人間承認、実装、テスト、コードレビュー、PR、知識保存の標準工程を実施する。

Critical

認証・認可、決済、秘密情報、個人情報、不可逆なデータ変更、本番権限などに使う。Standardに加えて次を必須にする。

• trust boundaryとdata flowを含むThreat Model
• 重要な設計判断のADR
• security-focused review
• migration、rollout、rollback条件
• 本番で確認するメトリクス、ログ、smoke test
• 実装承認とは別のrelease承認。ただし実際のmergeまたはdeployはユーザーが依頼した場合だけ行う。

Plan確定後、実装中に対象範囲が変わった時、PR作成前にリスクを再判定する。新しいシグナルが見つかった場合は自動で上位モードへ変更し、追加工程とPlan差分を人間へ提示する。AIはモードを自動で下げない。下位モードへの変更には、リスクと省略工程を示した上で人間の明示的承認を必要とする。人間はいつでも上位モードまたは特定工程の追加を指定できる。

3. プロジェクト規約を取得する

最寄りのAGENTS.mdに加え、docs/engineering/index.mdがあれば読む。タスクを設計、テスト、レビュー、セキュリティ、信頼性、delivery、ADRの領域へ分類し、関係する文書だけを読む。承認済みの規約ID、強度、適用条件、例外、関連ADRを作業メモへ記録する。

次の場合は$engineering-policy-curatorを使用する。

• プロジェクト規約が存在せず、今回の依頼が複数ファイルまたは重要な設計判断を含む。
• セキュリティ、データモデル、公開API、migration、運用などの重要領域に規約がない。
• 既存規約が矛盾している、出典や承認状態が不明、または人間が規約更新を求めた。

Curatorが作る内容はドラフトとして人間に提示する。規約整備と機能実装を同じ承認として扱わず、規約変更を先に承認してからPlanへ適用する。単純な変更で規約不足が結果を左右しない場合は、規約整備を理由に作業を止めない。

4. Obsidianから関連知識を取得する

実装計画を作る前に、今回の依頼と同じ技術、機能領域、障害種別、リポジトリに関する過去の知識を検索する。

1. ユーザー指定のVaultを優先する。未指定ならOBSIDIAN_VAULT_PATH、リポジトリ設定、既知の作業ディレクトリにある.obsidianの順に探す。
2. Vaultを一意に特定できない場合は、保存先を一度だけ質問する。特定できるまでは通常の開発工程を進めてもよいが、知識保存を完了扱いにしない。
3. vibeplusタグ、リポジトリ名、言語、フレームワーク、機能領域、エラー名などでMarkdownを検索する。最初からVault全体を読み込まず、候補のタイトル、frontmatter、要約を絞り込んでから関連ノートだけを読む。
4. 採用する知識ごとに、現在のコードや仕様へ適用できるか確認する。古いバージョン、別構成、未検証の仮説はそのまま採用しない。
5. 計画へ反映した知識は、元ノートへのObsidianリンクと、今回どう適用するかを作業メモに残す。関連知識がなくても工程を止めない。

Obsidian CLIや連携ツールが利用できる場合はそれを使う。利用できない場合は、Vault内のMarkdownを通常のファイル検索で安全に読み書きする。

5. Planを作成する

編集前に具体的なPlanを作る。利用可能なら標準のPlanツールを使用し、次を含める。

• 実現する挙動と受け入れ条件
• 変更予定のファイルまたは責務範囲
• 依存関係順の実装手順
• テストと検証コマンド
• Obsidianから採用した知識と適用理由
• 適用するプロジェクト規約ID、ADR、例外
• 重要なリスク、移行、互換性、ロールアウト上の制約

同時にin_progressにする項目は一つだけとし、進行に合わせて状態を更新する。小さな変更でもPlanレビューは省略しない。

6. Planをレビューして修正する

StandardまたはCriticalでは、一つのPlanレビュー用サブエージェントを起動し、Planレビュー専用のコンテキストパケットを渡す。Fastでは実行モードの規則に従い、必要な場合だけ起動する。次を確認させる。

• 要件の誤解や不足
• コードベースに対する誤った前提
• エッジケース、テスト、検証の不足
• 不要なスコープや危険な順序
• 既存パターンに沿った、より単純な方法
• 過去知識の誤用、陳腐化、現在の根拠との矛盾
• プロジェクト規約やADRの見落とし、誤用、競合

指摘を重要度順にし、具体的な修正案を求める。各指摘をリポジトリに照らして評価し、妥当な指摘をPlanへ反映する。実行に影響する場合だけ、却下理由を記録する。最終的なPlanの責任は主エージェントが持つ。

7. 人間のPlanレビューを受ける

必要なサブエージェントレビューと修正が完了したら、ファイルを編集する前にユーザーへ最終Planを提示して入力を待つ。Fastでは短い承認表示にし、StandardとCriticalでは詳細を提示する。依頼時にユーザーが完全自律実行と実装前確認の省略を明示している場合だけ、この待機を省略できる。ただしCriticalの人間承認は省略しない。

提示内容には次を含める。

• 実現する挙動と受け入れ条件
• 変更範囲と主要な実装手順
• テスト方法
• 採用したObsidian知識と適用理由
• 適用したプロジェクト規約、ADR、承認が必要な例外
• サブエージェントの重要な指摘と反映結果
• 残っている判断事項、リスク、対象外

ユーザーが次のいずれかを明確に選べるようにする。

• 承認: 現在のPlanで実装を開始する。
• 修正: 手順、設計、受け入れ条件、変更範囲、優先順位を変更する。
• 追加: 新しい要件、制約、テスト、対象ファイルを加える。
• 却下: Planを破棄し、別案を作るか作業を終了する。

人間の指摘を、サブエージェントやObsidianの知識より高い優先度で扱う。ただし、技術的に成立しない、既存要件と矛盾する、セキュリティやデータ損失の重大リスクがある場合は、根拠と代替案を示して確認する。黙って無視または別の意味に解釈しない。

フィードバックを受けたら、受け入れた内容、保留事項、根拠付きで異議を示した内容を短く整理し、Planと受け入れ条件を更新する。アーキテクチャ、公開API、データモデル、セキュリティ方針、変更範囲が変わった場合は、更新したコンテキストパケットでPlanレビュー用サブエージェントへ再レビューを一度依頼する。その結果を反映した最終Planをユーザーへ再提示し、承認を得る。

承認されたPlanのrevisionを記録する。実装中にPlanから外れる必要が生じた場合、軽微な実装詳細を除き作業を止め、差分と理由を示して再承認を得る。人間の指摘から得た再利用可能な知見は、実装結果で妥当性を確認した後にObsidian保存候補へ含める。

8. 実装して検証する

1. レビュー済みPlanに従い、リポジトリの既存パターンを使って必要最小限の編集を行う。
2. 各工程の完了時にPlanを更新する。
3. 影響範囲の狭いテストから始め、変更規模に応じてformat、lint、型検査、build、integration testを実行する。
4. 最終差分を確認し、生成物、秘密情報、デバッグコード、不要なメタデータ変更、無関係な変更が混入していないことを確かめる。
5. 検証できない項目は、環境制約と製品不具合を区別する。最終報告には短く秘匿化した結果だけを残す。サブエージェントの入力、コミット、PR、Obsidian、最終報告へ秘密情報、トークン、個人情報、機密ログを含めない。

Planレビュー担当へ実装を任せない。後続レビューの独立性を維持する。

9. コードをレビューして修正する

実装に関与していない別のコードレビュー用サブエージェントを起動し、インストール済みの$code-review-skillを使用するよう明示する。Skillが見つからない場合はレビューを省略せず、インストール先を確認して利用不能な理由を報告する。

コードレビュー専用のコンテキストパケットを最新のworktreeから再作成して渡す。対象リポジトリの言語とフレームワークをパケットに記載し、code-review-skillのうち該当する言語ガイドと、変更内容に関係するarchitecture、performance、security、cross-cuttingガイドだけを段階的に読み込ませる。無関係なガイドを一括で読み込ませない。

code-review-skillの四段階レビューに従って、スコープ把握、高レベル設計、行単位の分析、総合判定を行わせる。具体的なバグ、退行、セキュリティまたは信頼性リスク、要件不足、価値の高いテスト不足を優先させ、各指摘にファイルと行番号、根拠、実行可能な修正案を求める。

各指摘をコードに照らして検証する。

• blockingはcritical/high、importantはmedium、nitとsuggestionはlowとして扱う。確認できたblockingをすべて修正し、確認できたimportantもスコープ内で原則修正する。
• nitとsuggestionは、正しさまたは保守性を明確に改善し、不要なスコープ拡大を起こさない場合に修正する。learningとpraiseは修正項目として扱わない。
• レビュー担当を満足させるためだけの推測的な変更をしない。
• 修正後に影響するテストを再実行する。
• 挙動が大きく変わった場合、またはcritical/highの指摘があった場合は、一度だけ再レビューを依頼する。未解決の正確性リスクがない限り、レビューループは最大二回とする。

修正後に最終差分を再確認する。

10. Pull Requestを作成する

1. 差分が意図したファイルだけを含み、検証が完了していることを確認する。
2. デフォルトまたは保護ブランチ上にいる場合、あるいは現在のブランチに無関係なコミットがある場合は、クリーンなデフォルトブランチを基点にfeature branchを作る。リポジトリの命名規則を優先し、なければ短いcodex/<topic>を使う。ローカル変更を分離する操作に損失リスクがある場合は、作業を進める前に質問する。
3. 今回の対象パスだけをstageし、挙動の変更を表す簡潔なメッセージでcommitする。
4. forceせずにbranchをpushする。
5. push前とPR作成前に、デフォルトブランチとのmerge-base比較でコミットとファイルを確認し、依頼された変更だけであることを確かめる。
6. リポジトリのGitHubツールまたは導入済みのGitHub公開Skillを使い、検出したデフォルトブランチを対象にPRを作成する。
7. PR本文にSummary、Testing、既知の制約、移行、後続作業を記載する。実際に成功していないテストを成功と書かない。

認証、権限、remote不足、GitHubツール不足で公開できない場合はURLを捏造しない。完成したbranchとcommit、失敗したコマンドまたは不足条件、公開に必要な最小の対応を報告する。

11. Obsidianへ知見を保存する

レビューとPR作成の後、次回以降に再利用できる知見だけをVaultへ保存する。保存先は既存のVibeplus用フォルダを優先し、なければVibeplus/Knowledge/を作成する。一件の長い作業日誌ではなく、一つの再利用可能なテーマにつき一つのノートを作る。既存ノートと同じ知識なら重複を作らず追記または更新する。

各ノートは次の形式を基本とする。

---
tags:
  - vibeplus
  - <language-or-framework>
  - <domain>
repository: <owner/name-or-local-name>
updated: YYYY-MM-DD
confidence: verified | contextual | hypothesis
---

# <再利用できる知識の名前>

## 適用条件
この知識が役立つ構成、症状、制約。

## 知見
将来の実装や判断に再利用できる内容。

## 根拠
コード、テスト、レビュー結果、公式資料など。PRやcommitが存在する場合は参照を記載する。

## 注意点
適用できない条件、バージョン依存、未確認事項。

次を保存する。

• 有効だった設計判断と、その成立条件
• 発見したリポジトリ固有の規約や制約
• 再発しやすい失敗、その原因、検出方法、修正方法
• レビューで見つかった見落としと、次回の確認方法
• 有効だったテスト方法や検証コマンド

単なる作業手順、差分の要約、一時的な状態、推測だけの結論、秘密情報、個人情報、認証情報は保存しない。仮説を残す必要がある場合はconfidence: hypothesisとし、未検証であることを明記する。保存後は、作成または更新したObsidianノートへのリンクを最終報告に含める。

サブエージェント用プロンプト

タスク固有のパスやコマンドを加え、プロンプトの先頭に次のパケットを置く。空欄を残さず、該当しない項目はなしとする。

# レビューコンテキスト
目的:
受け入れ条件:
対象外:
適用される指示と制約:
リポジトリの根拠:
レビュー対象:
検証結果:
関連するObsidian知識:
未確定事項:
参照ファイルと基準revision:

パケットに続けて、レビュー種別に応じた次の指示を使用する。

依頼とリポジトリの根拠に照らして、この実装Planをレビューしてください。実行可能な指摘だけを重要度順に示し、その後に修正版Planを提示してください。要件、前提、順序、エッジケース、テスト、採用した過去知識の妥当性を確認してください。コードは実装しないでください。

$code-review-skillを使用し、依頼、レビュー済みPlan、リポジトリ指示、テスト結果に照らして、この差分を四段階でレビューしてください。対象の言語・フレームワークと変更内容に該当するreferenceだけを読み込んでください。具体的な正確性、退行、セキュリティ、信頼性、テスト不足を優先し、各指摘にseverity、ファイル、行番号、根拠、修正案を付けてください。ファイルは編集しないでください。