菜单
Before building anything non-trivial, research real-world failure modes from production post-mortems and issue trackers and produce a committed symptom→cause→fix→URL map, instead of donating your own debugging time or asking the model to hallucinate what could break.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ariaxhan/the-agent-library --skill research-failures-first命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Turn a borrowed metaphor, analogy, or cross-domain inspiration into a testable mechanism, or prove it is decoration and discard it. Use when a design leans on language from another field ("immune system", "evolution", "market", "quorum", "crystallization"), when someone proposes copying how another domain solves a problem, or when reviewing a system whose names sound deeper than its code. Produces either a named domain-free invariant with evidence and falsifiers, or an explicit rejection with the reason it failed.
Design systems so a failure can never present as success. Use when building or reviewing pipelines, extractors, reconciliations, checkers, or any computation whose output humans act on; when missing inputs, unreadable files, or crashes could pass silently; when a tool "found" an explanation that feels too convenient; or on "make this fail loudly", "could this lie to us", "harden the failure paths". Produces named invariants, explicit skip and no-answer states, honest cause classes, and adversarial regression fixtures.
A compact decision protocol for non-trivial choices, reviews, governance calls, and live disagreement. Use implicitly at decision points, even when nobody says "debate", whenever a choice is high-impact, hard to reverse, policy-bearing, or has multiple plausible paths that evidence alone cannot settle. Skip for trivial, cheap-to-reverse, or deterministically decidable choices.
正在显示 SKILL.md
基于 SOC 职业分类
| name | research-failures-first |
| description | Before building anything non-trivial, research real-world failure modes from production post-mortems and issue trackers and produce a committed symptom→cause→fix→URL map, instead of donating your own debugging time or asking the model to hallucinate what could break. |
A protocol that inverts the default workflow. Instead of searching for the happy path ("how to use X") and discovering its sharp edges by stepping on them, you hunt for other people's already-debugged pain first and turn it into a committed reference: a symptom → root-cause → fix → source-URL table for the specific thing you're about to build. Most non-trivial implementation pain is somebody else's solved problem. Finding their bruises before donating your own runs about 5× return on the time spent looking.
The default happy-path search optimizes for "make it work once" and hides every failure at the boundaries: empty input, the second concurrent writer, the migration that runs twice, the auth token that expires mid-request. Those are exactly what people who hit production already documented. You want their post-mortems, not a tutorial.
Mandatory before writing code for:
NOT required for: typo and copy fixes, comment changes, single-file bug fixes inside familiar code, or test additions to an existing suite.
Empirically ranked by unique-find rate: how often a channel surfaces a failure no other channel did (from a controlled run of parallel research agents, each locked to one channel on identical topics):
| Channel | What it is | Unique-find rate | Run? |
|---|---|---|---|
| Production case studies: engineering-blog post-mortems, incident write-ups | 78% | always | |
| Issue tracker: the project's OWN GitHub/GitLab issues, open + closed | 47% | always | |
| Forums: Reddit, Hacker News, Stack Overflow | 29% | optional supplement, if the issue tracker returns < ~20 entries | |
| Generic web search: "X gotchas", "X common mistakes" | 15% | never, drop it |
Rule: always run the top two in parallel. The generic "gotchas" search mostly re-derives the issue tracker at lower quality. It's a waste of a slot. Use forums only to top up a thin result set.
One persistent, committed file at research/<topic>.md in your durable notes store.
Subsequent work cites specific row numbers from it. The full fill-in-the-blank format
(frontmatter, TL;DR, failure-mode table, pre-flight checklist) is in
reference/failure-map-template.md.
Minimum ~10 unique entries. Below 10 usually means the channels weren't queried hard enough. Expand the search or add the forums channel before declaring the map done.
Never ask the model what could go wrong. Foundation models confidently invent failure modes that don't exist for your specific version, and omit the real ones. Every row needs a resolving source URL: a real post-mortem, issue, or thread you can open. No URL, no row. The map is only as trustworthy as its weakest citation.
When you have sub-agents, run it as a sprint and keep raw research out of the orchestrator's context:
research/<topic>-channel-<name>.md.research/<topic>.md. Dedupe overlapping rows,
citing both source URLs in the merged entry.