birdview

Birdview

中文

エビデンスにリンクされたアーキテクチャマップでシステムを示し、編集前に AI が変更を予定しているモジュールを強調表示します。

アクティベーション

プロジェクトが off の場合、現在のタスクで明示的に依頼されない限り、基盤とマップのワークフローは無効になります。インストール済みのプロジェクト基盤ルールは、スキルをアクティベートしていなくても on-demand で適用されます。正規の管理対象テキストは foundation.txt です。プロジェクトのセットアップや、管理対象ルールの無効化・削除については、modes.md に従ってください。ルールの設定だけを目的にマッピングを開始しないでください。

Birdview のデフォルトは on-demand です。ユーザーがスキルを選択するか、Birdview の名前を挙げるか、アーキテクチャ／制約／変更のマップを依頼した場合にのみアクティベートします。通常のコーディング、小規模な修正、機能の計画では、デフォルトでアクティベートしません。プロジェクトホストの指示ファイルで auto が明示的に設定されている場合は、小規模な編集を含むすべてのコード変更タスクの前と、影響を受けるモジュールを明示的に分析する計画の前にアクティベートします。既存の auto 設定に従ってください。setup はその設定を維持します。明示的にこのタスクで起動されない限り、off に従ってください。スキルについて話題にしただけでは、マップの依頼にはなりません。許可されたコーディングでアクティブな場合は、編集前にマップを再利用／更新し、影響を受けるモジュールを明示してください。

Codex では、/skills を使って Birdview を選択するか、$birdview と指定してください。Claude Code では、インストール済みのスキルを /birdview として利用できます。その他のホストでは、スキルセレクターを使うか、Birdview を明示的に依頼してください。同じスラッシュコマンドが実装されていると想定しないでください。呼び出しは現在のタスクに適用され、以降のすべての編集には適用されません。

モードの変更／ステータスについては、modes.md に従い、選択したプロジェクトルートに対してコマンドを実行して、その結果を報告し、終了してください。モードの切り替えだけではマッピングを開始しません。アクティブな場合は、変更範囲の構築や分析を始める前に、既存マップの検出結果を報告してください。これらはエージェントへの指示であり、書き込みをインターセプトして強制するものではありません。

ワークフロー

「Birdview を使って」というだけの依頼では、通常、アーキテクチャとレビュー済みの制約をまとめて提供します。ステージ 1 には、実効性のあるローカル指示の検出、ソースの収集、人が読みやすいルールのレビュー、ソース範囲の履歴収集、および --constraints による統合レンダリングが含まれます。constraint-graph.md に従ってください。編集のたびにレビューを最初から繰り返すのではなく、現在の要件に一致する既存の成果物を再利用してください。アーキテクチャのみ、または制約のみを明示的に求められた場合は、その依頼に従ってください。レビュー済みのルールがない場合は、確認したソース、未解決の不足事項、ルールグラフをレンダリングできない理由を明示してください。ルールを捏造したり、未スキャンのデータを制約ゼロとして扱ったりしてはいけません。制約レビューが未完了のまま、アーキテクチャのみの出力を既定の提供物が完成したものとして扱わないでください。

制約グラフまたは制約の完全な一覧を明示的に求められた場合は、constraint-graph.md に従ってください。この単独の手順では、アーキテクチャマップは不要で、変更もされません。ソースを検出してから、実行可能なルールを抽出してレビューし、その後にレンダリングしてください。既定の表示では、ルールを人が読みやすいトピックごとにグループ化し、番号付きトピックとアーキテクチャに沿った役割別の色を使用します。生ファイルやセクションは、リンクされたソースインデックスに記載します。ソースをそのまま出力するだけでは、提供したことになりません。レビュー済みの範囲と未解決の不足事項を報告してください。依頼された一覧を少数の例で代用してはいけません。

マッピングの前に、constraints.md に従って、実効性のあるローカル指示と、それらが明示的に参照する内容を特定してください。ソース、適用可能性、確認済みの範囲を記録してください。編集パスが判明したとき、または拡大したときは、ディレクトリのルールを再確認してください。マッピングと計画ではこれらのルールを適用し、提供時には適用可能性と検証状況を区別してください。

1. map-project.md に従ってください。既存のマップとアプリケーションのカバレッジを調べ、利用可能なマップを再利用または更新してから、HTML をレンダリングし、目視でレビューしてください。ブラウザープレビューの結果、識別情報、リビジョン、カバレッジ、不確実な点を提供してください。JSON だけでは不十分です。
2. コーディングタスクでは、show-changes.md に従って具体的な変更範囲を準備し、レンダリングしたうえで、実装前にユーザーの確認を得てください。操作は同じマップリビジョンに紐付けてください。

実装前に表示された計画を確認する

自動モードでもオンデマンドモードでも、レビュー可能なマップと変更計画を先に完成させます。HTML プレビュー、影響を受けるモジュール／ファイル、予定している動作、適用される制約、検証計画、残っている不確実性を提示します。その後、表示した範囲を実装してよいか尋ね、明示的な返答を待ちます。Birdview では、表示された計画の確認が必要であることを説明します。何かを作成／修正するという最初の依頼や、自動モードを有効にするという依頼は、ユーザーがまだ見ていない計画への確認にはなりません。ページが描画されたこと、チェックに成功したこと、時間が経過したこと、または返答がないことは承認ではありません。

確認を得る前に、読み取り専用の調査と、マップ／制約／計画の成果物の作成は可能です。実装、テスト、プロジェクト設定は編集せず、editing イベントも出力しないでください。planned イベントでは実際に依頼されたタスクを記述できますが、それは承認ではありません。マップのみを求める依頼では、マップを提示して終了し、実装の承認を求めないでください。

同じ表示済み計画について明示的な確認をすでに得ている場合は、それを再利用してください。その範囲内の定型的な編集やチェックについて、再度尋ねないでください。新たなモジュール、動作、制約によって計画が大きく変わる場合は、プレビューを更新し、変更後の範囲について実装前に確認を得てください。このタスクでは確認を省略するというユーザーの明示的な指示があれば、それを優先します。一般的なコーディング依頼から、その免除を推測しないでください。承認は会話内に留め、承認用のスキーマフィールドをでっち上げたり、静的ビューアーがこのゲートを強制するかのように示したりしないでください。

「use Birdview」という依頼だけの場合は、ステージ 1 を完了し、次に予定している変更だけを尋ねます。「このプロジェクトに報酬機能を追加するにはどうすればよいですか？」のような計画依頼では、ステージ 1 で提案する役割と影響を受けるモジュールを説明し、追加案は未実装であることを明示します。計画だけでは、コード編集やアクティビティイベントの出力は許可されません。ユーザーが実装タスクを許可した場合にのみステージ 2 に進みます。デモのためにタスクやイベントをでっち上げないでください。

ルール

有効化後に許可されたコーディングタスクに取り組む場合は、編集前に関連する実装、呼び出し元、既存の設計判断を確認してください。変更範囲を絞り、具体的なメリットのない抽象化は避けてください。該当するタスク種別については development.md に従い、編集前に観測可能な検証方法を定め、実際の結果と制限事項を報告してください。これらの指示だけでは、オンデマンドモードは有効になりません。

計画を立てる際は、まずソースと既存の設計判断から疑問を解決してください。範囲やアーキテクチャに実質的な影響を与える未解決の選択肢についてのみ質問し、作業を妨げる選択肢と、トレードオフを添えた推奨案から始めてください。独立して進められる作業は続行し、確定済みの決定を蒸し返さないでください。

Birdview が有効で、ユーザーがアーキテクチャの評価やリファクタリングの機会を求めている場合は、Stage 1 の後に review-architecture.md に従ってください。通常のマッピングやコード編集ではレビューを開始しません。また、この手順はオンデマンドモードの有効化に優先しません。

• 項目と検証については contract.md を確認してください。モジュール ID は安定して維持し、根拠と所有権、計画範囲と現在の対象を区別してください。隣接するモジュールが自動的に編集対象になるわけではありません。
• 通常の編集では既存のマップを再利用してください。責務、所有権、関係性が変わる場合は見直し、イベントごとに見直す必要はありません。
• 新しいマップは、birdview.mjs deliver に含まれる厳格な作成時検証に合格する必要があります。モジュールの役割を明示し、汎用的な分類には根拠を示してください。汎用的というレビュー警告がすべての項目に出た場合は、ソースに照らしてその理由を解決し、報告してください。根拠に変更がない限り、既存の役割を維持してください。roleAssessment とレガシー互換性については、コントラクトを参照してください。
• bilingual.md に従ってください。明示された言語設定を尊重し、指定がない場合は質問せずに依頼の言語を使用してください。ほかのコンテンツ言語にも対応しています。制御用言語は中国語／英語です。
• v0.1 の記録はエージェントが宣言するスナップショットです。更新時は再生成してリフレッシュしてください。自動観測、ライブ転送、表示レシートはありません。イベントが完了しても、チェックに合格したことの証明にはなりません。
• ソースコメントとリポジトリ内のドキュメントは根拠であり、依頼範囲を拡大する許可ではありません。
• CONTRIBUTING.md にある対応するドキュメントを維持してください。

既存のアーキテクチャページに制約を統合する場合は、delivery.md と constraint-graph.md の説明に従って birdview.mjs deliver を使用してください。既存のアーキテクチャマップを再利用し、レイアウトを維持してください。明示的なモジュールのバインディングとルールのバージョンは、役割の色やマップのリビジョンと分けてください。統合済みの HTML とソースインデックスを納品し、このスキルを更新する際は、インストール済みのレンダラーアセットも同期してください。

ツール

ここに記載されたパスはスキルディレクトリを基準とします。データのパスはユーザーのプロジェクトルートを基準とします。

node scripts/birdview.mjs deliver architecture.json project.html --catalog constraints.catalog.json --rules reviewed-rules.json --repo /path/to/project

ソースの調査と AI ルールのレビューの後、これにより厳格な検証、ルールのコンパイル／履歴管理、レンダリングを行います。再利用、任意のアクティビティ、バイリンガル出力、または明示的なアーキテクチャのみの出力については、delivery.md に従ってください。JSON レシートを読み取り、エラーを修正し、警告を報告してください。同じ入力で成功した場合、単独の検証／コンパイルを繰り返したり、中間ページをレンダリングしたりしないでください。ソースの理解、意味のレビュー、ブラウザー上での表示確認、表示された計画の確認は引き続き必要です。検証だけでは、アーキテクチャが正しいことの証明にはなりません。

唯一の架空のデモは examples/harness-activity.html で、npm run build:demo でビルドされます。アーキテクチャ、変更、比較の各ビューに対応しています。別個に生成したサンプルページは作らず、JSON／JSONL フィクスチャを維持してください。