菜单
Use when a spec or plan is about to depend on a dependency, library, API, CLI, or platform whose real behavior you have not personally observed — run a small real experiment before trusting docs or memory, and let the observed result outrank documentation when they disagree.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | environment-research |
| description | Use when a spec or plan is about to depend on a dependency, library, API, CLI, or platform whose real behavior you have not personally observed — run a small real experiment before trusting docs or memory, and let the observed result outrank documentation when they disagree. |
Documentation describes what a dependency is supposed to do; its source describes what it was written to do. Neither tells you what it actually does under your input, at its edges, or when it fails — you don't know until you run it. Before a spec or plan leans on a claim about a dependency's behavior, spend the ten minutes to turn that claim into an observation.
Skip it for dependencies you've already empirically characterized, or questions with no design consequence.
Red-flag thoughts that mean STOP and apply this skill:
A fluent, plausible-sounding claim about a dependency is exactly as dangerous whether it comes from a model, a stale doc, or your own memory of a similar tool — it's uncorrelated with whether it's true. Reading the source tells you intent, not behavior: a library can be written to validate input and still ship a code path where it doesn't. Only running the real thing, at its real version, against a real input, produces a fact instead of an inference. And the failure this catches is expensive precisely because it's silent until the design built on it hits the boundary in question — often in production, from a user, long after the "probably fine" assumption stopped being cheap to unwind.
Adapted from cmanaha/extended-superpowers (MIT), rewritten here as a general research discipline with no tie to any specific tool, hook, or bundled agent — any environment capable of running the real dependency and recording the result can fill this role. Two recurring shapes of the failure motivate it, genericized from real incidents: a published OpenAPI document typed a field as writable, but the live server silently rejected any write to it — the only way to know was one real PATCH call, not a closer read of the spec. Separately, an HTTP client framework silently stripped the Authorization header on redirect unless a specific flag was set — a behavior no amount of reading the framework's front-page docs surfaces, because it's disclosed three issues deep in an unrelated thread. Both would have shipped a wrong assumption into a design had the real call not been made first; in both cases, the fix was one line, but finding it required treating the documentation as a hypothesis rather than a fact.
What a machine can check: the residue, not the curiosity. A recorded observation everywhere a design claim leans on a dependency — a dated research entry in the spec (structure lint), the divergence written into the code the next caller reads, a decision-memory note pinning the exact version probed. The probe script is disposable by rule 7; what fails closed is a spec claiming dependency behavior with no observation behind it — the factual-grounding lens of adversarial-lens-review reviews exactly that.
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
