Forge App Review

Forge App Review

Run a general Forge release-readiness review. This skill is the front door for broad app review, not a replacement for specialist security, cost, or debugging skills.

Boundaries

Use this skill for:

• Pre-deploy and release-readiness checks.
• General architecture and maintainability review.
• Manifest/module/resource/function wiring.
• Runtime, dependency, package, and script sanity checks.
• Basic tests/deploy readiness and operational hygiene.
• Obvious security, cost, or reliability smells that should trigger a deeper specialist pass.

Use another skill instead when the user's primary intent is:

• Deep security audit, SAST, authz, secrets, tenant isolation, exploitability, or CVSS reporting -> forge-security-review.
• Cost optimization, invocations, GB-seconds, storage/log volume, trigger frequency, or memory tuning -> forge-cost-optimizer.
• A known failure, error message, blank UI, failed deploy/install, broken resolver, missing app, or logs/tunnel diagnosis -> forge-debugger.

If a broad review finds a deep security/cost/debug concern, include it as a handoff recommendation rather than duplicating the specialist workflow.

Review Rules

• Audit first. Do not modify app files unless the user explicitly asks to apply fixes.
• Read the codebase before making claims.
• Prefer concrete file/line evidence.
• Keep findings focused on bugs, release blockers, meaningful risks, and missing validation.
• Do not run full SAST or cost tooling from this skill. Recommend the specialist skill when warranted.
• Do not report speculative security or cost observations as confirmed vulnerabilities or savings.

Workflow

1. Read manifest.yml or manifest.yaml.

• Identify modules, resources, functions, resolver bindings, triggers, web triggers, remotes, permissions, runtime, and memory settings.
• Verify referenced handlers/resources exist.

2. Read package.json.

• Check Forge package fit, scripts, runtime assumptions, direct dependencies, and obvious unused/missing packages.

3. Inspect source files.

• Backend/resolvers: resolver.define, handler exports, product API calls, storage usage, external fetches, logging, error handling.
• Frontend: UI Kit or Custom UI resource entry points, invoke() patterns, bridge usage, loading/error states.

4. Inspect tests and project docs when present.

• Note missing tests only when behavior risk justifies it.

5. Produce a prioritized readiness report.

What To Check

Release Blockers

• Manifest references a missing handler, resource path, or module key.
• Resolver names called by the frontend do not match resolver.define() names.
• Required scopes or egress permissions are missing for actual API/fetch usage.
• Runtime, package versions, or module syntax likely fail forge lint, build, deploy, or install.
• App has no clear way to exercise its primary user flow.

Architecture And Maintainability

• Module type matches the intended UX surface.
• Resolver boundaries are coherent and not overly monolithic for the app size.
• Sensitive or privileged logic stays backend-side.
• UI-only formatting/transforms are not unnecessarily forced through backend functions.
• Error handling is sufficient for user-facing workflows.
• Code organization matches existing project style.

Lightweight Security Signals

Only flag obvious signals and recommend forge-security-review for deep validation:

• Broad/write/admin scopes without visible usage.
• api.asApp() in user-triggered resolvers without obvious authorization checks.
• Hardcoded credentials or token-like literals.
• External fetches without manifest egress entries.
• Web triggers without visible authentication strategy.
• Full payload/request logging that may expose user, tenant, or secret data.

Lightweight Cost Signals

Only flag obvious signals and recommend forge-cost-optimizer for deep analysis:

• Resolver invoked only to return static data or product context.
• Multiple independent invoke() calls on page load.
• Scheduled triggers that look like broad polling.
• Product triggers without filters or ignoreSelf where applicable.
• Full payload/API response logging in hot paths.
• Storage writes on every invocation.

Lightweight Debuggability Signals

Only flag readiness gaps; use forge-debugger when there is an observed failure:

• Missing loading/error states around async UI paths.
• Logs are either too noisy or absent around important failures.
• README or scripts do not explain how to lint/build/deploy/test.
• App has no obvious local verification command besides forge lint.

Output Format

Return a concise Markdown report:

# Forge App Review Results

## Summary
- Readiness: Ready | Needs changes | Blocked
- Highest-risk area: <manifest | resolver wiring | permissions | dependencies | tests | operational hygiene>
- Files inspected: <short list>
- Specialist handoffs: <none | security | cost | debugger>

## Findings

1. [Critical | Warning | Info] <title>
   - Evidence: `<file:line>` and observed pattern
   - Impact: <why this affects readiness>
   - Recommendation: <specific fix or specialist handoff>

## Clean Areas
- <important categories checked with no issues>

## Suggested Next Step
- <apply fixes | run specialist review | deploy/lint/test command>

If there are no findings, say the app looks ready from this general review and list any residual specialist reviews that were intentionally out of scope.

Forge App Review Skill

Performs a lightweight pre-release readiness review for Atlassian Forge apps. Use it as the broad "is this app ready to ship?" pass before deployment or handoff.

This skill is the review front door. It checks whether a Forge app looks ready to lint, deploy, install, and maintain, then routes deeper concerns to specialist skills instead of duplicating their rulebooks.

Use For

• General Forge app review
• Pre-deploy or release-readiness checks
• Manifest/module/function/resource wiring
• Architecture and maintainability review
• Dependency, runtime, script, and verification sanity checks
• Obvious security, cost, or debugging signals that need specialist follow-up

Do Not Use For

• Full SAST, exploitability analysis, CVSS scoring, or secrets/authz/tenant-isolation audits
• Cost optimization plans, platform-consumption reductions, or memory/storage/log tuning
• Known failures such as blank UI, failed deploy/install, resolver errors, or specific stack traces

Specialist Handoffs

• Use forge-security-review for deep security audit, SAST, authz, secrets, tenant isolation, exploitability, and CVSS reporting.
• Use forge-cost-optimizer for reducing invocations, GB-seconds, storage/log volume, trigger frequency, memory, and Forge platform consumption.
• Use forge-debugger for known failures, error messages, blank UI, deploy/install problems, resolver errors, tunnel/log diagnosis, and apps that stopped working.

What It Checks

• Manifest references: modules, resources, functions, handlers, permissions, remotes, triggers, and runtime.
• Package shape: scripts, direct dependencies, Forge package fit, and obvious unused or missing packages.
• Source wiring: frontend entry points, resolver names, handler exports, bridge calls, product API calls, storage usage, and logging.
• Readiness gaps: missing verification commands, stale docs, missing tests where behavior risk justifies them, and specialist follow-ups.

The output is a concise readiness report with prioritized findings, clean areas, and recommended next steps.

Example Prompts

Review my Forge app before I deploy it.

Is this Forge app ready to ship?

Do a general app-review pass on this manifest and source.

Check whether this Forge app is ready for release, and route any deep security or cost concerns to the right skill.

See SKILL.md for the full workflow.