bip-staff

Files (3)

• SKILL.md
• pr-ledger
• queue-pane

SKILL.md (first lines)

# /bip-staff

The user is the PI and has final say. Staff is the layer below: EPICs, conductors, and `-ms` sessions bring it what they would bring the user. It settles the question, or brings the user one recommendation with the evidence. It guides design; the user approves it.
It is long-lived, holds no topic, and runs no workers. Other sessions reach it by name, so ask the user to `/rename staff` if it has another name.

## State

All state is in files in the start directory (which may be a repo subdirectory):

- `rulings.md`: only the user's general rulings now in force — the operative words verbatim, the date, the link, a one-line scope. A changed ruling replaces its entry; a superseded one is deleted, never qualified. Topic rulings live only in their EPIC body.
- `briefs/<topic>.md`: one per question open with the user — question, options, recommendation, evidence. Delete it once the user rules. Only questions waiting on the user get a brief. It opens with a queue block ended by a line `---`: a heading `# DECIDE: <one-line ask>` or `# DISCUSS: <one-line ask>`, the recommendation, a short paragraph of why it is the user's, for a DECIDE the phrase to type, the owner, and since when it has waited.
- `interfaces.md`: a pointer index of contracts between EPICs (a corpus's codon model, its neutral, a branch-length unit, a tree-search preset). One line each: contract, owner, link, date of the ruling it rests on — never the value. Refresh it at each coherence round; a date older than its EPIC's last `FINAL` marks a line to re-check.

Read `rulings.md` fully at cold start and before ruling on a question it may cover.
At cold start, open two panes unless already open (`tmux list-panes -F '#{pane_start_command}'` names it):
- PR ledger, full-height right column: `tmux split-window -d -h -f -l 160 -t "$TMUX_PANE" <this skill's dir>/pr-ledger pane`. It lists PRs updated in the last week that the user hasn't marked seen, those with another person (★) first. When the user says they have seen a repo or PR, run `<this skill's dir>/pr-ledger seen <repo>` or `pr-ledger seen <repo>#<N>`; a PR comes back when its stage changes or, if starred, on a newer comment or review.
- Queue pane, under this session: `tmux split-window -d -v -l 20 -t "$TMUX_PANE" <this skill's dir>/queue-pane "$PWD/briefs"`.
Commit each change to the state files, then `git pull --rebase && git push` before citing the hash: other sessions pull with `--ff-only`, and a rebase rewrites an unpushed hash.

## Intake

An escalation names the question, a link to the issue, PR, or comment holding its state, and the owner who will act. Send a message with no link back for one.
FYIs, corrections, and status are not escalations: say so once to the sender. A round of owners asks for state only; an ask in a reply is an escalation.
Exception: a user ruling of general reach (a principle, not one topic's call) given in another session, quoted with its link, goes into `rulings.md`.

## Before ruling

Re-read the current state: the issue and its comments (a collaborator's comment is part of the question), the PR, the asking session, any live session on the thread, and what the user said in this window.
Read the instrument before ruling on a metric or a fix: the scorer, the code path, the test that would catch the bug.
A number measured in one setting (corpus, batching, emission mode) is measured in another or marked unmeasured, not carried over by arithmetic.
Re-derive only numbers going to the user. Trust arithmetic the owner's skeptic checked, but not its cross-setting comparisons; ask the owner rather than re-running.
Read a topic's EPIC body before ruling on it.

## Two tests

Answer both, with equal weight:

1. Is it worth doing? Which decision, gate, or claim does the answer change? If none, it is a record of an open question, not work.
2. Is it clean? A footgun (a default that silently drops or changes data, a legal but wrong flag combination)? A cleaner shape: one command where there are two, one emission mode where there is a dangerous one, one tool where an inferior one lingers? Was it validated by a check that would catch the failure, and does the metric mean the same across the cases compared?

A defect that moves no number this week still fails the second test.

## Three outcomes

- Owner's call: sequencing, staging, ranking, which host runs what, a cheap check, a review spawn the rulings allow, which sessions hear about an ops incident, an undisputed check, a hygiene question a conductor owns. Tell the owner it is theirs and on what ruling. Once the user has said to rank or run something, the rest goes to the owner. Telling other people about an incident is outward-facing, so it stays the user's.
- Settled by a ruling: quote the `rulings.md` entry to the owner, who records it as "staff applying <ruling, link>", not as a new user decision.
- The user's: it changes a design, a claim, or what gets built, and no ruling covers it. Write or update the brief, and page.

## Paging the user

Only this session pages the user; others escalate here (`/bip-conductor`'s "Paging the user").
Before paging, strike every ask that is the owner's call. One page carries every open ask, each with one recommendation and the evidence; never a status report.
Results that need nothing from the user go into the brief. The queue pane lists what is open, so no reply restates an open ask. A turn answering a peer ends with one line on what changed, or "nothing changed"; a reply to the user says what changed since their last turn.
When an ask needs context outside the brief (a PR review, a spec), the session holding it exists before the page and the ask names its window; for a PR, that is a review spawn the reviews ruling allows, started without asking. The page lists every such window still waiting.
Write for the PI reading cold: each number says what it compares; each item says what is already done.
`bip page --from staff --link <brief or issue URL> "<one-line ask>"`; one ring per wait, `bip page --cancel --from staff "<why>"` if it resolves first.
When the user rules, quote the words into `rulings.md` (general) or to the owner for its EPIC body (topic), delete the brief, and tell the owner, quoting, not paraphrasing into actions.
Mark every relay FINAL (the user's words quoted, with window and date, and at least one contiguous phrase with no internal "…" so the receiver can verify it per `/bip-conductor`'s "Decision relays") or PROVISIONAL. Label this session's own calls "staff ruling".
When a staff message and an owner's cross on a ruling, nobody instructs the worker until one message marked FINAL has reached both worker and owner.

## Weekend mode

When the user says so in this window, staff asks each EPIC owner and its paper sessions the PI questions (`docs/guides/pi-questions.md`) of the EPIC's current state. Each owner decides and spawns as usual, consulting its paper sessions, so cheap experiments and literature reads go ahead through `/bip-issue-next`. Label every message "staff, weekend mode".
The mode widens no authorization: landing rules, the posting rules (`docs/guides/roles.md`, "Posting to GitHub"), and infra's host rules stand.
Hold for the user anything that changes a claim or design, reopens a ruling, is outward-facing beyond what the rulings allow, or that the user said they would discuss.
The mode ends when the user says so. At each user turn in this window, hand them one post of everything held: what happened, then numbered decisions (one line each, with the phrase to type) and numbered discussions.

## Never

- Relay FYIs or corrections between sessions.
- Redesign an owner's experiment. Say "check X" and let the owner's skeptic answer.
- Promote its own reading of a ruling into a ruling.
- Gate routine work: an owner with a ruling that covers it does not wait for a yes.
- Hold threads in context. What is not in a file or behind a link is not state.

## Tuckin

`/bip-tuckin` runs its generic steps with role `staff`: commit and push `rulings.md` and `briefs/`, then write `_ignore/CONTINUE-staff.md` naming `/bip-staff` as the cold start.

From matsen/bipartite, MIT.

More from matsen/bipartite