AGENTS.md is the cross-vendor name (opencode, Codex, Gemini CLI read it natively; so does current Claude Code), and the brief goes to every vendor's agents — an opencode work agent previously launched with no project brief at all. The content moves verbatim to AGENTS.md at the root and in manager/local/; each CLAUDE.md becomes a load-bearing compatibility pointer (@AGENTS.md import) for older Claude Code CLIs. update.sh's core-owned file list now carries both names, so updating an old-layout install lands AGENTS.md and replaces the full CLAUDE.md with the pointer instead of resurrecting it. All four core prompts, README, the board.py/taskfiles.py docstrings, the task template and the adapter contract docs now name AGENTS.md; adapters/README.md notes that vendors reading AGENTS.md from the working tree need no adapter work. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.6 KiB
NN — Imperative title: what changes when this is done
Status: Backlog Priority: Medium — one clause on why it sits at this level Type: Feature Depends on: 03, 05 — task numbers or external preconditions that must land first, for whoever sequences the board; delete when nothing blocks this
One paragraph for someone — human or agent — who has the codebase but not the conversation: what this task changes, and why it is worth doing.
Context
What exists today and why it falls short. Point at real places rather than
describing from memory: packages and modules (packages/domain/...), prior
tasks (../done/...), plan files (../../plans/...) and reference
documents (../../reference/...) — a link outlives a summary.
Affected areas: the modules or layers this touches, one line in the repo AGENTS.md's module-map vocabulary — telling reviewers where to look and agents where to stop. Optional: delete when the title already says it.
What to build
The work itself, concrete enough to start on. Name the layers things belong in — the repo AGENTS.md's dependency rules decide where code goes, not convenience.
- First piece
- Second piece
Out of scope — the adjacent changes this task deliberately does not make. This is what bounds the work agent's brief; scope creep is the classic headless failure. Optional, but cheap insurance on any task with tempting neighbours — delete rather than leave empty.
- Not this, even though it is nearby
Acceptance
Observable outcomes, not implementation steps — review agents judge the diff against exactly this list. The repo's definition of done (the project's configured checks pass, new behaviour covered) applies on top; don't restate it. Given/When/Then phrasing is welcome where it sharpens a criterion, and edge cases belong here too — boundaries, empty inputs, failure paths.
- Something a reviewer can check without reading the diff
- Given , when , then
- Edge case: the boundary that would embarrass this feature if missed
Open questions
Decisions only the task's author can settle. This section is load-bearing:
an agent told to start work while anything real sits here will refuse with
NOT READY and send the card back — that is the point. Empty it (or delete
it) when the task is ready to action.
- None.
Notes
Freeform: research findings, links, decisions taken along the way. The board's relevance checks and PR reviews append their reports below this line as the task moves.
Risks — known hazards and blockers: what could sink the approach, what the change might break, what must hold for it to work. For the author weighing the task and the reviewer double-checking it. Optional: delete when there is nothing real to name.
- None worth naming yet.