issue-tracker-workflow

name	issue-tracker-workflow
description	创建和使用团队问题跟踪表，把问题描述、截图或录屏、处理状态、代码修复、 开发自测与人工验收串成闭环。用户说“记录这个 bug / 建问题表 / 问题汇总表 / 处理这条问题 / 解决这个问题单”，或当前上下文包含问题表、问题记录链接时使用。

问题跟踪工作流

把表格当作团队可见的问题处理现场。Skill 只定义稳定流程；表 ID、仓库、分支、 发布规则等运行时信息从当前资源与 Workspace 规则读取，不写死在 Skill 中。

入口判断

按顺序判断：

1. 当前上下文有表格或记录链接：读取表结构；结构兼容时直接处理对应记录。
2. 用户明确要创建问题表：先展示下方表结构与用途，询问是否创建。
3. 用户明确要记录、分派或持续跟踪问题，但没有兼容表：提醒一次并询问是否创建。
4. 用户只是在咨询报错、排查一次性问题：直接帮助解决，不推销建表。

提醒使用这段产品语言，可按上下文压缩但不要省略“会创建什么”：

看起来你想把这个问题交给团队持续跟踪。小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>

结构不兼容时说明缺哪些能力，并询问用户是创建标准表，还是只处理当前任务；不要 自动给业务表补字段。

处理一条问题

1. 用记录链接原样读取详情；描述很短时先看证据附件，再判断需求。
2. 开始处理后把状态改为 处理中，让团队看到有人接手。
3. 完成代码修改与验证；代码交付按下一节读取当前 Workspace 规则。
4. 只有在真实客户端或运行环境亲眼验证后，才转为 开发自测。
5. 填写修复反馈：改了什么、在哪里、怎么验证、下一步等谁。
6. 有部署环节则进入 待部署；部署完成且证据齐全后进入 待验收。
7. 已完成、验收附件和验收日期属于人工验收动作，Agent 不代替用户确认。

记录链接优先直接使用，不手工拆 UUID：

tabtin table record detail "<record-url>" --format json
tabtin table record update --url "<record-url>" --set "状态=处理中"

状态必须名副其实：lint、类型检查和单元测试通过仍只是代码验证，不等于客户端 开发自测。拿不准时停在前一个状态，并在修复反馈里说明阻塞点。

代码交付边界

本 Skill 不规定分支名、GitFlow、远端仓库、PR 目标或发布节奏。进入代码处理阶段时：

1. 读取当前 Workspace 的 AGENTS.md、仓库规则和相关开发 Skill。
2. 检查当前分支、工作树与仓库状态。
3. 按仓库自己的测试、提交和交付规则执行。
4. 没有仓库规则且是否提交会改变结果时，先询问用户；不要创造发布制度。

问题表负责“谁在处理、证据是什么、走到哪一步”；仓库规则负责“代码怎么交付”。 两者不要互相硬编码。