| name | issue-tracker-workflow |
| description | 创建和使用团队问题跟踪表，把问题描述、截图或录屏、处理状态、代码修复、 开发自测与人工验收串成闭环。用户说“记录这个 bug / 建问题表 / 问题汇总表 / 处理这条问题 / 解决这个问题单”，或当前上下文包含问题表、问题记录链接时使用。 |
问题跟踪工作流
把表格当作团队可见的问题处理现场。Skill 只定义稳定流程；表 ID、仓库、分支、
发布规则等运行时信息从当前资源与 Workspace 规则读取，不写死在 Skill 中。
入口判断
按顺序判断：
- 当前上下文有表格或记录链接：读取表结构；结构兼容时直接处理对应记录。
- 用户明确要创建问题表：先展示下方表结构与用途，询问是否创建。
- 用户明确要记录、分派或持续跟踪问题，但没有兼容表：提醒一次并询问是否创建。
- 用户只是在咨询报错、排查一次性问题：直接帮助解决，不推销建表。
提醒使用这段产品语言，可按上下文压缩但不要省略“会创建什么”：
看起来你想把这个问题交给团队持续跟踪。小Tin 可以创建一张「问题跟踪」表，
用来保存问题描述、证据附件、负责人、处理状态、修复反馈和验收结果。
是否现在创建，并把这个问题记录进去？
创建前必须得到用户明确同意。用户拒绝时继续当前任务，不重复提醒。
标准表结构
初始化脚本创建以下字段：
| 字段 | 类型 | 用途 |
|---|
| 问题描述 | text | 主字段，一句话说明问题 |
| 证据附件 | attachment | 截图、录屏或日志文件 |
| 环境信息 | long_text | 系统、版本、复现环境 |
| 状态 | select | 唯一状态机 |
| 负责人 | user | 当前处理责任人 |
| 修复反馈 | long_text | 改了什么、在哪里、怎么验证、下一步 |
| 验收附件 | attachment | 实际效果或验收证据 |
| 验收日期 | date | 人工验收通过时间 |
| 提交人 | created_by | 自动记录创建者 |
| 提交时间 | created_time | 自动记录创建时间 |
状态值固定为：
新提交 → 待处理 → 处理中 → 开发自测 → 待部署 → 待验收 → 已完成
分支终态：重复、无法复现、已取消、暂不处理、待产品确定、后续排期。
经用户同意后运行：
bash scripts/ensure-issue-tracker-table.sh
脚本会复用同名兼容表；同名表结构不兼容时停止，不会擅自改表或再建重名表。
成功后读回 table_id，继续记录当前问题。只想向用户展示建表内容时运行
bash scripts/ensure-issue-tracker-table.sh --preview，它不会写数据。
兼容已有问题表
不要靠固定 UUID 识别问题表。按字段语义识别，并兼容以下旧字段名：
| 标准字段 | 兼容字段名 |
|---|
| 问题描述 | Bug 描述 |
| 证据附件 | 操作录屏 / 截图 |
| 环境信息 | 系统 |
| 负责人 | 指派人 / 提交人 |
| 验收附件 | 验收截图 |
有当前 table_id 时可验证并复用：
bash scripts/ensure-issue-tracker-table.sh --table-id <table_id>
结构不兼容时说明缺哪些能力，并询问用户是创建标准表，还是只处理当前任务；不要
自动给业务表补字段。
处理一条问题
- 用记录链接原样读取详情；描述很短时先看证据附件，再判断需求。
- 开始处理后把状态改为
处理中，让团队看到有人接手。
- 完成代码修改与验证；代码交付按下一节读取当前 Workspace 规则。
- 只有在真实客户端或运行环境亲眼验证后，才转为
开发自测。
- 填写修复反馈：改了什么、在哪里、怎么验证、下一步等谁。
- 有部署环节则进入
待部署；部署完成且证据齐全后进入 待验收。
已完成、验收附件和验收日期属于人工验收动作，Agent 不代替用户确认。
记录链接优先直接使用，不手工拆 UUID：
tabtin table record detail "<record-url>" --format json
tabtin table record update --url "<record-url>" --set "状态=处理中"
状态必须名副其实：lint、类型检查和单元测试通过仍只是代码验证，不等于客户端
开发自测。拿不准时停在前一个状态，并在修复反馈里说明阻塞点。
代码交付边界
本 Skill 不规定分支名、GitFlow、远端仓库、PR 目标或发布节奏。进入代码处理阶段时：
- 读取当前 Workspace 的
AGENTS.md、仓库规则和相关开发 Skill。
- 检查当前分支、工作树与仓库状态。
- 按仓库自己的测试、提交和交付规则执行。
- 没有仓库规则且是否提交会改变结果时，先询问用户；不要创造发布制度。
问题表负责“谁在处理、证据是什么、走到哪一步”；仓库规则负责“代码怎么交付”。
两者不要互相硬编码。
