How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

numen-error-cleanup - Prompt

Name: numen-error-cleanup
Author: THEjacob1000

Prompt file imported from THEjacob1000/dotfiles (.codex/prompts/numen-error-cleanup.md). Copyright stays with the author.

/error-cleanup

Systematically fix type errors, lint errors, and failing tests. Use when the user says "fix the type errors", "fix the lint errors", "tests are failing", "clean up the errors", "make the build green", or after your own edits introduced errors. Enforces root-cause fixes, never suppressions.

Error Cleanup

Goal: a genuinely green gate, not a silenced one.

1. Inventory first

Run the full gate to get the complete error list before fixing anything (use the repo's own scripts; prefer test:ci over test if it exists):

bun run typecheck (or tsc --noEmit), bun run lint, bun test / bun run test:ci, or the repo's Go/Rust/Flutter equivalents (go build ./... && go vet ./..., cargo check && cargo clippy, dart analyze && flutter test).

2. Group by root cause

Cluster errors by cause, not by file. One missing type export can produce 50 diagnostics. Fix causes in dependency order (shared packages → apps).

3. Forbidden "fixes"

Never, under any circumstances:

// @ts-ignore, // @ts-expect-error, biome-ignore/eslint-disable comments, or editing lint config to drop a rule
Casting through any / as any / as unknown as to silence the checker
Commenting out assertions, .skip-ing tests, deleting tests, or loosening expectations to make them pass
Widening a type to unknown/any when a precise type is derivable

If a rule/test seems genuinely wrong, fix the code anyway and flag the rule to the user separately.

4. Known gotchas (from this user's history)

TS2307: Cannot find module 'bun:test' or its corresponding type declarations → the tsconfig is missing bun types. Copy the setup from a working sibling app in the monorepo ("types": ["bun-types"] or a bun-env.d.ts reference). Don't hand-roll declarations.
Monorepo type errors often mean a dependent package needs rebuilding first, so check for a build/generate step in the failing package's dependencies.
Mock-related failures (X is not a function) usually mean the test's mock is missing a newly added method. Extend the mock, don't weaken the assertion.

5. Verify and report

Re-run the complete gate (typecheck + lint + tests) at the end, even if you only touched one category, fixes leak across categories. Report actual final numbers (0 type errors, 0 lint errors, N/N tests passing). If anything still fails, say so explicitly with the output.

Install numen-error-cleanup and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# /error-cleanup Systematically fix type errors, lint errors, and failing tests. Use when the user says "fix the type errors", "fix the lint errors", "tests are failing", "clean up the errors", "make the build green", or after your own edits introduced errors. Enforces root-cause fixes, never suppressions. # Error Cleanup Goal: a genuinely green gate, not a silenced one. ## 1. Inventory first Run the full gate to get the complete error list before fixing anything (use the repo's own scripts; prefer `test:ci` over `test` if it exists): - `bun run typecheck` (or `tsc --noEmit`), `bun run lint`, `bun test` / `bun run test:ci`, or the repo's Go/Rust/Flutter equivalents (`go build ./... && go vet ./...`, `cargo check && cargo clippy`, `dart analyze && flutter test`). ## 2. Group by root cause Cluster errors by cause, not by file. One missing type export can produce 50 diagnostics. Fix causes in dependency order (shared packages → apps). ## 3. Forbidden "fixes" Never, under any circumstances: - `// @ts-ignore`, `// @ts-expect-error`, `biome-ignore`/eslint-disable comments, or editing lint config to drop a rule - Casting through `any` / `as any` / `as unknown as` to silence the checker - Commenting out assertions, `.skip`-ing tests, deleting tests, or loosening expectations to make them pass - Widening a type to `unknown`/`any` when a precise type is derivable If a rule/test seems genuinely wrong, fix the code anyway and flag the rule to the user separately. ## 4. Known gotchas (from this user's history) - `TS2307: Cannot find module 'bun:test' or its corresponding type declarations` → the tsconfig is missing bun types. Copy the setup from a working sibling app in the monorepo (`"types": ["bun-types"]` or a `bun-env.d.ts` reference). Don't hand-roll declarations. - Monorepo type errors often mean a dependent package needs rebuilding first, so check for a `build`/`generate` step in the failing package's dependencies. - Mock-related failures (`X is not a function`) usually mean the test's mock is missing a newly added method. Extend the mock, don't weaken the assertion. ## 5. Verify and report Re-run the complete gate (typecheck + lint + tests) at the end, even if you only touched one category, fixes leak across categories. Report actual final numbers (0 type errors, 0 lint errors, N/N tests passing). If anything still fails, say so explicitly with the output.

{ "prompt": "# /error-cleanup\n\nSystematically fix type errors, lint errors, and failing tests. Use when the user says \"fix the type errors\", \"fix the lint errors\", \"tests are failing\", \"clean up the errors\", \"make the build green\", or after your own edits introduced errors. Enforces root-cause fixes, never suppressions.\n\n# Error Cleanup\n\nGoal: a genuinely green gate, not a silenced one.\n\n## 1. Inventory first\nRun the full gate to get the complete error list before fixing anything (use the repo's own scripts; prefer `test:ci` over `test` if it exists):\n- `bun run typecheck` (or `tsc --noEmit`), `bun run lint`, `bun test` / `bun run test:ci`, or the repo's Go/Rust/Flutter equivalents (`go build ./... && go vet ./...`, `cargo check && cargo clippy`, `dart analyze && flutter test`).\n\n## 2. Group by root cause\nCluster errors by cause, not by file. One missing type export can produce 50 diagnostics. Fix causes in dependency order (shared packages → apps).\n\n## 3. Forbidden \"fixes\"\nNever, under any circumstances:\n- `// @ts-ignore`, `// @ts-expect-error`, `biome-ignore`/eslint-disable comments, or editing lint config to drop a rule\n- Casting through `any` / `as any` / `as unknown as` to silence the checker\n- Commenting out assertions, `.skip`-ing tests, deleting tests, or loosening expectations to make them pass\n- Widening a type to `unknown`/`any` when a precise type is derivable\n\nIf a rule/test seems genuinely wrong, fix the code anyway and flag the rule to the user separately.\n\n## 4. Known gotchas (from this user's history)\n- `TS2307: Cannot find module 'bun:test' or its corresponding type declarations` → the tsconfig is missing bun types. Copy the setup from a working sibling app in the monorepo (`\"types\": [\"bun-types\"]` or a `bun-env.d.ts` reference). Don't hand-roll declarations.\n- Monorepo type errors often mean a dependent package needs rebuilding first, so check for a `build`/`generate` step in the failing package's dependencies.\n- Mock-related failures (`X is not a function`) usually mean the test's mock is missing a newly added method. Extend the mock, don't weaken the assertion.\n\n## 5. Verify and report\nRe-run the complete gate (typecheck + lint + tests) at the end, even if you only touched one category, fixes leak across categories. Report actual final numbers (0 type errors, 0 lint errors, N/N tests passing). If anything still fails, say so explicitly with the output.", "variables": [], "notes": "Systematically fix type errors, lint errors, and failing tests. Use when the user says \"fix the type errors\", \"fix the lint errors\", \"tests are failing\", \"clean up the errors\", \"make the build green\", or after your own edits introduced errors. Enforces root-cause fixes, never suppressions.", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/THEjacob1000/dotfiles", "path": ".codex/prompts/numen-error-cleanup.md", "ref": "8cb1feccf64642f418d3c1670e2f7119c201bdee", "url": "https://github.com/THEjacob1000/dotfiles/blob/8cb1feccf64642f418d3c1670e2f7119c201bdee/.codex/prompts/numen-error-cleanup.md", "key": "THEjacob1000/dotfiles/.codex/prompts/numen-error-cleanup.md" } } }

numen-error-cleanup

About

/error-cleanup

Error Cleanup

1. Inventory first

2. Group by root cause

3. Forbidden "fixes"

4. Known gotchas (from this user's history)

5. Verify and report

Install numen-error-cleanup and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews