> For the complete documentation index, see [llms.txt](https://docs.warp.dev/llms.txt).
> Markdown versions of each page are available by appending .md to any URL.

# Factory use cases

Choose a practical Warp Factories recipe for development workflows such as issue triage, code review, and UI verification.

Warp Factories can automate development work like investigating bugs, preparing changes for review, and checking that an application behaves as expected. These recipes show how to configure a workflow in your existing factory, verify its results, and decide where human input is required.

Each recipe combines agents, automations, skills, integrations, and repository controls. The examples use [definitions as code](https://docs.warp.dev/factories/factory-as-code/) so you can review and validate changes, or adapt them to a Warp-managed factory.

## Choose a use case

[Issue triage](https://docs.warp.dev/factories/use-cases/issue-triage/)Return evidence, classification, priority, and a next action without starting implementation.

[Code review](https://docs.warp.dev/factories/use-cases/code-review/)Post actionable pull request findings without changing, approving, or merging code.

[Issue implementation](https://docs.warp.dev/factories/use-cases/issue-implementation/)Turn approved GitHub, Linear, or Jira issues into validated pull requests for human review.

[Production incident resolution](https://docs.warp.dev/factories/use-cases/production-incident-resolution/)Return a read-only incident report, then request a code fix separately.

[Computer Use verification](https://docs.warp.dev/factories/use-cases/computer-use-verification/)Return observed UI behavior and visual evidence in a pull request comment.

[End-to-end SDLC automation](https://docs.warp.dev/factories/use-cases/end-to-end-sdlc-automation/)Carry an issue through planning, implementation, review, and verification to a human-controlled merge.

## Start with one workflow

Choose one task your team can evaluate on its own, like triaging incoming issues or reviewing pull requests. Define what the factory should return and where it should stop for human input.

Before you add an automation, choose the event that should start work and check whether it’s handled by an existing automation. Update that automation where appropriate, or use nonoverlapping filters when separate automations serve different purposes. See [automation matching rules](https://docs.warp.dev/factories/automations/#how-matching-works).

Follow the chosen recipe to configure the agents, access, and repository-specific instructions it needs. Test it on a sample issue or pull request, and review whether the output meets your expectations and respects the stopping point. Once that workflow works reliably, expand its scope or connect it to another stage.

## Related pages

-   [Warp Factories quickstart](https://docs.warp.dev/factories/quickstart/) - Create a factory and send its first work item
-   [About factory agents](https://docs.warp.dev/factories/factory-agents/) - Understand default roles and human decision points
-   [Factory automations](https://docs.warp.dev/factories/automations/) - Route provider events to agents with filters
-   [Factory definition syntax](https://docs.warp.dev/factories/factory-as-code/) - Look up configuration keys and validate definitions