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 skills/jerrylalala/compound-engineering/workflows-plannpx skills add Jerrylalala/compound-engineering --skill workflows-plangit clone --depth 1 https://github.com/Jerrylalala/compound-engineeringWrote 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/skills/jerrylalala/compound-engineering/workflows-plan)<a href="https://agentmods.dev/skills/jerrylalala/compound-engineering/workflows-plan"><img src="https://agentmods.dev/badge/skills/jerrylalala/compound-engineering/workflows-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 | $0.00027 | $0.02011 |
| Opus 5 | $0.00014 | $0.01006 |
| Sonnet 5 | $0.00005 | $0.00402 |
| Haiku 4.5 | $0.00003 | $0.00201 |
Grade A, and why
workflows-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 4d 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 — 288 lines — stays where its author put it; the contents beside it link to each section on GitHub.
workflows-plan
用于把功能描述或 brainstorm 结果转成 Claude 可继续执行的 plan 文档。
这是 Codex 中的 plan 主入口。目标不是做一篇泛泛的分析报告，而是产出一份真正能交给 Claude /workflows:work 继续执行的计划。
铁律：输出必须优先满足 Claude /workflows:work 的消费协议，而不是追求漂亮或自由发挥的文风。
目标
写入：
docs/plans/YYYY-MM-DD-<type>-<descriptive-name>-plan.md
并确保格式兼容 Claude 的 /workflows:work。
输入
- 功能描述
- bug 描述
- 改进需求
- 或已有 brainstorm 的主题
执行步骤
- 先检查
docs/brainstorms/下是否有相关 brainstorm。 - 如果有相关 brainstorm：
- 读取并沿用其中的关键决策、约束、开放问题
- 如果没有：
- 通过简短对话补足目的、范围、约束、成功标准
- 进行本地研究：
- 现有模式
- 相关文件
- 项目约束
- 已有经验文档
- 基于风险、上下文清晰度和现有模式决定是否需要外部研究。
- 生成计划文档。
研究策略
优先做本地研究：
$repo-research-analyst$learnings-researcher
仅在这些情况下补做外部研究：
- 安全、支付、隐私、外部 API 等高风险主题
- 仓库里没有相似实现
- 技术选型明显不确定
外部研究优先调用：
$best-practices-researcher$framework-docs-researcher
必须保留的高价值能力
1. Brainstorm 继承
如果存在相关 brainstorm，不要只把它当参考。 必须显式继承：
- 关键决策
- 被否决方案
- 约束
- 开放问题
- 成功标准
必要时在计划正文中引用 brainstorm 路径。
2. 任务原子化
每个任务应尽量控制在 2-5 分钟级别。
禁止出现这种大任务：
- “实现整个认证系统”
- “完成前端重构”
- “修复所有 bug”
必须拆成原子任务。
3. 风险评估
写入计划前必须做风险评估，并生成：
risk_scorerisk_levelrisk_note
至少从这些维度考虑：
- 安全/隐私
- 可逆性
- 影响范围
- 变更规模
- 外部依赖
4. 可执行验证
每个任务都应包含可执行验证，而不是模糊表述。
例如：
- 运行某个测试命令
- 打开某个页面验证行为
- 查看某个文件输出
- 检查某个日志或状态
计划格式要求
1. 文件名必须固定模式
必须写到：
docs/plans/YYYY-MM-DD-<type>-<descriptive-name>-plan.md
要求：
type只能是feat、fix、refactor<descriptive-name>必须具体，不要用thing、feature、update这类空名字- 文件名必须可搜索
- 不允许省略日期前缀
2. frontmatter 必须固定输出
frontmatter 必须包含：
---
risk_score: 0
risk_level: low
risk_note: "主要风险描述"
plan_protocol: executable_checkboxes_v1
source_brainstorm: docs/brainstorms/... # 如果有
---
要求：
risk_score必须是 0-10 整数risk_level必须是low|medium|highrisk_note必须是单句风险摘要plan_protocol必须是executable_checkboxes_v1- 如果本计划基于 brainstorm，必须写
source_brainstorm
3. Header 必须固定输出
正文必须包含：
## Overview
**Goal**: ...
**Tech Stack**: ...
**Architecture**: ...
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.
- 4d ago First seen · 288 lines · 27 tokens per session scan A 80d80526f5d7
workflows-plan is a skill published in the GitHub repository Jerrylalala/compound-engineering (5 stars, last pushed 3mo ago), licensed MIT. It adds 27 tokens to every session and 2,011 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 skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…