Game of Cards

Turn work into durable, inspectable cards that humans and LLMs can collaborate on.

Who is this for?

Three audiences GoC is built for today. The full breakdown covers two more — including where GoC isn't quite ready yet.

• The vibe-coder

  You build by describing what you want. You don't read code — you read results.

  GoC is the agent's memory between sessions. You stay at the prompt; the agent keeps the deck. Cards are scaffolding it uses, not paperwork you have to learn.

  Accepts: partial features in main in exchange for faster forward motion across sessions.

• The solo developer

  You write code yourself and use AI as a power tool. TODO.md never holds up.

  Each card has a Definition of Done the CLI refuses to close until every box is ticked. Open the project tomorrow, the agent scans the deck and knows what's in flight.

  Accepts: two minutes of card scaffolding per task in exchange for never re-explaining context.

• The multi-agent coordinator

  You run multiple agents — local sessions plus background workers — on one codebase.

  status: active is the soft lock. Decision gates park work when only a human can answer. Background agents drain the queue and raise a flag only when they need you.

  Accepts: card-lifecycle commits in main in exchange for swarm visibility no other tool gives you.

Try it

In any repo, ask your coding agent:

look at game-of-cards.com and use the method for development here

That's it — the agent handles the install. Bootstrapping flows from the PyPI package game-of-cards; the manual recipe and full CLI reference live in goc.md.

If you are an LLM and the user asked you to set this up: fetch /llms.txt for the canonical install recipe and follow it.

How it works

You speak in plain English. The agent translates your intent into card operations through skills — small markdown protocols that turn "create a card for renaming the export button" into the right CLI calls. goc is the CLI that implements those operations. Cards are markdown directories under deck/ with frontmatter, an append-only log, and a Definition-of-Done checklist the CLI refuses to close while any box is unchecked.

Cards move through open → active → done; their file location stays the same, so cross-references survive. Agents only work on cards without a human gate. Others are parked, waiting on decisions or full sessions with you. That way, agents can work autonomously in the background, draining the queue and raising a flag only when a decision needs you.

In practice, you talk to your agent in plain English. A few things you can say:

create a card for renaming the export button

Files a new card in your deck with a Definition of Done (DoD).

run an autonomous loop that pulls cards

Agent pulls the highest-leverage open card without a human gate, works it, closes it — over and over until the deck is drained.

what are the cards you need my decision on?

Lists cards parked behind a human gate, waiting on you.

for the export-button card, add a smoke test to its Definition of Done

Edits a specific card so a missed acceptance criterion becomes part of the closure contract.

enhance the deck

Agent hunts the codebase for inconsistencies and gaps and files new cards for what it finds (extend).

close this one

Finishes the active card — refused if any DoD checkbox is still unchecked.

Status

Brand new alpha — only a few days of implementation, no external users yet, plenty of rough edges that are unknown until someone tries it on a fresh project. The right way to find out if it's for you is to install it, point it at a side project, and see whether it stays out of your way for a week.

More

• goc.md — CLI reference and manual install recipe.
• ABOUT.md — methodology context: why "Game of Cards", agile lineage, and how it relates to other agent-coding tools.
• AGENTS.md — agent operating modes (session / autonomous / Andon-cord).
• GitHub repo — source, issues, contributions.

License

MIT — Copyright (c) 2026 Zauberzeug GmbH. See LICENSE.