Communityコーディング&開発github.com

堅牢アーキテクチャ

具体的なフロー、不変条件、所有権、障害エビデンスからソフトウェアアーキテクチャを設計または検証します。新規システム設計、不明確なモジュール境界、横断的バグクラスタ、または状態、権限、履歴、外部影響契約の変更に使用します。通常のローカル修正はローカルに留めます。すべての編集に必須のアーキテクチャ儀式ではありません。

堅牢アーキテクチャ とは?

このスキル「Robust Architecture(堅牢アーキテクチャ)」は、ソフトウェアシステムのアーキテクチャを、具体的な証拠とトレーサブルな決定に基づいて設計・検証するためのガイドです。 主な目的は、最小限の設計で保証を説明可能かつ挑戦可能にすることです。 このスキルは、システムの実際のエントリポイント、呼び出し元、状態ストアを調査することから始め、所有権のギャップ、境界欠陥、製品ギャップ、表示/ローカル欠陥の4つの介入レベルを定義します。 不変条件には論理的な権限(所有者)を割り当て、そのルールを強制できる場所に配置することを重視し、データの所有権、履歴、導出ルールの明確な管理を要求します。 また、完全な成果をトレースし、アトミック性、非同期境界、障害回復を考慮した設計を推奨し、常に反証を試みることで堅牢性を高めます。 Markdownファイルとして提供されており、すべてのAIエージェントプラットフォーム(Claude Code、Cursor、Codexなど)で直接利用可能です。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/pkasarda/skills/tree/HEAD/skills/robust-architecture

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

堅牢アーキテクチャ は何をしますか?

保証を説明でき、挑戦できる最小の設計を生成する。ルールは判断を導くものであり、正しさを認証するものではない。有用なアーキテクチャは、重要な事実を明示し、ルールに権威のある居場所を与え、何かが失敗したり変更されたりしたときでも理解可能であり続ける。

結果から始める

既存システムの場合、図や以前の提案を信頼する前に、実際のエントリポイント、呼び出し元、状態ストア、チェックを調査する。新規システムの場合、要件と前提を区別し、コンポーネントを選択する前に最初の実際のフローを記述する。

決定を変更する制約のみを記録する:ユーザーと権限、運用ボリューム、レイテンシまたはリソース予算、可用性、障害条件、リカバリと耐久性のニーズ、デプロイ制約、チームが運用可能なもの。正しさを変更する場合、欠落している製品選択を問い合わせる。その選択が未解決の間は、独立したリバーシブルな作業を継続する。

介入を調整する:

  • モデル/所有権ギャップ: 必要な事実、完全な操作、または一貫した権限が存在しないか、分割されている。その契約を、その読み取り側にパッチを当てる前に解決する。
  • 境界欠陥: 適切な所有者が存在するが、呼び出し元がそれを迂回しているか、その実施が不完全である。その所有者を強化または使用する;層をまたいだ欠陥は、それ自体では新しいアーキテクチャを必要としない。
  • 製品ギャップ: 必要な振る舞いが未決定である。具体的な結果と最小限の選択肢を提示し、黙って選択しない。
  • 表示/ローカル欠陥: 正しい基礎的事実が、ローカルなレンダリング、解析、またはコピー修正を必要としている。通常のローカル修正を適用し、ここでアーキテクチャワークフローを停止する。

大きなファイル、重複する構文、欠落したパターン名、または提案されたパッケージは、それ自体ではモデルギャップの証拠にはならない。

保護されたリソースへのアクセスを伴う設計またはレビューの場合、インストールされていれば認可を適用する。それがアクセスポリシーのウォークスルーを所有する;このスキル単独で使用する場合は、以下のローカルな所有権と信頼ルールを維持する。

事実とルールに居場所を与える

事実または不変条件、その論理的な権限、およびそれを変更できる操作に名前を付ける。権限は、ローカル関数、ファイル発行者、ライブラリハンドル、プロセス、またはサービスであり得る;サーバーや新しいモジュールである必要はない。

  • ルールを、関連するすべてのプロデューサーに対してそれを強制できる場所に配置する。エントリアダプターは、呼び出し元の信頼を確立し、入力を解析し、その所有者を呼び出し、結果を変換する。有用な早期チェックはフィードバックを改善する;権威あるチェックは実際の効果を保護する。
  • 共有データを誰が所有するかを明示的にモデル化する。欠落した親またはスコープ値は、自動的にグローバル権限にはならない。目に見える制御だけでなく、アクターの実際のポリシーを読み取り、シリアル化、および効果に適用する。
  • 現在の関係、不変の発生事実、および射影を分離する。機能が実際に必要とする履歴またはスナップショットを保存する。現在の関係は、欠落した過去の事実を再構築できない;未知のレガシー履歴を正直にマークする。
  • リトライにその操作IDを与える。2つの同一のペイロードは、別々の意図である可能性がある。リトライの正しさが重要である場合、現在の権限の下で、キースコープ、不整合な再利用、保持、およびリプレイを定義する。
  • 導出されたルールと表現には、コンシューマーが同意しなければならない1つの維持された定義を与える。オーディエンス、コホート、単位、時間の意味の間の意図的な違いを保持する。共有が人工的な依存関係を生み出す場合、安価なローカル表示の重複を維持する。
  • 明示的に指定されたマルチライターまたはオフライン設計は有効である。単一の物理ライターが常に強制できると想定するのではなく、競合セマンティクス、調整、およびパーティション動作に名前を付ける。

境界は、決定を隠蔽し、呼び出し元から知識を取り除くことによって、その存在価値を得る。これを直接確認する:変更後、どの呼び出し元がルール、ストレージレイアウト、または順序付けを知らなくなるか?すべての呼び出し元が同じビジネスステップを調整するようにさせるラッパーは、所有権を移動させていない。

完全な成果を所有する

1つの意図をその重要な効果を通してトレースする。一緒に成立しなければならないもの、権威ある完了ポイント、およびそのポイントの前後で実行が停止した場合にユーザーが受け取るものを述べる。

キャッシュやバックグラウンドコールバックを含む、すべての観測可能な公開を列挙する。非同期作業の場合、結果が属する操作、ID、バージョン、ライフタイムを特定し、関連する各公開境界で適用可能性をチェックする。遅延ビューチェックは、以前のキャッシュまたはストア書き込みを保護できない。コンシューマーのキャンセルと、すでにコミットされたビジネス効果の取り消しを区別する。

1つの権限内で不可分性を必要とする不変条件には、実際のアトミックプリミティブを使用する。並行ライターが以前の読み取りを無効にする可能性がある場合、効果または同等のシリアル化において、該当するスコープ、状態、およびバージョンを強制する。メカニズムを到達可能なインターリーブに一致させる;シングルスレッドの純粋な変換は、データベーススタイルの並行性メカニズムを必要としない。

ネットワーク、プロセス、ファイル、または非同期境界では、境界チェックを読む。該当するブランチを選択する:持続効果、リソースライフタイム、リアルタイムワーク、または状態/履歴。ローカルトランザクションは外部効果をアトミックにしない;未知の結果は必ずしも失敗ではない。リトライを追加する前に、リカバリと真実のペンディング/部分的な結果を定義する。

再利用可能なAPIの場合、入力、出力、拒否、所有権、およびクリーンアップ責任を明示的にする。意味のあるエラー/制御フローの区別を保持する。保護されたデータを公開せずに障害を説明できる場所に診断情報を配置する;ログはリカバリメカニズムでも、認可/履歴データベースでもない。

比例した構造を選択する

既存の一貫したモジュールとサポートされているプラットフォームメカニズムを優先する。新しい小規模アプリケーションでは、いくつかの適切に境界設定された関数またはモジュールで十分な場合がある。具体的な要件が独立したスケーリング、障害分離、ランタイム制約、または組織的な所有権を必要とする場合に、別個のデプロイまたはインフラストラクチャを導入する。意味のあるトレードオフを説明しながら、明示的に選択されたプラットフォームを尊重する。

もっともらしい代替案と並べて、最小の変更を評価する。正しさ、リソース/運用コスト、および可逆性における重要な違いを説明する。各設計決定を1つの居場所に保つ;安定した有用なシームのみを独立して抽出する。物理フォルダ、パッケージ、サービスは、証明を提供するのではなく、証明された境界に従う。

配置の変更全体にわたって、不変条件全体を保持する。移行とロールアウトは、既存のデータ、古い/新しいライター、パブリックコンシューマー、およびロールバック互換性を考慮しなければならない。カラム、API、またはリソースの削除には、その義務とコンシューマーが終了したという証拠が必要である。

反証を試みる

論争中の境界を行使する、薄い垂直スライスを選択する。主張に関連する実際のストレージ、ファイル、プロトコル、またはリソースシームを使用する;真の外部依存関係のみを分離する。実装がない初期設計の場合、識別実験を指定し、その結果を未知のままにしておく。

関連する障害で不変条件に挑戦する:誤った権限、古い状態、繰り返しまたは順序変更された作業、完了境界でのクラッシュ、キャンセル、欠落/曖昧な履歴、および実際の負荷またはタイミング制限。ルールを区別する場合、明示的なデコイと制御されたインターリーブまたはクロックを使用する。テストは、そのルールが削除されたときに失敗するべきであり、モックされた呼び出しを数えたり、選択された名前を認識したりするだけでは不十分である。

安全性 と 進行をチェックする:有効な操作がどのように最終的に完了するか、または正直な拒否を与えるか;ペンディング中の作業がどのようにリカバリされるか;メモリ、キュー、接続、レイテンシがどのように有界に保たれるか。これらのチェックを運用エンベロープから選択し、すべての理論上の失敗をリハーサルしない。

それが機能すると主張する場合、マウントされた/ユーザーまたはパブリックライブラリのフローを観察する。ユニットアサーション、図、グリーンリトライ、ベンチマーク推測、および合成フィクスチャは、それら自身のテストされた境界のみを確立する。測定結果、ソースの発見、前提、欠落した決定、および未実行の証明を分離する。

レビュー可能な決定を提供する

出力を決定に合わせてスケーリングする。実質的な設計の場合、以下を提供する:

  1. 具体的なフロー、制約、および重要な未知事項。
  2. 不変条件、名前付き権限、および影響を受けるプロデューサー/コンシューマー。
  3. 状態/履歴、信頼、完了および障害の境界。成功と失敗をトレースするのに十分な契約。
  4. 選択された小さな構造、関連する代替案、およびなぜトレードオフが適合するか。
  5. 観測可能な受容、リカバリ、および進化/ロールアウトチェックを備えた最初の1スライス。
  6. 準備ができているもの、製品決定または証明が必要なもの、および実際に検証されたもの。

境界を明確にする場合にのみ、小さな図を使用する。ローカル修正のために空のテンプレートセクションをスキップする。ユーザーのスコープを保持する:設計/レビュー要求は決定を生成し、実装、移行、デプロイ、公開、またはライブデータの変更の許可ではない。

このスキルを採用または評価する場合、評価プロトコルを参照すること。主要な背景は基礎にリストされている;それは個々の設計を検証するのではなく、推論に情報を提供する。

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

関連スキル