mcpField
A
architect

architect

github.com/thebeardedbearsas開発107202 回インストール2 日前に更新
リポジトリ

architect について

TDD を行う開発者向けに、テストやコードを書く前にアーキテクチャ仕様を作成するスキルです。境界、契約、依存関係、設計上のトレードオフ、アーキテクチャテストを順に整理します。

主な機能

  1. 01機能がまたぐアーキテクチャ境界の特定
  2. 02境界の入出力と副作用の定義
  3. 03依存関係の図示と方向の確認
  4. 04トレードオフと簡易 ADR の記録
  5. 05アーキテクチャテストの事前計画

活用シーン

  1. 01複数ファイルにまたがる機能の設計
  2. 02新しいモジュールや境界づけられたコンテキストの計画
  3. 03技術移行や外部連携の準備
  4. 04TDD 前の設計・実装タスクの分割

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/thebeardedbearsas/claude-craft --skill architect

インストール後、Claude Code で/architectを入力して読み込まれたか確認します。

詳細

Architect — TDD 前のアーキテクチャフェーズ

obra/superpowers に着想を得たスキルです。目的： テストやコードを1行でも書く前に、アーキテクチャ仕様を作成します。

黄金律： 図を描けないなら、その機能はコーディングできません。

使用するタイミング

状況Architect フェーズ？
1ファイルのバグ❌ いいえ（そのまま TDD へ）
3ファイル未満の新機能⚠️ 短時間（10分）
3ファイルを超える新機能✅ 必須
新しいモジュール／境界づけられたコンテキスト✅ 必須
技術的な移行✅ 必須
外部連携（API、MQ、DB）✅ 必須

5つのステップ

1. 境界を特定する

この機能はどの境界に関わりますか？

  • ドメイン境界 — 関わる境界づけられたコンテキストは？
  • レイヤー境界 — Presentation / Application / Domain / Infrastructure？
  • プロセス境界 — 同期 HTTP / 非同期キュー / イベント駆動？
  • データ境界 — どのデータベース、どのテーブル？
  • オーナーシップ境界 — どのチームがどの部分を所有する？

成果物： またぐ境界の一覧。

2. コントラクトを定義する

またぐ境界ごとに、コントラクトを定義します。

  • 入力：形式、型、不変条件、null 許容性
  • 出力：形式、エラーコード、目標レイテンシ
  • 副作用：DB への書き込み、発行するイベント、外部呼び出し
  • 冪等性：コントラクトは冪等ですか？
  • トランザクション：アトミックですか？ 最終的整合性ですか？

成果物： 関数／エンドポイントのシグネチャ + DTO。

3. 依存関係を図にする

何が何に依存していますか？ 依存の向きは？

[HTTP Controller] ──▶ [Use Case] ──▶ [Domain Service]
                                          │
                                          ▼
                                     [Repository] (interface)
                                          │
                                          ▼
                        [Postgres Adapter] ─implements─▶

確認事項：

  • 循環がない（A → B → A）
  • DIP が守られている（ドメインがインフラに依存しない）
  • 入口から業務ロジックまでの呼び出し階層が3段を超えない

成果物： 図（Mermaid、ASCII、または構造化テキスト）。

4. トレードオフを列挙する

自明でない判断について、なぜその選択をしたのかを記録します。

判断検討した代替案この選択をした理由
キュー経由の非同期処理同期 HTTPレイテンシが500msを超え、即時性が重要ではない
CQRSシンプルな CRUD読み取り／書き込み比率が20:1
イベントソーシング状態の保存法的監査の要件

成果物： 簡易 ADR（箇条書き3〜5項目）— 重大な判断に関する正式な ADR については .claude/rules/10-documentation.md を参照してください。

5. アーキテクチャテストを定義する

振る舞いに対する TDD の前に、アーキテクチャテストを定義します。

  • 依存関係のテスト（ArchUnit、Dephpend、deptrac）
  • コントラクトテスト（OpenAPI 検証、コントラクトテスト）
  • 目標性能のテスト（p99 レイテンシ、スループット）
  • 該当する場合はマルチテナント分離テスト

成果物： TDD フェーズで作成するアーキテクチャテストの一覧。

成果物

Architect フェーズの終了時に、以下を作成します。

  1. 依存関係図（最大1ページ）
  2. 境界のコントラクト（シグネチャ + DTO）
  3. 主要なトレードオフをまとめた簡易 ADR
  4. アーキテクチャテストの一覧
  5. アトミックなタスクへの分割（スキル atomic-tasks を参照）

TDD（Red/Green/Refactor）に進むのは、その後です。

アンチパターン

アンチパターン解決策
図を描かずに直接コーディングする先に描く。5分でも十分です
シンプルな機能に Architect フェーズで2時間以上かけるYAGNI — 手短に済ませる
曖昧なコントラクト（「User オブジェクト」）厳密な型を使い、すべてのフィールドを定義する
トレードオフを無視する簡易 ADR を必須にする
閉鎖的なアーキテクチャペアレビュー、またはサブエージェント @tech-lead によるレビュー

Claude Craft との連携

  • /workflow:design — デフォルトでこのスキルを使用します
  • エージェント @tech-lead — Architect の成果物を作成できます
  • 正式な ADR：/common:architecture-decision を参照してください
  • Rule 04 SOLID + Rule 17 CQRS + Rule 14 Multitenant — 状況に応じて参照してください

Ressources

  • obra/superpowers
  • Rule .claude/rules/04-solid-principles.md
  • Rule .claude/rules/10-documentation.md (ADR)
  • Skill atomic-tasks

Date de dernière mise à jour : 2026-04-15 Version : 1.0.0

コメント

Markdown 対応