$npx -y skills add atlassian/forge-skills --skill forge-cost-optimizerOptimizes 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
| 1 | # Forge Cost Optimizer |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | ## Source Guidance |
| 6 | |
| 7 | Base recommendations on Atlassian's official guide: <https://developer.atlassian.com/platform/forge/optimise-forge-costs/> |
| 8 | |
| 9 | 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. |
| 10 | |
| 11 | ## Core Principle |
| 12 | |
| 13 | Prioritize changes that reduce unnecessary work: |
| 14 | |
| 15 | 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. |
| 16 | 2. **Do less work per invocation** — bulk API calls, field selection, source-side filtering, pagination, early exits, bounded concurrency. |
| 17 | 3. **Reduce billed data volume** — trim resolver payloads, reduce KVS reads/writes, avoid large log payloads, use entity properties where appropriate. |
| 18 | 4. **Tune compute cost** — right-size `memoryMiB`, reduce duration, offload only when the operational trade-off is justified. |
| 19 | |
| 20 | 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. |
| 21 | |
| 22 | ## When Triggered |
| 23 | |
| 24 | When the user asks to optimize an existing Forge app, immediately inspect the app before asking questions unless the target app directory is ambiguous. |
| 25 | |
| 26 | **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". |
| 27 | |
| 28 | Read, in order: |
| 29 | |
| 30 | 1. `manifest.yml` / `manifest.yaml` — functions, modules, triggers, scheduled triggers, remotes, resources, permissions, endpoint mappings, `memoryMiB`. |
| 31 | 2. `package.json` — dependencies, scripts, Forge package versions. |
| 32 | 3. Backend/resolver code — `src/**`, handlers referenced by the manifest, storage usage, API calls, logging, async control flow. |
| 33 | 4. Frontend code — UI Kit or Custom UI resources, bridge usage, `invoke()` patterns, render lifecycle, caching, payload needs. |
| 34 | 5. Any tests or fixtures that describe behavior to preserve. |
| 35 | |
| 36 | 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. |
| 37 | |
| 38 | ## Optimization Workflow |
| 39 | |
| 40 | ### Step 1: Establish the Cost Profile |
| 41 | |
| 42 | Identify which cost drivers the app likely uses: |
| 43 | |
| 44 | | Driver | Inspect | Common signals | |
| 45 | |---|---|---| |
| 46 | | Function GB-seconds | `manifest.yml`, handlers | many resolver calls, slow sequential APIs, high `memoryMiB`, heavy transforms | |
| 47 | | Invocations | frontend `invoke()`, triggers | calls on render, chatty UI, scheduled polling, broad event subscriptions | |
| 48 | | KVS / Custom Entities | `storage.*` usage | writes on every request, loops over keys, low TTL cache churn, large values | |
| 49 | | Logs | `console.*` | full event/API payload logging, debug logs in hot paths | |
| 50 | | Forge SQL | SQL client usage | frequent compute requests, long queries, oversized stored data | |
| 51 | | Remote / egress | `remotes`, fetch calls | external polling, compute offload candidates, Runs on Atlassian implications | |
| 52 | |
| 53 | When usage metrics are unavailable, mark estimates as qualitative: `High`, `Medium`, `Low`, or `Unknown`. |
| 54 | |
| 55 | ### Step 2: Find No-Invocation Opportunities |
| 56 | |
| 57 | Prefer removing function invocations over making them cheaper. |
| 58 | |
| 59 | Check for: |
| 60 | |
| 61 | - Resolver calls that only fetch product context. Replace with: |
| 62 | - UI Kit: `useProductContext()` from `@forge/react` |
| 63 | - UI Kit or Custom UI: `view.getContext()` from `@forge/bridge` |
| 64 | - Read-only Jira/Confluence API calls routed through a resolver even though u |