KadraPractice

Practice real TypeScript engineering on a working headless CMS

Quillio is a working headless CMS with posts, publishing and a public content API. Three bugs are in its publishing, slug and draft logic. You fix each one in the real codebase and open a GitHub pull request. An AI teammate reviews the diff, and a hidden Vitest suite decides whether the fix holds.

Real GitHub PRs · Graded by Vitest · Free during beta

What you'll actually do

Three bugs in Quillio's publishing

You work in a TypeScript backend someone else wrote. Each ticket reads like a real bug report, with acceptance criteria and a teammate you can ask for help.

CMS-401

Publishing never updates updatedAt, so the feed goes stale

The publish and edit handlers save the new content and never touch updatedAt, and the feed sorts by it. New and edited posts stop rising to the top. To pass, every publish and edit has to set updatedAt, the feed has to sort newest-updated first, and untouched posts keep their order.

CMS-408

Duplicate slugs collide on the same URL

Creating a post saves whatever slug it's given, so "My-Post" and "my-post" can both exist and one silently hides the other. To pass, a duplicate slug has to be rejected or auto-suffixed, case-insensitively, without changing existing posts.

CMS-417

Draft posts leak into the public API

The public list and detail endpoints have no status filter, so anonymous readers can see drafts. To pass, the public endpoints have to hide drafts while authors can still fetch their own through the authoring endpoint.

How grading works

Vitest decides whether the fix works

Each Quillio ticket has a hidden test file that's added to your branch at grading time. The result appears on your pull request as a check.

  • The hidden tests run with Vitest against your branch in a clean sandbox. They check every acceptance criterion, including the case-insensitive slugs and the author's own drafts.
  • An AI teammate reviews the diff in the PR thread and can request changes. That review is feedback; the tests decide pass or fail.
  • If a check fails, the test output is on the PR. Push another commit and it runs again.
  • Shipped tickets and tracked hours go on a certificate with a public link for your résumé or LinkedIn.
See exactly how the grading pipeline works →
Who it's for

Who the CMS track is for

Quillio assumes you know TypeScript and basic API concepts. It tests whether you can fix a bug in a backend you didn't write.

Backend-leaning devs and bootcamp grads whose projects are solo CRUD apps nobody reviewed.

People who have used a CMS like Contentful, Sanity or WordPress and want to see one from the inside.

Anyone preparing for interviews who would rather talk about a slug-collision bug than a blog they built.

Juniors who want to see what a "request changes" review feels like before it happens at work.

Not for: people new to TypeScript. Quillio is about debugging an existing backend, so learn the language first.

FAQ

Questions about the CMS track

What do I need installed?

Node.js 24 and npm if you work locally. Every Quillio repo also opens in GitHub Codespaces.

Who reviews my pull request?

An AI teammate reviews the diff in the PR thread and can ask for changes. Whether the fix is correct is decided by the hidden test suite.

What happens if the tests fail?

The failing test output is on the pull request. Push a new commit and the check runs again.

How is this different from building my own blog?

Your own blog only has the bugs you notice. Quillio has bugs a user reported, a reviewer reading your fix and tests that decide whether it's done.

Can I put it on my résumé?

Yes. Finishing the sprint gives you a certificate with the stack, the tickets you shipped and your tracked hours, behind a public link.

Does it cost anything?

It's free during the beta.

Take CMS-417 and get the drafts out of the public API.