Skip to content

Factories > Factory configuration

Factory skills

Open in ChatGPT ↗
Ask ChatGPT about this page
Open in Claude ↗
Ask Claude about this page
Copied!

Skills give a factory's agents repeatable, version-controlled procedures that can be shared across every agent or scoped to just one.

A skill tells an agent what to check, how to classify results, what to produce, and when to escalate. In a factory, skills are how you extend or override the default agents without editing their prompts directly.

A factory’s agents draw on three kinds of skills:

  • Built-in skills - SKILL.md files Warp adds to the factory definition for the code host, chat tool, and issue tracker you connect, plus shared code-quality and review procedures.
  • Custom skills - SKILL.md files your team adds to the definition, available to every agent or scoped to one.
  • Bundled Warp skills - Skills that ship with the Warp Agent harness, such as factory-files for editing definitions and factory-mcp for working with a factory through Factory MCP.

When you create a factory, Warp writes a set of skills into the definition’s skills/ directory so the agents know how to work with your tools before you write anything custom:

  • Code quality, code review, and UI verification - Every factory gets these three: the standard a code change is held to, how to review a change and write up findings, and how to capture visual proof of a UI change with Computer Use.
  • Code host - The skill for your connected code host: github, gitlab, or azuredevops. It covers branches, commits, draft pull requests, review comments, and CI status.
  • Chat tool - A slack or microsoft-teams skill when you connect that tool. The foreman’s instructions tell it to use the skill, since it’s the agent that replies in threads.
  • Issue tracker - A linear or jira skill when you connect that tracker. Connecting a tracker later adds its skill then.

Because these live under skills/, every agent in the factory can use them, including custom agents. They’re ordinary files: read them in the Factory definition tab of a Warp-managed factory or in the repository of a GitHub-backed one, and edit them the same way you edit any other skill. Anything you add alongside them extends the set rather than replacing it.

A custom skill is a directory containing a SKILL.md. It’s part of the factory’s definition, not an agent’s settings, and where you place the directory decides who can use it:

skills/
repository-conventions/
SKILL.md
agents/
foreman/
skills/
incident-triage/
SKILL.md
  • skills/<name>/SKILL.md - Available to every agent in the factory. Use this for procedures that apply regardless of role, such as your repository’s coding conventions or a shared escalation policy.
  • agents/<name>/skills/<name>/SKILL.md - Available only to that agent. Use this for procedures specific to one role, such as how the review agent applies your security checklist.

Both forms use the same SKILL.md format as skills anywhere else in Warp. See Skills for the file format, frontmatter, and argument syntax.

Add a custom skill when an agent needs to do something the built-in set doesn’t cover, such as:

  • Running a specific test, lint, or validation command before a change counts as complete.
  • Following a runbook for a category of incident or request your triage agent sees repeatedly.
  • Applying a security or compliance checklist during review that goes beyond general code quality.
  • Teaching a custom agent its job. Custom agents start with the factory-wide skills but no role instructions of their own.

A skill changes what an agent knows how to do, not what it can reach. To scope access, configure the agent’s secrets and MCP servers. See configure agent behavior and credential boundaries.

Where you edit a skill depends on where the factory’s definition lives:

  • Warp-managed - Add or edit SKILL.md files in the Factory definition tab of the factory dashboard. Saving validates and commits the change in one step.
  • GitHub-backed - Add or edit the files in the definition repository and open a pull request. The same pull request checks that validate the rest of the definition apply to skill files.

For a factory-wide skill and a per-agent skill side by side, see 02-sdlc-issue-to-pr in the warp-factory-examples repository.

Agents on the Warp Agent harness also carry Warp’s bundled skills, which aren’t files in your definition. The ones that matter for factory work are factory-files, which reads the definition schema and validates a definition tree, factory-mcp, which sends work to a factory and takes it back through Factory MCP, and oz-platform, which runs and inspects cloud agents through the API and CLI. In run data, a bundled skill load carries a bundled_skill_id; see skill actions in conversation data for the full list and how to tell bundled loads apart from your own skills.

A factory can propose changes to a skill. When Self-improvement is on for a Scorer and that Scorer flags a recurring failure, the follow-up run can edit the responsible skill the same way it can edit application code. The change arrives as a pull request for your team to review, in the factory dashboard or on your Git host.

  • Factory agents - The agents that use a factory’s skills, and how to configure each one.
  • Factory definition syntax - The full schema for factory.yaml, agents, automations, and runners alongside skills.
  • Skills - The general skill file format, shared across Warp, cloud agents, and factories.
  • Measure and improve a factory - How Self-improvement turns repeated failures into skill and code changes.