シニアデベロッパーは、時間の経過とともにスケールし、保守可能なシステムを設計することに苦労しています。このスキルは、エンタープライズグレードのアプリケーションを構築するためのアーキテクチャパターン、システム設計ワークフロー、および技術的決定フレームワークを提供します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「senior-architect」を使用しています。 リアルタイム在庫管理で1日10万件の注文を処理するEコマースプラットフォームを設計する
期待される結果:
- 推奨アーキテクチャ: イベント駆動型マイクロサービス
- コアコンポーネント: API Gateway、注文サービス、在庫サービス、決済サービス、通知サービス
- データベース戦略: トランザクションデータにはPostgreSQL、キャッシュにはRedis、読み取り専用レプリカを分離
- スケーラビリティ: Kubernetesを使用した水平スケーリング、CPU/メモリに基づく自動スケーリング
- セキュリティ: JWT認証、APIレート制���、入力検証、SQLインジェクション防止
「senior-architect」を使用しています。 大規模なエンタープライズダッシュボードアプリケーション向けのReact vs Vue vs Angularを比較する
期待される結果:
- 推奨: エンタープライズダッシュボードにはReact
- 理由: より大きなエコシステム、より多くの人材プール、柔軟なアーキテクチャ、強力なエンタープライズサポート
- 考慮事項: チームの学習曲線、状態管理のニーズ、長期的な保守
セキュリティ監査
安全Security audit completed. Static findings are false positives: external_commands (33) triggered by markdown code blocks, filesystem access is legitimate output functionality, sensitive finding is standard .env setup. No actual security risks identified. Skill is safe for marketplace publication.
中リスクの問題 (3)
低リスクの問題 (2)
品質スコア
作れるもの
新しいSaaSプラットフォームのアーキテクチャ設計
フロントエンド、バックエンド、データベース、インフラストラクチャの選択を含む、新しいマルチテナントSaaSアプリケーションのアーキテクチャを設計します
既存のシステム設計のレビュー
既存のコードベースを分析し、スケーラビリティと保守性のためのアーキテクチャ改善を提供します
テクノロジース���ックの選択
要件、チームの専門知識、長期的な保守性に基づいて、プロジェクトに適したテクノロジーを評価・選択します
これらのプロンプトを試す
I need to design a [type of application] that handles [number] users. What architecture patterns would you recommend? Consider [specific requirement].
Design a system architecture for a [description of system]. Include: 1) Component diagram 2) Data flow 3) API design 4) Database schema 5) Security considerations. The system must handle [scale requirements].
I am building a [application type] with these requirements: [list requirements]. Compare [Technology A] vs [Technology B] vs [Technology C] for the [component]. Recommend the best choice with rationale.
Review the architecture of my existing [system description]. Identify: 1) Scalability bottlenecks 2) Security vulnerabilities 3) Maintainability issues 4) Performance concerns. Provide specific recommendations for improvement.
ベストプラクティス
- アーキテクチャを選択する前に要件から始める - 最初にスケール、複雑さ、チームの能力を理解する
- アーキテクチャ決定記録(ADR)を使用して、長所、短所、トレードオフを含めてアーキテクチャ決定を文書化する
- 障害に備えた設計 - コンポーネントの障害を計画し、優雅なデグラデーション戦略を持つ
回避
- 早期の過剰エンジニアリング - モノリスとして機能可能なシンプルなアプリケーションにマイクロサービスパターンを適用しない
- 非機能要件の無視 - パフォーマンス、セキュリティ、スケーラビリティは最初から考慮する必要がある
- テクノロジーの飛び移り - テックスタックを頻繁に切り替えると技術的負債が発生し、デリバリーが遅くなるため避ける