doc-todo-log-loop

基于日志记录驱动的轻量级项目开发和管理方案。如果用户在项目章程提及,应使用此技能。

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "doc-todo-log-loop" with this command: npx skills add cafe3310/public-agent-skills/cafe3310-public-agent-skills-doc-todo-log-loop

Skill: doc-todo-log-loop

1. 概述 (Overview)

本 Skill 定义了一种人机协作的开发工作流,其核心是文档驱动、日志记录的迭代循环。它旨在通过清晰的步骤和产出物,确保开发过程的规范性、可追溯性和高质量,同时允许用户自由控制开发节奏。

此工作流特别适用于需要设计、过程记录和阶段性确认的软件功能开发或问题修复任务。

2. 核心工作循环 (Core Workflow Loop)

本工作流由用户(项目负责人)和 Gemini(开发助理)交替执行,遵循以下六个核心步骤:

步骤 1: 背景描述 -> 文档撰写 (User -> Gemini)

  • 触发: 用户提出一个高阶的功能目标或问题背景。
  • Gemini 的行动:
    1. 与用户充分沟通,理解背景、目标、约束。
    2. 撰写一份正式的需求描述文档。
    3. 文档应遵循项目章程定义的命名约定。如无特别约定,使用 YYYY-MM-DD-HH-mm-需求-{简述}.md
    4. 如果 agent 有 plan mode 中已经被接受的 plan 文件,也要留在文档目录下,用文件的创建时间作为文件名上的时间。

步骤 2: 需求描述 -> TODO 拆分 (User -> Gemini)

  • 触发: 用户基于设计文档,或直接提出具体的功能需求。
  • Gemini 的行动:
    1. 将高阶需求拆解为一系列具体的、可执行的待办事项。
    2. 将这些待办事项结构化地更新到项目章程定义的 TODO.md 文件中。如无特别约定,放在项目根目录下。
    3. 每个待办事项应尽可能清晰、原子化。

步骤 3: 任务指派 (User -> Gemini)

  • 触发: 用户从 TODO.md 中选择一个或一组待办事项,并明确指示 Gemini 开始执行。
  • Gemini 的行动:
    1. 确认任务指令。
    2. 绝不能在收到用户明确指令前,提前进行开发。

步骤 4: 开发与确认 (Gemini -> User)

  • 触发: Gemini 接收到开发指令。
  • Gemini 的行动:
    1. 执行具体的开发任务,如修改代码、创建文件、安装依赖等。
    2. 每完成一个有意义的、原子性的操作后,都应停下并等待用户确认。
    3. 用户作为审查者和测试者,对 Gemini 的操作结果进行确认。如果发现问题,应立即指出,Gemini 负责修正。

步骤 5: 开发日志记录 (Gemini -> User)

  • 触发: 在一个阶段性功能或一个完整的 TODO 事项 经用户确认 完成后。
  • Gemini 的行动:
    1. 撰写一份新的开发日志。
    2. 开发日志应遵循项目章程中提及的命名和目录约定。如无特别约定,放在项目日志目录下并在命名中统一命名 YYYY-MM-DD-HH-mm-开发日志-{标题}.md
    3. 日志内容应总结本次开发的工作,包括:
      • 实现了哪些功能点。
      • 对代码或项目结构做了哪些主要修改。
      • 遇到了哪些问题,以及是如何修正的(包括用户和 Gemini 双方)。
      • 对后续步骤的建议或说明。

步骤 6: 版本控制 (User)

  • 触发: Gemini 完成开发日志的撰写。
  • 用户的行动:
    1. 审查最终的代码变更和开发日志。
    2. 执行 git addgit commit 等操作,将本次开发的产出物提交到版本控制系统中。Gemini 不负责此步骤。

3. 文档命名与分类规范 (Document Naming & Classification)

本 Skill 默认实施统一的文档命名格式:

YYYY-MM-DD-HH-mm-{类别}-{标题}.md

文档类别定义:

如果用户要求,Gemini 可以随时写文档。命名时,按建议的下列分类进行归类:

  1. 开发日志 (最重要): 对过去一段时间开发过程、决策、遇到的问题及解决方式的忠实记录。
  2. 需求 (最重要): 忠实记录用户想要实现的功能或达到的目标。仅包含「需求」本身,不含实现细节。
  3. 设计: 对即将实施的任务进行的提前分析。可使用包括 系统设计架构设计交互设计需求设计 的子类别。
  4. 规范: 定义未来广泛适用的规则、流程或标准。可使用包括 架构规范代码规范流程规范 的子类别。
  5. 文档: 对已完成的技术实体(如接口、模块、工具)的使用说明和描述。可用 接口文档模块文档 等子类别。
  6. 调研: 对外部技术、互联网资料或其他现有文档的研究与对比分析。
  7. 参考: 从外部摘录的资料、API 说明书或原始规范。与「调研」的区别在于其侧重于原样引用而非主动分析。

4. Gemini 的主动性与约束 (Constraints & Proactivity)

为了提升协作效率,Gemini 在此 Skill 中被赋予了有限的主动性。

  • 可以主动:
    • 在完成一个步骤(如步骤 4 或 5)后,主动查阅 TODO.md 和最新的开发日志。
    • 基于查阅结果,向用户 建议 下一步可以执行的任务。例如:“开发日志已记录完毕。根据 TODO.md,下一个待办事项...。需要现在开始吗?”
  • 禁止主动:
    • 绝对禁止 在未获得用户明确指令的情况下,提前开始任何待办事项的开发工作。

此约束旨在确保用户始终对开发节奏拥有完全的控制权。

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Automation

weekly-report-writer

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

im-local-kb

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

project-design-concept-organizer

No summary provided by upstream source.

Repository SourceNeeds Review
Automation

project_management

No summary provided by upstream source.

Repository SourceNeeds Review