autor3search-typescript

autoresearch for your codebase — the same loop in eight languages, with every agent prompt in one place.

Let an AI coding agent loose on your repository's performance, without letting it grade its own homework. autor3search-typescript freezes your tests and benchmarks, measures every change the agent proposes against a baseline it cannot touch, and only keeps a commit that is a real, statistically significant, material win.

Licensed under the MIT License. Copyright (c) 2026 Gal Be.

Start here

Open your coding agent inside the TypeScript repository you want to make faster, and paste this:

Install and run autor3search-typescript on this repository, then optimize it.

Setup:
0. Run git status. If the working tree has changes, STOP and ask me to
   commit or stash them first.
1. npm install --save-dev @autor3search/typescript@^0.3.0
2. npx autor3search-typescript init
   Show me the benchmarks it discovered. If it reports none, STOP and tell me:
   this tool can only optimize what it can measure.
3. git add -A && git commit -m "autor3search-typescript init"
4. npx autor3search-typescript doctor
   Show me any warnings. If the machine looks unfit to measure, stop and ask me
   before continuing.
5. npx autor3search-typescript baseline -tag <today, e.g. sep7>
   This runs your install command once per worktree, so dependency install
   time and node_modules disk use both double. That is expected.

Then:
6. Read program.md in this repository, in full. It is your instruction set for
   the rest of this run. Follow it exactly.

Rules for the whole run:
- One hypothesis per commit. Commit before each experiment, then run
  `npx autor3search-typescript eval --json` and apply its verdict before touching
  anything else: KEEP means the commit stays; anything else (DISCARD, FAIL, CRASH)
  means `git reset --hard HEAD~1`.
- Never edit program.md, .autor3search/config.yaml, results.tsv, any
  *.test.*/*.spec.*/*.bench.* file, package.json, a lockfile, or tsconfig.json.
  They are not yours.
- Never pass -force to any autor3search-typescript command. (I may run
  `autor3search-typescript stop -force` myself; that one is mine, not yours.)
- Print one context line before each experiment, so I can see where you are:
  [exp <n> | <branch> | vs <measure_commit> | stop: npx autor3search-typescript stop]

Run the loop until I stop you. I stop you by running
`npx autor3search-typescript stop` in my own terminal — you will see it as
"stop_requested": true in a verdict. When you do: apply that verdict, do not
start another experiment, run `npx autor3search-typescript report`, summarize
what you tried, and exit the loop.

That's the whole handoff. The agent installs the tool, discovers your benchmarks, freezes a baseline, and then follows program.md — generated for your repository by init — which tells it how to run the keep-or-discard loop. program.md names the benchmarks in scope, spells out the KEEP/DISCARD/FAIL/CRASH contract, lists everything the agent must never touch, and ends with a bank of generic V8/TypeScript performance ideas for when the agent is out of hypotheses.

Two things worth knowing before you start it:

• It needs benchmarks. init refuses to run without a discovered bench* function in a *.bench.ts file — the tool optimizes what it can measure, and refuses to guess.
• Numbers are only as good as the machine. Run doctor and read it. See Limitations below for how much run-to-run noise a JS runtime can add even on an idle machine.

Or install it as a skill

The same prompt ships as an agent skill, in skills/autor3search-typescript. Install it once and ask your agent to make the repository faster; it loads the prompt itself.

mkdir -p ~/.claude/skills/autor3search-typescript
curl -fsSL https://raw.githubusercontent.com/autor3search/typescript/main/skills/autor3search-typescript/SKILL.md \
  -o ~/.claude/skills/autor3search-typescript/SKILL.md

The idea

You do not edit TypeScript to tune performance. You edit program.md — the instructions that drive your agent. The agent edits the TypeScript. The harness holds the metric, and the agent cannot reach it.

Who owns what

	you edit	the agent edits
program.md	yes, before handing it over — never after	never (enforced: editing it is a scope violation)
.autor3search/config.yaml	yes	never (enforced: a config hash mismatch FAILs the experiment)
source files under scope	rarely	yes — this is the whole point
*.test.ts, *.spec.ts, *.bench.ts	yes	never (enforced: frozen content is restored before every measurement)
package.json, lockfiles, tsconfig.json	yes	never (enforced: immutable regardless of scope)
results.tsv	never, ordinarily	not prevented, but pointless — it is gitignored and untracked, so no gate ever sees it as "changed," and it is never read back to decide a verdict; editing it corrupts a human-readable log, nothing more
baselines, locks, stop requests	never — this is what the agent cannot reach	never

The measurement state — baselines, locks, stop requests — lives outside the repository entirely (see "Where run state lives" below). If the agent could write any of it, it could grade its own work.

What you get back

An unattended loop that, commit by commit:

以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗