組織がソフトウェアをどのように構築し、配置し、運用しているかについての質問に答えます。システムが何なのか、どこで実行されるのか、何に依存しているのか、そして具体的な名前（クラウドプロジェクト、クラスター、ネームスペース、ホスト名、バケット）を、アーキテクチャドキュメント（システム設計書）から提供します。 次のような場合に使用： - 「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スキルが設定した話し方に従います。答えから始め、簡潔に、次のステップがあればそれをひとつ示します。
質問をシステムまたはその識別子（サービス名、ホスト名、クラスタ、バケット、デプロイメント）に絞り込みます。リテラル識別子（キーワード検索と 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 による自動翻訳です。