hunk Agent Rules

Review-first terminal diff viewer built for reading agent-authored changesets.

Overview

Hunk has one central constraint: every interface shares the same review model, and renderers may not rebuild it themselves. The file also maps changes to test commands and defines three project terms.

Documents

├── 
├──  · symlink → AGENTS.md
├── .changeset
│   └── 
├── docs
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   ├── 
│   └── 
├── packages
│   └── hunk
│       └── skills
│           ├── hunk-extensions
│           │   └── 
│           └── hunk-review
│               └── 
├── skills
│   └── hunk-release
│       └── 
├── test
│   └── 
├── 
└── 

Techniques in this file

01 / Architecture as narrative

The seam drawn as a pipeline

Two ASCII flows show how a diff becomes a review document and how an intent becomes a surface projection. Each stage names the module that owns it and the facts a renderer is to consume rather than recompute.

Source excerpt starting at line 49.
  parity manifests. Consume them; never re-derive those facts in a renderer.

02 / Ratchets

Shrink-only baselines and append-only tombstones

The known-violations baseline may only shrink, while tombstone lists may only grow. Removing a violation requires deleting copies, adding a tombstone and adversarial fixture, registering consumers, and updating the audit.

Source excerpt starting at line 104.
  explicit `@hunk/vcs/*` leaves. The known-violations baseline is shrink-only: fix an edge, rerun  `bun run deps:baseline`, and never add to it.

03 / Verification by change type

Checks selected by kind of change

Rendering changes need type, integration, TTY, and real-terminal checks. Interaction work needs PTY coverage; broker work needs the Node adapter suite. The guide also names four suites excluded by default.

Source excerpt starting at line 149.
- `bun run test` does not include review conformance, PTY, TTY smoke, or real-Node adapter  conformance under `test/session-broker-node/`. Run the dedicated command documented in

04 / House vocabulary

A stated voice for comments

Header comments are written in active voice and lead with what the module does. Two phrasings are named as the ones to avoid, both of which describe the architecture's opinion of itself rather than its behavior.

Source excerpt starting at line 158.
  invariants. Avoid passive or self-important framing ("The one place where…", "the single  source of truth for…") — name the behavior, not the architecture's opinion of itself.

05 / House vocabulary

Three words defined

layout for structural arrangement, geometry for aggregate spatial data, bounds for one concrete visible extent. Three definitions that settle naming for everything in that area.

06 / Generated file guards

Generated files named with their generators

Four generated outputs list their source and rebuild command. Updating a session fixture also requires a protocol version bump and deletion of the previous fixture.

Ideas for your repo

  1. If several surfaces share semantics, draw the pipeline and name the owner of each stage.
  2. Give every known-violations baseline a stated direction of travel, and enforce it in CI.
  3. If your default test command excludes suites, say which ones. Agents run the obvious command.
  4. Define the three or four words your domain keeps arguing about.
Sponsored byModem

Give your agents the whole story.

These instructions explain how to work in hunk. Modem shows your agents what customers said, who is affected, and what changed.

See how Modem works