forge-app-builder

Forge App Builder

各リクエストを、必要な分岐と機能ゲートだけを経由して処理します。プラットフォームの情報を最新に保ち、安全な判断に焦点を当てたローカルガイダンスを維持します。

次の不変条件を維持してください

1. プラットフォームの構文、モジュール、API、スコープ、制限、ランタイム、パッケージ、ライフサイクルの状態、CLI フラグを確定する前に、最新の公式 Forge ガイダンスを取得してください。
2. 新しいデプロイ可能なアプリはすべて forge create で登録してください。アプリの ID を手作業で作成したり、作成に失敗した際に未登録のスキャフォールドで代用したりしないでください。
3. 既存のアプリを計画または編集する前に、そのアプリとリポジトリの指示を確認してください。無関係なユーザーの変更は保持してください。
4. チャットで認証情報を要求したり、受け取ったりしないでください。該当する対話型 CLI または安全な設定フローを使用してください。
5. 明示的な許可と対象の確認なしに、Forge の利用規約への同意、課金への同意、デプロイ、インストール、アップグレード、昇格、本番環境の変数設定、稼働中のサイトの変更を行わないでください。
6. マニフェストを変更するたびに、正確な最新のリファレンスに照らして検証し、forge lint を実行してください。
7. 最小権限を適用し、不要な外部通信、特権を要するバックエンド操作、移行を避けてください。
8. このスキルで実行する Forge CLI コマンドには ATL_FORGE_ATTRIBUTION_SKILL_NAME=forge-app-builder をプレフィックスとして付けてください。ユーザーが実行する forge login と forge tunnel は除外します。

主な目的に応じてルーティングする

実装ガイダンスを読み込む前に、主なルートを 1 つ選択してください。

目的	ルート
アーキテクチャ、実現可能性、または実装計画のみ	references/plan-only.md を読み、変更を加える前に停止します
デプロイ可能なアプリを作成する	references/create-new-app.md を読む
既存のアプリの動作を追加または変更する	references/extend-existing-app.md を読む
既知のエラー、失敗したコマンド、空白の UI、ログ、または予期しない動作	forge-debugger にルーティングします
デプロイ前またはリリース準備状況の包括的なレビュー	forge-app-review にルーティングします
詳細なセキュリティレビューまたは静的解析	forge-security-review にルーティングします
コストまたはプラットフォーム消費の最適化	forge-cost-optimizer にルーティングします
Teamwork Graph コネクター	forge-connector にルーティングします

診断やレビューが進行中のビルド作業に付随する場合は、ここで続行してください。ルートが明確でない場合は、ユーザーに尋ねる前にワークスペースを確認してください。

選択したルートの根拠を確認する

最新のプラットフォーム詳細が必要な場合は、references/documentation-routing.md を読んでください。Forge MCP が利用可能な場合は、まず Forge MCP を使用してください。ツール名が固定だと想定せず、目的に基づいて現在の機能を確認し、Web ドキュメントや記憶しているプラットフォームの知識に頼る前に、関連性の最も高い機能を呼び出してください。MCP が利用できない場合、失敗した場合、必要な範囲を正確に網羅していない場合、および重要な検証が必要な場合は、対象を絞った Atlassian の公式ドキュメントを使用してください。

全般的なオリエンテーションに役立つ場合は、Forge 開発ガイドを呼び出してください。タスクで既知のリーフリファレンス 1 つだけが必要な場合に、形式的に呼び出さないでください。参照情報に基づいて判断する前に、正確なモジュール、マニフェストのプロパティ、エンドポイント、スコープ、または CLI のページを取得してください。

機能ゲートを条件に応じて有効化する

依頼された成果と確認したコードに関連するリファレンスのみを読み込みます。

トリガー	読み込むリファレンス
拡張ポイントまたはモジュールを選択または追加する	references/module-selection.md
UI Kit を実装または変更する	references/ui-kit.md
Custom UI または Frame を実装または変更する	references/custom-ui.md
リゾルバー、関数、イベント、スケジュール、キュー、ウェブトリガー、アプリ REST API、リアルタイム機能、またはランタイムサービスを追加する	references/backend-and-events.md
Atlassian、Forge アプリ、または外部 API を呼び出す、もしくは公開する。プロバイダーやリモートを使用する。スコープ、認可、またはエグレスを変更する	references/apis-permissions-and-egress.md
データを永続化する、またはテナント、ライフサイクル、移行、データレジデンシーに影響する	references/storage-and-residency.md
環境、ランタイム変数、シークレット、またはマニフェストの補間を設定する	references/environments-and-configuration.md
プロダクト間の互換性、ライセンスのないアクセス、ライセンス、共有、または配布の動作を変更する	references/distribution-and-access.md
検証、デプロイ、インストール、アップグレード、または引き継ぎを行う	references/validation-and-release.md

ヘッドレスアプリに UI のガイダンスを読み込まないでください。ステートレスな機能にストレージのガイダンスを読み込まないでください。UI Kit のみを変更する場合に Custom UI のガイダンスを読み込まないでください。また、検証または承認済みのリリースが必要になるまでは、リリースのガイダンスを読み込まないでください。

実装と検証を反復する

重要な変更を行う前に、求められている結果、影響を受ける Forge の領域、重要な設計上の選択肢、適切な検証方法を明確にします。実装前に、認可、データの取り扱い、互換性、ライフサイクルの状態、コスト、ライブ状態に影響する判断を解決してください。

一貫性のある単位で作業します。意味のある変更を行うたびに、対象を絞ったテスト、型チェック、フロントエンドのビルド、ハンドラーやリソースの確認、forge lint など、利用可能な最も関連性の高い根拠を用いて評価します。変更単位の大きさと検証頻度は、リスク、フィードバックにかかるコスト、既存のコードベースに応じて選択します。個別に検証しても得られるものが少ない場合は、関連する変更をまとめてください。

検証に失敗した場合や、前提と矛盾する結果になった場合は、原因を特定します。Forge の動作に関わる場合は、正確な最新のドキュメントを参照し、実装を調整してから再度検証します。求められている動作と影響を受ける配線が確認できるまで、またはユーザーの入力や利用できない外部状態が必要になるまで続けてください。

機能が動作することを合理的に確認できる、より強力なローカル検証がある場合、生成、コンパイル、リンティングの成功だけを機能の動作の証明と見なさないでください。秘密情報や特権を要する処理をフロントエンドに含めないでください。表示条件はプレゼンテーション上の制御として扱い、認可として扱わないでください。移行が必要であるか、明示的に許可されている場合を除き、サポートされている既存の慣例と、無関係な変更を維持してください。

検証して安全に終了する

ユーザーがリリース作業を依頼していない限り、ローカル検証の完了後に終了します。リリース作業が許可されている場合は、実行の直前に、対象となるアプリ、環境、サイト、製品、バージョンまたはアップグレード時の動作、想定される範囲やデータへの影響を確認してください。