用途：对工单进行双重评分——工单清晰度（A-F，百分制）与代码改动对工单的解决对齐度（A-F，百分制），最终给出是否可发布的结论。
主要能力：
- 识别工单：未提供 ID 时从当前分支名解析，如 gareth/min-1916-slug → MIN-1916、gh-123-slug → GitHub issue #123、fix/PROJ-456-slug → PROJ-456。
- 加载项目评估指南：若项目根目录存在 .cursor/ticket-assessment.md，则读取并叠加其项目特定标准；不存在则跳过。
- 获取工单：依次尝试 Linear CLI（lc issue get <TICKET_ID> --json）、GitHub（gh issue view <number>），都失败则仅用分支名并标记置信度降低。捕获标题、描述/验收标准、优先级、标签、关联问题。
- 获取评论与附件：Linear 来源时用 lc comment list <TICKET_ID> --json 取评论，扫描评论中 uploads.linear.app 的 Markdown 链接（最多 5 个）并用 API key 下载，仅限该域名；PDF/图片用 Read 工具读取，文本直接读取，并汇总附件内容。
- 清晰度评分维度：问题陈述 25%、复现路径 20%、验收标准 25%、范围边界 15%、上下文与证据 15%。C 及以下需列出可能导致错误修复的具体歧义。
- 理解修复：检测基线分支（优先 gh pr view --json baseRefName，其次 origin/HEAD，最后 main），执行 git diff $base...HEAD、git diff --name-only $base...HEAD、git log --oneline $base...HEAD，阅读改动文件并理解代码路径、触发条件与用户场景。
- 对齐度评分维度：根因匹配 35%、完整性 25%、无过度修复 15%、回归安全 15%、用户体验 10%。核心是根因追踪：识别用户动作或系统事件，沿代码追踪失败点，检查 diff 是否修改该失败点，不匹配则标记。
使用方式：/ticket-check 自动从分支名识别工单；/ticket-check MIN-1916 显式指定。输出包含工单信息、清晰度评分与理由、对齐度评分、根因追踪、覆盖缺口、过度修复、回归风险与最终结论。
适用场景：代码评审前评估工单质量与改动是否对症，尤其适合 Linear/GitHub 工作流。
限制：依赖 lc、gh、jq、curl 等工具与相应配置；Linear 评论与附件步骤在 which lc 失败或 ~/.linearctl/config.json 不存在时跳过；无工单来源时仅凭分支名，置信度降低；仅从 uploads.linear.app 下载附件，不跟随任意 URL。具体安装方式与收费信息暂未提供。