From 82cb6eef9f5b754d352b245e6772515b99a73be9 Mon Sep 17 00:00:00 2001 From: Hong Yi Chen Date: Sat, 15 Aug 2026 16:43:05 -0700 Subject: [PATCH 1/6] docs(factories): document integrations and intake Co-Authored-By: Warp Agent --- .../docs/factories/connect-your-factory.mdx | 88 ++++++++++++++++--- 1 file changed, 77 insertions(+), 11 deletions(-) diff --git a/src/content/docs/factories/connect-your-factory.mdx b/src/content/docs/factories/connect-your-factory.mdx index 675c8bb9..3db4fad4 100644 --- a/src/content/docs/factories/connect-your-factory.mdx +++ b/src/content/docs/factories/connect-your-factory.mdx @@ -1,18 +1,84 @@ --- -title: Connect your Factory +title: Connect your factory description: >- - Route work into your Warp Factory from Slack, Linear, GitHub, and local - coding agents via the Factory MCP. + Route work into your factory from Slack, GitHub, Linear, Jira, local agents, + direct runs, and schedules. sidebar: - label: "Connect your Factory" + label: "Connect your factory" --- -[STUB — pending content from HYC/content team for the 8/18 closed-beta soft launch. Owner: HYC. +Connect a factory to the tools where work is discussed, tracked, and reviewed. Each intake path preserves source context and returns results. -Lightweight aggregation page — mostly link into existing detailed docs rather than duplicate them. Cover: -- How work enters a Factory: communication tools (Slack/Teams), task trackers (Linear/Jira), source forges (GitHub/GitLab) -- The Factory MCP: how any coding agent or MCP client can push work in, pull status, or guide sessions -- Integration with Warp Terminal and the Warp Agent CLI (native MCP support, local-to-factory handoff) -- API, SDK, and CLI for building custom integrations (cross-link to the Reference tab) +## Choose a source -Cross-link to the Automation Platform tab's Integrations docs for the underlying connector setup rather than duplicating it.] +| Source | Best for | Context continuity | Typical outputs | +| --- | --- | --- | --- | +| Slack | Chat and support requests | Thread or DM | Summary and issue or pull request links | +| GitHub | Issues, pull requests, reviews, and CI | Issue, pull request, or review thread | Comments, branches, and pull request links | +| Linear | Planned issues | Issue and agent session | Plans, updates, and pull request links | +| Jira | Rovo assignment | Rovo agent session | Task status and text result | +| Factory MCP | Local-agent handoffs | Work item | Notes and artifacts | +| Direct or scheduled automation | One-off or recurring work | Work item | Summaries and code changes | + +## Connect and verify intake + +1. Select a factory. Follow the [Warp Factories quickstart](./quickstart) if needed. +2. Authorize the provider at its narrowest scope, or configure the Factory MCP, a direct run, or a schedule. +3. Configure the intake path you chose. For provider events, set the automation's agent, run settings, subscriptions, and filters. For recurring work, configure a schedule. For one-off work, start a manual factory run handled by the foreman agent. +4. Trigger the path, then confirm the expected work item and source updates. + +## How intake works + +```mermaid +flowchart LR + Provider["Provider event"] --> Integration["Integration"] + Integration --> Match["Subscription and
filter matching"] + Match --> Automation["Configured automation"] + Schedule["Schedule tick"] --> Automation + Automation --> Foreman["Foreman run"] + Manual["Manual request"] --> Foreman + Foreman --> Work["Work item"] + Work --> Output["Updates and
artifacts"] +``` + +Provider events pass through integration and subscription/filter matching. Schedule ticks invoke their configured automation; manual requests start a foreman run. Every path creates a work item. See [how Warp Factories work](./how-factories-work) for later stages. + +## Review seeded default automations + +When you create a managed factory, Warp seeds provider-aware default automations for connected providers. + +| Provider | Seeded starting point | +| --- | --- | +| GitHub | Routes mentions and assignments into factory work, then handles pull requests when they close or merge. When a pull request is linked to tracker work, this handling can complete the tracker item when applicable. | +| Jira | Routes agent sessions from the selected Jira projects into factory work. | +| Slack | Uses the default automations described in the [Slack integration guide](./integrations/slack). | + +Treat these automations as starting points. Review and edit their subscriptions, filters, agents, and run settings to match your workflow. + +## Intake boundaries + +| Concern | Boundary and behavior | +| --- | --- | +| Authorization | Slack uses one app per factory. GitHub uses a GitHub App installation and repository grants. Linear uses an OAuth workspace connection. Jira uses a site connection. Grant the narrowest provider-supported scope. | +| Tracker selection | A factory can use Linear, Jira, or no issue tracker, but its definition can declare only one tracker. The selection changes the seeded tracker skill and prompt appendix. The setup wizard currently offers Linear; configure Jira after setup or through factory definitions. | +| Routing | Subscriptions and filters select an automation for provider events. A schedule tick invokes its configured automation directly. A manual request starts a foreman run directly. Filters can select repository, channel, team, project, label, author, or status when available; they do not reduce integration access. | +| Duplicate delivery | Providers can retry events. Warp avoids duplicate work when the source identifies a repeated delivery, but receiving workflows must remain safe to retry, especially for Jira. | +| Continuation | A new reply is not a duplicate. Slack threads; GitHub issues, pull requests, and review threads; and Linear issues and agent sessions can continue an existing work item. Jira continues through follow-ups in the same Rovo agent session. | +| Output policy | Writeback follows provider grants and separately configured repository credentials. Branch protection and review still apply; humans decide what merges. | + +## Integration guides + +* [Slack](./integrations/slack) - Route chat requests, direct messages, and thread follow-ups through a dedicated factory app. +* [GitHub](./integrations/github) - Route repository events with issue, pull request, review, or CI context. +* [Linear](./integrations/linear) - Route planned issues through issue activity and agent sessions. +* [Jira](./integrations/jira) - Route Jira Rovo assignments through an agent-session automation. + +## Factory MCP + +The Factory MCP connects local coding agents and other MCP clients to a factory. Use it to find work, inspect context, coordinate with the foreman, and return notes or completed artifacts to the same work item. See the [Factory MCP guide](./factory-mcp). + +## Direct and scheduled automation + +Start a manual factory run for one-off work without an external source. Use a scheduled automation for recurring maintenance or reports. Event-driven automations use a connected provider instead. See the [triggers overview](../platform/triggers/). + +Next, define the receiving agents and intake rules with [factory definitions as code](./factory-as-code). From 65303e9609256241fe2191afe49767a5818347dd Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 05:11:29 +0000 Subject: [PATCH 2/6] docs(factories): replace intake jargon with plain language on connect page Rewrites Connect your factory so external readers don't need internal vocabulary to follow it: - Drop 'intake' everywhere (intake paths, intake boundaries, how intake works); use plain framing like 'how work reaches your factory'. - Dissolve the 'Intake boundaries' grab-bag table into a 'Good to know' list scoped to user-facing behavior, and move provider authorization mechanics to the per-provider integration guides. - Remove internal implementation details: seeded tracker skill and prompt appendix, retry-safety guidance for receiving workflows, subscription-matching plumbing, and the unexplained 'managed factory' qualifier. - Simplify the flow diagram and setup steps; gloss 'foreman agent' and 'work item' on first mention per the terminology glossary. Validated with npm run build (377 pages), the style_lint skill (--changed, no findings for this page), and the broken-links checker (0 broken links). Co-Authored-By: Warp --- .../docs/factories/connect-your-factory.mdx | 89 +++++++++---------- 1 file changed, 43 insertions(+), 46 deletions(-) diff --git a/src/content/docs/factories/connect-your-factory.mdx b/src/content/docs/factories/connect-your-factory.mdx index 3db4fad4..eedd37b0 100644 --- a/src/content/docs/factories/connect-your-factory.mdx +++ b/src/content/docs/factories/connect-your-factory.mdx @@ -7,78 +7,75 @@ sidebar: label: "Connect your factory" --- -Connect a factory to the tools where work is discussed, tracked, and reviewed. Each intake path preserves source context and returns results. +Connect your factory to the tools where your team already discusses, tracks, and reviews work. Wherever work starts, the factory keeps the original context — the thread, issue, or pull request — and posts results back to the same place. ## Choose a source -| Source | Best for | Context continuity | Typical outputs | +| Source | Best for | Where follow-ups continue | What you get back | | --- | --- | --- | --- | -| Slack | Chat and support requests | Thread or DM | Summary and issue or pull request links | -| GitHub | Issues, pull requests, reviews, and CI | Issue, pull request, or review thread | Comments, branches, and pull request links | -| Linear | Planned issues | Issue and agent session | Plans, updates, and pull request links | -| Jira | Rovo assignment | Rovo agent session | Task status and text result | -| Factory MCP | Local-agent handoffs | Work item | Notes and artifacts | -| Direct or scheduled automation | One-off or recurring work | Work item | Summaries and code changes | +| Slack | Chat and support requests | The Slack thread or DM | A summary with issue or pull request links | +| GitHub | Issues, pull requests, reviews, and CI | The issue, pull request, or review thread | Comments, branches, and pull requests | +| Linear | Planned issues | The Linear issue and its agent session | Plans, status updates, and pull request links | +| Jira | Issues assigned to a Rovo agent | The Rovo agent session | Task status and a text result | +| Factory MCP | Sending work from a local coding agent | The factory work item | Notes and artifacts | +| Direct runs and schedules | One-off or recurring work | The factory work item | Summaries and code changes | -## Connect and verify intake +## Connect a source -1. Select a factory. Follow the [Warp Factories quickstart](./quickstart) if needed. -2. Authorize the provider at its narrowest scope, or configure the Factory MCP, a direct run, or a schedule. -3. Configure the intake path you chose. For provider events, set the automation's agent, run settings, subscriptions, and filters. For recurring work, configure a schedule. For one-off work, start a manual factory run handled by the foreman agent. -4. Trigger the path, then confirm the expected work item and source updates. +1. Pick the factory you want to connect. If you don't have one yet, follow the [Warp Factories quickstart](./quickstart). +2. Connect the source: install the provider integration, set up the [Factory MCP](./factory-mcp), or create a schedule. Each integration guide below walks through authorization — grant only the access the factory needs. +3. Tell the factory how to respond. Provider connections come with default automations that decide which events start work and which agent handles them; review their filters and run settings. Schedules and direct runs skip this step. +4. Send a test request — for example, mention the factory in Slack or assign it an issue — and confirm it picks up the work and replies at the source. -## How intake works +## How work reaches your factory ```mermaid flowchart LR - Provider["Provider event"] --> Integration["Integration"] - Integration --> Match["Subscription and
filter matching"] - Match --> Automation["Configured automation"] - Schedule["Schedule tick"] --> Automation - Automation --> Foreman["Foreman run"] - Manual["Manual request"] --> Foreman + Event["Event from a
connected tool"] --> Automation["Matching
automation"] + Schedule["Schedule"] --> Automation + Automation --> Foreman["Foreman agent"] + Direct["Direct request"] --> Foreman Foreman --> Work["Work item"] - Work --> Output["Updates and
artifacts"] + Work --> Results["Results posted
back to the source"] ``` -Provider events pass through integration and subscription/filter matching. Schedule ticks invoke their configured automation; manual requests start a foreman run. Every path creates a work item. See [how Warp Factories work](./how-factories-work) for later stages. +An event from a connected tool starts the automation whose filters match it — a specific repository, channel, or label, for example. Schedules start their automation on a timer, and direct requests go straight to the factory. In every case, the factory's foreman agent — the orchestrator that assigns work to the right agents — turns the request into a work item and sees it through. See [how Warp Factories work](./how-factories-work) for what happens next. -## Review seeded default automations +## Review the default automations -When you create a managed factory, Warp seeds provider-aware default automations for connected providers. +When you create a factory through the setup wizard, Warp adds default automations for each tool you connect, so common requests work immediately: -| Provider | Seeded starting point | -| --- | --- | -| GitHub | Routes mentions and assignments into factory work, then handles pull requests when they close or merge. When a pull request is linked to tracker work, this handling can complete the tracker item when applicable. | -| Jira | Routes agent sessions from the selected Jira projects into factory work. | -| Slack | Uses the default automations described in the [Slack integration guide](./integrations/slack). | +* **GitHub** - Starts work when the factory is mentioned or assigned, and follows up when pull requests close or merge — including completing a linked tracker issue when it can. +* **Jira** - Starts work when a Rovo agent session begins in one of the Jira projects you selected. +* **Slack** - Starts work from mentions and messages, as described in the [Slack integration guide](./integrations/slack). -Treat these automations as starting points. Review and edit their subscriptions, filters, agents, and run settings to match your workflow. - -## Intake boundaries - -| Concern | Boundary and behavior | -| --- | --- | -| Authorization | Slack uses one app per factory. GitHub uses a GitHub App installation and repository grants. Linear uses an OAuth workspace connection. Jira uses a site connection. Grant the narrowest provider-supported scope. | -| Tracker selection | A factory can use Linear, Jira, or no issue tracker, but its definition can declare only one tracker. The selection changes the seeded tracker skill and prompt appendix. The setup wizard currently offers Linear; configure Jira after setup or through factory definitions. | -| Routing | Subscriptions and filters select an automation for provider events. A schedule tick invokes its configured automation directly. A manual request starts a foreman run directly. Filters can select repository, channel, team, project, label, author, or status when available; they do not reduce integration access. | -| Duplicate delivery | Providers can retry events. Warp avoids duplicate work when the source identifies a repeated delivery, but receiving workflows must remain safe to retry, especially for Jira. | -| Continuation | A new reply is not a duplicate. Slack threads; GitHub issues, pull requests, and review threads; and Linear issues and agent sessions can continue an existing work item. Jira continues through follow-ups in the same Rovo agent session. | -| Output policy | Writeback follows provider grants and separately configured repository credentials. Branch protection and review still apply; humans decide what merges. | +These defaults are starting points. Review each automation's filters, agent, and run settings, and adjust them to match your workflow. ## Integration guides * [Slack](./integrations/slack) - Route chat requests, direct messages, and thread follow-ups through a dedicated factory app. * [GitHub](./integrations/github) - Route repository events with issue, pull request, review, or CI context. * [Linear](./integrations/linear) - Route planned issues through issue activity and agent sessions. -* [Jira](./integrations/jira) - Route Jira Rovo assignments through an agent-session automation. +* [Jira](./integrations/jira) - Route issues assigned to a Rovo agent into factory work. ## Factory MCP -The Factory MCP connects local coding agents and other MCP clients to a factory. Use it to find work, inspect context, coordinate with the foreman, and return notes or completed artifacts to the same work item. See the [Factory MCP guide](./factory-mcp). +The Factory MCP connects local coding agents and other MCP clients to your factory. Use it to send work to the factory from your terminal, check status, coordinate with the foreman agent, and hand finished work back to the same work item. See the [Factory MCP guide](./factory-mcp). + +## Direct runs and schedules + +Not every task starts in an external tool: + +* Start a direct factory run for one-off work — describe the task, and the foreman agent takes it from there. +* Create a scheduled automation for recurring work such as maintenance or reports. + +See the [triggers overview](../platform/triggers/) for how schedules and other triggers work across the platform. -## Direct and scheduled automation +## Good to know -Start a manual factory run for one-off work without an external source. Use a scheduled automation for recurring maintenance or reports. Event-driven automations use a connected provider instead. See the [triggers overview](../platform/triggers/). +* **Follow-ups continue the same work item** - Replying in the same Slack thread, GitHub issue or pull request, Linear issue, or Jira Rovo session adds to the existing work item instead of starting a new one. Repeated event deliveries from a provider don't create duplicate work either. +* **One issue tracker per factory** - A factory can use Linear or Jira, or no tracker at all — but not both at once. The setup wizard currently offers Linear; to use Jira, connect it after setup or in your [factory definition](./factory-as-code). +* **Filters route work, they don't restrict access** - Automation filters (repository, channel, team, project, label, author, or status) choose which requests start work. To limit what an integration can reach, change what you authorize for that provider instead. +* **You stay in control of what ships** - The factory posts back only where you've connected it, and pushes code with the repository credentials you configure. Branch protection and code review still apply; your team decides what merges. -Next, define the receiving agents and intake rules with [factory definitions as code](./factory-as-code). +Next, customize which agents receive work and how it's routed with [factory definitions as code](./factory-as-code). From 0c3ffa065ea2b3da5d6e1f2048eafc2ed929f56a Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 05:15:51 +0000 Subject: [PATCH 3/6] docs(factories): link provider mentions to their integration guides Link Slack, GitHub, Linear, Jira, and Factory MCP from the source table, the default-automation bullets, and the tracker-selection note so readers can jump straight to the relevant guide from wherever a provider is mentioned. Validated with the style_lint skill (no findings for this page) and the broken-links checker (0 broken links). Co-Authored-By: Warp --- .../docs/factories/connect-your-factory.mdx | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/content/docs/factories/connect-your-factory.mdx b/src/content/docs/factories/connect-your-factory.mdx index eedd37b0..89faaf23 100644 --- a/src/content/docs/factories/connect-your-factory.mdx +++ b/src/content/docs/factories/connect-your-factory.mdx @@ -13,11 +13,11 @@ Connect your factory to the tools where your team already discusses, tracks, and | Source | Best for | Where follow-ups continue | What you get back | | --- | --- | --- | --- | -| Slack | Chat and support requests | The Slack thread or DM | A summary with issue or pull request links | -| GitHub | Issues, pull requests, reviews, and CI | The issue, pull request, or review thread | Comments, branches, and pull requests | -| Linear | Planned issues | The Linear issue and its agent session | Plans, status updates, and pull request links | -| Jira | Issues assigned to a Rovo agent | The Rovo agent session | Task status and a text result | -| Factory MCP | Sending work from a local coding agent | The factory work item | Notes and artifacts | +| [Slack](./integrations/slack) | Chat and support requests | The Slack thread or DM | A summary with issue or pull request links | +| [GitHub](./integrations/github) | Issues, pull requests, reviews, and CI | The issue, pull request, or review thread | Comments, branches, and pull requests | +| [Linear](./integrations/linear) | Planned issues | The Linear issue and its agent session | Plans, status updates, and pull request links | +| [Jira](./integrations/jira) | Issues assigned to a Rovo agent | The Rovo agent session | Task status and a text result | +| [Factory MCP](./factory-mcp) | Sending work from a local coding agent | The factory work item | Notes and artifacts | | Direct runs and schedules | One-off or recurring work | The factory work item | Summaries and code changes | ## Connect a source @@ -45,8 +45,8 @@ An event from a connected tool starts the automation whose filters match it — When you create a factory through the setup wizard, Warp adds default automations for each tool you connect, so common requests work immediately: -* **GitHub** - Starts work when the factory is mentioned or assigned, and follows up when pull requests close or merge — including completing a linked tracker issue when it can. -* **Jira** - Starts work when a Rovo agent session begins in one of the Jira projects you selected. +* **GitHub** - Starts work when the factory is mentioned or assigned, and follows up when pull requests close or merge — including completing a linked tracker issue when it can. See the [GitHub integration guide](./integrations/github). +* **Jira** - Starts work when a Rovo agent session begins in one of the Jira projects you selected. See the [Jira integration guide](./integrations/jira). * **Slack** - Starts work from mentions and messages, as described in the [Slack integration guide](./integrations/slack). These defaults are starting points. Review each automation's filters, agent, and run settings, and adjust them to match your workflow. @@ -74,7 +74,7 @@ See the [triggers overview](../platform/triggers/) for how schedules and other t ## Good to know * **Follow-ups continue the same work item** - Replying in the same Slack thread, GitHub issue or pull request, Linear issue, or Jira Rovo session adds to the existing work item instead of starting a new one. Repeated event deliveries from a provider don't create duplicate work either. -* **One issue tracker per factory** - A factory can use Linear or Jira, or no tracker at all — but not both at once. The setup wizard currently offers Linear; to use Jira, connect it after setup or in your [factory definition](./factory-as-code). +* **One issue tracker per factory** - A factory can use [Linear](./integrations/linear) or [Jira](./integrations/jira), or no tracker at all — but not both at once. The setup wizard currently offers Linear; to use Jira, connect it after setup or in your [factory definition](./factory-as-code). * **Filters route work, they don't restrict access** - Automation filters (repository, channel, team, project, label, author, or status) choose which requests start work. To limit what an integration can reach, change what you authorize for that provider instead. * **You stay in control of what ships** - The factory posts back only where you've connected it, and pushes code with the repository credentials you configure. Branch protection and code review still apply; your team decides what merges. From 935a971870174bd51d280c58b83a2e9e262bb638 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 05:30:34 +0000 Subject: [PATCH 4/6] docs(factories): Jira work goes to Warp, surfaced through Rovo The agent users assign or mention in Jira is Warp (the rovo:agentConnector module named 'Warp' in forge-jira/manifest.yml), not a generic Rovo agent. Rovo is Atlassian's framework that surfaces it; the conversation still happens in a Rovo agent session (A2A agent_session_created ingress). Reword the source table, Jira default-automation bullet, and integration guides bullet accordingly, and align 'Rovo agent session' phrasing with the Jira integration guide. Co-Authored-By: Warp --- src/content/docs/factories/connect-your-factory.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/docs/factories/connect-your-factory.mdx b/src/content/docs/factories/connect-your-factory.mdx index 89faaf23..86911677 100644 --- a/src/content/docs/factories/connect-your-factory.mdx +++ b/src/content/docs/factories/connect-your-factory.mdx @@ -16,7 +16,7 @@ Connect your factory to the tools where your team already discusses, tracks, and | [Slack](./integrations/slack) | Chat and support requests | The Slack thread or DM | A summary with issue or pull request links | | [GitHub](./integrations/github) | Issues, pull requests, reviews, and CI | The issue, pull request, or review thread | Comments, branches, and pull requests | | [Linear](./integrations/linear) | Planned issues | The Linear issue and its agent session | Plans, status updates, and pull request links | -| [Jira](./integrations/jira) | Issues assigned to a Rovo agent | The Rovo agent session | Task status and a text result | +| [Jira](./integrations/jira) | Work items assigned to Warp through Rovo | The Rovo agent session | Task status and a text result | | [Factory MCP](./factory-mcp) | Sending work from a local coding agent | The factory work item | Notes and artifacts | | Direct runs and schedules | One-off or recurring work | The factory work item | Summaries and code changes | @@ -46,7 +46,7 @@ An event from a connected tool starts the automation whose filters match it — When you create a factory through the setup wizard, Warp adds default automations for each tool you connect, so common requests work immediately: * **GitHub** - Starts work when the factory is mentioned or assigned, and follows up when pull requests close or merge — including completing a linked tracker issue when it can. See the [GitHub integration guide](./integrations/github). -* **Jira** - Starts work when a Rovo agent session begins in one of the Jira projects you selected. See the [Jira integration guide](./integrations/jira). +* **Jira** - Starts work when someone assigns or mentions Warp on a work item in one of the Jira projects you selected. See the [Jira integration guide](./integrations/jira). * **Slack** - Starts work from mentions and messages, as described in the [Slack integration guide](./integrations/slack). These defaults are starting points. Review each automation's filters, agent, and run settings, and adjust them to match your workflow. @@ -56,7 +56,7 @@ These defaults are starting points. Review each automation's filters, agent, and * [Slack](./integrations/slack) - Route chat requests, direct messages, and thread follow-ups through a dedicated factory app. * [GitHub](./integrations/github) - Route repository events with issue, pull request, review, or CI context. * [Linear](./integrations/linear) - Route planned issues through issue activity and agent sessions. -* [Jira](./integrations/jira) - Route issues assigned to a Rovo agent into factory work. +* [Jira](./integrations/jira) - Route work items assigned to Warp in Jira through Rovo agent sessions. ## Factory MCP @@ -73,7 +73,7 @@ See the [triggers overview](../platform/triggers/) for how schedules and other t ## Good to know -* **Follow-ups continue the same work item** - Replying in the same Slack thread, GitHub issue or pull request, Linear issue, or Jira Rovo session adds to the existing work item instead of starting a new one. Repeated event deliveries from a provider don't create duplicate work either. +* **Follow-ups continue the same work item** - Replying in the same Slack thread, GitHub issue or pull request, Linear issue, or Jira Rovo agent session adds to the existing work item instead of starting a new one. Repeated event deliveries from a provider don't create duplicate work either. * **One issue tracker per factory** - A factory can use [Linear](./integrations/linear) or [Jira](./integrations/jira), or no tracker at all — but not both at once. The setup wizard currently offers Linear; to use Jira, connect it after setup or in your [factory definition](./factory-as-code). * **Filters route work, they don't restrict access** - Automation filters (repository, channel, team, project, label, author, or status) choose which requests start work. To limit what an integration can reach, change what you authorize for that provider instead. * **You stay in control of what ships** - The factory posts back only where you've connected it, and pushes code with the repository credentials you configure. Branch protection and code review still apply; your team decides what merges. From 0cc70f16a7d8465ebe1003c5700ea86c18e3195e Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 05:37:21 +0000 Subject: [PATCH 5/6] docs(factories): de-emphasize Rovo on the connect overview MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lead with what matters to the reader: Jira work items are assigned to Warp. Drop the remaining Rovo mentions from the source table, the Jira integration-guides bullet, and the follow-ups note — the Jira guide covers the Rovo session mechanics. Co-Authored-By: Warp --- src/content/docs/factories/connect-your-factory.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/content/docs/factories/connect-your-factory.mdx b/src/content/docs/factories/connect-your-factory.mdx index 86911677..e6587177 100644 --- a/src/content/docs/factories/connect-your-factory.mdx +++ b/src/content/docs/factories/connect-your-factory.mdx @@ -16,7 +16,7 @@ Connect your factory to the tools where your team already discusses, tracks, and | [Slack](./integrations/slack) | Chat and support requests | The Slack thread or DM | A summary with issue or pull request links | | [GitHub](./integrations/github) | Issues, pull requests, reviews, and CI | The issue, pull request, or review thread | Comments, branches, and pull requests | | [Linear](./integrations/linear) | Planned issues | The Linear issue and its agent session | Plans, status updates, and pull request links | -| [Jira](./integrations/jira) | Work items assigned to Warp through Rovo | The Rovo agent session | Task status and a text result | +| [Jira](./integrations/jira) | Work items assigned to Warp | The Jira agent session | Task status and a text result | | [Factory MCP](./factory-mcp) | Sending work from a local coding agent | The factory work item | Notes and artifacts | | Direct runs and schedules | One-off or recurring work | The factory work item | Summaries and code changes | @@ -56,7 +56,7 @@ These defaults are starting points. Review each automation's filters, agent, and * [Slack](./integrations/slack) - Route chat requests, direct messages, and thread follow-ups through a dedicated factory app. * [GitHub](./integrations/github) - Route repository events with issue, pull request, review, or CI context. * [Linear](./integrations/linear) - Route planned issues through issue activity and agent sessions. -* [Jira](./integrations/jira) - Route work items assigned to Warp in Jira through Rovo agent sessions. +* [Jira](./integrations/jira) - Route Jira work items assigned to Warp into factory work. ## Factory MCP @@ -73,7 +73,7 @@ See the [triggers overview](../platform/triggers/) for how schedules and other t ## Good to know -* **Follow-ups continue the same work item** - Replying in the same Slack thread, GitHub issue or pull request, Linear issue, or Jira Rovo agent session adds to the existing work item instead of starting a new one. Repeated event deliveries from a provider don't create duplicate work either. +* **Follow-ups continue the same work item** - Replying in the same Slack thread, GitHub issue or pull request, Linear issue, or Jira agent session adds to the existing work item instead of starting a new one. Repeated event deliveries from a provider don't create duplicate work either. * **One issue tracker per factory** - A factory can use [Linear](./integrations/linear) or [Jira](./integrations/jira), or no tracker at all — but not both at once. The setup wizard currently offers Linear; to use Jira, connect it after setup or in your [factory definition](./factory-as-code). * **Filters route work, they don't restrict access** - Automation filters (repository, channel, team, project, label, author, or status) choose which requests start work. To limit what an integration can reach, change what you authorize for that provider instead. * **You stay in control of what ships** - The factory posts back only where you've connected it, and pushes code with the repository credentials you configure. Branch protection and code review still apply; your team decides what merges. From eb37158637bcb00d47a4feb032da4d991e1dd888 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Sun, 16 Aug 2026 22:30:40 +0000 Subject: [PATCH 6/6] docs(factories): tighten connect page from review feedback - Drop the vague 'What you get back' table column; the intro already covers results posting back to the source - Expand the foreman description: what it orchestrates (triage, spec, implementation, review) and where it pauses for humans - Replace the marketing-toned 'You stay in control of what ships' bullet with a factual pull-request hand-off note - Remove em dashes from procedural steps and reduce them elsewhere Co-Authored-By: Warp --- .../docs/factories/connect-your-factory.mdx | 36 ++++++++++--------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/src/content/docs/factories/connect-your-factory.mdx b/src/content/docs/factories/connect-your-factory.mdx index e6587177..1fa274bb 100644 --- a/src/content/docs/factories/connect-your-factory.mdx +++ b/src/content/docs/factories/connect-your-factory.mdx @@ -11,21 +11,23 @@ Connect your factory to the tools where your team already discusses, tracks, and ## Choose a source -| Source | Best for | Where follow-ups continue | What you get back | -| --- | --- | --- | --- | -| [Slack](./integrations/slack) | Chat and support requests | The Slack thread or DM | A summary with issue or pull request links | -| [GitHub](./integrations/github) | Issues, pull requests, reviews, and CI | The issue, pull request, or review thread | Comments, branches, and pull requests | -| [Linear](./integrations/linear) | Planned issues | The Linear issue and its agent session | Plans, status updates, and pull request links | -| [Jira](./integrations/jira) | Work items assigned to Warp | The Jira agent session | Task status and a text result | -| [Factory MCP](./factory-mcp) | Sending work from a local coding agent | The factory work item | Notes and artifacts | -| Direct runs and schedules | One-off or recurring work | The factory work item | Summaries and code changes | +Pick the sources that match where work starts for your team. You can connect more than one. + +| Source | Best for | Where follow-ups continue | +| --- | --- | --- | +| [Slack](./integrations/slack) | Chat and support requests | The Slack thread or DM | +| [GitHub](./integrations/github) | Issues, pull requests, reviews, and CI | The issue, pull request, or review thread | +| [Linear](./integrations/linear) | Planned issues | The Linear issue and its agent session | +| [Jira](./integrations/jira) | Work items assigned to Warp | The Jira agent session | +| [Factory MCP](./factory-mcp) | Sending work from a local coding agent | The factory work item | +| Direct runs and schedules | One-off or recurring work | The factory work item | ## Connect a source 1. Pick the factory you want to connect. If you don't have one yet, follow the [Warp Factories quickstart](./quickstart). -2. Connect the source: install the provider integration, set up the [Factory MCP](./factory-mcp), or create a schedule. Each integration guide below walks through authorization — grant only the access the factory needs. +2. Connect the source: install the provider integration, set up the [Factory MCP](./factory-mcp), or create a schedule. Each integration guide below walks through authorization; grant only the access the factory needs. 3. Tell the factory how to respond. Provider connections come with default automations that decide which events start work and which agent handles them; review their filters and run settings. Schedules and direct runs skip this step. -4. Send a test request — for example, mention the factory in Slack or assign it an issue — and confirm it picks up the work and replies at the source. +4. Send a test request, such as mentioning the factory in Slack or assigning it an issue, and confirm it picks up the work and replies at the source. ## How work reaches your factory @@ -39,13 +41,15 @@ flowchart LR Work --> Results["Results posted
back to the source"] ``` -An event from a connected tool starts the automation whose filters match it — a specific repository, channel, or label, for example. Schedules start their automation on a timer, and direct requests go straight to the factory. In every case, the factory's foreman agent — the orchestrator that assigns work to the right agents — turns the request into a work item and sees it through. See [how Warp Factories work](./how-factories-work) for what happens next. +An event from a connected tool starts the automation whose filters match it, such as a specific repository, channel, or label. Schedules start their automation on a timer, and direct requests go straight to the factory. + +Every request then lands with the foreman agent, the factory's orchestrator. The foreman turns the request into a work item, works out which stage the work needs next, and dispatches a specialized agent for each stage: triage to scope the request, spec when the design needs agreement, implementation to write the code, and review to check it. Between stages it relays questions and progress back to the source, and it pauses wherever a decision belongs to a human, such as approving a spec or merging a pull request. See [how Warp Factories work](./how-factories-work) for the full lifecycle. ## Review the default automations When you create a factory through the setup wizard, Warp adds default automations for each tool you connect, so common requests work immediately: -* **GitHub** - Starts work when the factory is mentioned or assigned, and follows up when pull requests close or merge — including completing a linked tracker issue when it can. See the [GitHub integration guide](./integrations/github). +* **GitHub** - Starts work when the factory is mentioned or assigned, and follows up when pull requests close or merge, completing a linked tracker issue when it can. See the [GitHub integration guide](./integrations/github). * **Jira** - Starts work when someone assigns or mentions Warp on a work item in one of the Jira projects you selected. See the [Jira integration guide](./integrations/jira). * **Slack** - Starts work from mentions and messages, as described in the [Slack integration guide](./integrations/slack). @@ -66,7 +70,7 @@ The Factory MCP connects local coding agents and other MCP clients to your facto Not every task starts in an external tool: -* Start a direct factory run for one-off work — describe the task, and the foreman agent takes it from there. +* Start a direct factory run for one-off work: describe the task and the foreman agent takes it from there. * Create a scheduled automation for recurring work such as maintenance or reports. See the [triggers overview](../platform/triggers/) for how schedules and other triggers work across the platform. @@ -74,8 +78,8 @@ See the [triggers overview](../platform/triggers/) for how schedules and other t ## Good to know * **Follow-ups continue the same work item** - Replying in the same Slack thread, GitHub issue or pull request, Linear issue, or Jira agent session adds to the existing work item instead of starting a new one. Repeated event deliveries from a provider don't create duplicate work either. -* **One issue tracker per factory** - A factory can use [Linear](./integrations/linear) or [Jira](./integrations/jira), or no tracker at all — but not both at once. The setup wizard currently offers Linear; to use Jira, connect it after setup or in your [factory definition](./factory-as-code). -* **Filters route work, they don't restrict access** - Automation filters (repository, channel, team, project, label, author, or status) choose which requests start work. To limit what an integration can reach, change what you authorize for that provider instead. -* **You stay in control of what ships** - The factory posts back only where you've connected it, and pushes code with the repository credentials you configure. Branch protection and code review still apply; your team decides what merges. +* **One issue tracker per factory** - A factory can use [Linear](./integrations/linear) or [Jira](./integrations/jira), or no tracker at all, but not both at once. The setup wizard currently offers Linear; to use Jira, connect it after setup or in your [factory definition](./factory-as-code). +* **Filters route work; they don't restrict access** - Automation filters (repository, channel, team, project, label, author, or status) choose which requests start work. To limit what an integration can reach, change what you authorize for that provider instead. +* **The factory hands off at the pull request** - It pushes branches and opens pull requests with the repository credentials you configure, and waits for a human to review and merge. Branch protection and required reviews apply as usual. Next, customize which agents receive work and how it's routed with [factory definitions as code](./factory-as-code).