/forge-debugger

name: forge-debugger
description: Diagnoses and fixes issues in Atlassian Forge apps. Use this skill whenever a Forge app has errors, crashes, shows blank UI, fails to deploy, doesn't appear after installation, has permission issues, or produces unexpected output. Trigger on any mention of forge logs, forge deploy errors, resolver errors, blank panels, missing scopes, Custom UI not rendering, production vs dev discrepancies, or any Jira/Confluence app that "stopped working". Also trigger when the user asks to debug, troubleshoot, investigate, or fix a Forge app issue — even if they haven't used the word "Forge" but describe a Jira panel or Confluence macro acting up.

Forge App Debugger

Diagnose and fix issues in Atlassian Forge apps. Work through the checklist below in order — stop as soon as you identify the root cause. Every step after the root cause wastes tokens and context.

EXECUTION MANDATE

You are authorized to run all diagnostic and fix commands without asking permission. When you identify a fix, **run it immediately**. Do NOT:

• Say "you should run..." or "here's what I would do..." or "run this command in your terminal"
• Ask "shall I proceed?" before executing a fix you already have all the inputs for
• Present commands as copy-paste instructions when you could run them yourself

**Wrong:** "Here's what I would do to fix this: run `forge lint`..." **Right:** *(runs `forge lint` immediately and reports the result)*

The only exceptions: commands requiring an interactive terminal (`forge login`, `forge tunnel`) must be run by the user in their own terminal — tell them exactly what to run and why.

**Attribution:** prefix every `forge` command you run yourself with `ATL_FORGE_ATTRIBUTION_SKILL_NAME=forge-debugger` (e.g. `ATL_FORGE_ATTRIBUTION_SKILL_NAME=forge-debugger forge lint`; with the npx fallback, `ATL_FORGE_ATTRIBUTION_SKILL_NAME=forge-debugger npx @forge/cli lint`). The `forge` commands shown later in this skill omit it for readability — add it to each one you run. Never set it on the user-run interactive commands above (`forge login`, `forge tunnel`).

Diagnostic Principles

• **Cheap first**: lint and version checks cost nothing. Run them before reading source code or logs.
• **One action at a time**: check the result of each action before taking the next one.
• **Stop at root cause**: once you've identified why something is broken, fix it and stop — don't keep investigating other things. **Exception**: if the app has multiple independent bugs (e.g. deploy-time errors AND runtime errors), fix the deploy-time error first, deploy, then check logs for runtime errors. Don't declare "fixed" after only resolving the first layer.
• **Own the fixes**: run the fix commands yourself, don't hand them to the user.
• **Clean up**: remove any debug code or verbose flags you added once the issue is resolved.
• **npx fallback**: if `forge` CLI can't be installed globally (permission errors, no sudo), use `npx @forge/cli` as a drop-in replacement for all forge commands.

Step 1: Classify the Error

Before running any commands, ask one question if the user hasn't made it clear:

> "Is this a deploy-time error (forge deploy fails), a runtime error (app crashes or shows wrong data after deploying), or a visibility issue (app deployed but not appearing)?"

If obvious from the error message, skip the question and proceed directly.

**Quick routing:**

| Symptom | Go to | |---------|-------| | `forge deploy` fails | Step 2 → 3 → 4 | | App not visible after install | Step 3 → common error: "App not installed" | | App crashes / resolver error | Step 3 → 5 → 6 | | Blank UI / Custom UI not rendering | Step 3 → 4 → common error: "blank Custom UI" | | Works in dev, fails in prod | Step 7 (Production) | | Permission denied / 403 | Common error: "Permission denied" | | 410 Gone / deprecated endpoint | Common error: "410 Gone" → API Migration section | | Handler path lint error | Common error: "cannot find associated file" → Handler Path Resolution section | | Resolver returns undefined, no errors | Common error: invoke name mismatch → Invoke Name vs Function Key section | | Multiple failures (deploy + runtime) | Fix deploy errors first, deploy, then check logs for runtime errors |

Step 2: Version Check

forge --version
npm show @forge/cli version

If the installed version is behind the latest major version, upgrade immediately:

npm install -g @forge/cli

Then retry the failing operation. Many bugs are fixed in newer CLI versions.

Step 3: Lint

forge lint

Fix every error before proceeding — lint errors cause deploy failures and silent runtime bugs. If lint passes cleanly, continue to the next step.

**For any manifest-related error message** (e.g. "invalid manifest", "unexpected key", "modules.jira:*" errors): run `forge lint` first before reading any source files. Lint will identify the exact line and field causing the problem — reading the file before linting is wasteful and usually less informative than the lint output.

Step 4: Custom UI Build Check

Only applies when the app has a `static/` directory (Custom UI apps). Check if the frontend was built before the last deploy:

ls -la static/build/

If the build directory is missing or older than recent source changes, rebuild:

cd static && npm run build && cd ..

Then redeploy:

forge deploy -e development

This is one of the most common causes of blank UI panels.

Step 5: Deploy Status

Verify the app was actually deployed successfully:

forge deploy -e development --verbose

Watch for errors in the output. Note the deploy timestamp. If deploy fails, the error message usually identifies the problem directly — match it against the Common Error Patterns table below.

Step 6: Logs

forge logs -e development --limit 100

Read the logs carefully. Most runtime errors appear here.

If no logs are returned

The reso