其他
管理 Conductor tracks 的规格…
适用于在 Conductor 中创建、维护和完成 feature、bug、refactor tracks，并编写或更新 spec.md、plan.md、状态标记与 tracks.md 注册表的场景。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 35/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 38/100 ×0.15
适用场景
管理 Conductor tracks 特定
解决思路
- 保持一个 track 只负责一个关注点，只包含单个逻辑变更。
- 将工作拆成小阶段，每个阶段最多 3-5 个任务。
- 每个阶段后都加入验证任务，确保阶段成果被检查。
- 工作过程中立即更新任务状态标记，不要等最后统一更新。
- 为每个已完成任务记录对应的 commit SHA。
- 创建 plan 前先审查 spec，确保 spec 已完整。
- 显式标注 track 之间的依赖关系。
- 完成的 track 要归档而不是删除，以便后续参考。
- 将 track 的工作量控制在 1-5 天范围内。
- 为每条需求写清晰且可测试的验收标准。
- 当上层导航信息不足时，读取 references/details.md 获取详细模式和示例。
适用边界 · 注意事项
- 项目没有使用 Conductor tracks，或没有 spec.md、plan.md、tracks.md 这套工作流时，不应套用本技能。
- 当单个变更无法拆成 3-5 个任务的小阶段，或工作量明显超过 5 天且无法拆分时，应先拆分或重新评估，而不是直接按本技能管理。
- 不要把多个不相关的关注点合并到一个 track；这种场景应先拆成多个 track。