Factories > Factory configuration
Factory skills
# Factory skills A skill is a reusable, version-controlled procedure an agent can follow: what to check, how to classify results, what to produce, and when to escalate. In a factory, skills are how you extend or override what the [default agents](/factories/factory-agents/) already know how to do, without editing their prompts directly. :::note Warp Factories is in **Early Access** and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. ::: ## Factory-wide and per-agent skills A skill is a directory containing a `SKILL.md`, not a configuration key, so it follows the factory's [definition](/factories/factory-as-code/) rather than an agent's settings. Where you place that directory decides who can use it: ```text 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 should apply your security checklist. Both forms use the same `SKILL.md` format as skills anywhere else in Warp. See [Skills](/agents/capabilities/skills/) for the file format, front matter, and argument syntax. ## Built-in skills Every default agent starts with a baseline of built-in skills so the factory works immediately after setup, before you write anything custom: * **GitHub** - Every default agent gets a GitHub skill, covering how to read issues, open pull requests, and follow your repository's conventions. * **Slack** - The foreman also gets a Slack skill, since it's the agent that replies in threads and DMs. * **Issue tracker** - The tracker you choose during setup, Linear or Jira, adds that tracker's skill and instructions to the agents that use it. If you don't connect a tracker, agents keep only the GitHub and Slack baseline. These baseline skills aren't files in your definition; they come from the agent roles and integrations you choose. Anything you add under `skills/` or `agents/<name>/skills/` extends this baseline rather than replacing it. ## When to add a custom skill Add a custom skill when a default agent needs to do something the built-in baseline doesn't cover, such as: * Enforcing a specific test, lint, or validation command before a change is considered 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 (one you've added beyond the defaults) how to do its job at all, since a custom agent has no built-in skills of its own. A skill changes what an agent knows how to do, not what it can reach. Scoping what an agent can access is a [secrets](/platform/secrets/) and [MCP server](/platform/mcp/) configuration question, covered in [factory agents](/factories/factory-agents/#configure-agent-behavior) and [infrastructure and security](/factories/infrastructure-and-security/#credential-boundaries). ## Add or edit a skill Where you edit a skill depends on [where the factory's definition lives](/factories/factory-as-code/#where-the-definition-lives): * **Warp-managed** - Add or edit `SKILL.md` files directly in the **Factory definition** tab of the [factory dashboard](/factories/factory-dashboard/). Saving validates and commits the change in one step. * **GitHub or GitLab-backed** - Add or edit the files in the connected repository and open a pull request. The same [pull request checks](/factories/factory-as-code/#pull-request-checks-for-github-backed-factories) that validate the rest of the definition apply to skill files. For worked examples, including a factory-wide skill and a per-agent skill together, see [`02-sdlc-issue-to-pr`](https://github.com/warpdotdev/warp-factory-examples/tree/main/examples/02-sdlc-issue-to-pr) in the [warp-factory-examples](https://github.com/warpdotdev/warp-factory-examples) repository. ## Skills and self-improvement Skills are part of what a factory can propose changes to. When [Self-improvement](/factories/measure-and-improve/#configure-and-review-self-improvement) is on for a Scorer and it flags a recurring failure, the follow-up run it opens can edit the skill responsible, the same way it can edit application code. The change still arrives as a pull request for your team to review, whether that's through the factory dashboard or your Git host. ## Related pages * [Factory agents](/factories/factory-agents/) - The agents that use a factory's skills, and how to configure each one. * [Definitions as code](/factories/factory-as-code/) - The full schema for `factory.yaml`, agents, automations, and runners alongside skills. * [Skills](/agents/capabilities/skills/) - The general skill file format, shared across Warp, cloud agents, and factories. * [Measure and improve a factory](/factories/measure-and-improve/) - How Self-improvement turns repeated failures into skill and code changes.Tell me about this feature: https://docs.warp.dev/factories/factory-skills/Skills give a factory's agents repeatable, version-controlled procedures, shared across every agent or scoped to just one.
A skill is a reusable, version-controlled procedure an agent can follow: what to check, how to classify results, what to produce, and when to escalate. In a factory, skills are how you extend or override what the default agents already know how to do, without editing their prompts directly.
Factory-wide and per-agent skills
Section titled “Factory-wide and per-agent skills”A skill is a directory containing a SKILL.md, not a configuration key, so it follows the factory’s definition rather than an agent’s settings. Where you place that directory decides who can use it:
skills/ repository-conventions/ SKILL.mdagents/ foreman/ skills/ incident-triage/ SKILL.mdskills/<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 should apply your security checklist.
Both forms use the same SKILL.md format as skills anywhere else in Warp. See Skills for the file format, front matter, and argument syntax.
Built-in skills
Section titled “Built-in skills”Every default agent starts with a baseline of built-in skills so the factory works immediately after setup, before you write anything custom:
- GitHub - Every default agent gets a GitHub skill, covering how to read issues, open pull requests, and follow your repository’s conventions.
- Slack - The foreman also gets a Slack skill, since it’s the agent that replies in threads and DMs.
- Issue tracker - The tracker you choose during setup, Linear or Jira, adds that tracker’s skill and instructions to the agents that use it. If you don’t connect a tracker, agents keep only the GitHub and Slack baseline.
These baseline skills aren’t files in your definition; they come from the agent roles and integrations you choose. Anything you add under skills/ or agents/<name>/skills/ extends this baseline rather than replacing it.
When to add a custom skill
Section titled “When to add a custom skill”Add a custom skill when a default agent needs to do something the built-in baseline doesn’t cover, such as:
- Enforcing a specific test, lint, or validation command before a change is considered 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 (one you’ve added beyond the defaults) how to do its job at all, since a custom agent has no built-in skills of its own.
A skill changes what an agent knows how to do, not what it can reach. Scoping what an agent can access is a secrets and MCP server configuration question, covered in factory agents and infrastructure and security.
Add or edit a skill
Section titled “Add or edit a skill”Where you edit a skill depends on where the factory’s definition lives:
- Warp-managed - Add or edit
SKILL.mdfiles directly in the Factory definition tab of the factory dashboard. Saving validates and commits the change in one step. - GitHub or GitLab-backed - Add or edit the files in the connected repository and open a pull request. The same pull request checks that validate the rest of the definition apply to skill files.
For worked examples, including a factory-wide skill and a per-agent skill together, see 02-sdlc-issue-to-pr in the warp-factory-examples repository.
Skills and self-improvement
Section titled “Skills and self-improvement”Skills are part of what a factory can propose changes to. When Self-improvement is on for a Scorer and it flags a recurring failure, the follow-up run it opens can edit the skill responsible, the same way it can edit application code. The change still arrives as a pull request for your team to review, whether that’s through the factory dashboard or your Git host.
Related pages
Section titled “Related pages”- Factory agents - The agents that use a factory’s skills, and how to configure each one.
- Definitions as code - 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.