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/getappz/agentflare/systematic-debuggingnpx skills add getappz/agentflare --skill systematic-debugginggit clone --depth 1 https://github.com/getappz/agentflareWhat 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.00070 | $0.01135 |
| Opus 5 | $0.00035 | $0.00567 |
| Sonnet 5 | $0.00014 | $0.00227 |
| Haiku 4.5 | $0.00007 | $0.00113 |
Grade A, and why
systematic-debugging 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 2d 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 — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Systematic Debugging
The Iron Law
NO FIX WITHOUT ROOT-CAUSE INVESTIGATION FIRST
A fix proposed before Phase 1 is complete is a guess, not a fix. Guesses that happen to work are indistinguishable from guesses that don't until the bug resurfaces somewhere else.
When to use
Any technical issue: a failing test, a production bug, unexpected output, a performance regression, a build failure, an integration that doesn't behave as documented.
Especially when under time pressure, when "just one quick change" seems obvious, or when a previous fix attempt didn't work — those are exactly the conditions where guessing feels fastest and costs the most.
Don't skip because the bug looks simple. Simple bugs have root causes too, and finding one usually takes minutes, not hours.
Phase 1: Root-cause investigation
Before touching any code:
- Read the actual error. Full stack trace, not the first line. Note exact file paths, line numbers, and error codes — they often name the fix directly.
- Reproduce it. Confirm exact, repeatable steps. If it won't reproduce reliably, that's information — gather more data (logging, a tighter repro case) rather than guessing at a fix for a moving target.
- Check recent changes.
git log/git diffon the affected paths, recent dependency bumps, config or environment drift. Most bugs are introduced by something that changed, not something that was always broken. - Trace the data flow backward. Find where the bad value or bad state actually originates, not just where it's first observed. Follow it through each call/component boundary until you reach the source, and fix there — not at the symptom.
Phase 2: Pattern analysis
If a working example exists (a similar endpoint, a sibling test, a reference implementation), read it completely before comparing — skimming guarantees you miss the difference that matters:
- Locate the closest working analog in the same codebase.
- Read it in full, not just the parts that look relevant.
- List every difference from the broken code, however small. Don't discard one because "that can't matter" — verify it doesn't.
- Note what the working version depends on (config, environment, call order) that the broken version might be missing.
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.
- 2d ago First seen · 110 lines · 70 tokens per session scan A 3ee1632cf55a
systematic-debugging is a skill published in the GitHub repository getappz/agentflare (2 stars, last pushed 2d ago), licensed Apache-2.0. It adds 70 tokens to every session and 1,135 once invoked, about $0.0003 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
task-loop
任务目标驱动执行闭环预装 skill,整合任务识别/规划/派发搜推/验收/BBS 接力/arch 场景规划变体(planning-arch)与架构师名册 mock(arch-analysis)共七段为单一 skill,预装到所有 bot 等同各段单独安装到对应 bot;各段按各自触发词自门控仅命中段执行(用户面 /task 或 [RESUMETASK] 或副屏标签命中识别;框架 [planning] 命中规划,arch 场景含「某某某公司」命中 planning-arch 变体;框架 [search] 命中派发搜推;worker 叶子自验收命中验收;引擎 BBS 通知命中接力,其 scoped 叶子 instruction…
bcs-coordination
全场景多智能体协同和交互引擎。覆盖多Bot复杂任务协同与沉浸式娱乐互动。通过提供注册发现、群组构建、上下文融合及路由通信能力等核心能力，支持能力互补、信息和知识的融合、冲突消解、工作流编排，以及2C场景下多人游戏互动等。.
bbs-relay-pickup
被唤醒时从 task API 发现 BBS 升级任务、CAS 占根、自判剩余、挂节点、执行、经回投写回.
bcs-coordination
全场景多智能体协作和交互引擎。覆盖 Bot 注册发现、自由聊天、任务协作、上下文融合、路由通信和自定义协作。用户需要自定义参与角色、执行步骤、串并行关系或最终交付物时，使用自定义协作能力，并通过 BCS 的 statemachine YAML 实现和校验。.
task-planning-arch
计算任务 gap 并产出下一步可执行子任务 List[TaskSpec];gap 已闭返回空数组。对齐 arch 场景(架构师名册/技术栈概览/双视角分析)确定式分解——按根目标交付物集合 + donechildren 查表(参照 task-planning storage 特例,非自由 LLM 分解)。.
task-search
在框架预查的候选 bot 集里决出执行者(who)与协作方式(how),返回 4 态 SearchResult(HITSINGLE/HITGROUP/HITMULTIBOTS/MISS)。对齐案例剧本确定式映射。.