Add `auto-implement` label that skips triage and opens a draft PR

[vikvang]

Motivation

Today, every newly-opened issue routes through triage-new-issues. Maintainers who already know an issue is implementation-ready have to wait for triage, then move the issue through ready-to-spec / ready-to-implement (and assign oz-agent) before the bot will start work.

We want a single label — auto-implement — that says "skip triage and spec, just implement this and open a draft PR." The motivating use case is trusted intake pipelines: a verified Warp team member, or a verified-scope social-media bot that files issues on behalf of real users, applies the label at issue-creation time so the bot dispatches in one step.

Desired behavior

When an issue is filed (issues.opened) with the auto-implement label pre-applied:

1. Skip triage — do not run triage-new-issues.
2. Dispatch the implementation workflow directly — same as create-implementation-from-issue does today for ready-to-implement + oz-agent-assigned issues.
3. Share the session link in the progress comment, same as today's implementation flow.
4. Open a draft PR for maintainers to review when the agent finishes.
5. Post the PR link as a comment on the issue (the existing progress-comment update with the PR link is sufficient).

Trust model

GitHub already restricts label application to repository collaborators (or bot identities granted that permission). That is the trust boundary — anyone who can apply auto-implement is by definition authorized to bypass triage. As a consequence:

• The label should be honored even when the issue author is a bot account, so a trusted intake bot can file + label in one step. (Today's issues.opened flow drops bot-authored issues; that drop needs to be bypassed when auto-implement is present.)
• No oz-agent assignee precondition. The label itself is the gate.

Scope / non-goals

• issues.opened only. Adding auto-implement to an existing issue after the fact should be a no-op. Existing labels (ready-to-spec, ready-to-implement) already cover the "promote later" case.
• No new workflow. The existing create-implementation-from-issue workflow already opens a draft PR, auto-assigns oz-agent, posts a progress comment, and surfaces the session link via the cron poller. The change should be limited to routing.
• Operator-managed label. The bot does not need to create the auto-implement GitHub label itself; operators add it to repositories that want this behavior.

Acceptance criteria

• Issue opened with auto-implement label → create-implementation-from-issue dispatched, no triage comment posted.
• Issue opened with auto-implement label by a bot account → still dispatched.
• Issue opened without auto-implement → existing triage behavior unchanged.
• Adding auto-implement to an existing issue → no dispatch (logged + dropped, like other unhandled labels).
• Unit tests for each of the above in tests/test_routing.py.
• Module docstring in core/routing.py updated to mention the new label.

[oz-for-oss]

@vikvang

Here's what I found while triaging this issue:

This looks implementation-ready as a workflow enhancement. No reporter follow-up is needed; the current router does not have an auto-implement shortcut for newly opened issues.

Maintainer details

I concluded that add an auto-implement issue label that routes newly opened issues directly to the implementation workflow while preserving existing triage behavior otherwise..

Triage summary

This is a workflow enhancement request for webhook routing. The requested auto-implement label should be treated as a trusted, issue-creation-time shortcut to the existing implementation workflow rather than as a new workflow.

Current routing does not support that shortcut: newly opened issues are sent to triage unless the author is detected as automation, and bot-authored opened issues are dropped before any label-specific handling can occur. Existing label handling also only reacts to ready-to-spec and ready-to-implement, so adding auto-implement after issue creation would currently be logged and dropped.

Likely implementation work is limited to the routing surface and its unit coverage: add an auto-implement label constant/branch for issues.opened, ensure it dispatches create-implementation-from-issue before the bot-author drop, leave issues.labeled behavior unchanged for that label, update the module docstring, and add the requested routing tests.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[oz-for-oss]

@vikvang

I'm starting work on product and tech specs for this issue.

You can view the conversation on Warp.

I created a new spec PR for this issue.

Preview generated specs:

• Product spec: specs/GH447/product.md
• Tech spec: specs/GH447/tech.md

Next steps:

• Review the spec PR and confirm that the proposed approach looks right.
• Request or make any needed spec updates before moving on to implementation.

Powered by Oz

[oz-for-oss]

A spec for this issue has been approved in PR #448. Future implementations of this issue should use the approved spec as the basis for implementation.

[oz-for-oss]

@vikvang

I'm implementing this issue on top of the approved spec PR's branch.

You can view the conversation on Warp.

I analyzed this issue but did not produce an implementation diff.

Powered by Oz

[vikvang]

@captainsafia it looks like the agent failed to produce a diff here