django-triage
Analyze Django ticket and provide triage recommendations.
Prerequisites:
uv— Script runner (install)gh— GitHub CLI (install). Rungh auth loginto authenticate.- Django source code —
git clone https://github.com/django/django.gitin the working directory (for Step 5: source code analysis)
Before starting, verify uv and gh are available. If either is missing, show the install link and stop.
If django/ directory is missing, warn the user and skip Step 5 (source code browsing).
Arguments:
- First argument: Trac ticket number (required, e.g.,
36812,2750) - Second argument: Language for the report (optional, default:
en)en- Englishko- Korean- Other language codes are also supported
Parse $ARGUMENTS to extract ticket_id and language. If only one argument is provided, use en as the default language.
IMPORTANT:
- DO NOT use WebFetch or Fetch for GitHub URLs. ALWAYS use the
ghCLI command instead. - For commits:
gh api repos/<owner>/django/commits/<sha> - For PRs:
gh pr view <number> --repo django/djangoorgh api repos/django/django/pulls/<number> - See
references/gh-examples.mdfor more examples.
Note: ./scripts/ paths are relative to this SKILL.md file. Use the actual resolved path when executing.
Step 1: Fetch Ticket Details
uv run --script ./scripts/trac.py get $ARGUMENTS
Identify the following:
- Basic info: summary, reporter, owner, component, version
- Status: status, resolution, triage_stage, has_patch
- Keywords: Extract key terms from keywords field
- Ticket type: Bug report / Feature request / Documentation / Cleanup
- History: Review comments for previous discussions, related PRs, prior patch attempts
Step 2: Search for Duplicates and Related Tickets
2-1. Trac Search (at least 2-3 queries)
# Search by key keywords
uv run --script ./scripts/trac.py search "<key keywords>"
# Search by error message or class/function name
uv run --script ./scripts/trac.py search "<error message or class name>"
# Search by component + keyword combination
uv run --script ./scripts/trac.py search "<component> <keyword>"
2-2. Review Potentially Related Tickets
Fetch details for related tickets found (top 3-5):
uv run --script ./scripts/trac.py get <related_ticket_id>
Step 3: Search Related PRs (GitHub)
Find PRs linked to the ticket:
# Search PRs mentioning ticket number in title/body
gh search prs "Fixed #$ARGUMENTS" --repo django/django --limit 10
gh search prs "#$ARGUMENTS" --repo django/django --limit 10
# Or search by Trac ticket URL
gh search prs "code.djangoproject.com/ticket/$ARGUMENTS" --repo django/django --limit 10
If related PRs exist, review details:
gh pr view <pr_number> --repo django/django --json title,state,body,comments
Step 4: Search Django Forum
Check for forum discussions related to the ticket:
# Search by ticket number
uv run --script ./scripts/forum.py ticket $ARGUMENTS
# If no results, search internals category by keywords
uv run --script ./scripts/forum.py search "<key keywords>" --category=internals
Step 5: Browse Related Source Code (If Applicable)
For tickets requiring code changes, check related code in django/ directory:
Find related files:
- Use the Glob tool with pattern
django/**/<relevant_file>.pyto find files by name - Use the Grep tool with pattern
<class or function name>indjango/to search code
Find related tests:
- Use the Glob tool with pattern
tests/**/test_*.pyto find test files - Use the Grep tool with pattern
<related keyword>intests/to search test code
Identify:
- Location of the problematic code
- Existing test coverage
- Scope of changes needed
Step 6: Validity Assessment
For Bug Reports
| Check | Question |
|---|---|
| Reproducibility | Are reproduction steps clear? Is there minimal reproduction code? |
| Version | Does it occur on latest version (main branch)? |
| Django's responsibility | Is this a Django bug or user code/configuration issue? |
| Intended behavior | Does it differ from documented behavior? Is it by design? |
| Supported version | Is this a supported Django version? |
| Security | Is this a security issue? (Should NOT be on Trac) |
For Feature Requests
| Check | Question |
|---|---|
| Generality | Is this useful to enough users? |
| Django philosophy | Does it align with Django's design philosophy? |
| Alternatives | Can this be solved with a third-party package? |
| Backwards compatibility | Does it break existing code? |
| Complexity | Is the maintenance burden worth the value? |
| DEP required | Is this a large change requiring a DEP? |
Red Flags (Likely Invalid)
- Security issue reported on public Trac (should go to security@djangoproject.com)
- Only affects unsupported Django versions
- "Only I need this" type of feature
- Works as documented (user misunderstanding)
- Third-party package issue, not Django core
Step 7: Triage Decision
Read references/triage-stages.md for stage definitions and duplicate criteria.
Step 8: Save Report and Output Summary
IMPORTANT: Write all content (report and terminal summary) in the specified language.
- If language is
ko: Write everything in Korean - If language is
enor not specified: Write everything in English - For other languages: Write in the specified language
8-1. Save Full Report to File
Create directory if needed and save the full report:
mkdir -p triage-reports
Read references/report-template.md and use it as the report format. Write the full report to triage-reports/<ticket_id>.md using the Write tool.
8-2. Output Summary to Terminal
Read the terminal summary format from references/report-template.md and output a brief summary.