組織がソフトウェアをどのように構築・展開・運用しているかについての質問に答えます。アーキテクチャドキュメント（設計・構成図）からの情報を活用して、システムが何であるか、どこで動いているか、何に依存しているか、そして実際の名称（クラウドプロジェクト、クラスタ（複数コンピュータの集合体）、名前空間、ホスト名、ストレージ領域など）に関する質問に答えます。 **次のような場合に使用:** - 「Xはどのように動いているのか」 - 「Yとは何か」 - 「Zはどこにあるのか」 - デバッグの前に、ある機能がシステム内のどこに位置し、どのように接続されているかを確認する場合
Answer questions about how the organisation builds, deploys, and runs its software — what a system is, where it runs, what it depends on, and the real names of things (cloud projects, clusters, namespaces, hostnames, buckets) — from architecture docs wherever they live. Use when asked "how does X run", "what is Y", "where does Z live", or when grounding a component before debugging it.
アーキテクチャ資料は、システムが「どのような状態か」を説明します。どこで動作しているか、何に依存しているか、そして実際の名称を記載します。これらはランブック（運用手順書）と対になっており、ランブックは「手順」（障害の診断と修復方法）を、アーキテクチャは「事実」（そのコンポーネントそのもの）を担当します。このスキルは、これらの資料から引用して、環境についての質問（環境＝あなたが運用するすべてのシステムとその場所）に答えます。一般的な知識からは答えません。これらの資料が存在するのは、正にそのためです。チームのセットアップは既定値から異なっており、その異なる部分こそが、記録する価値のあるものです。
あなたは incident.io のスキルを備えたコード実行エージェントです。
開始する前に： extensions スキルを読み込み、環境全体を把握させます。どのプラグインが登録されているか、それぞれがどこにあるか、その同期状態を確認します。これをスキップしても大きなエラーは出ません。ただし、環境の一部だけを検索して全体だと報告することになります。
検索する場所： where-docs-live.md に記載された4つの場所を、その順序で検索します。記載場所がわかっていると思っても、検索前に必ず読んでください。
ライブ設定の場所： ワークスペースです。
資料に記載漏れがある場合： ユーザーが今すぐ埋めてほしいなら、architecture-author スキルを使用してください。
質問が実は「この障害をどう修復するか」の場合： runbooks スキルに引き継ぎます。このスキルの検索機能が症状から該当するランブックへのルーティングを担当します。
回答の方法： talking-to-the-user スキルが設定する話し方に従います。答えを最初に述べ、簡潔に、次のステップが必要なら1つだけ提示してください。
質問を、対象となるシステムまたは識別子（サービス名、ホスト名、クラスタ、バケット、デプロイメント）に絞ります。文字列そのままの識別子（キーワード検索や grep 用）と、質問の言い方（意味的な検索用）の両方を記録します。
上記の場所を、その順序で検索します。各コーパス（資料の集合）は README から始めてください。きちんと整理されたコーパスなら「どこを見ればよいか」というルーティング表があり、ほとんどの質問が1段階で解決します。マップ（ルーティング表）を試すより先にツリーを grep してはいけません。マップこそが、所有するファイルを1段階で見つけるためのものです。マップで見つからない場合だけ grep を使用してください。検索結果にはソースプロバイダ（出所）と自動生成タグが付きます。アーキテクチャ関連の資料は、手順ではなくシステムと基盤を説明します。
識別子は字句通り引用してください。 プロジェクト ID、クラスタ名やプール名、ホスト名、サブスクリプション名など。言い換えられた識別子は、ないに等しいです。
各事実の出所となった資料を引用します。 また、その資料に名前が記載されている確実な設定リポジトリも示します。
資料が意図的に記載していないことを尊重してください。 レプリカ数、リソース上限、マシンタイプ、現在のフラグ状態など、変動する値は、引用ではなく「どこにあるか」を示します。上述のライブ設定がその値を持つなら、読んでどこから来たか説明してください。資料が約束したことのない数字を答えてはいけません。
短く保ってください。 ほとんどの質問は数文と1〜2つの資料参照で解決します。
まずそれが本当かを確認してください。到達できなかった場所は、資料がない場所ではありません。到達できないコーパスを記載漏れとして報告すると、実は存在する資料を書くよう誰かに指示することになります。検索できなかった場所を明示してください。
本当に記載漏れなら、明確にそう述べます。他の証拠がある場合はそこから答えます。デプロイメントマニフェスト、サービス定義、設定、関連システムの一覧など。資料ではなく「どこから来たか」を明記して、一般的な知識で資料の不足を黙って埋めてはいけません。
その後、その記載漏れをキュレーション（資料整備）の候補として記録します。資料で答えられなかった質問は、書かれるのを待つセクションです。「あなたの環境について」の記述に従って対応してください。
常に読み取り専用：このスキルは説明するだけです。状態を変更するミューテーション、フラグ切り替え、コマンド実行は決して行いません。
吸収しない、ルーティングする：質問が本当は「この障害をどう修復するか」なら、ここでコンポーネントを確認した上で、「あなたの環境について」に従って引き継ぎます。
アーキテクチャ資料の作成・保守、障害の診断と修復（その障害を担当するランブック）、実行時の現在の状態（レプリカ数、フラグの値など。資料はこれらがある場所を示します）、製品またはコード関連のドキュメント（API リファレンス、ユーザーガイド）。
Architecture docs describe what systems are: where they run, what they depend on, and the real names of things. They pair with runbooks — runbooks own procedures (how to diagnose and fix a failure), architecture owns facts (what the component is in the first place). This skill answers estate questions (the estate: everything you run and where) from those docs, cited — never from general knowledge. General knowledge is exactly what these docs exist to override: a team's setup differs from defaults in precisely the ways worth writing down.
You are a coding agent with incident.io's skills.
extensions skill and have it map the estate — which
plugins are registered, where each lives, and their sync state. Skipping it doesn't
fail loudly. It just means you searched the local half of the estate and reported it
as the whole.architecture-author skill.runbooks skill. Its Find job owns routing a symptom to its runbook.talking-to-the-user skill sets — lead with the
answer, be concise, one next step where there is one.Reduce the question to the system or identifier it is about: a service name, a hostname, a cluster, a bucket, a deployment. Keep both the literal identifier (for keyword search and grep) and the question phrasing (for semantic search).
Search the places above, in their order. Start each corpus at its README — a well-formed corpus has a "Where do I look?" routing table that resolves most questions in one hop. Do not grep the tree before trying the map; the map exists so one hop finds the owning file. Grep only when the map misses. Document search results carry a source provider and generated tags; architecture-shaped documents describe systems and infrastructure rather than procedures.
First make sure that is what happened. A place you couldn't reach is not a place with no docs, and reporting an unreachable corpus as a missing one sends someone to write a document that already exists. Name what you couldn't search.
Once it's genuinely a gap, say so explicitly. Answer from other evidence when you have it — deploy manifests, service definitions, config, a connected system's own listing — clearly labelled with where it came from, not the docs. Never silently substitute general knowledge for a missing doc.
Then note the gap as a curation candidate: a question the docs could not answer is a section waiting to be written. Handle it as "Where you are running" says.
Writing or maintaining architecture docs, diagnosis and fixes (the runbook that owns the failure), current runtime state (replica counts, flag values — the docs point at where those live), and product or code-level documentation (API references, user guides).
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。