wrapper-test is a zero-dependency Node.js CLI that statically scores an AI product repository against The Wrapper Test.
The methodology source is the Corteus post: The Wrapper Test: will this AI product survive the next model release?
AI products can look strong while depending on one provider call, one prompt, and one release calendar. This tool gives builders, buyers, and investors a quick static scan for the signals that usually separate a thin model wrapper from software with data, workflow, eval, and switching-cost depth.
It is not a diligence replacement. It is a fast first pass that turns a repo into specific questions and evidence.
Run against a local repository:
npx wrapper-test <path-to-repo>Run from a checkout of this repo:
node bin/wrapper-test.js <path-to-repo>Print JSON:
npx wrapper-test --json <path-to-repo>The tool makes no network calls. It reads local text/source files only, skips common generated directories, and skips dotenv- and credential-like file names at the filesystem walk layer.
The CLI returns one of three verdicts for repositories with AI product signals:
Thin wrapperWrapper with moats formingDefensible product
If no AI product signals are found in source/config files, it returns No AI product verdict instead of forcing a misleading score.
Each question receives a 0-10 score, evidence with file paths and counts, and a one-line explanation.
| # | Wrapper Test question | Static signals measured |
|---|---|---|
| 1 | what remains if the model ships this feature? | Combined durability: data pipelines, workflow integrations, evals, actions, switching-cost signals, prompt-to-code ratio, provider lock-in. |
| 2 | what proprietary data improves through use? | ETL/ingestion, customer/outcome fields, feedback/correction loops, fine-tuning artifacts, retrieval/vector stores, schemas and migrations. |
| 3 | where does it sit in the buyer's daily work? | Third-party workflow integrations, queues, webhooks/jobs, roles and permissions. |
| 4 | what eval proves the product is better than the raw model? | Eval/benchmark files, golden datasets, raw-model baseline comparisons, metrics, eval frameworks, test files. |
| 5 | can the team swap models without rebuilding? | Provider SDK imports, hardcoded model strings, old model names, abstraction layers, provider-agnostic config, fallback/retry logic. |
| 6 | what actions happen outside the chat box? | Governed actions, write-backs/mutations, webhooks/jobs/queues, audit logs, permission checks. |
| 7 | what would make leaving painful for a customer? | Customer-specific config, rules/templates/playbooks, history/reporting, audit history, export/archive paths. |
| 8 | what specific pain makes the buyer pay? | Buyer roles, ROI metrics, domain-specific pain language, budget/billing signals. |
Static analysis cannot prove product quality, customer pain, or whether an eval is trustworthy. It can miss signals hidden behind naming that the heuristics do not recognize, and it can over-credit repos that contain convincing vocabulary without working behavior.
Scores should be treated as prompts for review, not as investment or purchasing advice. For serious diligence, inspect the eval suite, run the product against raw-model baselines, review data rights, and interview users who live in the workflow.
npm testThe test suite uses fixture repositories under tests/fixtures.