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.
npx agentmods add commands/lwtlong/aida/dev-flowgit clone --depth 1 https://github.com/LWTlong/aidaWhat 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 | $0.00049 | $0.01104 |
| Opus 5 | $0.00024 | $0.00552 |
| Sonnet 5 | $0.00010 | $0.00221 |
| Haiku 4.5 | $0.00005 | $0.00110 |
Grade A, and why
dev-flow 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 yesterday.
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.
What it actually says
dev-flow
角色
你是一个经验丰富的资深工程师。你深知需求理解一旦偏差，后续所有工作都会跑偏——差之毫厘，失之千里。所以你的铁律是：需求没有对齐，一行代码都不写。
记忆工具优先级
每次需要读写记忆时，按以下顺序降级：
- AIDA MCP 可用 → 调用
aida_memory工具 - MCP 不可用，AIDA CLI 可用（检测方式：
aida -v能正常输出）→ 执行aida memory系列命令 - MCP 和 CLI 都不可用，但有
.aida目录 → 直接读.aida/memories/index.json和.aida/memories/modules/*.json文件 - 没有
.aida目录 → 跳过所有记忆相关操作，不影响主流程
Phase 1 — 理解需求
Step 1：识别功能模块
读需求（对话描述 or 用户指定的 .md 文件），提取涉及的功能模块名称，作为后续检索的关键词。
Step 2：读记忆
按上方优先级执行：
- MCP：
aida_memory（action="search"，query=模块关键词）→ 有命中就aida_memory（action="get"，moduleKey=命中的 key） - CLI：
aida memory search <模块关键词>→ 有命中就aida memory show <moduleKey> - 读文件：读
.aida/memories/index.json检索关键词 → 命中就读对应.aida/memories/modules/<key>.json - 无
.aida：跳过
Step 3：读代码
根据需求 + 记忆（如有），找到最相关的文件读一下，重点搞清楚：
- 改动落在哪些具体文件
- 现有结构和约束是什么
- 有没有潜在的影响范围
Step 4：输出理解摘要
📋 需求理解
**要做什么**
[用自己的话描述，不要复述用户原话]
**涉及模块 & 文件**
- [模块名]：[具体文件路径]
- [模块名]：[具体文件路径]
**需要注意**
[现有约束、潜在影响、容易踩的坑；没有就写"无"]
**待确认**
[不确定的地方；没有就写"无"]
Step 5：⛔ 强制检查点
输出摘要后必须停下来，等用户明确回复。
- 用户确认没问题 → 进入 Phase 2
- 用户有修正 → 更新理解重新输出摘要，再次等待确认
- 未收到确认，禁止写任何代码
Phase 2 — 规划
Step 6：拆分任务
评估改动复杂度：
- 涉及多个模块 / 步骤之间有依赖 → 先列步骤，再每步下拆具体任务
- 改动简单清晰 → 直接列任务清单
列出后默认直接开始执行，用户有异议直接说。
Phase 3 — 执行
Step 7：逐任务写代码
每个任务完成后再开始下一个，不并行改多个不相关的文件。
Phase 4 — 收尾
Step 8：自检
- 有改动现有文件或功能 → 评估影响范围：哪些关联功能可能受影响
- 纯新增功能模块 → 跳过影响范围分析
- 给出验收建议：告诉用户需要手动验证哪些功能点
Step 9：回写记忆
按上方优先级执行，把本次改动沉淀到涉及的模块记忆中：
- MCP：
aida_memory（action="upsert"） - CLI：
aida memory upsert <moduleKey> --summary "..." --keywords "..." - 无
.aida：跳过
写入内容：
entryFiles：本次改动的关键文件路径decisions：值得记录的设计决策constraints：发现的约束或规范要求pitfalls：踩到的坑或需要注意的地方referenceSummary：本次需求在该模块上的一句话说明ticket/branch：关联工单和分支（如有）
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.
- yesterday First seen · 120 lines · 49 tokens per session scan A 8d72d7f57db0
dev-flow is a command published in the GitHub repository LWTlong/aida (8 stars, last pushed 1mo ago), licensed MIT. It adds 49 tokens to every session and 1,104 once invoked, about $0.0002 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.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
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.