Community生产力与协作github.com

Lujker/road-map-journal

用于处理项目的路线图、开发计划、队列、工作日志或项目状态:询问下一步计划、继续或恢复计划工作、记录决策、更新项目或根据证据协调状态。遵循项目自身约定。触发词包括「дорожная карта」、「что дальше по плану?」、「продолжай разработку по плану」、「запиши решение」、「обнови статус пункта」。

road-map-journal 是什么?

该技能旨在帮助 AI 代理在与项目路线图、开发计划、工作队列、工作日志或项目状态相关的请求中进行交互,而无需强制推行新的布局。它遵循用户指令和项目自身的约定,保留现有的名称、标识符、语言、链接、未提交更改和不相关的内容。技能支持多种模式,包括只读模式(从相关文档和证据中获取答案,不进行编辑)、初始化模式(在新项目中讨论并提出合适的计划结构)、采用模式(使用现有计划材料)、恢复模式(根据最新指令和当前状态继续工作)以及更新模式(对现有记录进行修改)。在记录和协调时,技能强调使用项目已有的安排,维护稳定标识符,不静默删除决策或取消的工作,并确保状态更新与接受标准和实际证据保持一致。它要求在工作前进行发现步骤,识别项目根目录和相关文档,并且不假设使用 Git、特定目录布局或状态词汇。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Lujker/road-map-journal/tree/HEAD/skills/road-map-journal

Installed? Explore more 生产力与协作 skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

路线图与工作日志

维护一份有用的当前计划和可追溯的决策记录,而不强制采用新的布局。遵循用户指令和项目自身的约定。保留现有的名称、标识符、语言、链接、未提交的更改和不相关的内容。对于新计划,使用用户指定或合理指示的语言;如果不明确,请询问。不要强加语言。

何时使用

用于有关路线图、开发计划、队列、工作日志、项目状态或继续计划工作的请求。示例包括“路线图上接下来是什么?”、“继续商定的项目”、“дорожная карта”、“план разработки”、“дневник разработки”、“что дальше по плану?”和“продолжай разработку по плану”。根据上下文确定请求的范围;状态问题为只读。

先发现

识别项目根目录并阅读其说明。定位现有的路线图、队列、项目说明和交接文档;名称和位置可能不同。阅读相关项目、其验收标准、当前队列和关联的说明。检查相关实现、版本控制状态(如果可用)以及在需要当前状态评估时所需的证据。不要假设 Git、特定的目录布局或特定的状态词汇。对于多个仓库,遵循现有链接;如果无法访问权威位置,请询问,而不是自行创建替代位置。

根据请求隐含的模式选择:

  • 只读: 根据相关文档和证据回答。区分记录的声明与独立检查的事实;不进行任何编辑。
  • 初始化: 如果不存在计划,与所有者讨论其期望的工作方式,并提议合适的结构、位置、范围、初始项目和排序;在相关时包含轨道、代理角色和初始卡片。对于更深入的探索,如果可用且合适,请使用 grill-me;如果不可用,则提供安装它的帮助,但未经许可不得安装或阻塞工作流。否则,自行促成简洁的结构化讨论,并就未解决的选项提出建议。在创建文件前获得用户知情同意;不要擅自设定优先级或承诺。
  • 采用: 如果已有计划材料,则就地使用。当用户要求进行实质性审查时,使用与初始化相同的可选结构化讨论,但根据未解决的内容进行调整。解释任何提议的新文件、迁移或实质性重写,并事先获得知情同意。不要静默地创建平行的真相源。
  • 恢复: 阅读最新的指令、活动队列、项目说明和相关当前状态。根据当前证据和用户的最新决策解决矛盾或过时的指令;如果存在重大冲突,请询问。如果项目尚未选择或委托,请在实施前就一个项目达成一致。已保存的计划或批准记录并不意味着授权开始工作。
  • 更新: 对现有记录进行请求的、范围限定的更改。保持项目状态、剩余工作和受影响的队列条目一致;保留历史记录和不相关的排序。对于新文件或实质性重写,请解释提议的更改并事先获得知情同意。局限于一个项目的请求并不意味着授权实施或重写计划的其余部分。

记录与协调

使用项目既定的安排。通常,路线图总结项目及其当前顺序;日志记录决策、发现、证据和历史。链接比重复长细节更好。保持标识符稳定。不要静默删除决策或取消的工作:在相关时将其标记为已取代或已取消,并附上原因。

当决策、暂停或顺序发生更改时,在授权范围内更新受影响的当前摘要和下一步指令;将先前的指令标记为历史。暂停或延迟的计划不能显得像是继续工作的活动指令。不要仅仅因为添加了备注就重新排序不相关的工作。如果必要的更正超出了授权范围,请向用户标记,而不是扩大编辑范围。

除非所有者已授权更广泛的范围,否则一次只处理一个项目,并且不要自动开始下一个项目。完成子阶段并不意味着完成父项目;记录剩余部分。保持工作模式与权限和预算分离:授权继续并不等同于对生产操作或外部写入的全面许可。保持已记录的完成、待定的用户验收和完全验收的工作之间的区别。在交接、决策、验证结果和阻塞点处保留简洁的检查点,包括剩余内容和如何恢复;在重复不确定的在途操作之前,先进行验证。在对共享检出进行多文件更新之前,在写入前立即检查版本控制状态和脏路径,针对最新读取的内容应用狭窄的编辑,保留不相关的工作,并验证更改的范围,但除非获得授权,否则不要提交或发布。

对于跨越多个项目、代理或会话的工作,有预算,或者所有者授权轨道或连续模式,请先阅读 长时间运行的工作。

状态与证据

使用项目的状态词汇。如果不存在,建议使用 OPEN、IN_PROGRESS、BLOCKED、PARTIAL 和 DONE,并为项目商定其含义。根据验收标准和实际证据(而非意图或委托人的无依据声明)记录状态。对于 PARTIAL,指明剩余工作以及任何阻塞因素。保持受影响的状态引用一致。

记录实际执行过的检查、其结果、范围以及(如果相关)执行人。证据可能是历史性的或来自另一个执行者;注明其来源和适用性,并且不要暗示它已重新运行。如果后续更改使检查无效,则识别或执行适当的验证。绝不要编造命令、结果、测试计数、批准或用户验收。自动化测试、已发布的代码和实时操作是不同的声明:绝不要从实现或测试推断出实时验收。如果所需的验收尚未发生,则保留 PARTIAL 或项目的等效状态,并说明缺失的环境或批准。

在进行授权编辑后,检查受影响的状态、队列、链接以及与证据和范围的一致性。报告更改、实际执行过的检查以及未解决的项目。不要声称执行了未进行的验证。

参考

  • 通用模板 — 可选的起点,需根据项目进行调整。
  • 场景 — 模式和范围选择的简洁示例。
  • 长时间运行的工作 — 轨道、检查点、暂停和停止、验收、预算、共享检出。
  • 多仓库协调 — 跨检出保留工作并区分已记录、Git 和实时状态。

相关技能