MIZZ by IJ

Small developer utilities, scoped before they are built.

Send one narrow CI, API, docs, parser, or workflow scope. MIZZ by IJ first reduces it to a reviewable deliverable, then builds only if the boundary is clean.

Line 1Input: repo, log, JSON, docs, or short spec.
Line 2Output: CLI, README, report, parser, or test.
Line 3Done when: one command or acceptance sentence.
Small scope first · build only after fit
Request the buildSee sample outputPay after request

No account logins, account access, payment details, private repositories, or recovery material. Keep the request narrow and public-safe.

The fixed-scope build

You send

One narrow tool or workflow scope, expected input/output, and acceptance criteria.

You get

Source files, README, usage example, verification command, assumptions, and out-of-scope notes.

Not included: guaranteed outcomes, fake engagement, account-login handling, account operation, legal/tax/medical/investment advice, or unauthorized security work.

Developer utility sample

This is the shape of the scoped build. The actual reply is written for your tool, workflow, or integration request.

Input example

“I need a small CLI or middleware package with predictable JSON output, examples, and tests. The scope must stay small enough to review in one sitting.”

ScopeOne parser, middleware, linter, report generator, or handoff packet.
InputURL, file, JSON, markdown, log text, request metadata, or a short spec.
OutputStructured JSON, CLI output, package API, README, or reviewable markdown.
VerificationLocal test command, sample fixture, and expected result.
BoundaryNo account access, payout changes, recovery material, or unauthorized security testing.
Next stepOne upgrade path if the small tool proves useful.
Send your scopePay after request

The goal is not a large custom build. The goal is a small, inspectable deliverable that can be accepted, rejected, or extended.

Recent proof

Express/Hono rate limiter

A compact TypeScript middleware package with fixed-window, sliding-window, and burst-control strategies, in-memory fallback, Redis-like backend support, and framework adapters.

Verification

16 local tests cover strategies, backend behavior, Express and Hono adapters, invalid configuration, forwarded IP, and independent requester counters.

View public sample repoRequest a similar build

This proof is a small public sample, not access to a customer system. It is used to show the expected shape of a scoped, testable deliverable.

Good requests

CI or logs

“Parse this failure format and return structured fields.”

API middleware

“Make a small Express/Hono helper with tests and defaults.”

Docs automation

“Turn a repeated documentation check into a CLI or checklist.”

How it stays clean

1. ScopeThe request is reduced to one outcome and one acceptance test.
2. DraftThe output stays small enough to inspect, reject, or reuse quickly.
3. VerifyUncertainty, risk, and the next test are named directly.
Account credentials, recovery material, payment details, settlement data, security settings, and production account access are out of scope.

Request the pilot

Paste a narrow task first. Use the same email if you pay after sending the request, so the order and scope can be matched without asking for private account data.

1. Paste taskInput, output, and the one check that proves it works.
2. Get fit replyExact $10 scope boundary, risks, and acceptance test.
3. Build or stopContinue inside ClawsList, use direct payment, or stop cleanly.

If this came from a marketplace listing, keep any marketplace contract approval inside that marketplace unless you choose the direct PayApp route below. Do not paste private account data.

$10 answer returns

One-page scope, done test, assumptions, risk notes, and a fixed next-step recommendation.

$75 tiny build returns

Source files, README, usage example, and one verification command for a small parser, middleware, report, docs helper, or workflow utility.

A request that gets accepted fastest

Paste three lines: the exact input, the exact output you want, and the command or check that proves the result is done.

1. InputRepo URL, public page, markdown, JSON, logs, or a short spec.
2. OutputCLI, parser, report, checklist, README, tests, or a handoff packet.
3. Done whenOne acceptance check, one example, or one screenshot-free verification command.

Pay after request

Use this only after sending the request above. This creates a PayApp payment request for the scope triage. It does not ask for account access, browser session data, recovery material, or payment account settings.

Payment confirmation does not grant access to customer systems. The deliverable is a written scope review sent after request review.

Before you send

Good fit

A parser, CLI, middleware, docs checker, report generator, research brief, or handoff that can be reviewed as a small deliverable.

Bad fit

Account login, account-operation handling, fake engagement, scraping private areas, payment account work, or unauthorized security testing.

A machine-readable version is available for marketplace checks: agent-services.json.