Everyday Keel Workflow

Keel works best when it becomes a stable rhythm rather than an occasional cleanup tool. The board should be the first place you read and the last place you update before closing a turn.

Morning Read

Check health before pulling work

Start with `health`, `flow`, and `doctor` so you know whether the system is healthy before you create more motion.

Lane Discipline

Pull from the correct queue

Use `keel next --role ...` instead of browsing manually. The board should decide what is truly next.

Tight Closure

Submit with proof in hand

Do not split implementation and evidence into separate, vague cleanup phases. Close the slice in one motion.

The daily loop

keel health --scene
keel flow --scene
keel next --role operator

That short sequence answers three important questions:

Is the system healthy?
Is the board blocked, open, or waiting on human input?
What should I work on next from my lane?

Read flow and doctor together, not as duplicates. doctor remains the exact remediation surface, while flow decides whether the delivery circuit should actually shut down. During live mission intake, flow can stay open with a notice even if doctor still reports transitional mission-wiring errors.

When you are operating the board

For strategic review or coordination work:

keel mission next --status
keel next --role manager
keel workshop --scene

These surfaces help you decide whether the system needs planning, review, acceptance, or a structural repair.

When you are shipping a slice

For delivery work:

keel story start STORY-ID
keel story record STORY-ID --ac 1 --cmd "your-check-here"
keel story submit STORY-ID

Replace the proof command with whatever the acceptance criterion actually requires. Keel is vendor-neutral about your tools, but not neutral about attaching proof.

When the board feels wrong

Do not paper over weirdness with more work. Repair the board first.

keel doctor
keel flow

If the diagnostics surface drift, treat that as real operational work. Keel is designed around the idea that structural debt is still delivery debt.

The important exception is intake pressure: if you are actively creating a mission, attaching children, or laying down planning/research work, keel flow may keep the circuit energized instead of declaring an immediate shutdown. That does not clear the doctor debt. It means the board can distinguish live upstream creation from true flow collapse.

For the full command taxonomy and the logic behind the visual surfaces, keep CLI Interface and Scene Surfaces nearby.

If Keel lives inside another repo

If you are operating Keel inside a downstream project rather than contributing to Keel itself, the repo's AGENTS.md and INSTRUCTIONS.md are part of the product surface. Read Downstream Project Contracts to understand how those files make Keel the active project-management engine, and keep Upgrade Keel And Sync Upstream Instructions nearby for maintenance turns.

Keep the rhythm visible

Orient

keel health --scene

Read the board before acting. Check for drift, blocked work, and missing integrity.

Inspect

keel mission next --status

Understand what the system thinks matters now at the strategic and tactical level.

Pull

keel next --role operator

Take one role-scoped move from the delivery lane instead of browsing an unbounded backlog.

Ship

keel story submit STORY-ID

Move the slice into review only when the implementation and its evidence are ready together.

Close

keel story accept --role manager STORY-ID

Accept the slice with an explicit role, then let the next turn begin from a clean board state.