アーキテクチャドキュメント（システム構成の設計書）を作成・管理します。各システムが何であるか、どこで動作するか、何に依存しているか、そして実際の名称（クラウドプロジェクト、クラスタ、ネームスペース、ホスト名、バケットなど）を記述する文書です。 このスキルの中核は、実際に文書を書く前に、各システムの名称が具体的に何を意味するのかを明確にするインタビュープロセスです。これにより、曖昧性を排除した正確なドキュメントを作成できます。 **次のような場合に使用:** - アーキテクチャドキュメントの作成、拡張、改善を依頼する時 - システムをドキュメント化する必要がある時 - 他のアーキテクチャスキルでは答えられない情報ギャップを埋める時
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.
アーキテクチャドキュメント（構成図説）は、システムが「何であるか」を説明するものです。どこで動作しているか、何に依存しているか、そして実際の名称などです。このスキルは、こうしたドキュメントを作成・管理します。既存のドキュメントから質問に答えるのは「アーキテクチャ」スキルの役割であり、何か書く前には必ずそこから始まります。まず既存のものを検索してから、新しい内容を書きます。
ここから先の作業に入る前に、この2つを必ず行ってください：
「extensions」スキルを読み込んで、全体像を把握する: どのプラグインが登録されているか、それぞれがどこにあるか、同期状況はどうかを確認します。
「architecture」スキルを読み込んで、対象となる各システム名について検索する: アーキテクチャドキュメントが存在する可能性のあるすべての場所を検索します。見つかったものが今後の作業全体を左右します。既存のドキュメントがあれば、新規作成ではなく拡張することになります。
この2つをスキップしても明らかなエラーは出ません。ただ、どこかに既に存在する同じドキュメントの複製を、誰も見ていない場所に作ってしまうだけです。
アーキテクチャドキュメントを新規作成、または拡張します。その核となるのは「対話型のインタビュー」です。実際に何を書く前に、システム名が本当は何を意味しているのかを明確にします。人々が使う名称は曖昧で、システムの範囲は技術者が推測するものではなく、所有者が決める判断だからです。
新しいドキュメントをどこに配置するか、そして確実に見つかるようにするには、references/homes.mdを参照してください。
アーキテクチャドキュメントが機能するには、小さな構造仕様に従う必要があります：
この仕様は references/format.md に記載されています。また、個別のドキュメント群が独自の FORMAT.md を持つ場合は、それが優先されます。 references/concerns.md では、繰り返し現れるテーマ（デプロイメント、データベース、イベント など）と、各ファイルが答えるべき質問を一覧にしています。references/examples/ には、深さの基準を合わせるための完全な実例が載っています。
既存ドキュメントから質問に答える（それは「アーキテクチャ」スキルの仕事）、問題診断と修復（その責任は該当する手順書にある）、実行時の現在の状態確認（レプリカ数、フラグの値など──ドキュメントはそれらの位置を指し示すだけ）、製品やコードレベルのドキュメント（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 による自動翻訳です。