Repository navigation
Update triage taxonomy with agent: primary types and agent:priority-high - #15868
Conversation
Support explicit issue classification and priority tagging in local triage guidance, adding feature, security, and priority:high labels to config.json. Co-Authored-By: Warp <agent@warp.dev>
|
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 Powered by Oz |
![warp-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overview
This PR updates Warp's issue-triage label configuration and repo-local triage guidance to add feature, security, and priority:high classification paths.
Concerns
- The new primary-type requirement conflicts with the existing billing/appeals support-routing rule unless support-only reports are explicitly exempted.
- The
securityguidance treats vulnerability disclosures as normal public triage instead of directing reporters to the private disclosure channels inSECURITY.md. - The new
featurelabel coexists with the existingenhancementlabel and feature-request template behavior, which can split triage/search/routing unless the migration or aliasing behavior is defined.
Security
- Public vulnerability reports need private-disclosure handling before this guidance is used by automated triage.
Tests
No tests are added or changed; the diff is limited to issue-triage configuration and skill guidance.
Verdict
Found: 0 critical, 3 important, 0 suggestions
Request changes
Comment /warp-agent-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
| - When the issue includes screenshots, videos, logs, stack traces, or command output, use them as primary evidence and ask follow-up questions only for missing details that cannot be inferred from that evidence. | ||
| - Before asking any follow-up questions, check the Warp documentation and the repository's existing feature set to determine whether the desired behavior the reporter is describing is already supported. If an existing feature, setting, or workflow satisfies the request, recommend it to the reporter instead of treating the issue as a bug or feature gap. | ||
| - If the report is about billing (pricing, plans, subscriptions, payments, refunds, invoices, AI request quotas, charges) or about appeals (account suspensions, bans, takedowns, abuse decisions, or other account-status disputes), do not attempt to triage it as an actionable bug or feature request. Instead, notify the reporter that these requests must go through Warp's support channels (https://docs.warp.dev/support-and-community/troubleshooting-and-support/sending-us-feedback) and direct them there for resolution. Apply the relevant `area:billing` or `area:auth` label as appropriate so the issue is still routed correctly. | ||
| - Classify issues into at least one primary type (`bug`, `feature`, `security`, `documentation`). Explicitly bias towards tagging regressions ("broke in recent version", "worked in previous build"), panics/crashes, and security reports with `priority:high`. |
There was a problem hiding this comment.
| - Classify issues into at least one primary type (`bug`, `feature`, `security`, `documentation`). Explicitly bias towards tagging regressions ("broke in recent version", "worked in previous build"), panics/crashes, and security reports with `priority:high`. | |
| - Classify actionable OSS issues into at least one primary type (`bug`, `feature`, `security`, `documentation`). For billing and appeals reports covered above, apply the routing label and support-channel guidance instead. Explicitly bias towards tagging regressions ("broke in recent version", "worked in previous build"), panics/crashes, and security reports with `priority:high`. |
There was a problem hiding this comment.
Erm yeah I think we should do this but not critical since we have guidance in the bullet above (which should apply due to precedence) directing agents to escalate to support for billing/etc. issues. Can add though.
| Every issue should be classified with at least one primary type label: | ||
| - `bug`: Something isn't working. | ||
| - `feature`: This issue is a feature request, not a bug report. | ||
| - `security`: Security vulnerability or report. |
There was a problem hiding this comment.
SECURITY.md rather than handled as normal public issue triage; otherwise the triage agent can amplify disclosure details with labels and comments.
| - `security`: Security vulnerability or report. | |
| - `security`: Security-adjacent issue or report. If the issue may disclose a vulnerability, avoid public details and direct the reporter to the private disclosure channels in `SECURITY.md`. |
There was a problem hiding this comment.
Don't think this is actually important, but lemme know if there's a reason for this. If there's information that shouldn't be exposed it's already in the (public) issue, so there's no extra harm being done.
| "color": "d73a4a", | ||
| "description": "Something isn't working." | ||
| }, | ||
| "feature": { |
There was a problem hiding this comment.
feature without migrating or aliasing the existing enhancement label creates two canonical labels for the same issue type; the feature-request template still auto-applies enhancement, so triage/search/routing can split. Update the template/workflow to normalize one label or document enhancement as a legacy alias.
There was a problem hiding this comment.
I think it's fine to have both labels for now, IIUC enhancement is used for features or bugs reported via the dedicated feature request form. It's fine to have both labels but I think what we're getting at is that feature, bug, security, and priority:high are all agent-assigned and we should maybe distinguish them from other sources?
How broad-sweeping would it be to refactor this logic so that all labels just have an agent: alias to avoid interference with existing workflows? Maybe this is the change to make.
Use agent:bug, agent:feature, agent:security, and agent:documentation to encode provenance for agent-assigned classifications, and update local triage guidance. Co-Authored-By: Warp <agent@warp.dev>
vkodithala
changed the title
Update label definition in config.json and local skill guidance to use agent:priority-high. Co-Authored-By: Warp <agent@warp.dev>
vkodithala
changed the title
Description
Updates the repository's issue triage configuration and companion triage skill to encode provenance directly into agent-assigned classifications (
agent:bug,agent:feature,agent:security,agent:documentation) and support urgent issue prioritization withagent:priority-high.What changed
.github/issue-triage/config.json: Addedagent:bug(#8ff8fd),agent:feature(#f47f64),agent:security(#a0ce9f),agent:documentation(#5f966f), andagent:priority-high(#b60205) label definitions..agents/skills/triage-issue-local/SKILL.md: Documented the primary agent types andagent:priority-highin the label taxonomy section and updated heuristics to direct the triage agent to classify issues into primary agent types (exempting billing/appeals reports that route to support viawarp:needs-support) and explicitly bias toward applyingagent:priority-highto regressions ("broke in recent version", "worked before"), crashes/panics, data loss, and security vulnerabilities.Stack & Connections
This PR is part of a 3-repo stack to pause non-KTLO triage noise ahead of Factory GA:
warpdotdev/warp(this PR): Defines the agent label taxonomy and repository-local skill guidance.warpdotdev/oz-for-oss(PR Support primary agent issue classification and agent:priority-high triage oz-for-oss#500): Updates the automated triage workflow to classify issues into primary agent types, parametrize primary types in prompt construction, and preserveagent:priority-highduring retriage.warpdotdev/ossie(PR https://github.com/warpdotdev/ossie/pull/64): Updates issue triage Slack alerts to suppress individual messages/pings for non-prioritized issues, reserving individual Slack alerts foragent:securityandagent:priority-highissues.Co-Authored-By: Warp agent@warp.dev