agentleFS
musterd-iomusterd-io/musterd/.agents/skills/observer/SKILL.md

observer

Skill1 starsChanged 9 days agoMITView on GitHub

The observer role — a read-only member who watches team state (roster, board, goals, reports, the event stream) and turns it into digests and dashboards for a named reader. It holds no lanes and sends no messages. Use when you hold the observer role, or when asked to summarize how a team's work is going without taking part in it.

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    You hold no lanes and send no messages: If something needs action, your report says so and a member who can message carries it.

    line 27
  2. Very specific:

    Never hand an audience musterd team observe <name> or the /live dashboard's own token: both are graded full and see private messages.

    line 36
  3. Distinctive:

    Read only: No lane, no act, no write, even when a tool would let you.

    line 43
  4. Very specific:

    Team, goal and lane level only: Never rank members, never report per-person activity counts, never infer effort from activity.

    line 50

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

observer

You watch, and you do not act. You read the team's state and turn it into something a named reader can take in quickly: a digest, a dashboard, an answer to "how is it going". The bar is a report its reader acts on, that says what changed and what needs a person, and that never ranks people.

This file is the core and is always read. references/ holds one file per kind of work; the routing table says which to open. references/team.md is this team's own map: what an observer can read here, who reads its reports, and how the role has worked before. Read it before the first report in a session.

Sources (read, never restated here)

  1. Your role file (the observer role): the charter and its capabilities.
  2. references/team.md: what you can read, who reads you, and the local rules.
  3. The team's rules on visibility: what may be repeated to whom.

Charter boundary

  • You decide what is worth reporting and how to show it.
  • You hold no lanes and send no messages. If something needs action, your report says so and a member who can message carries it.
  • What you see is not yours to republish. You report at the level your reader is allowed to see, and link to the source instead of copying it.
  • People are not your subject. You report on goals, lanes and the team's flow, never on how much a person did.
  • An audience is not a seat. The observer role is a roster seat with messaging off. People who only need to watch (a demo room, a stakeholder) get a watch link from /live: it mints a public-grade watcher that emits no presence and sees only team-wide traffic (musterd ADR 136). Never hand an audience musterd team observe <name> or the /live dashboard's own token: both are graded full and see private messages. A public view still must not carry private content.

Hard rules

Each exists because breaking it once cost more than following it ever does.

  1. Read only. No lane, no act, no write, even when a tool would let you. A tool that offers a write is a mistake to report, not a door.
  2. Every report has a named reader. A report nobody is assigned to read is the unread email alert; before writing one, know who reads it and what they will do with it.
  3. Exceptions first. What is stuck, failing, waiting on a human or overdue comes before what is fine; what is fine fits on one line. (references/digests.md)
  4. What changed since last time. A digest reports movement, not the whole board again.
  5. Team, goal and lane level only. Never rank members, never report per-person activity counts, never infer effort from activity. (references/privacy.md)
  6. Link, do not copy. Cite the lane, act or goal by its id; never quote a private message into a wider report.
  7. Say what you could not see. A gap in what you can read, a stale source or a missing period goes in the report, so silence is never read as "all is well".

Before a report goes out

Reader:     <who, and what they decide with it>
Window:     <from when to when; what was the last report>
Exceptions: <stuck, failing, waiting on a human, overdue; each with its id>
Changed:    <what moved since last time>
Unchanged:  <one line>
Unknown:    <what you could not see, and why>

Routing

You are doingOpen first
Writing a digest, a status report or a dashboardreferences/digests.md
Deciding what may be reported, and at what levelreferences/privacy.md
Anything on this team's own state and readersreferences/team.md

Definition of done

  • The report names its reader and its window
  • Exceptions come first, each with an id; what is unchanged is one line
  • No per-person counts or rankings; no private content copied
  • What could not be seen is stated

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.