Django Ticket Triage 用于分析一个 Django Trac 工单，并推荐其分诊阶段（triage stage）。
用途 该技能面向 Django 工单的分诊流程，帮助判断工单是否有效、是否重复、是否已有相关 PR 或论坛讨论，并定位受影响的源码与测试，最终生成分诊建议报告。
前置条件
- python3（仅使用标准库，无需额外 Python 包）。
- gh —— GitHub CLI（需安装）。运行 gh auth login 进行认证。
- Django 源码 —— 在工作目录中执行 git clone https://github.com/django/django.git（用于第 5 步源码分析）。
开始前需确认 python3 与 gh 可用。若缺少 gh，显示安装链接并停止。若缺少 django/ 目录，警告用户并跳过第 5 步（源码浏览）。
参数 $ARGUMENTS：Trac 工单编号（必填，例如 36812、2750）。
GitHub 访问：所有 GitHub 查询都使用 gh CLI，而非 WebFetch。gh 通过已认证的 API 返回结构化 JSON；抓取 github.com URL 返回的是渲染后的 HTML，需要解析且会随页面布局变化而失效。
提交查询：gh api repos/<owner>/django/commits/<sha> PR 查询：gh pr view <number> --repo django/django 或 gh api repos/django/django/pulls/<number> 更多示例见 references/gh-examples.md。
注意：./scripts/ 路径相对于本 SKILL.md 文件。执行时使用实际解析后的路径。
主要能力与使用方式
第 1 步：获取工单详情 运行 python3 ./scripts/trac.py get $ARGUMENTS，识别基本信息（summary、reporter、owner、component、version）、状态（status、resolution、triage_stage、has_patch）、关键词、工单类型（Bug 报告 / 功能请求 / 文档 / 清理）以及历史评论中的既往讨论、相关 PR 和先前补丁尝试。
第 2 步：搜索重复与相关工单 进行至少 2-3 次 Trac 搜索，例如按关键词、按错误信息或类/函数名、按组件加关键词组合搜索；对找到的相关工单（前 3-5 个）获取详情。
第 3 步：搜索相关 PR（GitHub） 使用 gh search prs 按工单号、"Fixed #$ARGUMENTS" 或 Trac 工单 URL 搜索，并用 gh pr view 查看相关 PR 的标题、状态、正文与评论。
第 4 步：搜索 Django 论坛 使用 python3 ./scripts/forum.py ticket $ARGUMENTS 按工单号搜索；若无结果，则按关键词在 internals 分类中搜索。
第 5 步：浏览相关源码（如适用） 对需要代码变更的工单，在 django/ 目录中查找相关文件与测试，识别问题代码位置、现有测试覆盖范围以及所需改动范围。
第 6 步：有效性评估 对 Bug 报告检查：可复现性、是否在最新版本出现、是否为 Django 责任、是否与文档行为不符、是否为受支持版本、是否为安全问题（不应出现在 Trac）。 对功能请求检查：通用性、是否符合 Django 设计哲学、是否有第三方包替代、向后兼容性、复杂度、是否需要 DEP。 危险信号（可能无效）：在公开 Trac 报告安全问题（应发至 security@djangoproject.com）、仅影响不受支持的 Django 版本、"只有我需要" 的功能、按文档工作（用户误解）、第三方包问题而非 Django 核心。
第 7 步：分诊决策 阅读 references/triage-stages.md 获取阶段定义与重复判定标准。
第 8 步：保存报告并输出摘要 创建 triage-reports 目录，按 references/report-template.md 的格式将完整报告写入 triage-reports/<ticket_id>.md，并在终端输出简要摘要。
适用场景 适用于 Django 项目的工单分诊工作，尤其是需要快速判断工单有效性、查找重复工单、关联 PR 与论坛讨论、定位源码与测试的场景。
限制 需要预先安装并认证 gh CLI，且需在本地克隆 Django 源码才能进行源码分析；缺少 django/ 目录时会跳过源码浏览步骤。该技能依赖 Trac、GitHub 与 Django 论坛的可用性。