| name | issue-format |
| description | Classify a GitHub issue as bug or nonbug and extract metadata (test_type, category, dependency, platform, context). Use as the first stage of issue handling, when you need a structured classification of an issue's type and key attributes returned as JSON.
|
Issue Format — Classify & Extract Metadata
Execution mode: this skill behaves differently in interactive (default)
vs pipeline mode. See ../references/execution-modes.md.
Only the pipeline mode needs to format the issue body. If you are in interactive mode, ask the
user whether to format the issue body or just directly go to next xpu-issues-triaging stage.
Inputs
You receive a GitHub issue: its title, body, and labels.
If the body is already split into sections (description, reproducer,
error_log, environment, additional_context), use them directly. If it is
not pre-sectioned, identify those portions yourself from the raw body
before classifying.
Your Task
- Classify the issue as
"bug" or "nonbug".
- Extract metadata fields.
- Return a JSON object.
- Format the issue body according to the template.
Classification Rules
Bug — test failures, runtime errors, assertion errors, incorrect output, crashes.
Indicators: error tracebacks, failing test names, "RuntimeError", "AssertionError",
"fails with", ### 🐛 Describe the bug, test logs.
Non-bug — feature requests, tasks, performance issues, questions, discussions,
tracking issues, enhancement proposals, feature gaps.
Indicators: "Enable", "[Task]", "Consider", "Align", "feature gap", "clarification",
checklists of work items, "implement", enhancement label, performance label,
no failing tests, discussion-style content.
Output Format
Return ONLY this JSON object, no markdown fences, no explanation:
{
"issue_type": "bug | nonbug",
"test_type": "ut | e2e | \"\"",
"dependency": "upstream | \"\"",
"platform": "xpu | <specific GPU model>",
"category": "<category string>",
"related_components": "<components string>",
"context": "<one-line summary>",
"formatted_body": "<full formatted issue body as a string, pipeline mode only; empty string in interactive mode>"
}
Follow the template in the agent-issue-body.yml and agent-issue-body-nonbug.yml templates under .github/ISSUE_TEMPLATE/agent/ for the issue body formatting rules (formatted_body field, pipeline mode only).
Rules
- issue_type:
"bug" for test failures, runtime errors, crashes, incorrect output.
"nonbug" for feature requests, tasks, enhancements, performance, questions.
- test_type:
"ut" for unit tests, "e2e" for end-to-end tests, "" if unclear.
- dependency:
"upstream" if fix exists or is needed in pytorch/pytorch, "" otherwise.
- platform:
"xpu" unless a specific GPU is mentioned (BMG, etc.).
- context: Brief one-line summary with upstream links if available.
- Labels are authoritative — if labels say
agent_test: ut, test_type is ut.
- Do NOT hallucinate — if info isn't in the issue, use
"".
- Keep the output small. Do NOT echo back the issue body.
Issue-body status (backward compatible)
Pipeline mode only. In interactive mode (default), return the
classification JSON to the user/orchestrator and do not write to the issue body.
See ../references/execution-modes.md for the full
contract.
This is the first pipeline stage (legacy status DISCOVERED). When building the
issue body from the templates under .github/ISSUE_TEMPLATE/agent/
(agent-issue-body.yml for bug, agent-issue-body-nonbug.yml for non-bug),
this stage owns:
- the top status marker
<!-- agent:status:DISCOVERED -->,
- the canonical section headings (
Description, Reproducer, Error Log, Environment for bug; Description, Objective, Current Status for non-bug),
- the
<!-- agent:discovery-log --> slot,
- checking the "Issue formatted" Action Item.
