From 7a0c09bd09224962d032cb51c0dcbdbcb456c837 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Tue, 18 Aug 2026 00:54:34 +0000 Subject: [PATCH 1/2] docs(factories): bridge factory: to the Foreman name label on the GitHub page The Foreman name alignment pass in #560 updated control-room.mdx and quickstart.mdx to link the control room's **Foreman name** field to the definition's `alias` key, but it skipped the GitHub integration page because that page was still in the open PR for #526. The page uses `factory:` three times without ever saying where comes from, so a reader who only knows the control room label has no way to work out what their label is actually called. Bridge it on first use, matching the link convention the sibling pages now use. Co-Authored-By: Warp --- src/content/docs/factories/integrations/github.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/docs/factories/integrations/github.mdx b/src/content/docs/factories/integrations/github.mdx index b6e43201d..ecd1c2136 100644 --- a/src/content/docs/factories/integrations/github.mdx +++ b/src/content/docs/factories/integrations/github.mdx @@ -72,7 +72,7 @@ Use filters to route work precisely. For example, send failed runs of a specific ## Mention the factory -A factory doesn't get its own GitHub handle. Every factory listens through the same Warp agent account, **@oz-agent**, and the factory's `factory:` label decides which factory a mention reaches: +A factory doesn't get its own GitHub handle. Every factory listens through the same Warp agent account, **@oz-agent**, and the factory's `factory:` label decides which factory a mention reaches, where `` is the factory's [**Foreman name**](/factories/factory-as-code/#alias): 1. Apply the factory's `factory:` label to the issue or pull request. Warp creates the label in each connected repository. 2. Assign **@oz-agent** to the issue or pull request, or mention **@oz-agent** in the body or in any new comment. From bb29751d442707a2304dfbd86aeddf4f151bfea9 Mon Sep 17 00:00:00 2001 From: hongyi-chen Date: Tue, 18 Aug 2026 01:53:03 +0000 Subject: [PATCH 2/2] docs(factories): address Maggie's review on the GitHub page Two review comments on #526, which merged before they could be applied. Handle: the page said the shared account is @oz-agent. Maggie confirmed it will be @warp-factory. That matches warp-server's factoryGitHubHandleDefault, where FactoryGitHubHandle() is "permanently distinct from GitHubAgentHandle(): callers pick whichever applies, never fall back between them", and githubSeedAutomations materializes it into the seeded mention and assignment filters. Automations: the connect procedure ran to seven steps, of which the last five built an automation by hand. Default GitHub automations are seeded at factory creation, so that work isn't required to connect GitHub, and presenting it as part of setup implied the factory does nothing until you configure a trigger. Connecting is now the two steps it actually takes, followed by what the defaults already do and how to verify, with the custom-automation walkthrough moved to its own section for the cases the defaults don't cover. Sequencing: warp-server#15306 carries the handle rename and is still an open draft, so this page leads the server until it lands. Co-Authored-By: Warp --- .../docs/factories/integrations/github.mdx | 23 ++++++++++++------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/src/content/docs/factories/integrations/github.mdx b/src/content/docs/factories/integrations/github.mdx index ecd1c2136..4048a00a8 100644 --- a/src/content/docs/factories/integrations/github.mdx +++ b/src/content/docs/factories/integrations/github.mdx @@ -20,13 +20,20 @@ When you connect a factory to GitHub, repository activity starts work in your fa 1. In the {VARS.FACTORY_WEB_APP} at platform.warp.dev, click **+** next to **Factories** to open the setup wizard, then choose **I want to use repos from GitHub** under **Connect your code host**. 2. Under **Select your repos**, choose the repositories to provide code and context for the factory. -3. In the factory's [control room](/factories/control-room/), click **Automations**. Create an automation or edit a default one, choose the receiving agent, and add any **Additional instructions**. -4. Under **Triggers**, click **Add trigger**. -5. Choose **GitHub**, then choose an event. -6. Select a repository, then use **More filters** to narrow which activity matches. -7. Click **Save**. To confirm the automation works, trigger a matching event in GitHub, such as opening a test issue, and check that a work item starts in the control room. -Managed GitHub factories start with two editable default automations. The first handles agent mentions and assignments (see [Mention the factory](#mention-the-factory)). The second runs when a pull request closes or merges: on a merge it finds the work items linked from the pull request and moves each one to its tracker's completed state, and on a close without a merge it does nothing. +That's all the setup GitHub needs. Managed GitHub factories are created with two editable default automations, so the factory responds to GitHub activity without you configuring anything else. The first handles agent mentions and assignments (see [Mention the factory](#mention-the-factory)). The second runs when a pull request closes or merges: on a merge it finds the work items linked from the pull request and moves each one to its tracker's completed state, and on a close without a merge it does nothing. + +To confirm the connection works, mention the factory on a test issue and check that a work item starts in the factory's [control room](/factories/control-room/). + +## Add a custom automation + +The defaults cover mentions, assignments, and pull request completion. To start work from any other GitHub activity, such as a failed CI run or a review request, add your own automation: + +1. In the factory's [control room](/factories/control-room/), click **Automations**. Create an automation or edit a default one, choose the receiving agent, and add any **Additional instructions**. +2. Under **Triggers**, click **Add trigger**. +3. Choose **GitHub**, then choose an event. +4. Select a repository, then use **More filters** to narrow which activity matches. +5. Click **Save**. To confirm the automation works, trigger a matching event in GitHub, such as opening a test issue, and check that a work item starts in the control room. ## Supported triggers @@ -72,10 +79,10 @@ Use filters to route work precisely. For example, send failed runs of a specific ## Mention the factory -A factory doesn't get its own GitHub handle. Every factory listens through the same Warp agent account, **@oz-agent**, and the factory's `factory:` label decides which factory a mention reaches, where `` is the factory's [**Foreman name**](/factories/factory-as-code/#alias): +A factory doesn't get its own GitHub handle. Every factory listens through the same Warp agent account, **@warp-factory**, and the factory's `factory:` label decides which factory a mention reaches, where `` is the factory's [**Foreman name**](/factories/factory-as-code/#alias): 1. Apply the factory's `factory:` label to the issue or pull request. Warp creates the label in each connected repository. -2. Assign **@oz-agent** to the issue or pull request, or mention **@oz-agent** in the body or in any new comment. +2. Assign **@warp-factory** to the issue or pull request, or mention **@warp-factory** in the body or in any new comment. The default mentions-and-assignments automation starts a work item in the matching factory, and the factory replies in the same thread. The label is what routes the request. A mention without the factory's label doesn't match the default automation.