ship
Deliver the increment. Then go live with a rollback you have run.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/suboss87/FDEOps/HEAD/.claude/commands/ship.md -o ~/.claude/commands/ship.mdship.md
Load `@fde` (`skills/fde/SKILL.md`). Stage: **ship**. If `fde resume` shows NO ENGAGEMENT: ask "What should we call this client?" once, then **you** run `fde resume --init`. Never tell the human to type the CLI. Run `fde resume` (fallback: `npx --yes fdeops resume`). Read `references/ship.md` and follow it. Name brownfield or greenfield once. One change they can see, proven on their staging. Then pre-flight, who needs to know, rollback you have run. Host agent writes the code. You log what shipped and whether it was accepted. Confirm before any write to `.fde/`. Do not ship on “probably fine.” Done when: the change is proven on staging they operate, and go-live checks are on the record, or the human has named what still blocks live. Not for a one-line typo in an unbound file. Bound client work, a POC, eval, or go-live stays on `@fde`.
Engage. Interrogate the brief. Name who signs done.
Transfer operations. They operate it without you.
Capture the meeting. Notes into the record.
Diagnose. Check the brief is the real job.
Keeps the engagement record for client work. Use when they name a client or stakeholder. Use when they debrief a meeting or paste notes. Use when they ask what was agreed. Use when they run a POC, change the client's codebase, prove it on their staging, go live, or need evals before a model acts. Use when they prep a readout, when trust shifts, or they say @fde. Route and run the local fde CLI (or npx --yes fdeops). Never ask them to type commands. Not for ordinary code edits in an unbound repo.
Realize. Promised, measured, accepted.
Align. Sequence the work. Work backwards from success.
Prepare the meeting. One page from the record.