Blackboard

.yomi/boards/<feature>.md

Location and Naming

• <feature>

  = the feature slug set by the initiator (e.g.,

  auth-refactor

  ); the initiator (usually the leader) creates the board according to the template.

• ls .yomi/boards/

  lists all in-flight feature boards in the current directory.
• When spawning a sub-agent, provide the absolute path of the board in the prompt, instead of relying on the other party to guess using their own CWD (which may lead to incorrect board creation in subdirectories); all agents of the same feature must receive the same path.
• Feature wrap-up: After the leader accepts the work, delete the board to prevent accumulation of boards.

Template

# Board

## Agents

### <who>
- task: <ticket id + title>
- status: doing | done
- progress: ...(latest entry)
- updated_at: HH:MM
- notes: ...(findings useful to peers)

Rules

1. Check-in before starting work — After receiving a task, add your own

   ### <who>

   section under Agents, write the task (ticket id + title) and the first progress entry. who = role name + the session id prefix from your system prompt's Environment section, e.g.,

   worker-auth sub_01KZ

   (main session is

   sess_*

   , subagent is

   sub_*

   ; same source as the ticket's owner_session_id).
2. Only modify your own section — Keep only the latest progress entry, and refresh updated_at conveniently; write findings useful to peers into your notes line. Never modify others' sections.
3. Mark as done when finished — Change status to

   done

   , write a summary of the result into the progress line; after the leader accepts the work, delete the section (see "Location and Naming" for deleting the entire board).
4. Read the board — Read the board of your feature before starting work or when stuck: peers may have already solved your problem, or be modifying the file you need to change.
5. Concurrency — Concurrent writing is guaranteed by precise matching during editing: edit failure = someone just modified it, re-read and then edit again.