meltaA coding agent finishes a task in the fewest calls when its context already says what to change, where to look, what must not break, how to check the work and when to stop. Without that, it spends its first requests listing folders, grepping and reading files it will never edit. Melta's Chief gives each worker a task pack: a short project constitution followed by eight fixed sections, capped at 80 lines, with secrets fenced off. It then counts, from the worker's own transcript, what the pack failed to give.
Key facts
- Eight fixed sections: Goal, Write set, Read set, Where to look, Invariants, Validation, Ship, Receipt.
- A short constitution (mission, tech, roadmap, 60 lines at most) goes in front; the whole pack stays under 80 lines.
- The worker starts in safe mode with the pack appended to its system prompt and deny rules on secret files.
- Measured per task: looks before the first edit, files read twice, files read outside the pack, questions asked.
- A file, tool or variable that 3 or more tasks in one area needed becomes a proposed pack addition; a person says yes.
Why does a worker explore so much?
An agent dropped into a repo with only "fix the retry bug" has to rebuild the context a person already has: which folder, which file, which test, what the house rules are. Each step is a request that resends everything read so far. We wrote about the startup half of that cost in what a Claude Code session costs at startup. The pack is the other half: once the session is lean, put the right things in it.
What goes in the pack?
The pack is a Markdown file. In front is the project's constitution: three short files in specs/, mission.md, tech.md and roadmap.md, together 60 lines at most. They hold what every task in the repo needs: what the parts are, how each ships, the invariants, and the check commands. Then eight headings, always in this order, even when one is empty. A shortened example for a made-up repo:
## Goal Retry failed webhook deliveries 3 times with backoff; today they are dropped. ## Write set server/src/webhooks/deliver.ts, server/test/deliver.test.ts ## Read set server/src/webhooks/queue.ts ## Where to look deliver() sends once and logs on error; queue.ts has the job shape. also check: backoff, retryAfter ## Invariants Never retry a 4xx except 429. No new dependencies. ## Validation cd server && npm test -- deliver ## Ship Commit on the task branch; do not push. ## Receipt (the five lines below)
Chief refuses a pack over 80 lines. A short pack is cheap to carry for the whole task; a design document is not.
How does the worker start?
The worker is a new Claude Code session started with --safe-mode, which turns off CLAUDE.md, skills, plugins, hooks and MCP servers, and --append-system-prompt-file pointing at the pack. Lanes that should not edit get a tool list as well: a reviewer or architect lane gets only Read, Grep and Glob; a runner lane that only runs checks gets Bash, Read, Grep and Glob and no MCP servers.
The secrets fence is a deny list passed in the settings, for both Read and Edit: .env files, *.pem, *.key, *.p12, id_rsa*, id_ed25519*, ~/.ssh/, service-account JSON, and files named credentials* or secrets*. Chief also refuses a pack that names one of them.
How do you know what the pack missed?
Ask the worker, and check its transcript. The pack ends by asking for a five-line receipt:
status: landed|needs_you|reverted files: <n> touched tests: <command and result> next: <one line> branch: <name or none> missed: <term>, <term> (only if it had to search for things the pack did not name)
The missed: line is what the worker says it lacked. The transcript says what it did. When a task finishes, Chief reads the worker's own transcript and records:
| Metric | What it counts | What a high number means |
|---|---|---|
| Looks before the first edit | Reads and searches, including grep, find, cat and sed -n in the shell | Where to look was vague |
| Files read twice | Paths read two or more times | A big file, or the worker lost its place |
| Files read outside the pack | Reads before the first edit not in the Write or Read set | The Read set is missing a file |
| Questions | Times the worker asked a person | The Goal or Invariants left a decision open |
It keeps counts and paths only, never a tool's input or output, and drops any path that matches the secrets list. Search terms come from the worker's Grep and Glob patterns, the terms it searched for in the shell, and its missed: line.
How do misses become the next pack?
Two loops, one automatic and one with a person in it.
The automatic one is small. For each area a pack's Write set names, the three most frequent miss terms are added to new packs as an also check: line under Where to look. It is a hint, not a file list, so it is safe to add without asking.
The second is the weekly review. For an area with 3 or more measured tasks, any file read outside the pack, MCP tool used, or secret-like environment variable read by 3 or more of those tasks is proposed as a pack addition: a file to preload, a tool to name, a variable to name. Names only, never values. A person says yes or no to each one. An approved addition shows up in later packs as a preload: line in the Read set, a tools: line, or an env: line that says to take the value from the environment and never paste it. The review also prints one line of pack quality for the week: the median looks before the first edit, files read twice, and questions.
What is still missing?
Some of what a worker needs is not in the pack yet. Planned, not shipped: line ranges in the Read set ("read queue.ts 40 to 90" rather than "read queue.ts"), which needs a symbol map; the allowed tools named in the pack itself rather than only in the lane; and an explicit stop condition, so a worker knows when the task is done and does not polish. The test command is already in Validation by convention, but nothing checks it is there. We have no measured week-on-week trend to report yet; the target is that looks before the first edit fall as additions land.
Common questions
Why fixed headings instead of free text?
A fixed shape is easy to check and easy to read. Chief can tell an empty Validation section at a glance, and a worker always finds the test command in the same place.
Does a short pack make the worker miss things?
Sometimes, and that is what the miss metrics are for. A miss costs one search; a bloated pack costs its full size on every request.
Where do the constitution files come from?
melta-chief init-specs drafts them from the repo for you to edit. They are short files you own, kept in the repo.
Melta is free; join the waitlist.