메뉴
用户报告问题时的结构化拆解与追踪。将一个问题拆解为「产品设计类」和「技术实现类」，分别记录到对应的追踪文件，确保产品经理和技术架构师下次激活时能感知到未解决问题。触发词：「有个问题」「发现了bug」「这里不对」「用不了」「为什么会」「有个bug」。
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
SOC 직업 분류 기준
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/TashanGKD/tashan-cursor-skills --skill issue-tracker명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
| name | issue-tracker |
| description | 用户报告问题时的结构化拆解与追踪。将一个问题拆解为「产品设计类」和「技术实现类」，分别记录到对应的追踪文件，确保产品经理和技术架构师下次激活时能感知到未解决问题。触发词：「有个问题」「发现了bug」「这里不对」「用不了」「为什么会」「有个bug」。 |
用户反馈的问题往往同时包含「产品设计层面的问题」和「技术实现层面的问题」。把它们混在一起处理，要么产品经理不知道，要么开发只修了代码但设计漏洞还在。
本 Skill 的作用：拆解 → 分类 → 记录到正确的地方 → 保证不被遗忘。
| 层级 | 文档 | 需要理解的概念 |
|---|---|---|
| D0 认知根（必读） | _内部总控/认知结构/L1_系统性文档/产品理论维度/AI时代产品问题全景框架.md | §一 产品问题全景框架（产品设计类vs技术实现类的分类依据）；§十 各角色职责边界 |
| D3 规范参考 | — | 本 Skill 主要是分类路由，无特定规范参考 |
| D4 运行时数据 | 项目群/[项目]/产品经理/产品问题追踪台.md + 项目群/[项目]/技术架构师/技术问题追踪台.md | 写入目标（追踪台文件路径，与各角色领地一致） |
核心概念速查： ① 产品设计问题 = 「应该做什么」的疑问，需PM决策，写入产品问题追踪台 ② 技术实现问题 = 「怎么做」的疑问，AI可直接修复，写入技术问题追踪台 ③ 同一问题可能同时有两种属性（例：某功能体验不好=产品设计问题+可能的技术实现缺陷）
| 本 Skill（问题追踪） | 产品反馈处理 | 规范迭代审核 | |
|---|---|---|---|
| 触发 | 用户报告了现有功能的问题（不对、用不了、报错） | 用户提出改进想法（想要新功能） | 审核 AI 对比实现与规范的差距 |
| 核心动作 | 拆解根因 + 分类记录 | 评估是否值得做 | 更新开发规范 |
| 输出 | 产品问题追踪台 + 技术问题追踪台 | 产品定义更新 + 开发计划 | 开发规范.md |
Step 1 理解用户描述的具体问题现象（不要急于判断根因）
→ 问清楚：「你看到了什么？」「期望看到的是什么？」「怎么操作触发的？」
→ 如果现象描述不清晰，先追问，再继续
Step 2 拆解根因：判断这个问题属于哪一类（可多选）
□ 产品设计类：入口不对、流程断裂、用户感知歧义、功能缺失、交互误导
□ 技术实现类：代码 Bug、接口错误、数据写入失败、性能问题、边界情况未处理
Step 3 分类记录（见下方记录格式）
→ 产品设计类 → 写入「产品问题追踪台」
→ 技术实现类 → 写入「技术问题追踪台」
→ 两类都有 → 两个文件都写
Step 4 输出拆解结果给用户，说明：
「这个问题有两个层面：[产品层面]... [技术层面]...，已分别记录，下次处理对应模块时会自动看到。」
若问题属于「技术-产品冲突（技术无法实现某需求）」类型，且产品定义已被修改：
→ 提醒用户：「产品需求范围已变更，请在修改后说「做审核」重新触发关卡A，确保新版产品定义通过审核」
Step 5 判断是否需要立即处理
⚠️ 优先轴是「AI 确定/不确定」，P0/P1/P2 是辅助参考：
P0 + AI 确定修法（唯一技术方案）→ 立即处理，不等下次
P0 + AI 不确定（涉及产品设计 / 多方案权衡）→ 立即向用户呈现，等待决策
P1/P2 + AI 确定 → 记录进追踪台，可在当前轮次顺手修复
P1/P2 + AI 不确定 → 仅记录，不打断当前任务
若项目是 AI Agent 平台（如 tashan-openbrain），记录时标注架构层：
L1/L2/L3/L4/L5/FE（帮助 bug-fix-loop-coordinator 按层排序）
Step 6 【Bug 修复后必须执行】检查是否需要写入踩坑记录
每次修复完一个 Bug，在关闭追踪台条目之前，先问：
□ 这个 Bug 是一个可重复踩的模式吗？（下次遇到类似场景还会犯同样的错？）
□ 现有踩坑速查里有没有覆盖这类问题？
→ 是可重复模式 且 踩坑速查没有覆盖 → 立即追加到对应的踩坑速查文件：
前端问题 → `.cursor/skills/role-前端开发/knowledge/前端踩坑速查.md`
后端问题 → `.cursor/skills/role-后端开发/knowledge/后端踩坑速查.md`
部署问题 → `.cursor/skills/role-DevOps/knowledge/部署踩坑速查.md`
→ 已有覆盖 / 是一次性错误 → 不需要写，关闭追踪台条目即可
⚠️ **禁止「稍后统一补」**：踩坑记录必须在当次修复完成后立即写入，
不允许以任何理由推迟。推迟等于不写。
格式（追加一行到踩坑速查表）：
| FE-XX | [症状] | [根因] | [修复方案] |
文件路径：产品经理/产品问题追踪台.md（若不存在则创建）
## 产品问题追踪台
> 由 issue-tracker Skill 自动维护。
> 产品经理每次激活时读取此文件，处理「未解决」状态的问题。
| ID | 发现日期 | 问题描述 | 现象 | 影响范围 | 优先级 | 状态 | 处理记录 |
|---|---|---|---|---|---|---|---|
| PD-001 | 2026-03-19 | [一句话描述设计问题] | [用户看到了什么] | [哪个功能/用户流] | P0/P1/P2 | 未解决 | — |
状态值：未解决 / 处理中 / 已修复（产品定义已更新） / 已存档（不修复，附理由）
文件路径：技术架构师/技术问题追踪台.md（若不存在则创建）
## 技术问题追踪台
> 由 issue-tracker Skill 自动维护。
> 技术架构师和开发角色每次激活时读取此文件，处理「未解决」状态的问题。
| ID | 发现日期 | 问题描述 | 现象/报错 | 涉及模块 | 优先级 | 状态 | 处理记录 |
|---|---|---|---|---|---|---|---|
| TC-001 | 2026-03-19 | [一句话描述技术问题] | [错误信息/行为] | [文件/函数/组件] | P0/P1/P2 | L1/L3/FE（架构层，AI平台项目填写）| 未解决 | — |
状态值：未解决 / 处理中 / 已修复（含 commit 或修改说明） / 已存档（已知限制，不修复）
| 优先级 | 定义 | 处理策略 |
|---|---|---|
| P0 | 阻塞核心用户路径（用户完全无法完成关键操作） | 立即处理，本次对话内解决 |
| P1 | 功能错误但有绕行方案，或影响主要体验 | 记录后尽快排期，下一个工作单元处理 |
| P2 | 体验问题、边界情况、非核心路径的异常 | 记录进追踪台，按优先级排队 |
问题从「未解决」到「已修复」，必须有明确的角色负责关闭，否则追踪台会永远堆满「未解决」。
| 问题类型 | 谁写入（未解决） | 谁关闭（已修复） | 关闭时机 |
|---|---|---|---|
| 产品设计问题 | issue-tracker / 关卡A / 测试工程师 | 产品经理 | 产品定义已更新，问题已解决 |
| 技术实现问题 | issue-tracker / 关卡B / 测试工程师 | 前端/后端/AI工程师 | 代码已修复，测试工程师已验证 |
关闭格式：将对应行的「状态」列改为 已修复（2026-03-19，修复说明：xxx）
记录完成后，根据问题类型和优先级决定后续行为：
【产品设计类问题】→ 任何优先级都需要用户（产品经理/战略家）决策
P0 → 立即加载 role-产品经理 Skill，向用户呈现问题，等待指令
P1/P2 → 记录到产品追踪台，下次产品经理激活时呈现
【技术实现类问题】→ 原则上由 AI 直接处理，无需用户确认
P0 → 立即加载对应开发 Skill 直接修复，修复后通知用户结果
P1 → 直接修复，修复后通知用户结果
P2 → 直接修复，修复后通知用户结果
⚠️ 例外：如果有多个技术方案，必须先列出方案对比（见下方格式），等用户选择后再执行
## 技术方案对比：[问题描述]
| 方案 | 做法 | 优点 | 缺点 | 推荐程度 |
|---|---|---|---|---|
| 方案A | [具体实现] | [优点] | [缺点] | ⭐⭐⭐ |
| 方案B | [具体实现] | [优点] | [缺点] | ⭐⭐ |
**推荐**：方案A，因为 [一句话理由]。
请确认选择哪个方案，或直接说「按推荐」。
判断标准：以下情况构成「多方案」，需要用户选择：
以下情况不需要列方案，直接做：
产品经理激活时会读取 产品经理/产品问题追踪台.md，处理「未解决」问题。
技术架构师/开发激活时会读取 技术架构师/技术问题追踪台.md，处理「未解决」问题。
这两个读取步骤需要在对应 Skill 的「激活后立即执行」中注册（见下方说明）。
本 Skill 创建后，以下两个 Skill 需要在「激活后立即执行」加入读取追踪台的步骤：
role-产品经理/SKILL.md：
在 Step 1（Read 产品定义）之后，加入：
Step 1.5 Read: 产品经理/产品问题追踪台.md
→ 检查有无「未解决」的产品设计问题
→ 有 P0 → 优先处理，当前任务暂停
→ 有 P1/P2 → 纳入本次工作范围考量，视情况处理
role-技术架构师/SKILL.md：
在 Step 1（Read 产品定义）之后，加入：
Step 1.5 Read: 技术架构师/技术问题追踪台.md
→ 检查有无「未解决」的技术问题
→ 有 P0 → 优先处理
→ 有 P1/P2 → 纳入架构方案考量
role-后端开发/SKILL.md 和 role-前端开发/SKILL.md：
在 Step 1（Read 技术架构）之后，加入：
Step 1.5 Read: 技术架构师/技术问题追踪台.md
→ 检查涉及自己模块的未解决技术问题
根因：在双模式开发中，发现系统存在多个真实问题（[continue] 路由不稳定、proxy_dialogs 写入机制在 StreamingResponse 生成器中的执行时机问题等），这些问题有些是产品设计层面，有些是技术实现层面，但没有统一机制将它们结构化记录下来，问题可能在对话结束后被遗忘，下次产品经理或技术架构师激活时也无法感知。
修改内容：
验证结果：
已知风险：追踪台文件路径依赖项目目录结构，新项目启动时需要确认 产品经理/ 和 技术架构师/ 目录已存在
根因：追踪台只有写入没有关闭规范，时间一长全是「未解决」。
修改内容：
根因：用户明确指出技术问题 P1/P2 应由 AI 直接修复不需确认，只有产品设计/战略类问题需要用户决策；有多个技术方案时需要列出对比。原 Skill 缺少这个分层规则，导致 AI 把所有 P1/P2 记录后静默等待，没有自主处理。
修改内容：
验证结果：
根因：scenario-sandbox-builder Phase 2 验证（PD-014沙盘）发现：技术-产品冲突记录后，系统缺少提醒「产品需求变更后需重新触发关卡A」的机制，导致修改后的产品定义可能未经审核就进入开发。
修改内容：
验证方法：issue-tracker 处理技术-产品冲突时，应输出 GATE-A 重触发提醒 验证状态：🔵 待验证
根因：BrainChat 的 sendMessage import 遗漏 Bug 修复完成后，没有任何机制提示 AI 把这个踩坑写入踩坑速查文件，导致同类问题可能再次发生。流程缺口：Bug 修复 → 追踪台关闭，但踩坑速查没有更新。
修改内容：
验证结果：