suss

Why I built it

Code is written faster than anyone can read it. A thousand-line pull request lands several times a day now, and a reviewer cannot keep all of it in their head. Reading the diff tells you what the text changed, not what the service now does, and the tests written alongside the change check what its author meant.

Here is the kind of change that gets through. A handler starts returning 200 with status: "deleted" where it used to return 410. Both versions compile, the types still line up, and every caller that treats a 200 as a usable account is now wrong. No type checker or test suite sees both sides of that boundary at once.

What it does

suss reads the code and writes down what it does on every path, so a reviewer, a CI pipeline, or a coding agent can read that instead of the source. inspect prints each handler, consumer, and query with the conditions on every branch and the status and body fields it produces:

GET /users/{id}  (hono handler | line 5)
   if  !findUser()
     -> 404 { error }
   elif  findUser().deletedAt
     -> 410 { error }
   else
     -> 200 { id, name, email }

inspect --diff runs on the base and the head of a pull request and reports what the change did to each unit, whichever lines the diff touched. check pairs every handler with the clients that call it and says which client reads a field you want to remove, or never handles a status the handler produces. suss contract reads an OpenAPI document, a Prisma schema, or a CloudFormation template into the same form so the code can be checked against the document. The same summaries are available to an agent over MCP, so it can ask what a route reaches or what writes a table before it edits either.

It is deterministic and has no model in it. TypeScript is furthest along (Express, Fastify, Hono, NestJS, Next.js, ts-rest, Prisma, Drizzle, the AWS SDK clients), with Python and Ruby behind it.