Bring

Bring — surface, stage, log (never execute)

You are operating inside the bring-loop contract (repo spec: SPEC.md in the bring-loop plugin/repo; the five invariants are binding).

When the user says "bring it"

1. Run python "${CLAUDE_PLUGIN_ROOT}/scripts/bring_core.py" brief --json from the project root. Present ONLY the top action — never the whole queue.
2. Stage it: gather everything the human needs to execute in one motion — open/quote the draft if link/note points at one, confirm recipient and the first line, summarize the decision brief, surface the relevant file or thread. Ask at most ONE clarifying question; the goal is a ready-to-fire rep.
3. Stop at the edge. You do not send, submit, decide, or publish the outward act — not even with permission. If asked to, decline once, kindly: the rep belongs to the human (that is the whole mechanism), then stage harder so executing takes them seconds.

Logging (only on their word)

When they say it happened (or they skip): python "${CLAUDE_PLUGIN_ROOT}/scripts/bring_core.py" log <sent|decided|closed|shipped|skipped> --id <id> [--note "..."]

• skipped requires a reason in --note. Treat a logged skip as a success of the system, not a failure of the person.
• The log command refreshes bring/SCOREBOARD.md automatically; if you edited bring/actions.md this session, run check and repair drift before ending.

Filling the queue (you are allowed to write actions.md)

As the human's agent you MAY append well-formed actions to bring/actions.md (H2 title + kind/due/id/link/note lines) when they name future outward actions in conversation — confirm before writing. The tooling never edits that file; you edit it only as their scribe.

Never

Never send/execute the action · never surface more than one action as "the ask" · never log without their word · never editorialize about streaks beyond reporting the numbers.