long-task

语言 / Language

中文 | English

---

快速开始

1. 安装

方式一：Claude Code 原生命令（推荐）

在 Claude Code 中，首先注册市场：

/plugin marketplace add suriyel/longtaskforagent

然后从该市场安装插件：

/plugin install long-task@longtaskforagent

方式二：一键安装脚本

macOS / Linux：

curl -fsSL https://raw.githubusercontent.com/suriyel/longtaskforagent/main/claude-code/install.sh | bash

Windows（PowerShell）：

irm https://raw.githubusercontent.com/suriyel/longtaskforagent/main/claude-code/install.ps1 | iex

脚本会自动：

• Clone 仓库到 ~/.claude/plugins/marketplaces/longtaskforagent/
• 更新 known_marketplaces.json 注册信息

安装完成后，使用 Claude Code 安装插件：

/plugin install long-task@longtaskforagent

方式三：OpenCode 用户

如果您使用 OpenCode：

macOS / Linux：

curl -fsSL https://raw.githubusercontent.com/suriyel/longtaskforagent/main/install.sh | bash

Windows（PowerShell，需开发者模式或管理员权限）：

irm https://raw.githubusercontent.com/suriyel/longtaskforagent/main/install.ps1 | iex

安装完成后重启 OpenCode 即可激活。完整说明请参阅 OpenCode 安装指南。

2. 快速开始

启动 Claude Code 后，只需告诉它您想构建什么：

> 我想构建一个GitHub 热门项目周报系统。使用 long task skill。

系统将自动进入需求阶段，通过结构化提问帮助您完善需求，最终生成标准化的 SRS 文档。后续工作流程完全自动化：

需求 → UCD (如有UI) → 设计 → ATS (验收测试策略) → 初始化 → 工作循环 → 系统测试

点击查看样例项目

---

Long-Task Agent

一款 Claude Code 技能插件，将单会话 AI 编码转变为严谨的多会话软件工程工作流。

大多数 AI 编程助手在一次对话后会丢失上下文。Long-Task Agent 通过实现七阶段架构和持久状态桥接解决了这个问题——使 Claude Code 能够以专业工程团队的纪律，跨无限会话构建复杂项目。

为什么选择 Long-Task Agent？

问题	Long-Task Agent 如何解决
AI 在 /clear 后忘记所有内容	持久化产物（feature-list.json、task-progress.md、git 历史）自动桥接会话
AI 不理解需求就生成代码	符合 ISO/IEC/IEEE 29148 的需求收集在编写任何代码前产生经批准的 SRS
AI 跳过测试或编写浅层测试	严格的 TDD（红→绿→重构）配合覆盖率门禁（≥90% 行覆盖，≥80% 分支覆盖）和变异测试（≥80% 得分）
AI 产生不一致的 UI	带令牌化设计系统的 UCD 风格指南确保所有功能的视觉一致性
AI 验收测试覆盖不全	ATS（验收测试策略）在设计后前置规划每个需求的测试类别，独立 subagent 审核确保无覆盖盲区
AI 偏离批准的设计	设计接口覆盖门 + 每个功能后内联合规检查
无法安全地向现有项目添加功能	增量技能执行影响分析，就地更新 SRS/设计/UCD，用波次跟踪变更
"在我机器上能跑"综合症	系统测试阶段（IEEE 829）包含回归、集成、端到端和 NFR 验证

核心理念

1. 需求驱动，而非代码优先

每个项目都从结构化的需求收集开始——而不是编码。SRS 捕获做什么，UCD 捕获外观，设计文档捕获怎么做。三者全部批准后才会编写代码。

2. 持久状态桥接会话

十多个持久化产物确保会话间零知识丢失：

产物	用途
feature-list.json	带状态跟踪的结构化任务清单（JSON 防止模型损坏）
task-progress.md	逐会话日志，带当前状态标题
docs/plans/*-srs.md	已批准的软件需求规格说明书
docs/plans/*-design.md	已批准的技术设计文档
docs/plans/*-ats.md	已批准的验收测试策略（需求→场景映射，独立 subagent 审核）
docs/plans/*-ucd.md	已批准的 UCD 风格指南（UI 项目）
long-task-guide.md	工作会话指南，含环境激活 + 工具命令
docs/test-cases/feature-*.md	每功能的 ST 测试用例文档（ISO/IEC/IEEE 29119）
docs/plans/*-st-plan.md	带 RTM 的系统测试计划
docs/plans/*-st-report.md	带 Go/No-Go 结论的系统测试报告
RELEASE_NOTES.md	Keep a Changelog 格式的活态变更日志
Git 历史	带描述性提交的完整变更历史

3. 质量不可妥协

每个功能都要通过一系列自动化质量门禁——无例外，无捷径：

• TDD 红→绿→重构 — 先写测试，总是如此
• 覆盖率门禁 — 行覆盖 ≥90%，分支覆盖 ≥80%
• 变异门禁 — 变异得分 ≥80%（捕获那些通过但实际没测试任何东西的测试）
• 内联合规检查 — 每个功能后机械验证接口契约、测试清单、依赖版本和 UCD 令牌
• UCD 合规 — UI 功能要验证是否符合风格令牌

4. 每个周期一个功能

每个工作会话专注于恰好一个功能。这防止上下文耗尽，确保干净的提交，并使每个功能独立可验证。

七阶段架构

阶段 0a：需求收集

• 符合 ISO/IEC/IEEE 29148 的结构化提问
• EARS 需求模板（Given/When/Then 验收标准）
• 反模式检测：模糊词、复合需求、设计泄漏
• 产出一份已批准的 SRS（docs/plans/*-srs.md）

阶段 0b：UCD 风格指南

• 定义视觉方向、颜色令牌、排版、间距
• 为组件模型生成文本转图像提示词
• 非UI项目自动跳过
• 产出一份已批准的 UCD（docs/plans/*-ucd.md）

阶段 0c：设计

• 提出带有权衡分析的 2-3 种方案
• 每功能的 Mermaid 图（类图、序列图、流程图）
• 第三方依赖版本及兼容性验证
• 产出一份已批准的 设计文档（docs/plans/*-design.md）

阶段 0d：验收测试策略（ATS）

• 将每个 FR/NFR/IFR 映射到验收场景，标注必须的测试类别（FUNC、BNDRY、SEC、PERF、UI）
• NFR 测试方法矩阵（工具 + 阈值 + 负载参数）
• 跨功能集成场景预规划
• 风险驱动测试优先级排序
• 独立 ATS 审核 subagent（7 维度：覆盖完整性、类别多样性、场景充分性、可验证性、NFR 可测性、集成覆盖、风险一致性），支持自定义审核模板
• 小项目（≤5 FR）自动跳过，Tiny 项目嵌入设计文档
• 产出一份已批准的 ATS（docs/plans/*-ats.md）
• 约束下游 Init（verification_steps）和 feature-st（用例派生）

阶段 1：初始化

• 读取 SRS + 设计 + ATS，脚手架项目骨架
• 需求阶段双向粒度分析（G1-G6拆分 + S1-S4合并），确保每个FR适配单次会话上下文预算
• 生成环境引导脚本（init.sh / init.ps1）
• 创建初始 git 提交

阶段 2：工作循环

每个循环遵循严格纪律：

定位 → 引导 → 配置门禁 → 开发工具门禁 → 计划
  → TDD 红 → TDD 绿 → 覆盖率门禁
    → TDD 重构 → 变异门禁
      → 功能 ST（黑盒） → 内联合规检查
        → 持久化 → 下一个功能

阶段 3：系统测试

• 每功能 ST（ISO/IEC/IEEE 29119）—— 通过 Chrome DevTools MCP 进行黑盒验收测试
• 符合 IEEE 829 的系统级测试计划，带需求追溯矩阵
• 回归、集成、端到端、NFR 验证、探索性测试
• Go/No-Go 结论——缺陷循环回工作会话进行修复

阶段 1.5：增量（发布后变更）

• 放置 increment-request.json 信号文件 → 技能自动检测
• 对现有功能的影响分析
• 就地更新 SRS、设计、ATS、UCD（git 跟踪历史）
• 带波次元数据追加新功能以实现可追溯性

13 技能超能力架构

Long-Task Agent 使用按需技能加载模式——只有引导路由器在会话开始时加载；阶段技能按需加载，保持上下文精简。