カスタムユーティリティやヘルパー関数を再発明するのをやめましょう。このスキルでは、保守性が高くスケーラブルなコードを書くためのクリーンアーキテクチャとドメイン駆動設計の原則を教你します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「software-architecture」を使用しています。 このUserServiceクラスをアーキテクチャの問題についてレビューしてください：[ データベースクエリ、API呼び出し、UIレンダリングがすべて混在したUserServiceクラス ]
期待される結果:
検出されたアーキテクチャ問題：1) 混合された関心事 - データベースクエリはリポジトリレイヤーに属する、2) UIレンダリングは別のビューコンポーネントにあるべき、3) API呼び出しは専用サービスにあるべき。推奨リファクタリング：UserRepository（データ）、UserService（ビジネスロジック）、UserView（プレゼンテーション）に分割。
「software-architecture」を使用しています。 決済処理を実装する必要があります。自行uildするか、ライブラリを使用しますか？
期待される結果:
推奨：StripeまたはPaddleを使用し、カスタム決済処理を構築しないでください。これらのサービスはPCIコンプライアンス、請求定期処理、Webhook、月単位で構築する必要があるエッジケースを処理します。既存のソリューションが満たすことができない非常に独特な要件がある場合のみ、カスタム実装を検討してください。
「software-architecture」を使用しています。 Eコマースアプリの注文処理モジュールを設計してください
期待される結果:
推奨アーキテクチャ（DDD）：1) エンティティ（ドメイン）：Order、OrderItem、OrderStatus。2) リポジトリ：OrderRepository、InventoryRepository。3) サービス：OrderService（placeOrder、cancelOrder）、PaymentService（processPayment）、InventoryService（reserveItems）。4) 避けるべきアンチパターン：ビジネスロジックを行うOrderController、コントローラーでのデータベースクエリ、一般的なOrderUtilsクラス。
セキュリティ監査
安全All static analysis findings are false positives. Detected 'backtick execution' patterns are markdown code emphasis formatting for library names and file examples. 'Weak cryptographic algorithm' detections are references to 'Clean Architecture' design pattern, not cryptography. 'System reconnaissance' patterns match legitimate software development guidance. This skill contains no executable code and provides educational architecture guidance only.
品質スコア
作れるもの
新規プロジェクトのアーキテクチャ
新しいプロジェクトを開始し、最初の日から堅実なアーキテクチャ基盤を確立する必要がある
レガシーコードのリファクタリング
クリーンアーキテクチャの原則を適用して、既存コードベースのコード品質を向上させる
コードレビュー基準
チームコードレビューとプルリクエストのための一貫したアーキテクチャガイドラインを確立する
これらのプロンプトを試す
このコードコンポーネントをアーキテクチャの問題についてレビューしてください。確認項目：一般的な命名（utils/ヘルパー）、UIと混合されたビジネスロジック、200行を超えるファイル、50行を超える関数。クリーンアーキテクチャの原則に従って改善案を提案してください。
[feature]モジュールを構築する必要があります。DDDの原則に従ってアーキテクチャを設計してください。エンティティ、サービス、リポジトリのドメイン固有の名前を提案してください。明確な境界と関心の分離を定義してください。
[feature]機能を実装する必要があります。この問題を解決する既存のライブラリやサービスを検索してください。以下の基準に基づいてオプションを評価してください：メンテナンス状況、コミュニティの採用、ドキュメントの品質、要件への適合性。
このコードベースのアーキテクチャアンチパターンを分析してください：NIH症候群（ライブラリの代わりにカスタム実装）、一般的なファイル名、関心の分離の欠如、深いネスト。具体的なリファクタリング推奨事項を例とともに提供してください。
ベストプラクティス
- カスタムコードの保守負担を軽減するために、カスタムコードを書く前に既存のライブラリやサービスを検索する
- 一般的なutilsやヘルパーではなく、OrderCalculatorやUserAuthenticatorなどのドメイン固有の名前を使用する
- ビジネスロジックをフレームワークから独立させ、UIコンポーネントから分離する
- アーリーリターンパターンを適用してネストを減らし、コード可読性を向上させる
回避
- 無関係な関数を持つutils.jsやhelpers.tsファイルを作成し、ドメイン固有のモジュールの代わりにしない
- ビジネスロジックをUIコンポーネントと混合したり、データベースクエリをコントローラー直接書いたりしない
- 確立されたライブラリが存在する場合に、カスタム認証、状態管理、フォーム検証を構築する
- ファイルやモジュールを一般的な名前（common、shared、misc）で、ドメインの目的を明確にせず命名する