Connect to Forge Migration

Point this agent at an Atlassian Connect app and ask it to plan the move to Forge. It parses atlassian-connect.json, maps every module, scope, webhook, and AP.* call site to its Forge equivalent, scaffolds the manifest.yml and resolvers, and validates by deploying to a Forge development environment and installing on your development site.

What it does

1. Map the Connect app: descriptor modules, scopes, webhooks, JWT/iframe auth surfaces, and AP.* JavaScript API usage — each module tiered mechanical / rework / redesign.
2. Plan a module-by-module migration: UI Kit vs Custom UI per surface, storage strategy (Forge storage vs your existing database via remotes), and an incremental path that keeps the Connect backend running as a Forge remote while modules move.
3. Scaffold the Forge app: manifest.yml module mapping, resolver function stubs, permissions and egress declarations, and storage API usage sketches.
4. Sandbox — run forge lint, deploy to the development environment, and install on your development site; report PASS/PARTIAL/FAIL with lint output and install evidence.

Prerequisites

• FORGE_EMAIL — Atlassian account email for the Forge CLI
• FORGE_API_TOKEN — Atlassian API token for that account
• ATLASSIAN_SITE — <site>.atlassian.net development site used for forge install

Current scope

This solution migrates the app's descriptor, module surfaces, auth model, and storage strategy onto Forge. It does not migrate production tenant data out of your Connect database (it plans the strategy, including keeping data behind a Forge remote), does not publish to the Atlassian Marketplace or run the Connect-to-Forge listing transfer, and does not rewrite complex front ends wholesale — Custom UI surfaces get scaffolds and a porting checklist, not finished UIs.