> 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.

# Configuring issue implementation in your factory

Automate implementation of approved issues with your factory, from readiness signals to validated pull requests for human review.

Turn approved issues into code changes and pull requests with your existing factory. Use this pattern when your team distinguishes work that’s ready to implement from issues that still need investigation or product decisions.

This [recipe](https://docs.warp.dev/factories/use-cases/) routes approved issues to the foreman, which coordinates implementation and independent review. It can request research or a specification when needed. The automation prompt leaves specification approval and merging to people. Enforce merge permissions through your code host’s branch protection and required reviews.

## Prerequisites

-   A [factory](https://docs.warp.dev/factories/quickstart/) with access to the target repositories and permission to push branches and open pull requests.
-   A connected issue source ([GitHub](https://docs.warp.dev/factories/integrations/github/), [Linear](https://docs.warp.dev/factories/integrations/linear/), or [Jira](https://docs.warp.dev/factories/integrations/jira/)) with permission to read and update issues.
-   Approved issues with acceptance criteria and a readiness label, workflow state, or explicit request.
-   Documented build, test, lint, and formatting commands.
-   Required reviews and protected merge permissions in the code host.

## Recommended configuration

Use the following table to choose the intake signal, agents, skills, and expected output for your implementation automation.

| Part | Recommendation |
| --- | --- |
| Trigger | A readiness label, an approved workflow state, or an explicit Jira implementation request |
| Agents | Foreman, implement, and review, with triage and spec available when needed |
| Skills | Shared repository conventions and implementation-specific validation procedures |
| Settings | Limit intake to the relevant repositories, team, or project |
| Output | A pull request linked to the source issue, validation results, and a review report |

## Set up issue implementation

1.  Use your factory’s existing [foreman, implement, and review agents](https://docs.warp.dev/factories/factory-agents/#the-default-agents). Keep triage and spec available for issues that need investigation or planning. Preserve the agents’ shared instructions.
    
2.  Add shared repository guidance under `skills/` and implementation procedures under `agents/implement/skills/`, using your agent’s directory name if different. Record required checks, tests for behavior changes, and when to ask a human. Include visual-evidence requirements for user-facing changes. See [factory skills](https://docs.warp.dev/factories/factory-skills/) for the file format.
    
3.  Add or edit an automation that targets `agent: foreman`, replacing `foreman` if yours has a different name. Choose a signal that maintainers apply after approving the issue’s requirements. A label, state, or request routes work but doesn’t independently verify approval.
    
    Check existing label, assignment, comment, and agent-session automations before adding a route. Reuse an existing automation where appropriate, or narrow overlapping filters so one request doesn’t start duplicate work.
    
    Select your issue source from the tabs below, then follow the instructions to configure the automation.
    
    -   [GitHub](#tab-panel-703)
    -   [Linear](#tab-panel-704)
    -   [Jira](#tab-panel-705)
    
    This automation starts when `factory-ready` is applied to an issue in `acme/payments-service`. Replace the repository and label with your own.
    
    ```markdown title="automations/implement-approved-issues/automation.md"
    ---
    agent: foreman
    triggers:
      - provider: github
        event: issue_labeled
        filter:
          repos: [acme/payments-service]
          labels: [factory-ready]
    ---
    
    Implement the approved issue against its acceptance criteria. Ask a human
    about missing requirements or product decisions rather than guessing.
    If the triggering request asks only for information or investigation,
    do not implement.
    If a specification is needed, obtain approval before implementing it.
    Delegate implementation, run the repository's required checks, and obtain
    independent review. Continue an existing specification PR when provided.
    Return the pull request link, validation results, and review findings to
    the source issue. Report any failed or unverified checks. Never merge.
    ```
    
    For events sent by bots, 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 implementation prompt from the GitHub tab’s `automations/implement-approved-issues/automation.md` example. Replace its entire `triggers` list with the configuration below. Replace `Payments` and `Ready for Engineering` with the team and approved workflow-state names in your connected Linear workspace.
    
    ```yaml title="Linear implementation trigger"
    triggers:
      - provider: linear
        event: issue_state_changed
        filter:
          teams: [Payments]
          states: [Ready for Engineering]
    ```
    
    The trigger matches issues entering the selected state, including issues created in that state. Name-based filters are resolved through the connected Linear integration when the definition is applied. Connecting Linear doesn’t grant repository access.
    
    Copy `agent: foreman` and the implementation prompt from the GitHub tab’s `automations/implement-approved-issues/automation.md` example. Replace its entire `triggers` list with the configuration below, using your Jira project key in place of `ENG`.
    
    ```yaml title="Jira implementation trigger"
    triggers:
      - provider: jira
        event: agent_session_created
        filter:
          project_keys: [ENG]
          labels: [factory-ready]
    ```
    
    After approving the issue, apply `factory-ready`, then assign or mention **Warp** with an explicit request such as “Implement this issue against its acceptance criteria.” The label must be present when the session starts. Follow the [Jira setup and account-linking requirements](https://docs.warp.dev/factories/integrations/jira/).
    
    Jira setup may already have created a project-wide session automation. Update that automation if it handles only implementation requests. Otherwise, preserve its other workflows and make both routes’ filters nonoverlapping before adding this one. Adding the readiness label to the new route’s filter alone doesn’t exclude those requests from a broader existing route.
    
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](https://docs.warp.dev/factories/factory-as-code/#where-the-definition-lives).
    
5.  Test with a fresh, approved documentation or configuration issue that matches every filter.
    
    -   **GitHub** - Apply the readiness label.
    -   **Linear** - Move the issue into the approved state, or create it in that state.
    -   **Jira** - Apply the readiness label, then assign or mention **Warp** with the implementation request.
    
    Confirm the foreman coordinates implementation and review, posts the pull request link and validation results to the issue, and leaves merging to a person. Check that this automation doesn’t start when the required label or state is missing, or the issue belongs to a different team or project.
    
    These examples configure initial intake. If the factory already tracks an issue as a work item, send an explicit implementation request in its existing conversation rather than assuming a new intake prompt will replace the current instructions.
    
6.  Test missing requirements and failed validation. Confirm the foreman asks for clarification or specification approval when needed and reports failed checks rather than claiming success. Review the results before widening the automation’s filters.
    

## Example workflow

A Linear issue requests validation for a `currency` API field and specifies the accepted codes, error response, and required tests. A maintainer approves the requirements and moves it to `Ready for Engineering`. The automation routes the issue to the foreman, which delegates implementation.

The implement agent adds validation and regression tests, runs the service checks, and opens a pull request linked to the issue. The review agent checks the behavior and tests and reports to the foreman. The foreman posts the pull request and verification results to Linear for a maintainer to review and merge.

## Related pages

-   [Factory use cases](https://docs.warp.dev/factories/use-cases/) - Compare implementation with narrower factory recipes.
-   [How Warp Factories work](https://docs.warp.dev/factories/how-factories-work/) - Understand stage skipping, revision, and human handoff.
-   [Factory agents](https://docs.warp.dev/factories/factory-agents/) - Configure foreman, implement, and review roles.
-   [Factory skills](https://docs.warp.dev/factories/factory-skills/) - Add repository-specific implementation procedures.