What using it looks like
From the root of a project, with the CLI installed:
chadkit init # chadkit/config.yaml, a README, a scratch file
chadkit task add "Rotate the API keys" --tag ops
chadkit log add --type t_feedback --source "Dana" --summary "Wants the keys rotated monthly"
Which leaves, in chadkit/tasks.md and chadkit/log.md:
- [ ] PT-001 [#ops] Rotate the API keys
### PLR-20260923-01 t_feedback Wants the keys rotated monthly
- Date: 2026-09-23
- Source: Dana
- Summary: Wants the keys rotated monthly
An agent that has read the model does the same by hand, in the same format, and you review the diff either way.
What you get
- Goals (
PG-): the direction, a few of them, each a paragraph. - Tasks (
PT-): one line each, with the goals they serve, tags, and what they wait on. - Log (
PLR-): dated evidence by type: feedback, QA findings, lessons, experiments, reviews, releases. - Language: one word per concept, with the words to avoid, so people and agents stop talking past each other.
- Decisions (
PD-): why a consequential choice went the way it did, with the alternatives. - Workflows: repeatable procedures, such as a QA gate that reviews every change before it lands.
A CLI allocates ids, completes tasks, appends records, and validates references, so nothing free-rewrites the files. CLAUDE.md and its equivalents point at these files and never restate them.
When it fits, and when it does not
It fits when several of these are true:
- Git should be the authority for what the project knows and intends.
- People need to review what an AI agent changed as an ordinary diff.
- Agents need stable words and a small, targeted context instead of the whole wiki.
- The project already exists and should improve a little at a time.
- Lightweight goals, tasks, evidence, and decisions are enough; a project-management platform is too much.
It is unnecessary when a project has almost no durable state beyond its code, or when another system is intentionally the authority and a copy in git would only drift.
Compared with what you already use
| If you use | ChadKit is |
|---|---|
| Jira, Linear, GitHub Issues | The tracker in the repository: tasks and their evidence next to the code, reviewable as diffs, writable by agents. |
| Notion, Confluence, a wiki | The place for goals, decisions, and vocabulary, in files an agent reads on every run. |
| Spec Kit, OpenSpec | The information layer under them; they own specification, ChadKit owns goals, tasks, evidence, and decisions. |
| Superpowers, Claude Skills | Complementary: they package how agents work, ChadKit records what the project knows. Reuse their skills rather than copy them. |
| MADR decision records | The base of ChadKit's decision records, with its own file names. |
The model's Related systems section compares the frameworks in detail.
Get started
Today: hand the model to your agent and follow its formats by hand. The chadkit-cli Python package (3.11 or later) is not yet published; when it is, from your project's root:
chadkit init
chadkit task add "First real task"
chadkit validate
Either way, read Bootstrapping and migrating an existing project first: the useful work is deciding what the project already has, not producing files.
Status
Pre-1.0: formats can still change, and the model says how versioning works while that is true. ChadKit runs on its own repository and on a handful of other projects by the same author, which is where its changes come from. One person maintains it.