Before anything else: run djinn skills check --here in the repo you are working in. If it exits non-zero, stop: relay its output to the user verbatim — it names the fix — and run no other step of this skill. On exit 0, continue.

/rub — catch the operator up

The operator wants what a colleague would tell them after time away: what happened, what it means, and what needs their call. Not a copy of the facts, not a scoreboard. You investigate first and write second.

Stand aside under DJINN_SESSION=1: no operator is there to catch up. Stop and say so.

1. Read the facts

Run this first, before any other read:

djinn rub --facts

Its first line names the window's start. Then, each only when it has rows: landed, created, rulings, drain spend, not closed (disposition and log path per worker), duty trouble, needs you (each item with its bd show or gh run view pointer). A warning: line on stderr means a read failed; say which one in the answer.

An empty window prints one line ending nothing happened since then. With no warning: line, the whole answer is then one sentence saying nothing happened over the window that line names — since the operator last spoke, or over the past 24 hours when it says no previous message was recorded. Skip steps 2–4.

A warning: line voids that shortcut. An empty window beside a failed read means only that the read saw nothing. Redo the failed read yourself: djinn needs-you for a needs-you warning, djinn drain alive for the lock check, .djinn/state/last-operator-turn.json for the turn record. Then answer with what that showed, which read failed, and the window the facts actually cover; if the redo fails too, say what is unknown.

2. Investigate before writing

Write no answer text until every read below is done.

Each not closed worker:

1. Read its log at the printed log path: what was tried, where it stopped.
2. bd show <bead-id> --json: the title, the acceptance criteria, the parent.
3. Decide why it stopped and whether it matters: a retry the next drain will take on its own, or a call only the operator can make.

Each needs you item:

1. bd show <id> --json (a ci: item: its gh run view <run> --log-failed).
2. Its parent epic: bd show <parent-id> --json, for what the work is for.
3. What it waits on: the file to review, the question asked, the failing run. Read the file; read the bead's what:, why:, question: and answer lines in its notes.
4. Check what you can yourself — run the test, read the code at the line, look at the commit — so the operator decides only what only they can.
5. Form a recommendation with its one-line why.

Anything that looks off, unasked: a drain that cost far more than the ones before it, a bead retried again and again, a duty failing every run, a warning: line. Read the log or record behind it, as above.

3. Write the answer

Two parts, in this order.

What happened: short prose, as to a colleague back from lunch. Say only what is worth knowing — what changed for them, what went wrong and whether it matters, anything off. Group landed work by what it achieved, not bead by bead. Leave out what does not change what they would do.

Then one block per operator call — each needs you item, and each not closed bead that needs their decision. Each block carries, in this order:

<plain title>

What it is: <what it is and what it waits on, in everyday words, for someone who has never seen it>.
Why it matters: <what happens if it waits, or what it unblocks>.
What I checked: <what you read and ran yourself, and what you found>.

Recommendation: <what you would do> — <its one-line why>.

<one question>?

Exactly one question per block. A not closed bead you put to the operator is recorded first with djinn needs-you defer, as .djinn/lead/escalate.md step 3 does. Apply each answer the way .djinn/lead/escalate.md does for its kind of item.

No calls: end after the prose, saying nothing waits on them.

4. Never write

• A counts-only summary line ("3 landed, 1 stuck, $14"), anywhere in the answer. A number appears only inside a sentence saying what it means.
• A bead id without a plain description of that bead beside it.
• The facts output, or a bead's description or acceptance text, pasted.
• A question the reads in step 2 could have answered.