/forge-cost-optimizer

name: forge-cost-optimizer
description: >
  Optimizes Atlassian Forge apps to reduce platform consumption and avoid unnecessary costs using Atlassian's
  "Optimise Forge platform costs" guidance. Use when the user asks to optimize Forge app costs, reduce Forge
  invocations, lower GB-seconds, reduce storage or log usage, tune memory, replace polling, improve scheduled triggers,
  reduce KVS writes, move work to the frontend, use bridge APIs, batch API calls, add caching, or evaluate Forge Remote
  trade-offs. By default, perform an audit first and offer to make the recommended changes after presenting the audit.
  Only modify files immediately when the user explicitly asks the agent to implement or apply optimizations.

Forge Cost Optimizer

Optimize Forge apps for lower platform consumption while preserving correctness, security, and maintainability. This skill turns Atlassian's Forge cost optimization guidance into an actionable agent workflow.

Source Guidance

Base recommendations on Atlassian's official guide: <https://developer.atlassian.com/platform/forge/optimise-forge-costs/>

If live Forge documentation tools are available, search the Forge docs for the exact module or API before changing code that depends on current manifest syntax, bridge APIs, storage APIs, trigger filters, or Forge Remote behavior.

Core Principle

Prioritize changes that reduce unnecessary work:

1. **Avoid invocations entirely** — move safe work to UI Kit / Custom UI frontend, use context from the bridge, replace polling with events, add trigger filters. 2. **Do less work per invocation** — bulk API calls, field selection, source-side filtering, pagination, early exits, bounded concurrency. 3. **Reduce billed data volume** — trim resolver payloads, reduce KVS reads/writes, avoid large log payloads, use entity properties where appropriate. 4. **Tune compute cost** — right-size `memoryMiB`, reduce duration, offload only when the operational trade-off is justified.

Never reduce costs by weakening authorization, exposing secrets to the frontend, skipping required validation, dropping necessary error handling, or making data stale beyond the user's business requirements.

When Triggered

When the user asks to optimize an existing Forge app, immediately inspect the app before asking questions unless the target app directory is ambiguous.

**Default behavior is audit-first:** complete the cost optimization audit, present prioritized recommendations, and ask the user whether they want the agent to make the recommended changes. Do not modify files during the initial audit unless the user explicitly requested implementation in the same prompt, such as "make the changes", "apply the optimizations", "fix these issues", or "update the code".

Read, in order:

1. `manifest.yml` / `manifest.yaml` — functions, modules, triggers, scheduled triggers, remotes, resources, permissions, endpoint mappings, `memoryMiB`. 2. `package.json` — dependencies, scripts, Forge package versions. 3. Backend/resolver code — `src/**`, handlers referenced by the manifest, storage usage, API calls, logging, async control flow. 4. Frontend code — UI Kit or Custom UI resources, bridge usage, `invoke()` patterns, render lifecycle, caching, payload needs. 5. Any tests or fixtures that describe behavior to preserve.

After the audit, offer clear next-step options such as implementing all quick wins, implementing selected high-impact changes, or collecting usage measurements first. If the user explicitly requested implementation upfront, make safe, localized improvements after the audit findings are understood and explain trade-offs.

Optimization Workflow

Step 1: Establish the Cost Profile

Identify which cost drivers the app likely uses:

| Driver | Inspect | Common signals | |---|---|---| | Function GB-seconds | `manifest.yml`, handlers | many resolver calls, slow sequential APIs, high `memoryMiB`, heavy transforms | | Invocations | frontend `invoke()`, triggers | calls on render, chatty UI, scheduled polling, broad event subscriptions | | KVS / Custom Entities | `storage.*` usage | writes on every request, loops over keys, low TTL cache churn, large values | | Logs | `console.*` | full event/API payload logging, debug logs in hot paths | | Forge SQL | SQL client usage | frequent compute requests, long queries, oversized stored data | | Remote / egress | `remotes`, fetch calls | external polling, compute offload candidates, Runs on Atlassian implications |

When usage metrics are unavailable, mark estimates as qualitative: `High`, `Medium`, `Low`, or `Unknown`.

Step 2: Find No-Invocation Opportunities

Prefer removing function invocations over making them cheaper.

Check for:

• Resolver calls that only fetch product context. Replace with:
• UI Kit: `useProductContext()` from `@forge/react`
• UI Kit or Custom UI: `view.getContext()` from `@forge/bridge`
• Read-only Jira/Confluence API calls routed through a resolver even though user-context access is acceptable. Consider `requestJira()` / `requestConfluence()` from `@forge/bridge`.
• Formatting, sorting, grouping, client-safe validation, or UI-only transformation in resolvers. Move to frontend when data is already authorized for the context user.
• `invoke()` calls inside render bodies, unbounded effects, repeated event handlers, or multiple calls on page load that can be cached or batched.

Keep logic in the backend when it requires `asApp()`, Forge storage, secrets, external credentials, cross-user authorization checks, or sensitive business rules.

Step 3: Optimize Triggers and Scheduling

Check `scheduledTrigger`, `trigger`, and `webtrigger` modules.

Recommended changes:

• Increase scheduled trigger intervals when business requirements allow (`fiveMinutes` → `hour` → `day` → `week`).
• Replace scheduled polling of Atlassian product changes with product events.
• Replace scheduled polling of external services with inbound webhooks via Forge web trigge