Research and strategy
Technical proof and benchmarks
Substantiate technical claims with an appropriate test, reproducible evidence and honest limitations.
Open-source skill · format validated
When this is useful
Plan, assess, or write technical proof for developer and data products: reproducible benchmarks, architecture demonstrations, customer evidence, and defensible performance claims. Use when substantiating a claim or designing its test; not for inventing results or generic copywriting.
What to bring
Claim to substantiate, audience and decision, available code or data, baseline, environment, source permissions, and execution limits.
What you can work toward
A claim ledger, evidence protocol or results, reproduction instructions, publishable claim language, limitations, and unresolved proof gaps.
Developer-tool version
Define the actual task and baseline before making productivity or speed claims. A faster local demonstration does not prove team productivity. Record versions, equivalent setup, correctness, failures, repeated runs, and reproducibility.
Data-product version
Prove equivalent output and semantics before comparing workload speed or cost. Record dataset shape and skew, updates, cache state, concurrency, freshness, failures, resources, repeated runs, and uncertainty. Include unfavorable conditions and limitations.
How to use it
Choose the version for your product type and follow its repository installation instructions. Keep the skill folder, references and any assets together. Each skill works on its own; reuse a shared brief when helpful rather than repeating a full intake.
The source follows the open Agent Skills format and is MIT licensed. Live research and execution depend on the tools and permissions available in your host. Preparing a plan or draft does not itself authorize publishing, messaging, spending or production changes.
A starting prompt
Use the technical proof and benchmarks skill for our developer tool or data product. Our task is [specific task], our supported environment is [environment], and the decision is [decision]. Use these facts and sources: [evidence]. Produce the requested artifact, label unknowns, and do not invent results or perform external actions beyond my authorization.
How to judge the result
Do not cherry-pick runs, hide failures, manufacture customer results, or label illustrative charts as measured data. A vendor benchmark is evidence with a scope, not independent validation.
Check that the product-specific version changes the recommendation, the requested deliverable is complete, and proposed tests are distinguished from observed results. Format validation does not establish how a model will perform on your product.
From input to reviewed output
Put it to work
- Choose the collection for your product type and install the relevant skill with its bundled references and assets.
- Supply the task, supported behavior, existing evidence and constraints that affect the decision. Reuse context already available.
- Ask for the concrete deliverable, distinguishing facts, hypotheses, unknowns and any untested instructions.
- Check the product-specific acceptance criteria, source claims and next steps before using or publishing the output.
Limits and tradeoffs
Do not cherry-pick runs, hide failures, manufacture customer results, or label illustrative charts as measured data. A vendor benchmark is evidence with a scope, not independent validation. No fresh-host model performance is claimed; verify output against your product, evidence and authorized environment.