Update to Product Support Investigator

{
  "description": "Build, review, debug, and investigate Atlassian Forge apps and Jira/Confluence integrations, including Forge manifests, permissions, resolvers, REST calls, webhooks, storage, remote backends, and Rovo actions. Use when a request specifically involves Atlassian Forge or asks Jira/Rovo to interact with a Forge app.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 310
    }
  ],
  "name": "atlassian-forge",
  "skill_md_contents": "---\nname: atlassian-forge\ndescription: Build, review, debug, and investigate Atlassian Forge apps and Jira/Confluence integrations, including Forge manifests, permissions, resolvers, REST calls, webhooks, storage, remote backends, and Rovo actions. Use when a request specifically involves Atlassian Forge or asks Jira/Rovo to interact with a Forge app.\n---\n\n# Atlassian Forge\n\nUse this skill for Forge-specific implementation and support work. Keep the app's declared capabilities, user authorization, data residency, and deployment environment explicit.\n\n## Scope and evidence\n\n- Treat the repository, `manifest.yml`, Forge CLI output, app logs, Jira/Confluence responses, and Rovo context as separate evidence sources.\n- Never invent a Forge module, permission scope, event payload, deployment status, site, issue, account ID, or Rovo result.\n- Before changing code, identify the product (Jira, Confluence, or both), module/entry point, environment, expected behavior, observed behavior, and exact error or request ID.\n- Separate observed facts, inferences, and unknowns. State when the Forge CLI, Atlassian site, or Rovo context is unavailable.\n- Read-only investigation is the default. Treat deploy, install, upgrade, permission changes, data writes, and issue mutations as explicit mutations requiring user authorization in the current task.\n\n## Implementation workflow\n\n1. Inspect the existing app structure, `manifest.yml`, package scripts, runtime versions, and tests before proposing changes.\n2. Choose the smallest Forge module and resolver shape that satisfies the request. Preserve existing module keys and public action names unless a breaking change is requested.\n3. Derive permissions from the exact API operations and user/app execution identity. Request the narrowest scopes; do not add broad scopes “for convenience.”\n4. Make authorization boundaries visible: distinguish `asUser` from `asApp`, verify project/space permissions, and avoid treating app access as proof of user access.\n5. Validate inputs and outputs at resolver boundaries. Do not expose secrets, tokens, private issue data, internal errors, or unnecessary personal data to UI, logs, remote services, or Rovo.\n6. For remote backends, document the endpoint, authentication mode, egress permissions, timeout/retry behavior, failure mode, and whether the design affects Runs on Atlassian eligibility.\n7. Test locally where possible, then run the repository's lint/test checks and Forge validation available in the environment. Do not claim deployment or installation succeeded without command output proving it.\n8. Report changed files, checks run, remaining limitations, and any required manual steps (consent, install, deploy, or site-specific configuration).\n\n## Jira and Confluence API guidance\n\n- Prefer the official Forge API clients and documented product REST APIs over hand-built authentication.\n- Confirm the API version and required OAuth/Forge scopes from the specific operation documentation; do not infer scopes from a similar endpoint.\n- Preserve and inspect HTTP status, response body, pagination, rate-limit headers, and Atlassian request identifiers.\n- For webhooks/events, verify event type, payload version, delivery/retry semantics, idempotency, ordering assumptions, and whether the handler runs as a user or app.\n- For issue or content mutations, use idempotency safeguards where possible and make partial failure/retry behavior explicit.\n\n## Rovo interoperability\n\nWhen the request mentions Jira Rovo, Rovo agents, or Rovo actions:\n\n- Treat Rovo as a caller with its own product permissions and consent context. A Forge app does not automatically inherit access merely because Rovo can see a Jira issue.\n- If exposing an action to Rovo, use the Forge Rovo action module and the least required Rovo/Atlassian scopes. Describe the action's inputs, side effects, failure responses, and data returned to the agent.\n- Keep actions deterministic, bounded, and auditable. Prefer read-only actions for investigation; require explicit confirmation or a clearly stated mutation request for writes.\n- Return concise, structured results with stable field names, source identifiers, timestamps, and an uncertainty or limitation field when relevant.\n- Never claim that Jira Rovo can directly load a Codex `SKILL.md`. This skill is available to Codex through the plugin package; Rovo can use equivalent instructions only when an Atlassian/Rovo app or connector explicitly imports or exposes them.\n- If Rovo access is requested but no Rovo-capable connector, Forge app, or Atlassian environment is available, provide the implementation contract and state the access limitation instead of pretending the integration is enabled.\n\n## Debugging checklist\n\nCheck, in order:\n\n- manifest syntax, module keys, handler/export names, and package/runtime compatibility;\n- deployment environment versus installed environment;\n- missing or changed scopes and whether consent/reinstallation is required;\n- `asUser` versus `asApp` behavior and the caller's Jira/Confluence permissions;\n- request URL, API version, payload shape, pagination, rate limits, and request IDs;\n- resolver serialization, timeout, retry, duplicate delivery, and remote egress configuration;\n- recent deployment, configuration, permission, or Atlassian platform changes.\n\nFor every suspected cause, record supporting evidence, contradicting evidence, and the next check that would distinguish it. If evidence is insufficient, say: **Insufficient evidence to determine the root cause.**\n\n## Useful official references\n\nUse current Atlassian documentation for exact schemas and scopes:\n\n- [Forge manifest](https://developer.atlassian.com/platform/forge/manifest/)\n- [Forge permissions](https://developer.atlassian.com/platform/forge/manifest-reference/permissions/)\n- [Forge scopes](https://developer.atlassian.com/platform/forge/manifest-reference/scopes-forge/)\n- [Forge Rovo action module](https://developer.atlassian.com/platform/forge/manifest-reference/modules/rovo-action/)\n- [Forge Jira REST API](https://developer.atlassian.com/platform/forge/rest/v2/api-group-jira/)\n- [Forge `requestJira`](https://developer.atlassian.com/platform/forge/apis-reference/fetch-api-product.requestjira/)\n- [Forge Remote](https://developer.atlassian.com/platform/forge/remote/)\n\n## Output contract\n\nUnless the user requests another format, finish with:\n\n- **Outcome:** implemented, diagnosed, reviewed, or blocked;\n- **Forge surface:** product, module, resolver/API, environment;\n- **Observed / Inferred / Unknown:** clearly separated;\n- **Permissions and security:** scopes, execution identity, data exposure, and consent implications;\n- **Validation:** exact checks and results;\n- **Rovo compatibility:** whether Rovo can call it, what must be configured, and any limitation;\n- **Next actions:** concrete code, deployment, installation, or investigation steps.\n"
}