ogt-docs-create-task

核心用法

该 Skill 实现了基于文件系统的文档优先（docs-first）任务管理方法论。通过标准化的 docs/todo/ 目录结构，任务以文件夹形式在 pending/（待办）、in_progress/（进行中）、review/（审核）、done/（已完成）等阶段流转。每个任务文件夹包含 task.md（任务定义）、progress.md（进度日志）、implementation.md（实现记录）等结构化文档，以及 .version、.priority、.verified 等信号文件（signal files）来标记状态和元数据。这种设计将任务生命周期管理与文档编写紧密结合，强制要求在每个阶段留下书面记录，形成完整的决策链条。

显著优点

首先，流程高度标准化，提供从任务创建到部署上线的完整工作流模板，减少团队沟通成本，特别适合异地协作。其次，可追溯性极强，通过 progress.md 和 implementation.md 强制记录决策过程，便于后期复盘和知识沉淀。第三，验证机制严格，要求必须创建 .verified 信号文件和详细的 verification.md 文档才能将任务标记为完成，有效防止"虚假完工"。第四，与版本控制天然集成，基于文件的设计与 Git 工作流完美契合，PR 链接可直接记录在 .pr_link 文件中，实现代码与任务状态的同步。最后，状态可视化直观，通过文件系统层级即可快速查看项目整体进度，无需依赖外部工具。

潜在缺点

该方案的主要局限在于操作 overhead 较高，需要手动创建、移动文件夹和文件，相比 Jira、Linear 等电子看板效率较低。其次，学习曲线陡峭，开发者需要理解信号文件约定和文档模板规范，增加了认知负担。第三，缺乏自动化能力，作为纯文档指导型 Skill，不提供自动化脚本，所有状态流转依赖人工执行 bash 命令。此外，不适合快速迭代场景，对于需要频繁调整优先级或快速原型开发的敏捷团队，文件系统操作可能显得笨重且拖慢节奏。

适合目标群体

适合注重文档沉淀、需要严格审核流程的开发团队，特别是开源项目维护者、需要合规审计的企业级应用开发，以及偏好 Git 原生工作流的技术团队。对于追求极致敏捷、团队规模较小或任务流转极快的项目，建议权衡使用成本。

使用风险

主要风险包括人为操作错误，手动执行 mv 命令可能误删或误移动任务文件夹，强烈建议配合版本控制使用以便回滚。其次是路径权限问题，需要确保对 docs/todo/ 目录的读写权限，在多用户协作时需注意文件锁定冲突。第三是文档与状态不同步，信号文件与实际情况可能不一致（如忘记创建 .blocked 文件但任务实际已阻塞），需要团队高度自律维护。最后，由于是 T3 来源的个人项目，建议企业用户在使用前进行内部安全审计。