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.

plentry - Skill - OpenSmartRoute

Name: plentry
Author: NoeBouchard

Imported from NoeBouchard/plentry (AGENTS.md). Install upstream with npx skills add NoeBouchard/plentry. Copyright stays with the author.

Plentry — agent instructions

You are working on Plentry, a concierge grocery + meal-planning app (HelloFresh alternative). Treat this like a SaaS product: do not ship untested behaviour, and keep the vault current.

This GitHub repo is the app (index.html + Supabase Edge Functions). In the Cursor workspace “Kitchen planner”, the same files live under plentry/.

Read first

doc/REQUIREMENTS.md — locked MVP
doc/INVARIANTS.md — test IDs
doc/FLOWS.md — checkout / Ops / Meals
doc/CURRENT-STATE.md — what is live
doc/AGENT-PLAYBOOK.md — how to change the app
doc/ENGINEERING.md — branch → PR → CI → merge (merge is not live)
Security work: doc/SECURITY.md
There is no React/Next app. Do not add a bundler.

If doc/ is missing, stop. Do not invent product facts from doc/archive/ or this README.md stub.

Harness (required before production)

npm test

On GitHub this is the repo root. In the Kitchen planner workspace: cd plentry && npm test.

Must exit 0 before any production ship: Vercel static, supabase functions deploy, or telling the founder it is live. See doc/TESTING.md. If a change breaks a test, fix the app or update the test in the same change — never delete assertions to go green. If tests fail, stop — do not deploy.

Branch and PR

Product changes go on feat/… or fix/…, then a pull request. Wait for GitHub Actions test. Do not push product work straight to main. Do not vercel deploy from a PR. Money / XSS / RLS / pay PRs: /review-bugbot and /review-security before merge. CI is the merge gate; local npm test is still the production gate. git push is never ship.

After staging changes (required)

Update the vault in the same work:

doc/CURRENT-STATE.md — what is true now
doc/CHANGELOG.md — append date, what, why
doc/ROADMAP.md if next steps changed
doc/SECURITY.md if you added or closed a risk
MVP contract files if they moved: REQUIREMENTS.md, INVARIANTS.md, FLOWS.md

In the Kitchen planner workspace, edit root doc/ then npm run vault so this doc/ stays identical.

Deploy (only if the user asks)

Since PR #12 (4699353a, 15 Oct 2026) a merge to main does not auto-deploy production. git.deploymentEnabled.main is false. Other branches still get preview deployments. Production static is a Vercel REST create with autoAssignCustomDomains: false, then a promote. See doc/RUNBOOK.md. git push is not production.

Always run tests first. Do not run a Vercel or functions deploy if npm test failed.

npm test
# static: REST create + promote in doc/RUNBOOK.md
# if functions changed:
supabase functions deploy pay ai newcoming

Never

Put secrets in index.html or the vault
Capture more than the Stripe hold
Add a second front-end framework
Skip npm test, or ship to production while tests are red
Push product changes straight to main, or treat merge as production

Install plentry 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.

{ "ocm": "1", "id": "noebouchard-plentry-plentry", "kind": "skill", "name": "plentry", "description": "You are working on **Plentry**, a concierge grocery + meal-planning app (HelloFresh alternative). Treat this like a SaaS product: do not ship untested behaviour, and keep the vault current.", "publisher": "NoeBouchard", "version": "1.0.0", "capabilities": { "domains": [ "coding", "math" ], "tags": [ "skill-md", "github-agents" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "You are working on **Plentry**, a concierge grocery + meal-planning app (HelloFresh alternative). Treat this like a SaaS product: do not ship untested behaviour, and keep the vault current." ], "primary": false, "metadata": { "source": { "provider": "github-agents", "repository": "https://github.com/NoeBouchard/plentry", "path": "AGENTS.md", "ref": "6833beb9de908c7b517ba77d43c09ac0d8f734c3", "url": "https://github.com/NoeBouchard/plentry/blob/6833beb9de908c7b517ba77d43c09ac0d8f734c3/AGENTS.md", "key": "NoeBouchard/plentry/AGENTS.md" } }, "instructions": "# Plentry — agent instructions\n\nYou are working on **Plentry**, a concierge grocery + meal-planning app (HelloFresh alternative). Treat this like a SaaS product: do not ship untested behaviour, and keep the vault current.\n\nThis GitHub repo **is** the app (`index.html` + Supabase Edge Functions). In the Cursor workspace “Kitchen planner”, the same files live under `plentry/`.\n\n## Read first\n\n1. [`doc/REQUIREMENTS.md`](doc/REQUIREMENTS.md) — locked MVP \n2. [`doc/INVARIANTS.md`](doc/INVARIANTS.md) — test IDs \n3. [`doc/FLOWS.md`](doc/FLOWS.md) — checkout / Ops / Meals \n4. [`doc/CURRENT-STATE.md", "cost": { "context_tokens": 804 } }

plentry

About

Plentry — agent instructions

Read first

Harness (required before production)

Branch and PR

After staging changes (required)

Deploy (only if the user asks)

Never

Install plentry 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