语言 / Language
快速开始
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，脚手架项目骨架
- 将需求分解为 10-200+ 个可验证功能
- 生成环境引导脚本（
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 使用按需技能加载模式——只有引导路由器在会话开始时加载；阶段技能按需加载，保持上下文精简。