RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!
Project Summary
We are introducing rovo:skill, a new Forge module type that lets developers define AI skills directly inside a Forge app. A skill is a named, reusable AI capability backed by a SKILL.md instruction file and optional Forge tools. In v1, those tools are implemented as Forge action modules from the same app. When an app with rovo:skill modules is installed, those skills are automatically registered with the Atlassian Skills Registry, making them discoverable by Rovo Chat and other Atlassian agents without any additional configuration.
This RFC describes the developer experience, manifest design, packaging pipeline, skill lifecycle, end-user experience, and open questions we’re working through. We’re seeking feedback from Ecosystem partners before we finalise the implementation.
Publish: 29 May 2026
Discuss: 12 June 2026
Resolve: 17 June 2026
Problem
Forge developers can already expose callable capabilities to Rovo Studio agents through Forge action modules, and those actions can appear as ‘skills’ (soon, tools) in parts of the current UI. However, that model does not give developers a first-class way to package reusable skill instructions, examples, and supporting files that an agent can load at runtime.
Today, the gaps are:
- Developers cannot provide structured context and instructions that help agents complete complex tasks across one or more tools.
- Forge does not yet provide an ecosystem-facing skill packaging and registration model aligned with the Anthropic agent skills spec.
What’s the impact?
- Developers cannot expose their app’s domain expertise as structured, reusable skills with clear instructions, examples, and tool guidance.
- Rovo Chat and other Atlassian agents cannot reliably discover or use Forge app capabilities as ecosystem-contributed skills (other than basic
action). - Without a standard Forge packaging and registration model aligned with emerging agent-skills standards, developers must invent their own patterns for complex, multi-tool agent workflows.
Why now?
The Anthropic agent skills spec has emerged as a promising open standard for how skills should be defined and consumed by LLM-based agents. Atlassian is building an internal Skills Registry. We plan to extend this capability to Ecosystem developers so that third-party skills become a first-class part of the Atlassian agent ecosystem from the start.
Proposed Solution
We are proposing a new rovo:skill module type for Forge’s manifest.yml. A skill is a named capability backed by a SKILL.md instruction file (following the Anthropic agent skills spec) and a set of optional tool dependencies. In v1, those tool dependencies are Forge action modules from the same app. Forge handles bundling, validation, and registration with the Atlassian Skills Registry at deploy and install time.
Developer Experience
Three steps to ship a skill:
- Write a
SKILL.mdfile describing what your skill does and how to use your tools. - Declare a
rovo:skillmodule in manifest.yml pointing at that file and listing your Forge tool dependencies. - Run
forge deploy- Forge bundles and registers your skill automatically on install.
Developers declare one or more rovo:skill modules in their manifest.yml:
permissions:
scopes:
- read:jira-work # Scopes required by the tools this skill calls
resources:
- key: agent-skills
path: agent/skills # Directory containing one subdirectory per skill
modules:
function:
- key: get-issues-function
handler: src/index.getIssues
action:
- key: get-issues-action
function: get-issues-function
rovo:skill:
- key: jira-issue-analyst
name: Jira Issue Analyst
description: Helps agents retrieve, filter, and summarise Jira issues for a given project or sprint.
path: resource:agent-skills;jira-issue-analyst
dependencies:
tools:
- get-issues-action # reference to Forge action module key
Skill files live in subdirectories under the declared resources path:
agent/skills/
├── jira-issue-analyst/
│ ├── SKILL.md # Required — skill instruction file
│ ├── references/ # Optional — additional docs, examples
│ └── assets/ # Optional — images, data files
└── another-skill/
└── SKILL.md
SKILL.md follows the Anthropic agent skills spec. It contains YAML frontmatter with metadata, followed by natural-language instructions for the agent. The agent host (e.g. Rovo) loads this file when it decides to use your skill and uses the instructions to guide how it calls your tools, interprets results, and communicates with the user.
How it looks to users
The main end-user value is that installed Forge app skills can become available in Rovo Chat, not only in a partner-built agent experience. When Rovo Chat identifies a relevant task, it can discover the skill, load its instructions, call the associated tools, and respond to the user using the skill’s domain guidance.
Find and install skills on Skills Registry
Skills can be found, suggested and invoked directly from Rovo Chat
Invoked skills means app capability directly in Rovo chat experience
Module properties
| Property | Required | Description |
|---|---|---|
key |
Yes | Unique skill ID within the app; used in tooling and discovery |
name |
Yes | Human-readable name shown in the Skill Registry UI and agent skill selection |
description |
Yes | Short description used by the agent/LLM to decide when to invoke the skill. |
path |
Yes | Resource reference (resource:<key>;<subdir>) pointing to a directory containing SKILL.md |
dependencies.tools |
No | List of Forge tool dependencies the skill may invoke. In v1, these are Forge action module keys from the same app. |
Permissions and user consent
No new permission type is introduced for rovo:skill itself. The required OAuth scopes for a skill are exactly those needed by the Forge tools listed in dependencies.tools. In v1, those tools are Forge action modules, so developers declare the same scopes they would already declare for those actions.
Consent flow:
- When a user (or admin) installs a Forge app that includes
rovo:skillmodules, they grant consent for the app’s scopes at install time. - No additional consent step is required specifically for skills. The skill’s tools are constrained to the actions already authorised at install time.
- Site admins can see which skills are registered on their tenant via the Skills Registry (admin experience TBD - this is an open area)
Skill registrations are scoped per tenant. The same app installed on multiple Atlassian sites creates independent skill registrations, ensuring data and capability isolation between customers.
How skills are registered and discovered
The Atlassian Skills Registry stores skills in three progressive context layers, loaded progressively by the agent host to balance context window usage with completeness:
| Layer | Content | Used for |
|---|---|---|
| L1: Discovery | name, description, app ARI, tenant ARI |
Agent decides which skill is relevant for this task |
| L2: Instruction | Full SKILL.md content, tool list, auth hints (scopes) |
Agent loads full context before calling tools |
| L3: Files | Other files in the skill directory (references, assets) | Fetched by agent as referenced in SKILL.md |
Skill lifecycle:
- Install: Skills are automatically registered with the Skills Registry for the installing tenant. No extra developer step required.
- Uninstall: Skills are automatically deregistered for that tenant. Other tenants’ installs are unaffected.
- Redeploy: Updated skills are propagated to all active installs; new skills registered, changed skills updated, removed skills deregistered - scoped per tenant. Note: changes take effect immediately for new agent sessions. In-flight sessions that already loaded your skill complete with the previous version.
Skill and rovo:agent in the same app
If your app declares both a rovo:agent and a rovo:skill, the relationship between them is an open question we’re seeking feedback on. Two options we’re considering:
- Option A - Auto-wire: Skills in the same app are automatically available to the app’s
rovo:agentmodules, with no additional configuration - Option B - Explicit opt-in: The
rovo:agentmust explicitly list which skills it uses, similar to how it lists tools today
In both options, skills are registered globally in the Skills Registry and available to Rovo regardless of whether your app also has a rovo:agent.
What’s in v1 vs. future
| Capability | v1 | Future |
|---|---|---|
| Tool dependencies | Forge action modules from the same app only.Rationale: cross-app tool dependencies introduce complex permission and trust questions we want to design carefully. We plan to open this up once we have the right security model. |
External actions/tools, MCP servers, 1P Rovo Skills |
| Skill-to-skill dependencies | Not supported | Planned |
| Agent targeting | Skills available to all agents by default, including Rovo Chat where supported | Opt-in targeting (e.g. Rovo only, Rovo Dev only) |
| Error handling guidance | Developers can include error-handling guidance in SKILL.md, and Forge function/runtime errors follow the standard Forge action invocation path. |
More prescriptive skill error patterns and agent-host behaviour guidance |
| Local and end-to-end testing | Structural validation at lint/deploy time. Tool implementations can be tested through existing Forge workflows. | Dedicated eval-based skill testing harness |
| Cost and rate limits | Skills inherit the invocation limits and cost model of the Forge functions and actions they call. We do not plan to introduce additional skill-specific rate limits in v1. | Skill-level usage analytics and any future limits communicated as part of broader platform guidance |
| Skill versioning / gradual rollout | Not supported - redeployment propagates to all installs immediately | Phased rollout, version pinning |
| Skill observability | Standard Forge function logs via forge logs |
Skill-level invocation analytics (when, by which agent, success/failure) |
| Executable skill sources | Not supported (scripts/ directory) |
Requires Rovo coordination |
| Standalone skill distribution | Skills bundled with app install only | Marketplace-style standalone skill listing under consideration |
Asks
We’re open to all feedback as we work on this. In particular, we want to understand:
- How would you use skills and what use-cases would you support?
- What do you see as the high priority features we should invest in?
- What do you see as lacking or a blocker for the use case you have in mind?
- Does the developer experience feel right?