An issue tracker usually keeps its data on another server, reached through a browser or an API. The data is unavailable when the network fails. Tisket puts the issue beside the code. One branch holds both the fix and the issue state change.

Git supplies the history and sync. A clone brings the full issue history without an account, token, or webhook. A coding agent works with issues as file operations, without an API client or authentication flow.

Branches can still disagree. Tisket reads the same issue from every other branch and marks divergence with *. It names the branches and fields before a merge overwrites one version. Detection does not prevent divergence. What is tisket? explains the tracker and its relation to git.

Working notes survive the session

An agent’s investigation produces failed approaches and partial findings before it produces a fix. Tisket keeps that working text under ## Scratch Notes. The problem description above it stays unchanged.

Research often extends beyond an issue. An agent reads code, traces bugs, and compares options, but that work is usually lost when the session ends. Zettel records it in notes with provenance labels. Linking a note to an issue leaves the research available after the issue closes, as in How to keep an issue’s research in notes.

Provenance tells a later reader how to filter or weigh the text. Unknown is never upgraded to human, so an agent that forgets the label cannot mint human-authored text. A human can review and approve agent text.

Nothing verifies the label against whoever wrote the span. Review remains a person’s judgment; the label records that judgment for later readers. What is zettel? develops this distinction.

Published docs have a different job

An issue tracks work, and a note keeps research. Documentation is a published artifact, so diataxis keeps it in docs/, where readers and site builds look.

A page’s type makes its claim explicit. A tutorial promises a lesson; a how-to promises help with a goal. Reference describes the machinery, while explanation gives reasons and connections.

The type gives diataxis check something to test. The check reports only what the files prove. It does not judge prose. What is diataxis? describes the typed set; How to check issues, notes, and docs before a commit connects its checks to commits.

Skills enter context in parts

An agent does not need the full text of every skill at session start. Almanac’s list and Markdown index give names and descriptions within a byte budget. The agent loads one skill in full with show when it needs it.

Skills are pinned by commit and content hash. Adding a skill requires a red-flag scan and explicit --accept. A served library is read-only because curating a skill is a decision a person makes at the command line.

Only add, update, sync, and store sync reach the network. An answer does not change because of a fetch nobody requested. What is almanac? explains the library; How to vendor agent skills with almanac covers pinning it in a repository.

Context needs repetition

As the conversation grows, text injected at session start moves into the middle of the context window. It gets less attention there. That decay follows messages and tool calls, not elapsed time. Gaff counts those events and re-injects named text on a cadence.

Repository configuration is data on the agent path. Commands run only from the user’s configuration or after a human runs gaff init --git. Guards live only in the user configuration and can refuse a tool call. No gaff failure blocks a session.

These trust gates raise the cost of an agent granting itself permission. They are not a sandbox. The same configuration also drives git hooks that run the other tools’ checks. How gaff works describes the cadence and trust boundaries.

Tests are directories

Missouri checks CLI behavior through directories. A state is a directory, and the expected result is a directory; there is no assertion language. Gaff’s own end-to-end suite is a missouri state graph. What is missouri? explains that model.

One storage layer and one resolution rule

Mdstore is the shared storage layer beneath tisket, zettel, almanac, and diataxis. Issues, notes, skills, and pages are frontmattered Markdown, read by the same parser. They share stores.yml composition and root resolution. cat and grep can read the files too.

A store sees only what it declares. A personal store declares the repositories it annotates. A repository does not declare a personal store because that target does not exist for others who clone it.

Root resolution ignores environment variables. A repository can set variables through direnv or mise, and a variable is an input an agent cannot see in a transcript. A literal root argument or a marker file makes the target visible. Tools gives the resolution rule, including the distinction between reads and writes.

Bundled documentation and MCP access

The CLIs also carry their own documentation through docs and docs --all. Most provide a short prime text for an agent’s context. Each site has llms.txt, and every page has a Markdown twin.

MCP servers answer what the CLI answers and are read-only by default. A served store has no authentication. How to serve issues, notes, and skills over MCP keeps the servers on loopback or behind an authenticating proxy.