The first ten minutes
You start your Monday in your agent — Claude Code or Claude Desktop with Ship connected over MCP — not in a browser tab. You ask it the only question that matters first: "what's waiting on me?" It calls Ship and comes back with the short list of decisions: clarifications, approvals, failures. You can also glance at the console hub, which shows three things and nothing more — is the engine healthy, what's waiting on you (each item a link to its approval page), and the command to connect a new agent. Most mornings there's nothing red. You confirm the engine is alive and move to the decisions.
Work the decisions
The day's decisions live in your inbox, and you work them through your agent: "list what's waiting," then dispose them one by one. Triage by impact.
Failures first — something tried to happen and stopped; you unblock it or defer it with a one-line reason the team can read tomorrow. Approvals next: signoffs someone asked for or a gated step is waiting on. Quick yes-or-no work that makes the difference between "the team is waiting on me" and "the team is moving."
Then clarifications — a question baked into a piece of work: did you mean it this way, is this acceptable, should we ship this variant. Answering one often cascades, clearing the next step queued behind it, so spend the most time here.
Improvements and exceptions come last. An improvement is a suggestion you can defer with a sentence about why; an exception is something that didn't fit the normal lane — give it an owner and move on. Most of this you do straight from the agent. The exceptions are deliberate human signoffs and anything destructive — Ship routes those to a web approval page (the hub links you straight to it) so a high-stakes "yes" is always a conscious click, never something an agent can fire on your behalf.
Spot-check the trail
Ship's domain views live where your team already works — merged PRs and CI in GitHub, tickets and projects in Linear. So spot-check there, or ask your agent ("what shipped overnight?", "what's in flight?"). You're not reading commit messages; you're confirming the trail holds. Did each merged PR link back to a ticket? Does the ticket reflect what shipped? Does each in-flight item have a tracker link, a repo and branch, and an owner? If something's been stuck longer than it should be, it's usually waiting on a decision you can clear in two minutes — bring it forward.
Catch the knowledge that drifted
Did you answer the same question twice this week? Did somebody ask about something that should already have been written down? If the answer you gave was general enough to help the next person, it belongs in Knowledge. Open the catalog, pick the bucket where it fits, write a paragraph. The fix for a recurring question is one entry, not five repeats.
Close on quiet
A healthy morning looks like this: an Inbox you cleared, a few items in flight with owners, a couple of things that shipped overnight with clean trails, and a knowledge entry or two if a pattern repeated. Routines may have run and reported nothing eligible — that's valid, the work wasn't there. A system that quietly does nothing on a quiet day is doing exactly what you want.
If you sensed a gap — something that should have happened and didn't — the audit log is where you check. It records every action with who, what, and when. You probably won't open it most mornings. Knowing it's there for the morning you need it is the architecture working as intended.
That's the whole loop. Read, decide, write down what changed, close the laptop. The next part of these docs walks setup — connecting the workspace, the repo, and the tracker.