diff --git a/src/content/docs/factories/use-cases/code-review.mdx b/src/content/docs/factories/use-cases/code-review.mdx new file mode 100644 index 000000000..2b669490f --- /dev/null +++ b/src/content/docs/factories/use-cases/code-review.mdx @@ -0,0 +1,129 @@ +--- +title: Configuring pull request review in your factory +description: >- + Automate pull request reviews with your factory to identify bugs, security + risks, and missing tests and post actionable findings. +--- +import { Tabs, TabItem } from '@astrojs/starlight/components'; + +Automate pull request review in your factory to check code changes against the acceptance criteria recorded in the issue or pull request, repository conventions, and security requirements. Use this pattern for independent review of code written by people or agents. + +This [recipe](/factories/use-cases/) routes pull requests to your factory's foreman, which asks the review agent to inspect the change and publishes its report. The review agent reports to the foreman rather than posting on the pull request. The automation prompt limits this workflow to review without implementation, approval, or merging. Keep required approvals and merge permissions in the code host. + +## Prerequisites + +* A [factory](/factories/quickstart/) connected to [GitHub](/factories/integrations/github/), [GitLab](/factories/integrations/gitlab/), or [Azure DevOps](/factories/integrations/azure-devops/). +* Repository credentials that can read code, checks, and review discussions, and post findings. +* A review policy with required validation commands, security checks, and finding thresholds. +* A test pull request or merge request with a known defect. + +## Recommended configuration + +Use the following table to choose the trigger, agent, skills, settings, and expected output for your review automation. + +| Part | Recommendation | +| --- | --- | +| Trigger | A pull request becomes ready or is created, depending on the provider | +| Agents | Your factory's foreman coordinates the review agent and publishes its findings | +| Skills | Repository-specific review policy and validation commands | +| Settings | Filter by repository and target branch. Choose a different model or harness from implementation when possible | +| Output | Actionable findings with affected lines, a recommendation, and validation results | + +## Set up pull request review + +1. Use your factory's existing [foreman and review agents](/factories/factory-agents/#the-default-agents). Keep both agents' shared instructions intact. +2. Add a review-policy skill under `agents/review/skills/`, using your agent's directory name if different. Include validation commands, relevant security or migration checks, and which findings require changes. See [factory skills](/factories/factory-skills/) for the file format. +3. Add or edit an automation for your code host. Target the foreman with `agent: foreman`, replacing `foreman` if yours has a different name. Put this workflow's review-only instructions in the automation prompt. + + Reuse an existing automation if it already handles those requests. Check for overlapping triggers before adding another route. + + Select your code host from the tabs below, then follow the instructions to configure the automation. + + + + + This automation starts when a pull request is opened ready for review or changes from draft to ready. Replace `acme/api-service` and `main` with your repository and target branch. + + ```markdown title="automations/review-ready-prs/automation.md" + --- + agent: foreman + triggers: + - provider: github + event: pull_request_ready + filter: + repos: [acme/api-service] + base_branches: [main] + labels: + not_in: [skip-factory-review] + --- + + Coordinate a review-only task. If the pull request is a draft or is no + longer open, stop without posting a review. Treat this event as a fresh + review request, even if an earlier revision was reviewed. Ask the factory's + review agent to inspect the current head commit against acceptance criteria + in the source issue or pull request and repository guidance, run relevant + validation, and return its report to you. Publish the report on the pull + request as comments, not an approval or rejection. Include affected lines, + impact, recommended corrections, + validation results, and anything unverified. Stop after publishing. + Do not edit code, dispatch implementation, approve, or merge. + ``` + + The optional `skip-factory-review` label excludes a pull request when the event fires. For bot-authored events, see the published [GitHub bot-event policy](https://docs.warp.dev/factories/integrations/github/#events-from-bots-dont-start-work). + + + + + Copy `agent: foreman` and the Markdown review prompt from the GitHub tab's `automations/review-ready-prs/automation.md` example. Replace its entire `triggers` list with the configuration below, using your GitLab project path and target branch in place of `acme/api-service` and `main`. + + ```yaml title="GitLab review trigger" + triggers: + - provider: gitlab + event: merge_request + filter: + repos: [acme/api-service] + base_branches: [main] + actions: [open] + ``` + + `merge_request` also covers updates, approvals, and other actions. The `actions: [open]` filter limits initial review to newly opened merge requests. This trigger has no label or draft filter, so keep the prompt's instruction to skip drafts. + + + + + Copy `agent: foreman` and the Markdown review prompt from the GitHub tab's `automations/review-ready-prs/automation.md` example. Replace its entire `triggers` list with the configuration below. Replace `AZURE_DEVOPS_REPOSITORY_ID` with the repository's UUID, not a GitHub-style `owner/repo` path, and replace `main` with the target branch. + + ```yaml title="Azure DevOps review trigger" + triggers: + - provider: azure_devops + event: pull_request_created + filter: + repos: [AZURE_DEVOPS_REPOSITORY_ID] + base_branches: [main] + ``` + + This trigger has no label or draft filter. Keep the prompt's instruction to skip drafts. See [Azure DevOps events and filters](/factories/integrations/azure-devops/#supported-events-and-filters) for setup and scope. + + + +4. Apply the definition changes before testing. Save edits in the factory dashboard for a Warp-managed factory, or merge them into the configured production branch for a GitHub-backed factory. Confirm validation succeeds and the changes are applied. See [where the factory definition lives](/factories/factory-as-code/#where-the-definition-lives). +5. Test the selected event with a pull request or merge request that contains a known defect and matches every filter. + * **GitHub** - Mark a draft pull request as ready for review, or open a non-draft pull request. To test the optional exclusion, repeat with `skip-factory-review` applied before opening the pull request or marking it ready. + * **GitLab** - Open a non-draft merge request. + * **Azure DevOps** - Create a non-draft pull request. + + Confirm the review agent returns its findings to the foreman, the foreman posts the defect on the pull request, and neither agent changes the branch or starts implementation. Test exclusions too: GitHub's skip label should prevent a run, while draft requests on GitLab and Azure DevOps may start a run but should produce no review. +6. Add re-review events only if the workflow needs them. Use `pull_request_synchronized` for GitHub, `merge_request` with `actions: [update]` for GitLab, or `pull_request_updated` for Azure DevOps. GitLab and Azure DevOps update events are not limited to new commits. Keep the same repository and target-branch filters, retain the draft and closed-request checks, and decide how the agent should reply to or update earlier findings instead of duplicating them. Push a fix and confirm the next review checks the revised code. + +## Example workflow + +A pull request changes a cache key from `account_id:region` to `account_id`. When the author marks it ready, the foreman requests a review. The review agent finds that two regions now share one entry and reports the collision scenario and expected key shape to the foreman, which posts the finding on the pull request. + +After the author pushes a fix, a configured re-review event requests another check of the current head commit. The review agent verifies the new key and the foreman publishes the result. A person still decides whether to approve and merge. + +## Related pages + +* [Factory use cases](/factories/use-cases/) - Compare review with triage, implementation, and verification recipes. +* [Factory automations](/factories/automations/) - Configure pull request events and filters. +* [Factory agents](/factories/factory-agents/) - Configure the review role and choose a separate model or harness. +* [GitHub integration](/factories/integrations/github/) - Review supported pull request events and permissions. diff --git a/src/content/docs/factories/use-cases/computer-use-verification.mdx b/src/content/docs/factories/use-cases/computer-use-verification.mdx new file mode 100644 index 000000000..981bc9df6 --- /dev/null +++ b/src/content/docs/factories/use-cases/computer-use-verification.mdx @@ -0,0 +1,8 @@ +--- +title: Verify changes with Computer Use +description: >- + Configure a factory to exercise rendered interfaces and attach screenshots + or recordings as verification evidence. +--- + +{/* This scaffold is completed by its dependent guide PR. */} diff --git a/src/content/docs/factories/use-cases/end-to-end-sdlc-automation.mdx b/src/content/docs/factories/use-cases/end-to-end-sdlc-automation.mdx new file mode 100644 index 000000000..0620b2acd --- /dev/null +++ b/src/content/docs/factories/use-cases/end-to-end-sdlc-automation.mdx @@ -0,0 +1,8 @@ +--- +title: Automate the software development lifecycle with factories +description: >- + Connect factories across triage, implementation, review, verification, and + human-controlled merging. +--- + +{/* This scaffold is completed by its dependent guide PR. */} diff --git a/src/content/docs/factories/use-cases/index.mdx b/src/content/docs/factories/use-cases/index.mdx new file mode 100644 index 000000000..a6ddb2df4 --- /dev/null +++ b/src/content/docs/factories/use-cases/index.mdx @@ -0,0 +1,61 @@ +--- +title: Factory use cases +description: >- + Choose a practical Warp Factories recipe for issue triage, implementation, + code review, incident response, UI verification, or SDLC automation. +sidebar: + label: Overview +--- +import { CardGrid, LinkCard } from '@astrojs/starlight/components'; + +A recipe is a recommended configuration and set of instructions for completing a specific task with your factory. Recipes combine agents, automations, integrations, skills, and repository controls. Test the recipe's results before expanding the workflow. For example, check that issue triage categorizes issues correctly before adding implementation. + +Each guide links to the canonical configuration and integration references. The examples use definitions as code so you can review changes, validate them in CI, and adapt the same pattern to a Warp-managed factory. + +## Choose a use case + + + + + + + + + + +## Start with the smallest recipe + +Use one factory with the repositories that ship together. Add an automation for one clear intake event, route it to the agent responsible for that task, and make the expected output explicit. Keep a human responsible for approving specifications, accepting risk, and merging changes. + +When a workflow spans several roles, prefer the default foreman, triage, spec, implement, and review agents before creating custom agents. Add a custom skill for repository-specific procedures, such as required test commands or an incident runbook. + +## Related pages + +* [Warp Factories quickstart](/factories/quickstart/) - Create a factory and send its first work item. +* [Factory agents](/factories/factory-agents/) - Configure the default roles and add custom agents. +* [Factory automations](/factories/automations/) - Route provider events to agents with filters. +* [Factory definition syntax](/factories/factory-as-code/) - Look up configuration keys and validate definitions. diff --git a/src/content/docs/factories/use-cases/issue-implementation.mdx b/src/content/docs/factories/use-cases/issue-implementation.mdx new file mode 100644 index 000000000..bbefc0ed4 --- /dev/null +++ b/src/content/docs/factories/use-cases/issue-implementation.mdx @@ -0,0 +1,8 @@ +--- +title: Implement issues with a factory +description: >- + Configure a factory to turn approved GitHub, Linear, or Jira issues into + tested pull requests. +--- + +{/* This scaffold is completed by its dependent guide PR. */} diff --git a/src/content/docs/factories/use-cases/issue-triage.mdx b/src/content/docs/factories/use-cases/issue-triage.mdx new file mode 100644 index 000000000..c4f0ced4a --- /dev/null +++ b/src/content/docs/factories/use-cases/issue-triage.mdx @@ -0,0 +1,124 @@ +--- +title: Configuring issue triage in your factory +description: >- + Have your factory's triage agent investigate, categorize, and prioritize + incoming issues, then recommend what to do next. +--- +Automate issue triage in your factory so incoming issues include a category, priority, supporting evidence, and a recommended next step. Use this pattern when your team spends time gathering information about each issue before deciding what to work on. + +This [recipe](/factories/use-cases/) configures an intake automation for your factory's existing triage agent. + +The automation prompt asks the agent to stop after triage, but other workflows in the same factory can continue through specification, implementation, and review. + +## Prerequisites + +* A [factory](/factories/quickstart/) with read access to the relevant repositories. +* A connected issue source ([GitHub](/factories/integrations/github/), [Azure DevOps](/factories/integrations/azure-devops/), [Linear](/factories/integrations/linear/), or [Jira](/factories/integrations/jira/)) with permission to comment on and update issues. +* A triage policy defining categories, priority levels, required evidence, and when to ask a human. +* A test repository or issue-tracker project outside your production backlog. + +## Recommended configuration + +Use the following table to choose the trigger, agent, skills, settings, and expected output for your issue-triage automation. + +| Part | Recommendation | +| --- | --- | +| Trigger | A new issue, a triage label added, or an explicit Jira request | +| Agent | Your factory's existing triage agent | +| Skills | A repo-specific triage skill with category, priority, reproduction, duplicate-search, and escalation rules | +| Settings | Start with one repository and one event; use the Warp Agent harness so built-in code-host tools are available | +| Output | One issue update with evidence, classification, priority, and the recommended next stage | + +## Set up issue triage + +1. Use your factory's existing [triage agent](/factories/factory-agents/#triage) and keep its shared instructions intact. +2. Add `agents/triage/skills/issue-triage/SKILL.md`, using your agent's directory name if different. Define allowed categories and priorities, duplicate-search rules, required evidence, and when to ask a human. Require a code location, duplicate issue, log, or reproduction before assigning a root cause. See [factory skills](/factories/factory-skills/) for the file format. +3. Add or edit an automation for your issue source using the examples below. They use `agent: triage`. Replace `triage` if your agent has a different name, and keep the stopping instructions in the automation prompt. + + Reuse an existing automation when it already handles those requests. Avoid overlapping routes, including a broad issue-created automation and a label automation that could both start work on the same issue. See the [trigger schema](/factories/factory-as-code/#triggers) and [filter reference](/factories/factory-as-code/#triggersfilter) for provider-specific values. + + ### GitHub: Triage newly created issues + + This automation starts on every new issue in `acme/payments-service`. Replace that repository with your own. + + ```markdown title="automations/triage-new-issues/automation.md" + --- + agent: triage + triggers: + - provider: github + event: issue_created + filter: + repos: [acme/payments-service] + --- + + Triage the new issue. Search for duplicates, inspect the relevant code, and + reproduce a bug only when the cause is not already supported by evidence. + Use the repository's triage skill for categories and priority. Ask for missing + evidence rather than guessing. Update the issue with category, priority, scope, + and the next action, then stop. Do not implement or start implementation. + ``` + + For a controlled rollout, change the event to `issue_labeled` and add `labels: [needs-triage]` alongside `repos`. + + ### Azure DevOps: Triage labeled work items + + This automation starts when a work item receives the `needs-triage` label: + + ```markdown title="automations/triage-new-work-items/automation.md" + --- + agent: triage + triggers: + - provider: azure_devops + event: work_item_labeled + filter: + labels: [needs-triage] + --- + + Triage the labeled work item using the repository's triage skill. Update it + with evidence, classification, priority, and the next action, then stop. + Ask for missing evidence rather than guessing. Do not implement or start + implementation. + ``` + + Work item events accept `assignees`, `authors`, `labels`, and `work_item_types`, but not `repos`. Use `work_item_created` instead to triage newly created work items that match those filters. See [Azure DevOps events and filters](/factories/integrations/azure-devops/#supported-events-and-filters) for setup and scope. + + ### Linear + + Use `provider: linear` with `issue_created` or `issue_labeled`. Replace the GitHub example's `repos` filter with Linear team or project filters, and add a label filter for a controlled rollout. + + ### Jira + + Use `provider: jira` with `agent_session_created` and a `project_keys` filter. Check existing automations first. [Jira setup](/factories/integrations/jira/#connect-jira-and-add-an-automation) may already have created one for your projects. + + * **All requests need triage** - Retarget the existing automation to your triage agent and use the triage-only prompt above. + * **Other workflows share the handler** - Keep that handler and narrow both routes' project or keyword filters so each request matches only one automation before adding a separate triage automation. + + Adding a keyword filter to the new route alone doesn't exclude it from an existing project-wide route. A triage-only prompt also doesn't stop another automation from starting its own run. + + ### GitLab + + GitLab has no native issue-created trigger. Use an explicit bot mention or a [custom webhook](/factories/webhooks/). + +4. Apply the definition changes. For a Warp-managed factory, save the edits in the factory dashboard. For a GitHub-backed factory, merge the changes into its configured production branch. Confirm validation succeeds and the changes are applied. See [where the factory definition lives](/factories/factory-as-code/#where-the-definition-lives). +5. Test the selected trigger with an issue or work item that describes a concrete symptom and matches every configured filter: + * **Creation intake** - Create an issue for GitHub or Linear, or a work item for Azure DevOps. Include any labels required by the filter when creating it. + * **Label intake** - Apply `needs-triage` to a test issue or work item after creating it. + * **Jira agent sessions** - Assign or mention **Warp** on a test work item in a matching project and ask it to triage the issue. + + Confirm one run starts, updates the issue or work item with evidence, uses only the allowed labels, and stops without creating a branch. For Jira, also test that a non-triage request still reaches its intended handler. +6. Review several results before expanding the repository or event filters. + +## Example workflow + +A customer opens `Checkout fails after applying two coupons` in `acme/payments-service`. The automation starts the triage agent, which searches for duplicates, identifies the discount calculation path, and reproduces the failure with the supplied cart data. + +The agent labels the issue `bug` and `payments`, assigns the team's `P1` priority according to the skill, and posts the failing test output and affected code path. It recommends implementation because the cause is bounded. If the issue lacks cart data, the agent asks for that evidence and leaves the issue waiting for a human instead. + +To take accepted issues through implementation in the same factory, follow the [issue implementation recipe](/factories/use-cases/issue-implementation/). + +## Related pages + +* [Factory use cases](/factories/use-cases/) - Compare this recipe with other factory workflows. +* [Factory automations](/factories/automations/) - Configure triggers and filters. +* [Factory agents](/factories/factory-agents/) - Understand the default triage role. +* [GitHub integration](/factories/integrations/github/) - Review issue triggers, permissions, and outputs. diff --git a/src/content/docs/factories/use-cases/production-incident-resolution.mdx b/src/content/docs/factories/use-cases/production-incident-resolution.mdx new file mode 100644 index 000000000..200cc7708 --- /dev/null +++ b/src/content/docs/factories/use-cases/production-incident-resolution.mdx @@ -0,0 +1,8 @@ +--- +title: Resolve production incidents with a factory +description: >- + Configure a factory to investigate production failures and propose or + implement evidence-backed fixes. +--- + +{/* This scaffold is completed by its dependent guide PR. */} diff --git a/src/sidebar.ts b/src/sidebar.ts index 539e2216b..64552f2d0 100644 --- a/src/sidebar.ts +++ b/src/sidebar.ts @@ -404,6 +404,18 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ { slug: 'platform/transitioning-from-oz', label: 'Transitioning from Oz' }, ], }, + { + label: 'Factory use cases', + items: [ + { slug: 'factories/use-cases', label: 'Overview' }, + { slug: 'factories/use-cases/issue-triage', label: 'Issue triage' }, + { slug: 'factories/use-cases/code-review', label: 'Code review' }, + { slug: 'factories/use-cases/issue-implementation', label: 'Issue implementation' }, + { slug: 'factories/use-cases/production-incident-resolution', label: 'Production incident resolution' }, + { slug: 'factories/use-cases/computer-use-verification', label: 'Computer Use verification' }, + { slug: 'factories/use-cases/end-to-end-sdlc-automation', label: 'End-to-end SDLC automation' }, + ], + }, { // Parallel to 'Agent configuration' in the Automation Platform tab. // Scoped to the factory itself: who runs the work, how it is defined,