Linear 任务跟踪自动化

问题背景

工程团队把 Linear 当「单一事实来源」时，常见痛点是：新工单堆在 inbox 没人统一分级、周期（Cycle）承诺和实际 PR/CI 状态脱节、子任务结构不一致导致复盘时对不上号。若只靠 UI 点选，很难把 Bug Report / Feature Request 模板、标签体系和 GitHub 分支、PR 的对应关系固化成可重复流程。

技能如何工作

本技能围绕 Linear 的工单与周期管理，把文档里列出的能力串成可执行的工作流说明，而不是替代 Linear 本身：

• Issue Lifecycle：从创建、指派、状态流转到关闭的完整生命周期，配合 Automation Triggers 在状态或字段变化时触发后续动作（具体动作需结合你的集成与团队规范）。
• Issue Templates：按 Bug Report、Feature Request 与 Sub-Issue Structure 统一字段与子任务拆分，减少「标题写了、上下文没写」的工单。
• Cycle Management：覆盖 Cycle Planning、Cycle Dashboard，把周期范围与承诺可视化，便于对照 backlog 做取舍。
• GitHub Integration：Branch & PR Sync、CI/CD Integration，把代码侧事件与工单状态对齐（需你方已配置官方或认可的集成）。
• Labels & Organization 与 Reporting（如 Velocity Tracking、Team Analytics）用于归类与回顾；API Examples 中的 GraphQL 查询可作为批量查询或报表脚本的起点。

文档中的 Best Practices（如日更 triage、规划扑克估点、PR/commit/docs 互链、保护 cycle scope 等）可作为与 Agent 协作时的检查清单。

适用边界与注意

• 技能描述的是流程与能力边界；不会擅自安装依赖、改系统权限或创建持久化后台任务。
• 涉及向 Linear/GitHub 等服务的发送、发布、删除、部署等写入操作，应先说明目标与影响并取得你明确确认；凭据仅用于你指定的官方服务。
• GraphQL 与集成示例默认作参考；在你未明确要求且范围不清时，不应自动执行命令或批量改库。