Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/hahaxiang27/FlowHarnessWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/hahaxiang27/flowharness/harness.plan)<a href="https://agentmods.dev/commands/hahaxiang27/flowharness/harness.plan"><img src="https://agentmods.dev/badge/commands/hahaxiang27/flowharness/harness.plan.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00025 | $0.01719 |
| Opus 5 | $0.00013 | $0.00860 |
| Sonnet 5 | $0.00005 | $0.00344 |
| Haiku 4.5 | $0.00003 | $0.00172 |
Grade A, and why
harness-plan scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 111 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Harness Sprint 规划
上下文管理: 保持当前上下文（需要看到 tasks.md 全貌）
指令
读取以下文件：
specs/[FEATURE_ID]/tasks.md— 完整任务清单.harness/prompts/planner.md— Sprint 规划模板
按照 planner.md 中的规划规则，将 tasks.md 拆分为 Sprint。
输入参数（用户可选提供）
- Sprint 时长: $ARGUMENTS 或默认 1周
- 团队规模: 如用户未指定，默认 1人 + 自动化辅助
- 从哪个 Phase 开始: 如用户未指定，从 Phase 1 开始
执行步骤
Step 0 · Spec 颗粒度 pre-check（关联 Constitution 原则 XII · 阻断式）
在生成 sprint 计划前必须先验证 spec 颗粒度。任一阈值超出 → 立即阻断，提示用户走拆分流程，不进入后续步骤。
- 数 user story：从
specs/<feature>/spec.md中 grep^### User Story \d+行数，得到 US 数 N。 - 数 task：从
specs/<feature>/tasks.md中 grep^- \[[ x]\] T\d+行数，得到 task 数 M（tasks.md 缺失则跳过此项）。 - 判定：
- N > 3 → BLOCK · 输出："Spec 含 N 个 user story，超过原则 XII 阈值 3。请先拆分为 N 个独立 spec，再依次跑 specify → plan → tasks → harness.plan。"
- M > 30 → BLOCK · 输出："Tasks.md 含 M 个 task，超过原则 XII 阈值 30。这是 Sprint 49 类型的爆炸前兆，必须先拆 spec 再重新生成 tasks。"
- 两者都 ≤ 阈值 → 继续 Step 1。
- 3 选 1 处理建议（BLOCK 时一并输出）：
- 拆 spec（推荐）：列出当前 N 个 US 标题，建议按 US 边界切成 N 个 spec
- 合并 US：仅当几个 US 真正紧密耦合（独立交付不构成价值）
- 升级 justification：在 spec 末尾显式写明不可拆分的根本理由 + 增大 sprint 容量预估
- 不允许 bypass：除非用户在命令里加
--forceflag 显式承担风险（且必须在 sprint plan 里显式记录"已 bypass 原则 XII"）。
如需手工跑独立审计：/harness.spec-check <feature>。
Step 1+ · 生成 Sprint 计划（pre-check 通过后才执行）
- 读取 tasks.md，理解全部 Phase 和依赖关系
- 读取 planner.md，理解规划规则和工时估算基准
- 按规则生成 Sprint 计划，每个 Sprint 包含：
- 目标和对应 Phase
- 按 Day/Batch 组织的任务清单（含并行标记和预估工时）
- 验证检查点
- 风险项
- 将 Sprint 计划写入
.harness/sprints/sprint-{n}.md - 创建对应的进度文件
.harness/sprints/sprint-{n}-progress.md，格式要求：- 每个任务一行:
- [ ] T{ID} {描述} | L1:- L2:- | - 每个批次末尾必须插入门禁行:
- [ ] 🚧 **批次X.X门禁: L1 Step4 ({验证内容描述})** | 结果: - | - 门禁行的验证内容根据批次类型确定：
- 服务/核心批次:
启动+数据迁移验证或启动+接口端点验证 - 用户界面批次:
[TYPECHECK_COMMAND]或[UI_START_COMMAND]+页面可访问 - 集成批次:
[APP_START_COMMAND]+[UI_START_COMMAND]+真实接口调用链验证 - 涉真实外部服务或用户 UI 批次: 必须含 4f 子步骤（
[REAL_SERVICE_CHECK]至少 1 次成功 + UI 肉眼截图 ≥ 2 张 +[MOCK_INDICATOR]清洁）· 见.harness/prompts/evaluator.mdL1 Step 4f
- 服务/核心批次:
- 门禁行是 harness.exec 的强制检查点，不可被跳过
- 每个任务一行:
- 👁 人工验证节点 HV 强制识别（Sprint 47 血教训沉淀 · 2026-04-24）:
- 涉真实外部服务场景或用户可见 UI 的 feature · 必须识别至少 2 个人工验证节点 （典型：首个 US MVP 完成 + 批次 5 Polish 收官前）
- HV 节点对应批次门禁行格式扩展：
🚧 **批次N门禁: L1 Step4 + 👁 HV-M (~N min, 验证人)** - 规划规则详见
.harness/prompts/planner.md§ 人工验证节点 - 纯内部重构（零 UI / 零真实外部服务）可 0 个 HV · 但需在 Sprint 目标里显式说明
- 未识别 HV 节点直接规划 · Sprint 收官时 Checkpoint 自动对 Constitution VIII -2 · X -1
- 输出 Sprint 总览表 · 表中含
HV 节点数列
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 111 lines · 25 tokens per session scan A 5d10cf46693d
harness-plan is a command published in the GitHub repository hahaxiang27/FlowHarness (4 stars, last pushed 2mo ago), licensed MIT. It adds 25 tokens to every session and 1,719 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.