backend-development-feature-development
要件定義からデプロイまでのバックエンド機能開発をエンドツーエンドで統括します。複数チームやサービスにまたがる多フェーズの機能リリースを調整する際に使用してください。
description の原文を見る
Orchestrate end-to-end backend feature development from requirements to deployment. Use when coordinating multi-phase feature delivery across teams and services.
SKILL.md 本文
要件から本番運用まで、エンドツーエンドの機能開発を調整します:
[Extended thinking: このワークフローは、特定の目的を持つエージェントを包括的な機能開発フェーズを通して調整します。発見と計画から実装、テスト、デプロイメントまで各フェーズが前のフェーズの出力に基づいて構築されます。このワークフローは複数の開発手法(従来型、TDD/BDD、DDD)、機能の複雑さレベル、フィーチャーフラグ、段階的ロールアウト、観測可能性第一の開発を含むモダンなデプロイメント戦略をサポートします。エージェントは開発ライフサイクル全体を通して一貫性と品質を維持するために、前フェーズの詳細なコンテキストを受け取ります。]
このスキルを使用する場面
- バックエンド、フロントエンド、データ全体で、エンドツーエンドの機能配信を調整する
- 要件、アーキテクチャ、実装、テスト、ロールアウトを管理する
- デプロイメントとモニタリングのニーズを伴う複数サービスの変更を計画する
- スコープ、リスク、成功指標をチーム間で調整する
このスキルを使用しない場面
- タスクが小規模で独立したバックエンド変更またはバグ修正である
- 完全なワークフローではなく、単一の専門家タスクのみが必要である
- デプロイメントやクロスチーム調整が関わっていない
実行手順
- 機能スコープ、成功指標、制約を確認する。
- 開発手法を選択し、フェーズの出力を定義する。
- 実装、テスト、セキュリティ検証を調整する。
- ロールアウト、モニタリング、ドキュメンテーション計画を準備する。
安全性
- 承認とロールバック計画なしで本番環境の変更を避ける。
- データマイグレーションとフィーチャーフラグをステージング環境で最初に検証する。
設定オプション
開発手法
- traditional: 実装後のテストを伴う順序立った開発
- tdd: レッド・グリーン・リファクタリングサイクルを伴うテスト駆動開発
- bdd: シナリオベースのテストを伴う振る舞い駆動開発
- ddd: 有界コンテキストと集約を伴うドメイン駆動設計
機能の複雑さ
- simple: 単一サービス、最小限の統合(1-2日)
- medium: 複数サービス、中程度の統合(3-5日)
- complex: クロスドメイン、広範な統合(1-2週間)
- epic: 主要なアーキテクチャ変更、複数チーム(2週間以上)
デプロイメント戦略
- direct: すべてのユーザーへの即座なロールアウト
- canary: トラフィックの5%から開始する段階的ロールアウト
- feature-flag: フィーチャートグルによる制御された有効化
- blue-green: ゼロダウンタイムデプロイメントと即座なロールバック
- a-b-test: 実験とメトリクスのためのトラフィック分割
フェーズ1:発見と要件計画
-
ビジネス分析と要件
- Task ツールを使用、subagent_type="business-analytics::business-analyst"
- プロンプト: "以下の機能要件を分析してください:$ARGUMENTS。ユーザーストーリー、受入基準、成功指標、ビジネス価値を定義してください。ステークホルダー、依存関係、リスクを特定してください。明確なスコープ境界を持つ機能仕様書を作成してください。"
- 期待される出力:ユーザーストーリー、成功指標、リスク評価を含む要件ドキュメント
- コンテキスト:初期機能リクエストとビジネスコンテキスト
-
技術アーキテクチャ設計
- Task ツールを使用、subagent_type="comprehensive-review::architect-review"
- プロンプト: "以下の機能の技術アーキテクチャを設計してください:$ARGUMENTS。要件を使用:[ステップ1の業務分析を含める]。サービス境界、APIコントラクト、データモデル、統合ポイント、テクノロジースタックを定義してください。スケーラビリティ、パフォーマンス、セキュリティ要件を検討してください。"
- 期待される出力:アーキテクチャダイアグラム、API仕様、データモデルを含む技術設計ドキュメント
- コンテキスト:ビジネス要件、既存システムアーキテクチャ
-
実現可能性とリスク評価
- Task ツールを使用、subagent_type="security-scanning::security-auditor"
- プロンプト: "以下の機能のセキュリティ上の影響とリスクを評価してください:$ARGUMENTS。アーキテクチャを確認:[ステップ2の技術設計を含める]。セキュリティ要件、コンプライアンス必要事項、データプライバシー懸念事項、潜在的な脆弱性を特定してください。"
- 期待される出力:リスク行列、コンプライアンスチェックリスト、軽減戦略を含むセキュリティ評価
- コンテキスト:技術設計、規制要件
フェーズ2:実装と開発
-
バックエンドサービス実装
- Task ツールを使用、subagent_type="backend-architect"
- プロンプト: "以下の機能のバックエンドサービスを実装してください:$ARGUMENTS。技術設計に従ってください:[ステップ2のアーキテクチャを含める]。RESTful/GraphQL API を構築し、ビジネスロジックを実装し、データレイヤーと統合し、レジリエンスパターン(サーキットブレーカー、リトライ)を追加し、キャッシング戦略を実装してください。段階的ロールアウト用のフィーチャーフラグを含めてください。"
- 期待される出力:API、ビジネスロジック、データベース統合、フィーチャーフラグを備えたバックエンドサービス
- コンテキスト:技術設計、APIコントラクト、データモデル
-
フロントエンド実装
- Task ツールを使用、subagent_type="frontend-mobile-development::frontend-developer"
- プロンプト: "以下の機能のフロントエンドコンポーネントを構築してください:$ARGUMENTS。バックエンド API と統合:[ステップ4の API エンドポイントを含める]。レスポンシブ UI、ステート管理、エラーハンドリング、ローディング状態、分析トラッキングを実装してください。A/B テスト機能用のフィーチャーフラグ統合を追加してください。"
- 期待される出力:API統合、ステート管理、分析トラッキングを備えたフロントエンドコンポーネント
- コンテキスト:バックエンド API、UI/UX設計、ユーザーストーリー
-
データパイプラインと統合
- Task ツールを使用、subagent_type="data-engineering::data-engineer"
- プロンプト: "以下の機能のデータパイプラインを構築してください:$ARGUMENTS。ETL/ELT プロセスを設計し、データ検証を実装し、分析イベントを作成し、データ品質モニタリングをセットアップしてください。プロダクト分析プラットフォームと統合して、機能の使用状況をトラッキングしてください。"
- 期待される出力:データパイプライン、分析イベント、データ品質チェック
- コンテキスト:データ要件、分析ニーズ、既存データインフラストラクチャ
フェーズ3:テストと品質保証
-
自動化テストスイート
- Task ツールを使用、subagent_type="unit-testing::test-automator"
- プロンプト: "以下の機能の包括的なテストスイートを作成してください:$ARGUMENTS。バックエンド:[ステップ4より]とフロントエンド:[ステップ5より]のユニットテストを作成してください。API エンドポイントの統合テスト、重要なユーザージャーニーの E2E テスト、スケーラビリティ検証用のパフォーマンステストを追加してください。最小80%のコードカバレッジを確保してください。"
- 期待される出力:ユニット、統合、E2E、パフォーマンステストを含むテストスイート
- コンテキスト:実装コード、受入基準、テスト要件
-
セキュリティ検証
- Task ツールを使用、subagent_type="security-scanning::security-auditor"
- プロンプト: "以下の機能のセキュリティテストを実施してください:$ARGUMENTS。実装を確認:[ステップ4-5のバックエンドとフロントエンドを含める]。OWASP チェック、ペネトレーションテスト、依存関係スキャン、コンプライアンス検証を実行してください。データ暗号化、認証、認可を検証してください。"
- 期待される出力:セキュリティテスト結果、脆弱性レポート、修復アクション
- コンテキスト:実装コード、セキュリティ要件
-
パフォーマンス最適化
- Task ツールを使用、subagent_type="application-performance::performance-engineer"
- プロンプト: "以下の機能のパフォーマンスを最適化してください:$ARGUMENTS。バックエンドサービス:[ステップ4より]とフロントエンド:[ステップ5より]を分析してください。コードをプロファイルし、クエリを最適化し、キャッシングを実装し、バンドルサイズを削減し、読み込み時間を改善してください。パフォーマンスバジェットとモニタリングをセットアップしてください。"
- 期待される出力:パフォーマンス改善、最適化レポート、パフォーマンスメトリクス
- コンテキスト:実装コード、パフォーマンス要件
フェーズ4:デプロイメントとモニタリング
-
デプロイメント戦略とパイプライン
- Task ツールを使用、subagent_type="deployment-strategies::deployment-engineer"
- プロンプト: "以下の機能のデプロイメントを準備してください:$ARGUMENTS。自動テスト:[ステップ7より]を備えた CI/CD パイプラインを作成してください。段階的ロールアウト用のフィーチャーフラグを設定し、ブルーグリーンデプロイメントを実装し、ロールバック手順をセットアップしてください。デプロイメントランブックとロールバック計画を作成してください。"
- 期待される出力:CI/CDパイプライン、デプロイメント設定、ロールバック手順
- コンテキスト:テストスイート、インフラストラクチャ要件、デプロイメント戦略
-
観測可能性とモニタリング
- Task ツールを使用、subagent_type="observability-monitoring::observability-engineer"
- プロンプト: "以下の機能の観測可能性をセットアップしてください:$ARGUMENTS。分散トレーシング、カスタムメトリクス、エラートラッキング、アラートを実装してください。機能の使用状況、パフォーマンスメトリクス、エラーレート、ビジネス KPI のダッシュボードを作成してください。自動アラート付き SLO/SLI をセットアップしてください。"
- 期待される出力:モニタリングダッシュボード、アラート、SLO定義、観測可能性インフラストラクチャ
- コンテキスト:機能実装、成功指標、運用要件
-
ドキュメンテーションとナレッジ転送
- Task ツールを使用、subagent_type="documentation-generation::docs-architect"
- プロンプト: "以下の機能の包括的なドキュメンテーションを生成してください:$ARGUMENTS。API ドキュメンテーション、ユーザーガイド、デプロイメントガイド、トラブルシューティングランブックを作成してください。アーキテクチャダイアグラム、データフロー図、統合ガイドを含めてください。コミットから自動化されたチェンジログを生成してください。"
- 期待される出力:API ドキュメンテーション、ユーザーガイド、ランブック、アーキテクチャドキュメンテーション
- コンテキスト:すべての前フェーズの出力
実行パラメータ
必須パラメータ
- --feature: 機能名と説明
- --methodology: 開発アプローチ(traditional|tdd|bdd|ddd)
- --complexity: 機能の複雑さレベル(simple|medium|complex|epic)
オプションパラメータ
- --deployment-strategy: デプロイメントアプローチ(direct|canary|feature-flag|blue-green|a-b-test)
- --test-coverage-min: 最小テストカバレッジ閾値(デフォルト:80%)
- --performance-budget: パフォーマンス要件(例:<200ms のレスポンスタイム)
- --rollout-percentage: 段階的デプロイメントの初期ロールアウトパーセンテージ(デフォルト:5%)
- --feature-flag-service: フィーチャーフラグプロバイダー(launchdarkly|split|unleash|custom)
- --analytics-platform: 分析統合(segment|amplitude|mixpanel|custom)
- --monitoring-stack: 観測可能性ツール(datadog|newrelic|grafana|custom)
成功基準
- ビジネス要件のすべての受入基準が満たされている
- テストカバレッジが最小閾値を超えている(デフォルト:80%)
- セキュリティスキャンに重大な脆弱性がない
- パフォーマンスが定義されたバジェットと SLO を満たしている
- フィーチャーフラグが制御されたロールアウト用に設定されている
- モニタリングとアラートが完全に機能している
- ドキュメンテーションが完了し承認されている
- 本番環境へのデプロイメントが成功しロールバック能力を有している
- プロダクト分析が機能の使用状況をトラッキングしている
- A/B テストメトリクスが設定されている(該当する場合)
ロールバック戦略
デプロイメント中またはその後に問題が発生した場合:
- 即座のフィーチャーフラグ無効化(1分未満)
- ブルーグリーントラフィック切り替え(5分未満)
- CI/CD 経由の完全なデプロイメントロールバック(15分未満)
- 必要な場合、データベースマイグレーションロールバック(データチームと調整)
- 再デプロイメント前のインシデント事後分析と修正
機能の説明:$ARGUMENTS
制限事項
- このスキルは、タスクが上記で説明されているスコープと明確に一致する場合にのみ使用してください。
- 出力を環境固有の検証、テスト、または専門家による確認の代替と見なさないでください。
- 必須入力、権限、安全境界、成功基準が欠落している場合は、停止して明確化を求めてください。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- sickn33
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/sickn33/antigravity-awesome-skills / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。