사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/atlassian/forge-skills --skill forge-app-builder시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Forge App Builder
Route each request through only the branches and capability gates it needs. Keep platform facts live and keep local guidance focused on safe decisions.
Preserve these invariants
- Retrieve current official Forge guidance before committing to platform syntax, modules, APIs, scopes, limits, runtimes, packages, lifecycle status, or CLI flags.
- Register every new deployable app with
forge create; never hand-build an app identity or replace a failed creation with an unregistered scaffold. - Inspect an existing app and its repository instructions before planning or editing it. Preserve unrelated user changes.
- Never request or accept credentials in chat. Use the relevant interactive CLI or secure configuration flow.
- Never accept Forge terms or billing consent, deploy, install, upgrade, promote, set a production variable, or change a live site without explicit authorization and a confirmed target.
- Validate every manifest change against the exact current reference and with
forge lint. - Use least privilege and avoid unnecessary egress, privileged backend operations, and migrations.
- Prefix Forge CLI commands run for this skill with
ATL_FORGE_ATTRIBUTION_SKILL_NAME=forge-app-builder; exclude user-runforge loginandforge tunnel.
Route the primary intent
Choose one primary route before loading implementation guidance:
| Intent | Route |
|---|---|
| Architecture, feasibility, or implementation plan only | Read references/plan-only.md; stop before mutations |
| Create a deployable app | Read references/create-new-app.md |
| Add or change behavior in an existing app | Read references/extend-existing-app.md |
| Known error, failed command, blank UI, logs, or unexpected behavior | Route to forge-debugger |
| Broad pre-deploy or release-readiness review | Route to forge-app-review |
| Deep security review or static analysis | Route to forge-security-review |
| Cost or platform-consumption optimization | Route to forge-cost-optimizer |
| Teamwork Graph connector | Route to forge-connector |
Continue here when diagnosis or review is incidental to active build work. If the route is unclear, inspect the workspace before asking the user.
Ground the selected route
Read references/documentation-routing.md when current platform detail is needed. Use Forge MCP as the first preference whenever it is available. Discover its current capabilities by purpose rather than assuming permanent tool names, and call the narrowest relevant capability before relying on web documentation or remembered platform knowledge. Use focused official Atlassian documentation when MCP is unavailable, fails, or lacks the exact coverage needed, and for critical verification.
Call the general Forge development guide when broad orientation is useful. Do not call it merely to satisfy a ritual when the task needs only one known leaf reference. Retrieve the exact module, manifest property, endpoint, scope, or CLI page before relying on it.
Activate capability gates conditionally
Load only the references implicated by the requested outcome and observed code:
| Trigger | Read |
|---|---|
| Select or add an extension point or module | references/module-selection.md |
| Implement or change UI Kit | references/ui-kit.md |
Implement or change Custom UI or Frame | references/custom-ui.md |
| Add resolvers, functions, events, schedules, queues, web triggers, app REST APIs, realtime, or runtime services | references/backend-and-events.md |
| Call or expose Atlassian, Forge app, or external APIs; use providers or remotes; change scopes, authorization, or egress | references/apis-permissions-and-egress.md |
| Persist data or affect tenancy, lifecycle, migration, or residency | references/storage-and-residency.md |
| Configure environments, runtime variables, secrets, or manifest interpolation | references/environments-and-configuration.md |
| Change cross-product compatibility, unlicensed access, licensing, sharing, or distribution behavior | references/distribution-and-access.md |
| Validate, deploy, install, upgrade, or hand off | references/validation-and-release.md |
Do not load UI guidance for a headless app, storage guidance for a stateless feature, Custom UI guidance for a UI Kit-only change, or release guidance until validation or an authorized release becomes relevant.
Implement and validate iteratively
Before non-trivial edits, establish the requested outcome, affected Forge surfaces, consequential design choices, and a proportionate validation approach. Resolve decisions that affect authorization, data handling, compatibility, lifecycle status, cost, or live state before implementation.
Work in coherent increments. After each meaningful change, use the most relevant available evidence to assess it, such as focused tests, type checks, frontend builds, handler or resource inspection, or forge lint. Choose the increment size and validation frequency according to risk, feedback cost, and the existing codebase; combine related edits when validating them separately would add little value.
When validation fails or contradicts an assumption, identify the cause, retrieve exact current documentation when Forge behavior is involved, adjust the implementation, and validate again. Continue until the requested behavior and affected wiring are verified, or progress requires user input or unavailable external state.
Do not treat successful generation, compilation, or linting alone as proof that a feature works when stronger local verification is reasonably available. Keep secrets and privileged work out of frontend code. Treat display conditions as presentation controls, not authorization. Preserve supported existing conventions and unrelated changes unless a migration is required or explicitly authorized.
Validate and stop safely
Stop after local verification unless the user requested release work. For authorized release work, confirm the exact app, environment, site, product, version or upgrade behavior, and expected scope or data impact immediately before executing it.
