Skip to content

CONCEPT Cited by 2 sources

Agent orchestration skill

Definition

A skill (in the Rovo-Dev / Claude-Code sense of an addressable bundle of agent-facing instructions) that encodes a multi-step workflow, not a single narrow tool binding. The skill tells the agent how to work on a particular codebase end-to-end — the golden-path loops, the sequencing of tools, the verification checkpoints.

Atlassian's Rovo Dev / Fireworks post is the canonical articulation:

"We've built a meta-workflow / orchestration skill for Fireworks development. It doesn't do one narrow technical thing, instead it gives the agent a set of 'golden path' loops for how to work on Fireworks changes end-to-end." (Source: sources/2026-04-24-atlassian-rovo-dev-driven-development)

Two kinds of skills

Narrow / tool-binding skill Orchestration / meta-workflow skill
One domain or one action End-to-end workflow across domains
E.g. "how to use our CLI", "how to write a Raft test", "how to make a PR" E.g. "how to work on Fireworks changes end-to-end"
Answers what does this tool do Answers which tools in which order for this change shape
Single invocation Multi-step loop with checkpoints

The Fireworks post names the first kind ("Skills for PRs, using CLI, specific domains like Raft, gRPC") as the conventional skill and introduces the orchestration variant as the higher- leverage form for sustained work on a codebase.

Why orchestration skills matter

A coding agent's context budget is finite. For a complex codebase with many tools, many conventions, and a non-obvious golden-path sequence, the agent either:

  • Re-discovers the sequence every task — expensive, error- prone, and dependent on the agent's ability to piece together scattered README files.
  • Loads a pre-compiled orchestration skill — the sequence, conventions, and common traps are encoded once, loaded as context when the agent needs them, and maintained as the codebase evolves.

This is the procedural-knowledge analogue of a README — but structured for agent consumption rather than human onboarding. The Fireworks team reports the form factor works: "we've built lots of skills" and specifically "a skill that automates deploying, operating, and tearing down isolated Fireworks dev shards on the shared AWS scms Kubernetes cluster" — a second orchestration skill, for the dev-shard management sub-workflow.

What goes in an orchestration skill

Inferable from the Fireworks description:

  • Entry points — the workflows this skill covers ("raise a PR", "fix a failing test", "deploy to a dev shard").
  • Tool sequences — which tools to invoke in which order for each entry point.
  • Verification checkpoints — when to pause and check (run tests, check CI, read pipeline output).
  • Common traps / exclusions — things the agent should not do on this codebase ("don't skip the Helm validation step", "don't merge without running e2e").
  • Escape hatches — when to hand back to the human.

This is the same shape as a human team runbook, re-targeted at an LLM agent consumer.

Not the same as

  • A system prompt. The system prompt is always on. Skills are addressable — the agent loads them on demand. Maintaining a skill does not inflate every conversation.
  • A tool schema. A tool schema describes how to call a tool. An orchestration skill describes which tools to call in which order for a workflow.
  • A spec. A spec describes what the system does. A skill describes how the agent works on the system.

Per-codebase variability and skill-fallback chains

Atlassian's 2026-06-01 KTLO-automation post extends the orchestration-skill concept along a new axis: per-codebase variability across thousands of repositories.

"Atlassian hosts thousands of repositories owned by hundreds of teams, each with their own codebases and conventions so a 'one-size-fits-all' doesn't work. We've encoded our cleanup experience into repository-specific agent skills, and the system prompt gives each agent a clear fallback path: (1) repository's existing cleanup procedure → (2) flag the repo as needing a dedicated skill + provide owner instructions → (3) generic cleanup skill that works across most codebases." (Source: sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in)

Two new structural moves on top of the meta-workflow framing:

  • Repository-specific skills — the orchestration skill is scoped to one codebase, encoding its conventions / linters / flag wrapper APIs / test-cleanup discipline. Many such skills exist in parallel; the agent picks the one matching the repo it's working on.
  • Skill-fallback chain — when the repo-specific skill is absent, the agent's "no skill exists" failure mode is converted into operational signal that prompts the team to author one (tier 2), with a generic fallback (tier 3) producing a working draft PR even without a repo-specific skill. Canonicalised as patterns/agent-skill-with-fallback-chain.

The fallback-chain mechanic also generalises to other selector axes — Atlassian's flaky-test workflow uses per-test-category specialist skills with the same classify-then-dispatch shape (patterns/test-category-classifier-then-specialist-skill).

Two axes of skill specialisation

The wiki now names two distinct selector axes for orchestration skills:

Selector axis Skill shape Canonical instance
Per-codebase One orchestration skill per repository Atlassian KTLO cleanup; Fireworks dev-shard
Per-failure-category One specialist skill per failure type Atlassian flaky-test (unit / integration / visual)

The two axes can compose: a flaky-test agent can classify on test-category, then within that, fall back from repo-specific specialist skill → flag-for-creation → generic specialist skill.

Seen in

Last updated · 542 distilled / 1,571 read