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 skills add ooooooooooooooooooop/agent-tools --skill systematic-optimizationgit clone --depth 1 https://github.com/ooooooooooooooooooop/agent-toolsWrote 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/ooooooooooooooooooop/agent-tools/systematic-optimization)<a href="https://agentmods.dev/skills/ooooooooooooooooooop/agent-tools/systematic-optimization"><img src="https://agentmods.dev/badge/skills/ooooooooooooooooooop/agent-tools/systematic-optimization/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ooooooooooooooooooop/agent-tools/systematic-optimization"><img src="https://agentmods.dev/badge/skills/ooooooooooooooooooop/agent-tools/systematic-optimization.svg" alt="Reviewed on agentmods" width="80" 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.00180 | $0.02857 |
| Opus 5.5 | $0.00072 | $0.01143 |
| Sonnet 5.5 | $0.00036 | $0.00571 |
| Haiku 4.5 | $0.00018 | $0.00286 |
Grade A, and why
systematic-optimization 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 1mo 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 — 165 lines — stays where its author put it; the contents beside it link to each section on GitHub.
系统化问题解决与优化流程（Systematic Problem-Solving & Optimization）
方法骨架与业界经典问题解决法同构（见文末对照表），本 skill 在经典流程上补充了两次实践沉淀的关键增量：量化先行（第 0 步）与约束分层（第 5 步）——后者回答"为什么改了还会复发"：方案若落在"靠人遵守"的约定层，就必然复发。
触发边界
- 用户说"优化 / 改进 / 复盘 / 为什么反复出问题 / 效率是不是低 / 成本是不是高 / 质量是不是差 / 总在重复犯同一个错"；
- 接手一个反复失败或长期停滞的任务/流程/系统；
- 审查发现同一类问题反复出现（反模式重演）。
流程（九步）
第 0 步：证据先行，量化基线
没有数字的"问题"是感觉。 先量化再下结论：
- 从日志、监控、账单、转录、数据中提取指标：频次、时长、成本、等待时间、失败率、资源消耗、重复次数；
- 用时间线重建事件流，找"长时间无产出/高消耗"的段；
- 建立优化前的基线数字（第 8 步同口径对比用）。
- 反例：不量化就下结论（"好像很慢""感觉浪费"）→ 无法证明改进，也无法定位根因。
第 1 步：发现所有问题（全量列举）
- 不修修补补，先把问题全部列出（悬挂、空转、重复、超支、返工、错误率……）；
- 每个问题标注证据（哪段日志/哪个数字/哪个事件）；
- 区分表象与真问题：表象是症状，真问题是"缺什么机制导致症状反复出现"。
第 2 步：寻找根因（分类定位）
根因分三类，处理方式不同：
| 根因类型 | 特征 | 对策 |
|---|---|---|
| 缺约束 | 根本没有对应的规则/流程/检查 | 补约束 |
| 有约束不执行 | 规则/流程存在但当事人没遵守 | 加执行点检查（checklist、门禁） |
| 无法强制执行 | 约束靠"记得遵守"，没有系统拦截 | 改系统/工具/平台层做强制约束（唯一真正根治） |
判定方法：对每个问题问"约束存在吗？存在但没执行吗？为什么没执行——是不知道、忘了、还是没法强制？"。第三类是复发问题的常见真根因：规则写在哪不重要，规则拦不拦得住才重要。
第 3 步：寻找解决方案（结构性优先，拒绝临时）
每提出一个方案先问：这是临时方案还是结构性方案？
- 临时方案：手动清理一次、这次注意点、下次记得、特例处理……（会复发）
- 结构性方案：自动回收、预算上限、参数必填、流程节点拦截……（系统无法绕过）
追求大局观：不从单个问题打补丁，而是看"这一类问题"缺什么结构性机制。临时方案只用于止血，必须伴随结构性方案，否则问题必然复发。
第 4 步：借鉴同类问题的已知解法
- 先定义问题域，再检索（关键词来自根因；来源：文献、业界方案、开源项目、其他领域类比、内部历史案例）；
- 只回收结构化结果（机制名 | 出处 | 实现方式 | 链接/引用），不堆砌原文；
- 对照表：机制 | 出处 | 实现 | 来源。
第 5 步：归纳成为最终方案（取舍）
- 借鉴方案对照本系统/本场景约束：哪些能移植、哪些不能、怎么改造；
- 最终方案必须包含：落点（改哪里）、行为变化（什么条件下触发什么）、可验证的验收点（可观测的字段/指标/行为）；
- 按成本/收益取舍，不做过度设计（防御过多本身也是问题）。
约束分层（本步必做，逐方案标注）——回答"这方案会不会复发"：
| 约束层 | 含义 | 可靠性 | 判定 |
|---|---|---|---|
| 系统层 | 平台/代码/工具层强制执行（参数门禁、自动回收、硬校验） | ✅ 无法绕过 | 真方案 |
| 流程层 | 流程节点检查、checklist、审批门 | ⚠️ 依赖执行者"记得查" | 半方案，需观察 |
| 约定层 | 文档、规范、培训里的"应当/禁止" | ❌ 经常不执行 | 弱约束，不算方案 |
约定层不执行是经验事实，不是假设（实证：禁令写入文档并被当事人看过，下一次照旧违反；"及时处理"规则存在数月，问题照样悬挂）。因此：
- 约定层条目必须显式标注"未强制，待观察"，不得自称"已解决"；
- 若该问题反复出现，就必须升级到系统层，不能停留在约定层；
- 半方案（流程层）要设观察期和升级触发条件：N 次复发即升级。
第 6 步：展示计划，确认实施（决策门）
方案在实施前必须过一次决策门。 把第 5 步归纳的最终方案以紧凑、可决策的形式呈现给用户/决策方：
- 要改什么：方案清单（每条含：落点、行为变化、约束层、成本/收益）；
- 不改什么：非目标（明确排除的相邻内容，防止实施时范围蔓延）；
- 风险：主要风险与回滚方式；
- 验收标准：第 7 步生效验证的可观察判据；
- 等待确认：明确请求确认（同意 / 调整 / 驳回）后才进入实施。
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 165 lines · 180 tokens per session scan A c09428d04042
systematic-optimization is a skill published in the GitHub repository ooooooooooooooooooop/agent-tools (3 stars, last pushed 1mo ago), licensed MIT. It adds 180 tokens to every session and 2,857 once invoked, about $0.0007 per session on Opus 5.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
analyze
Analyze a legacy app in any language before rewriting it in Elixir: inventory, features as goals, why each mechanism exists, runtime topology, external contracts. Use to start or refresh a rewrite.
session-deep-dive
Deep qualitative analysis of high-signal sessions. Spawns subagents with v2 template, synthesizes patterns, compares against known findings. Use after /session-scan.
brainstorm
Brainstorm Elixir/Phoenix features — explore ideas, compare approaches, gather requirements. Use when vague idea, not sure how to approach, or want to discuss before plan.
plugin-dev-workflow
Guide plugin development workflow — editing skills, agents, hooks, or eval framework in this repo. Use when modifying files in plugins/elixir-phoenix/, lab/eval/, or lab/autoresearch/. Ensures changes pass eval, lint, and tests before committing.
elixir-idioms
OTP/BEAM patterns and Elixir idioms — GenServer, Supervisor, Task, Registry, pattern matching, with chains, pipes. Use when designing processes or debugging BEAM issues.
tidewave-integration
Tidewave MCP runtime tools — debugging, smoke testing, live state inspection, SQL queries, hex docs. Use when evaluating code in a running Phoenix app.