[warp-agent-staging]

What this feature does

An initial-intake automation routes approved GitHub, Linear, or Jira issues through an existing factory's foreman for implementation, validation, and independent review. The workflow requests human specification approval when needed and leaves merging to people.

Summary

Replaces the issue-implementation scaffold with a ready-work recipe that routes issues through the foreman, optional specification, implementation, validation, and independent review.

Changes

src/content/docs/factories/use-cases/issue-implementation.mdx

• Adds source-specific readiness triggers and filters in GitHub, Linear, and Jira tabs.
• Reuses an existing factory and agents, with a foreman automation example and six numbered setup steps.
• Documents test, visual-proof, review, permission, and human-merge expectations.

Content design plan

Audience and JTBD: A team with an approved backlog that wants agents to implement bounded work and hand back reviewable pull requests.

Problem: Existing integration and agent pages do not show how to turn a tracker readiness signal into a validated code change without bypassing product or merge gates.

Goals:

• The reader can choose a reliable ready-work signal.
• The reader can route initial implementation requests through the foreman and preserve planning and review decisions.
• The reader can preserve acceptance criteria and human merge control.

Purpose and value: The guide connects tracker intake to the default factory roles and gives teams a constrained first implementation workflow.

Content type: Feature documentation (combined) — the reader needs workflow guidance and provider-specific setup.

Skill and template: draft_feature_doc / .agents/templates/feature-doc.md.

High-impact scenarios:

• Covers: initial intake of approved issues from GitHub, Linear, and Jira that produce validated pull requests.
• Excludes: implementing every new issue, unresolved product decisions, and agent-controlled merging.

Source files consulted

Checked on 2026-10-21:

• Default foreman, implement, and review instructions at warp-factory-examples@84e7c952f1506c4bd2784d96fd40a6f4d6398cad: the foreman coordinates work and communicates results, implementation continues an existing specification PR when supplied, and review returns its report to the foreman. The recipe preserves those shared instructions.
• At warp-server@084e0e425af93139c6e95a78e2981dce55557c31, provider_github.go supports issue_labeled and matching the applied label.
• provider_linear.go classifies state transitions, including issues created in a state. Its filter evaluator compares previous and current states. The production schema accepts the teams and states name aliases.
• provider_jira.go, the label-filter tests, and A2A event construction support session routing with project and current-label filters. The recipe uses project_keys plus a readiness label, followed by an explicit implementation request.
• Jira keyword discrepancy: the schema accepts keywords, but the inspected session evaluator checks project and labels without evaluating that field. The recipe therefore does not rely on a keyword filter. Confirm behavior with engineering before extending this recipe or canonical references to promise keyword-only routing.
• Managed definition saves, save handling, and production-branch synchronization support the activation step. Readers must confirm application before testing.

Validation and rollout evidence

• Production automation JSON Schema retrieved on 2026-10-21: v1alpha1, SHA-256 655d676dbc436f7b89edfe2c37ef9f383c29b459a22b51c87fcda172a6ccde8e.
• Factory MCP validate_factory_files returned valid: true with no diagnostics for a complete minimal tree containing foreman, implement, review, and all three intake variants. Linear teams and states resolution was deferred; the connected workspace must resolve those names on application. Provider access and other state-dependent checks were not performed.
• Ran the unchanged rollout helper from docs@9fe3255523eda5c858f3daefd9a15a970a7ea3be against warp-server@084e0e425af93139c6e95a78e2981dce55557c31. Seven relevant intake, provider, definition-management, and delegation gates were enabled in checked-in production configuration. A separate follow-up-related check did not pass production-availability review. The recipe is explicitly scoped to initial intake and does not promise that a new intake prompt replaces an existing work item's instructions. Private flag names and raw output are not published here.

Unverified claims

• No live provider workflow has exercised end-to-end implementation, independent review, tracker updates, specification approval, or the missing-requirements and failed-validation tests for this recipe.
• Linear name resolution and actual repository/tracker permissions require a connected factory and workspace; syntax acceptance is not access verification.
• Jira keyword-filter behavior needs engineering confirmation because the schema and inspected evaluator disagree. The example avoids that field and uses source-tested label matching.
• The inspected server revision has not been matched to a running production deployment. Checked-in rollout configuration and a live published schema do not prove a full provider round trip.
• The original October 7 stable-release assertion was removed because no claim-specific release evidence established all behavior described here.

Documentation risk

Risk: engineering-review-required
Rationale: Adds new public Factory workflow guidance and configuration examples that require product review.
Docs override: none

PR stack

• #895 — Navigation and structure
• #896 — Issue triage
• #897 — Code review
• #898 — Issue implementation
• #899 — Production incident resolution
• #900 — Computer Use verification
• #901 — End-to-end SDLC automation

Dependency: #895 is the shared base and targets main. PRs #896–#901 each independently target factory/factory-use-cases-structure; no guide PR depends on another guide PR.

Human review focus

• Confirm the provider-specific ready-work trigger recommendations.
• Confirm when the default foreman should skip or require triage and specification.

Co-Authored-By: Oz oz-agent@warp.dev

Co-Authored-By: Warp agent@warp.dev

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Oct 22, 2026 8:47pm UTC

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-staging-factory on this PR to send it follow-up work.

  

[warp-for-oss]

@rachaelrenk

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /warp-agent-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[warp-for-oss]

Overview

This PR replaces the issue-implementation scaffold with a full Factory recipe covering GitHub, Linear, and Jira intake, foreman routing, validation expectations, and human merge controls. I reviewed the attached annotated diff, PR description, and spec context; no approved or repository spec context was available for implementation drift checks.

Concerns

• One non-blocking security hardening improvement is worth adding to the reusable automation prompt so copied recipes explicitly treat tracker issue text as untrusted requirements, not policy-overriding instructions.

Verdict

Found: 0 critical, 0 important, 1 suggestions

Approve

Comment /warp-agent-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[github-actions]

Review summary

The independent agent completed its review for this commit.

Findings

• No findings.

Verdict

Approve

[github-actions]

Review summary

The independent agent completed its review for this commit.

Findings

• No findings.

Verdict

Approve

[github-actions]

Review summary

The independent agent completed its review for this commit.

Findings

• src/content/docs/factories/use-cases/issue-implementation.mdx:106 — [SUGGESTION] The instruction to make Jira routes' filters nonoverlapping gives no concrete remedy for an existing project-wide route that also matches implementation-ready issues. Requested change: link to canonical exclusion-filter instructions, provide a source-verified exclusion example for the existing route, or explain how to retain one foreman route for both request types while preserving its other workflows.

Verdict

Approve with nits

[github-actions]

Review summary

The independent agent completed its review for this commit.

Findings

• src/content/docs/factories/use-cases/issue-implementation.mdx:106 — [SUGGESTION] Making Jira routes' filters nonoverlapping lacks a concrete remedy for an existing project-wide route that also matches implementation-ready issues. Requested change: link to the canonical matcher/exclusion syntax and explain which existing route to narrow, or explain how to retain one foreman route for both request types while preserving its other workflows.

Verdict

Approve with nits

[github-actions]

Review summary

The independent agent completed its review for this commit.

Findings

• No findings.

Verdict

Approve