/fde

name: fde
description: 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.

@fde

Purpose

Coordinate customer work from the first brief through implementation, verification and handoff. Select the relevant task instructions; never make the user choose a phase. Work directly on a standalone request, or maintain a confirmed `.fde/` record for an ongoing engagement. Reuse the customer’s tools, decisions and operating process.

Task entry

Read `references/task-context.md` first. An explicitly selected task skill (such as `discover` or `build`) runs directly; do not wrap it in another coordinator or repeat entry. For a one-off task with supplied context, use the relevant method without initializing `.fde/`. For ongoing client work use the bounded entry and memory contract below. Missing record files alone are not a reason to restart discovery.

When to use

• They named a client, pasted notes, or asked what was agreed
• The brief feels wrong, a sponsor went quiet, or Friday needs the ledger
• For ongoing client work without a binding, use the supplied name or ask once, then **you** run `fde resume --init`. A standalone request does not enter this setup path.

When NOT to use

Ordinary code edits in an unbound repository do not automatically trigger the coordinator. If the user explicitly asks `@fde` for a standalone task, follow Task entry without creating records. On a bound client, use the relevant task for POC, characterization, implementation, evaluation, release or handoff.

Use these first

| What's happening | Sentence to say | You run | Then read | |---------|-----------------|---------|-----------| | **The brief is wrong** | "If this works, who in their company would have to agree that it worked?" | Current entry packet (see Entry below), then discover | `references/discover.md` | | **They went quiet** | "What changed, and what do we know about why?" | Review supplied evidence; confirm any signal update before `fde log contact "…" --signal amber\|red\|green` | `references/rescue.md` | | **When did we agree?** | Don't argue from memory. Search the record. | `fde receipts <term>` | - | | **What's the outcome?** | A number nobody signed is claimed, not delivered. | `fde status` | `references/readout.md` |

For a bound engagement update after a meeting: the agent runs `fde debrief --smart`, interprets and reconciles the sanitized proposal, then validates it with `fde debrief --review`. Show the human one concise review of consequential changes and uncertainties → **Save this update?** → `--apply` only after confirmation → verify the saved facts. For standalone meeting analysis, use the review-only path in `references/debrief.md` without CLI setup or saving. Walk-in: `fde prep`. Friday: `fde status`.

Ground loop

On someone else's site the work is not "write code, remember later." Every change on a bound client stays on `@fde`:

1. **Name it** in `decisions.md` (plan), or timebox the riskiest assumption and record what the POC proves. 2. **Characterise their code** before you change it. Brownfield: their tests, their runner. Greenfield: the empty tree, first path they can click. 3. **Verify, then prove delivery.** Use their checks and the agreed representative environment; at the delivery checkpoint the signer in `success.md` can replay and reject the acceptance check. See `ship` for evidence requirements. 4. **If a model judges:** `evals.md` Verdict SHIP before that change is done (eval-pack). 5. **Log delivery.** Outcome is promised → measured → accepted, not a green CI. Then go live with a tested recovery path (`ship`).

Scale the loop to the change. A routine, reversible fix within confirmed scope reuses the existing outcome, signer, acceptance criteria, and engineering plan; batch its verification into a concise delivery receipt. It does not need a new sponsor decision or staging ceremony per edit. New outcomes, changed acceptance or authority, and production release decisions still need the relevant confirmation and evidence. This does not bypass confirmation for judgment written into the engagement record.

**Status is explicit.** Record what is implemented, verified, deployed, and accepted separately. A routine fix may be implementation-complete before release or customer acceptance; state what remains and attach the current verification receipt. The included build, integrate, debug and QA methods cover implementation; `@fde` connects their evidence to the engagement.

Engineering within the pack

Use `references/build.md` for implementation, `references/integrate.md` for customer-system boundaries, `references/debug.md` for failures and `references/qa.md` for the delivered journey. Each uses `references/verification.md` for actual evidence. These methods use the customer's coding conventions and installed tools; another skill pack is not required. Use an existing engineering plan rather than creating a competing backlog. Green tests establish tested behavior, not customer acceptance or production authority.

Human surface vs agent plumbing

**FDE (human):** `@fde` + English, or `/brief` `/discover` `/plan` `/ship` `/outcome` `/close` `/debrief` `/prep` `/trust` `/receipts` `/readout`. They may also invoke an individual task skill directly.

**You (agent):** run the CLI when the task needs real records. **Never tell the FDE to type** `fde …`. For ongoing work without a binding, use the supplied client name or ask once, then run `fde resume --init`. Never ask them to run the CLI. Standalone drafts and cod