アーキテクチャドキュメント（システムの構成図）を作成・管理するスキルです。 各システムが何であるか、どこで動作するか、何に依存しているか、そしてクラウドプロジェクト・クラスター・ネームスペース・ホスト名・ストレージなどの実際の名前を記録します。 最初の重要なステップは、各システム名が具体的に何を指しているのかをしっかり確認するためのヒアリング（対話を通じた確認）です。これを行った上で、ドキュメント作成に進みます。 **次のような場合に使用:** - アーキテクチャドキュメントの作成・拡張・改善が必要な場合 - 新しいシステムを記録したい場合 - 既存の「アーキテクチャ」スキルでは答えられなかった項目を埋める必要がある場合
Write and maintain architecture docs — the documents that say what each system is, where it runs, what it depends on, and the real names of things (cloud projects, clusters, namespaces, hostnames, buckets). The heart of it is an interview that pins down what each system name actually means before anything is written. Use when asked to write, extend or improve architecture documentation, to document a system, or to fill a gap the `architecture` skill could not answer.
アーキテクチャドキュメント（システムの構成に関する技術文書）は、システムの実態を記述します。どこで動いているのか、何に依存しているのか、そして物の実際の名前が何なのか——こうした情報です。ドキュメントはランブック（トラブル対応手順書）と一対で機能します。ランブックは手順（障害の診断と修復の方法）を担当し、アーキテクチャドキュメントは事実（コンポーネントとは何か）を担当します。両者は相互に参照し合い、一方がもう一方を吸収するのではなく分担します。このスキルは、こうしたドキュメントの作成と保守を行います。既存ドキュメントから質問に答えるのはarchitectureスキルの役割です。すべての執筆は、ここから始まります。何かを書く前に、まず既存の内容を検索するのです。
以下の2つを、他のすべてに先立って実行してください：
extensionsスキルを読み込んで、システム全体を把握する：どのプラグインが登録されているか、それぞれどこに置かれているか、同期状態はどうかを確認します。
architectureスキルを読み込んで、対象範囲内のシステム名ごとに検索を実行する：アーキテクチャドキュメントが存在するあらゆる場所を検索します。見つかったものが全体の方向性を決めます。既存のドキュメントがあれば、新規作成ではなく拡張することになります。
この手順を省略しても、目立たしい失敗にはなりません。ただし、どこかに既に存在するドキュメントの複製を、誰も見ていない場所に作成してしまうだけです。
アーキテクチャドキュメントの作成、または拡張を行います。中核となるのは、何かを書く前にシステム名が実際に何を意味するのかを明確にするインタビュープロセスです。人々が使う名前は曖昧であり、システムの境界は所有者の意思決定であって、AIエージェントが推論できるものではありません。
詳細は → references/write.md
新しいドキュメントの配置先と、そこに確実に見つけてもらうための確認方法は references/homes.md にあります。
アーキテクチャドキュメントが機能するには、小さな構造規約に従う必要があります：
この規約は references/format.md に記載されています。個別のドキュメント群がFORMAT.mdを持つ場合、そちらが優先されます。
references/concerns.md では、繰り返し現れる関心事（デプロイメント、データベース、イベント処理など）と、各ファイルが答えるべき質問をカタログ化しています。
references/examples/ では、完全な実例から深さのレベルを判断できます。
既存ドキュメントからの質問への回答（それはarchitectureスキルの役割）、障害の診断と修復（その障害に関するランブックが担当）、実行時の現在の状態（レプリカ数やフラグの値——ドキュメントはそれらの在り処を指すだけ）、製品やコードレベルのドキュメント（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
writes and maintains those docs. Answering questions from them is the architecture
skill's job, and every write starts there: you search what already exists before
writing anything.
Do both of these before anything else here:
extensions skill and have it map the estate: which plugins are
registered, where each lives, and their sync state.architecture skill and follow it through its search for each system
name in scope. It searches every place architecture docs can live. What it finds
shapes the whole job: an existing doc means extending it, not writing a sibling.Skipping them doesn't fail loudly. It just means you wrote a second copy of a doc that already existed, somewhere nobody looked.
Author or extend architecture docs. The heart of it is an interview that resolves what system names actually mean before anything is written: the names people use are ambiguous, and boundaries are decisions the owner makes, not facts an agent infers. → references/write.md
Where the new docs go, and how to check they will be found, is references/homes.md.
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.
Answering questions from existing docs (that's the architecture skill), 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 による自動翻訳です。