mcpField
A
apidog-workflow-api-lifecycle

apidog-workflow-api-lifecycle

github.com/apidog開発352 回インストール16 週間前に更新
リポジトリ

apidog-workflow-api-lifecycle について

Apidogで要件からテスト、レポート、ブランチでの引き渡しまでAPI変更を扱うワークフロースキルです。現在のCLIスキーマを確認し、保存した各リソースを検証する手順を重視します。

主な機能

  1. 01APIエンドポイントとスキーマの設計
  2. 02環境と変数の設定
  3. 03テストケースとモックの追加
  4. 04テスト実行とレポート確認
  5. 05引き渡しに向けたブランチ変更の準備

活用シーン

  1. 01要件やAPI定義をApidogリソースに変換
  2. 02テストを追加してAPI変更を検証
  3. 03マージに向けてブランチ上のAPI変更を準備

インストール

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

$npx skills add https://github.com/apidog/apidog-cli-skills --skill apidog-workflow-api-lifecycle

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

詳細

API ライフサイクルのワークフロー

開始する前に、../apidog-cli/SKILL.md をお読みください。安定版のエントリースキルとこのワークフローが矛盾する場合は、現在の CLI ヘルプとこのワークフローを正としてください。必要に応じて、apidog-branch、apidog-import-export、apidog-test-case をお読みください。複雑なテストフローについては apidog-test-scenario を、実行と CI については apidog-test-automation をお読みください。

エンドポイント、スキーマ、環境、テストレポート、および関連コマンドについては、現在の CLI ヘルプを使用してください。このワークフローでは、要件から API アセット、テスト、レポート、ブランチのマージまで、エンドツーエンドのデリバリーを扱います。リソースの順序、品質ゲート、デリバリーの検証に重点を置いてください。エージェントは、古いドキュメントや記憶に頼って書き込むのではなく、help/schema -> get -> validate -> write -> run/report のループを構築してください。

使用する場面

  • 要件に基づいて API のセットを作成または更新します。
  • OpenAPI/Postman をインポートした後、API、スキーマ、フォルダー、テストを整理します。
  • コード、PRD、要件ドキュメント、テストドキュメント、または議論から API 仕様を生成し、Apidog にインポートします。
  • API にモック、テストケース、ドキュメント、公開設定を追加します。
  • AI ブランチで API の変更を完了し、マージに備えます。

ワークフロー

Confirm project/branch
  -> if importing from code/docs, generate spec and run quality gates
  -> design endpoints and schemas
  -> configure environments and variables
  -> configure mocks
  -> create API test cases
  -> run tests and inspect reports
  -> export/publish docs
  -> merge or create MR

ステップ 1. コンテキストを確認する

現在の CLI ヘルプを使用して、ユーザー、プロジェクト、対象ブランチ、および AI ブランチが必要かどうかを確認します。

  • ユーザーが main ブランチまたは sprint ブランチを直接編集することを希望する場合は、AI 書き込み権限を確認するか、AI ブランチを使用します。
  • AI ブランチを通じて既存のリソースを編集する場合は、まず branch pick-to でソースリソースをインポートします。

ステップ 2. API リソースを設計する

エンドポイント、スキーマ、レスポンスコンポーネント、セキュリティスキーム、フォルダー、および関連する API 設計コマンドについては、現在の CLI ヘルプを使用してください。

最小限の境界として、エンドポイントは API 定義、test-case はエンドポイント配下のテストケースです。両者を混同しないでください。スキーマ、レスポンスコンポーネント、セキュリティスキームなどの再利用可能なリソースは、エンドポイントから参照する前に作成してください。共通パラメーターに環境変数を書き込まないでください。

コード、PRD、またはドキュメントから API 仕様を生成してインポートする場合は、まず ../apidog-import-export/SKILL.md をお読みください。API 設計やテストの追加に進む前に、ジェネレーターの検索、OpenAPI のメトリクス、タグのグループ化、一時プロジェクトでの検証を完了してください。

  • 再利用可能な schema、response-component、security-scheme などのリソースを、参照する前に作成します。
  • 作成後は必ず endpoint get を実行し、実際に保存された構造を確認します。

ステップ 3. 環境を設定する

環境、変数、データベース接続、Vault、および関連する実行時コンテキストのコマンドについては、現在の CLI ヘルプを使用してください。

  • 適切な環境がない場合は、環境を作成または更新します。
  • 最終回答で機密変数を公開しないでください。
  • テストの実行と CI のデリバリーでは、再現できないデフォルト環境の変更を避けるため、--environment を明示的に指定します。

ステップ 4. テストケースを追加する

../apidog-test-case/SKILL.md をお読みください。

  • 空の殻だけのテストケースは作成しないでください。
  • 作成後は test-case get を実行し、ステップ、アサーション、抽出子が保存されたことを確認します。

ステップ 5. 検証してデリバリーする

  • レポートの問題については、まずローカルレポート、クラウドへのアップロード、ダウンロードしたサマリーを区別し、必要に応じて apidog-cli-checkup に切り替えます。
  • クライアントの表示に関する問題については、apidog-cli-checkup に切り替えます。
  • マージが必要な場合は、apidog-branch に切り替えます。
  • 新しい API のテストが 404 を返す場合やアサーションに失敗する場合は、まずモックと環境の設定を確認します。モック設定の問題は、API 設計アセットが保存されていないこととは異なります。

違反してはならないルール

  1. プロジェクトとブランチの確認を省略しないでください。
  2. 保護された main ブランチに直接書き込まないでください。
  3. 保存された構造を確認せずにエンドポイントを作成しないでください。
  4. 空のテストケースを作成しないでください。
  5. テストの失敗を API 作成の失敗と見なさないでください。API 定義、環境、テストケース、実行レポートを個別に診断してください。

コメント

Markdown 対応