For teams shipping code with agents
Your agent writes tests in plain TypeScript, reads structured failure JSON (not terminal output), patches the same file, and reruns — all in one loop. The same file runs locally, in CI, and in Cloud.
Open source TypeScript workflows, from the first local run to shared Cloud visibility.
Why Most Tests Die Young
Generation is the easy part now. The harder part is keeping the same test alive after the first failure, the first auth break, and the first system change.
They can generate a plausible draft, but once auth changes, data shifts, or a response shape moves, the loop falls back to human glue.
When failures come back as pasted logs, the agent has to guess. Repair quality drops, and iteration slows down immediately.
A first draft is easy. Keeping the same test useful across local runs, CI, and team ownership is the part most stacks do not solve.
The draft, the failure, the patch, and the promoted test all stay in one loop, so agent-written tests can keep working instead of being rewritten.
The Repair Loop
The point is not just that an agent can write a test. The point is that the same file can fail, come back with structured evidence, get repaired, and keep running without falling out of the loop.
Agent-written test to self-repairing workflow
One file goes from first draft to failure to repair to long-term verification.
The agent writes the first draft in plain TypeScript.
test("checkout-flow")
.step("login", async ({ http }) =>
http.post("/auth/login").json()
)
.step("create-cart", async ({ http }, { token }) =>
http.post("/cart", { json: { token } }).json()
)
.step("apply-promo", async ({ http }, { cartId }) =>
http.post("/cart/promo", {
json: { cartId, code: "AMBER10" }
})
)
.step("checkout", async ({ http, expect }) => {
const order = await http.post("/checkout");
expect(order).toHaveStatus(201);
expect(order.body.webhookDelivered).toBe(true);
});Real workflow shape
Multiple steps can share state, variables, and setup from the first draft.
Not a single endpoint check
Conditions, retries, and execution order live in code instead of being spread across tools.
The important shift
Generation stops being disposable because the workflow can keep evolving.
Why the loop works
Three concrete choices make the repair loop possible: tests are .ts files, failures are JSON events, and the same file goes from your laptop to CI to Cloud with no format change.
Tests are .ts files with real imports, real types, and real control flow. No DSL, no GUI state, no JSON collection files to diff. Your agent edits them the same way it edits your app code.
Every run emits a structured event stream — request, response, assertion, status, step — instead of a terminal dump. The agent reads the exact field that broke and patches against it, without copy-pasting stack traces.
The same explore/*.test.ts file runs with `glubean run` locally, `glubean run --ci` in CI, and uploads history to Cloud. No rewrite, no second format, no promotion step.
Get Started
Whether your API already exists or not, the install, runtime, and path to CI stay the same.
Recommended quick start
One install for both starting points.
npx skills add glubean/skillPoint your agent at the OpenAPI spec or the source files. It writes tests against real endpoints — with auth wired in, happy path plus 4xx boundaries, schema assertions. You review the diff, not the transcript.
Your agent declares the API boundary as executable contracts before the server exists, then builds the implementation against the same file. Reviewers read a generated surface map — nobody maintains a second spec.
What the agent reads
Example prompt
I need a checkout API. Write executable contracts and a readable projection before I build it.
Shared outcome
Same install
Shared outcome
Same runtime
Shared outcome
Same path to CI and Cloud
Migration
Already have collections, specs, or legacy tests? Start here instead.
Glubean treats migration as a staged workflow, not a blind format conversion. Start inside a real Glubean project, read the existing assets as evidence, lock one representative pattern, then batch-convert into plain TypeScript tests.
What to tell the agent
/glubean Migrate the existing pytest API tests in ~/path/codebase into Glubean workflows.
Start with one representative flow. Do not batch-convert until the pattern is approved.
The agent should treat the existing codebase as migration input, prove one slice first, then scale out.
01
Read the project and the source assets first. Classify what converts safely, what needs a decision, and what should not be guessed.
02
Collections and specs are weak sources of truth for runtime auth. Lock the real auth model before any batch conversion starts.
03
Migrate one real flow with auth, state, and assertions. Use it to lock grouping, configure(), and test style before scaling out.
04
Convert one folder or tag at a time, run the generated tests, fix the weak spots, and keep the same files as long-term workflows.
Product Surfaces
Use the same test workflow across extension, cloud, browser automation, and SDK or plugin layers.
Surface
Inline runs, traces, and debugging inside VS Code.
Surface
Hosted run history, alerts, and operational visibility.
Surface
The same workflow model, extended to browser verification.
Surface
Typed packages and plugin surfaces for custom verification flows.
What Glubean Is Not
Glubean is not another AI wrapper. It is a testing system for teams who need generated work to survive real execution.