Product Support Investigator

View saved version →

---
name: atlassian-forge
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.
---

# Atlassian Forge

Use this skill for Forge-specific implementation and support work. Keep the app's declared capabilities, user authorization, data residency, and deployment environment explicit.

## Scope and evidence

- Treat the repository, `manifest.yml`, Forge CLI output, app logs, Jira/Confluence responses, and Rovo context as separate evidence sources.
- Never invent a Forge module, permission scope, event payload, deployment status, site, issue, account ID, or Rovo result.
- Before changing code, identify the product (Jira, Confluence, or both), module/entry point, environment, expected behavior, observed behavior, and exact error or request ID.
- Separate observed facts, inferences, and unknowns. State when the Forge CLI, Atlassian site, or Rovo context is unavailable.
- 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.

## Implementation workflow

1. Inspect the existing app structure, `manifest.yml`, package scripts, runtime versions, and tests before proposing changes.
2. 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.
3. Derive permissions from the exact API operations and user/app execution identity. Request the narrowest scopes; do not add broad scopes “for convenience.”
4. Make authorization boundaries visible: distinguish `asUser` from `asApp`, verify project/space permissions, and avoid treating app access as proof of user access.
5. 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.
6. For remote backends, document the endpoint, authentication mode, egress permissions, timeout/retry behavior, failure mode, and whether the design affects Runs on Atlassian eligibility.
7. 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.
8. Report changed files, checks run, remaining limitations, and any required manual steps (consent, install, deploy, or site-specific configuration).

## Jira and Confluence API guidance

- Prefer the official Forge API clients and documented product REST APIs over hand-built authentication.
- Confirm the API version and required OAuth/Forge scopes from the specific operation documentation; do not infer scopes from a similar endpoint.
- Preserve and inspect HTTP status, response body, pagination, rate-limit headers, and Atlassian request identifiers.
- For webhooks/events, verify event type, payload version, delivery/retry semantics, idempotency, ordering assumptions, and whether the handler runs as a user or app.
- For issue or content mutations, use idempotency safeguards where possible and make partial failure/retry behavior explicit.

## Rovo interoperability

When the request mentions Jira Rovo, Rovo agents, or Rovo actions:

- 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.
- 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.
- Keep actions deterministic, bounded, and auditable. Prefer read-only actions for investigation; require explicit confirmation or a clearly stated mutation request for writes.
- Return concise, structured results with stable field names, source identifiers, timestamps, and an uncertainty or limitation field when relevant.
- 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.
- 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.

## Debugging checklist

Check, in order:

- manifest syntax, module keys, handler/export names, and package/runtime compatibility;
- deployment environment versus installed environment;
- missing or changed scopes and whether consent/reinstallation is required;
- `asUser` versus `asApp` behavior and the caller's Jira/Confluence permissions;
- request URL, API version, payload shape, pagination, rate limits, and request IDs;
- resolver serialization, timeout, retry, duplicate delivery, and remote egress configuration;
- recent deployment, configuration, permission, or Atlassian platform changes.

For 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.**

## Useful official references

Use current Atlassian documentation for exact schemas and scopes:

- [Forge manifest](https://developer.atlassian.com/platform/forge/manifest/)
- [Forge permissions](https://developer.atlassian.com/platform/forge/manifest-reference/permissions/)
- [Forge scopes](https://developer.atlassian.com/platform/forge/manifest-reference/scopes-forge/)
- [Forge Rovo action module](https://developer.atlassian.com/platform/forge/manifest-reference/modules/rovo-action/)
- [Forge Jira REST API](https://developer.atlassian.com/platform/forge/rest/v2/api-group-jira/)
- [Forge `requestJira`](https://developer.atlassian.com/platform/forge/apis-reference/fetch-api-product.requestjira/)
- [Forge Remote](https://developer.atlassian.com/platform/forge/remote/)

## Output contract

Unless the user requests another format, finish with:

- **Outcome:** implemented, diagnosed, reviewed, or blocked;
- **Forge surface:** product, module, resolver/API, environment;
- **Observed / Inferred / Unknown:** clearly separated;
- **Permissions and security:** scopes, execution identity, data exposure, and consent implications;
- **Validation:** exact checks and results;
- **Rovo compatibility:** whether Rovo can call it, what must be configured, and any limitation;
- **Next actions:** concrete code, deployment, installation, or investigation steps.

Referenced files: 1

View saved version →

---
name: product-support-investigator
description: Vendor-neutral evidence-first investigation of technical customer and product issues.
---

# Product Support Investigator Community

Follow the repository root `SKILL.md`, which is the canonical methodology for all agent implementations. Use available evidence from tickets, telemetry, code, deployments, infrastructure, and customer reports; integrations are optional.

Preserve these non-negotiable rules:

- Separate **Observed**, **Inferred**, and **Unknown**.
- Never invent evidence or present assumptions as facts.
- Rank hypotheses and show evidence for, against, missing, and qualitative confidence (High, Medium, or Low).
- Decide whether the available evidence supports immediate investigation or requires minimal clarification; do not ask for information that tools can discover.
- Check recent changes, similar incidents, business impact, blast radius, risk, ownership, and next discriminating checks.
- Trace beyond an exception toward the deepest evidence-supported underlying cause.
- Treat negative evidence carefully: absence is meaningful only when the signal was expected and the source is complete enough.
- Treat successful related operations as control evidence and compare successful versus failing paths before blaming a shared dependency.
- Prefer differential investigation: isolate what exists only in the failing path before broad generic troubleshooting.
- Re-rank hypotheses when new or contradictory evidence appears; do not preserve the first leading hypothesis by default.
- Do not infer severity from the technical error alone; severity must follow demonstrated customer/business impact and failure scope.
- Distinguish customer/product, platform, integration, deployment, developer-tooling, local-environment, and observability failures.
- Treat pre-signed URLs, temporary tokens, and signed query strings as sensitive; do not expose or probe them with arbitrary HTTP methods.
- Missing logs or connectors do not prevent investigation; degrade gracefully using the evidence available.
- Keep investigation read-only by default and customer communication safe.

Adapt output depth to complexity and requested mode. Do not include empty sections. For Standard and Deep investigations, use relevant headings from this canonical full structure:

1. Executive Summary
2. Goal and Failure Stage
3. Issue Validation Status
4. Incident Classification
5. Business Impact
6. Technical Signals
7. Timeline / Last Known Success / Onset
8. Observed Facts
9. AI Inferences
10. Unknowns
11. Evidence
12. Correlations
13. Layer / Sequence Validation
14. Successful Control Paths / Differential Signals
15. Blast Radius
16. Similar Incidents / Known Issues
17. Recent Changes / Version Compatibility
18. Hypotheses
19. Root Cause Assessment
20. Risk Assessment
21. Investigation Checklist / Next Useful Check
22. Missing Evidence
23. Suggested Command or Search
24. Workaround
25. Customer Communication
26. Ownership Recommendation
27. Engineering Escalation
28. Confidence

Use evidence IDs (`E1`, `E2`) and correlation IDs (`C1`, `C2`). State unavailable connectors and limitations. If the evidence cannot distinguish causes, say: **Insufficient evidence to determine the root cause.**