チーム内のソフトウェアがどのように構築・デプロイ・運用されているかについての質問に答えるスキルです。 **対応する内容:** - システムの定義、実行環境、依存関係、実際の名称（クラウドプロジェクト、クラスター、名前空間、ホスト名、ストレージバケット） - アーキテクチャドキュメント（設計図面）から、それがどこに置かれていようと情報を引き出す **ドキュメント作成のサポート:** 実装に先立ち、各システムが実際には何であるかを明確にするためのインタビューを通じて、ドキュメント執筆を支援します。 **次のような場合に使用:** - 「Xはどのように運用されているのか」 - 「Yとは何か」 - 「Zはどこに配置されているか」 といった質問が出た時 - コンポーネント（機能部品）をデバッグ（不具合調査）する前に、その背景を把握したい時 - アーキテクチャドキュメントを新たに書く、または改善する必要がある時
Answer questions about how a team 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. Also guides writing those docs: an interview that pins down what each system actually is before anything is written. Use when asked "how does X run", "what is Y", "where does Z live", when grounding a component before debugging it, or when asked to write or improve architecture documentation.
アーキテクチャドキュメントは、システムがどのような状態かを説明します。システムがどこで動作し、何に依存し、各要素の実際の名称が何かを記します。ランブック（操作手順書）と組み合わせて使われます。ランブックが手順（障害の診断と解決方法）を担当するのに対し、アーキテクチャは事実（そもそもそのコンポーネントが何であるか）を担当します。両者は互いに参照し合い、一方が他方を丸ごと含むことはありません。このスキルは、ドキュメントから基盤全体に関する質問（あなたが運用しているすべてのシステムと、それらがどこにあるか）に答え、ドキュメント作成もサポートします。
質問に答える — 「Xはどのように動作するか」「Yとは何が通信するか」といった質問を、アーキテクチャドキュメントがどこに置かれていようとも該当するドキュメントにルーティングし、そこから引用を示して答える。一般知識からの回答は行わない。 → references/answer.md
ドキュメントを書く — アーキテクチャドキュメントの作成または拡張を行う。最も重要なのは、何を書く前に「システム名が実際に何を意味するのか」を明確にするインタビュープロセスです。人が使う名前は曖昧であり、境界は所有者が決定する事実であり、AIが推測する事柄ではないからです。 → references/write.md
どちらの役割でも、どのプラグインが存在するかを把握する必要があります。extensionsスキルを読み込み、まず基盤全体をマッピングさせてください。どのプラグインが登録されているか、それぞれがどこにあるか、同期状態は何かを確認します。そのマップを得てから、実際の作業を始めてください。
このステップをスキップしても明らかなエラーは起きません。ただし、基盤の一部分だけを検索して、全体であるかのように報告してしまうことになります。
アーキテクチャドキュメントは4つの場所に存在でき、同じシステムが複数の場所に記載されることもあります。references/where-docs-live.mdがこれを管理します。各場所の用途、到達方法、何が見えないか、また読み書きする順序を説明しています。どちらの役割でも、場所を想定するのではなく、このファイルから情報を得て作業を進めます。
アーキテクチャドキュメントが機能するには、小さな構造規約に従う必要があります。
この規約はreferences/format.mdに定義されています。コーパス（ドキュメント集合）が独自の FORMAT.md を持つ場合、そちらが優先されます。references/concerns.mdでは、繰り返し現れる関心事項（デプロイメント、データベース、イベントなど）と、各ファイルが答える質問をカタログ化しています。references/examples/には、詳細さの基準を合わせるための完全な作業例があります。
診断と修正（これはその障害を担当するランブックの責任。runbooksスキルがそこにルーティングします）、現在のランタイム状態（レプリカ数、フラグ値など。ドキュメントはそれらが存在する場所を指します）、プロダクトおよびコードレベルのドキュメント（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) — and each side chains to the other rather than absorbing it. This skill answers estate questions (the estate: everything you run and where) from those docs, and guides writing them.
Both jobs need to know which plugins exist. Load the extensions skill and have it
map the estate first — which plugins are registered, where each lives, and their sync
state. Come back with that map, then start the job.
Skipping it doesn't fail loudly. It just means you searched the local half of the estate and reported it as the whole.
Architecture docs live in four places, and the same system can be documented in more than one. references/where-docs-live.md owns them: what each place is for, how to reach it, what it cannot show you, and the order to read and write in. Both jobs work from that file rather than assuming a location.
Architecture docs work when they follow a small structural spec — systems are directories (one per thing responders reason about separately, regardless of repo layout), views are root files answering one cross-system question, estate services (observability, the data platform, CI) are directories whose README routes across their tools, the README is the map, and churny values are pointed at rather than copied. The spec lives in references/format.md; a corpus may carry its own FORMAT.md, which takes precedence. references/concerns.md catalogs the recurring concerns (deployment, database, events, …) and the questions each file answers, and references/examples/ is a complete worked example corpus to calibrate depth against.
Diagnosis and fixes (that's the runbook that owns the failure — the runbooks skill
routes to it), 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 による自動翻訳です。