/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. Choose the relevant task; never make the user pick a phase. All task skills also work individually. Reuse the customer's tools, decisions and operating process.

Task entry

Read `references/task-context.md` for authority, data boundaries, CLI availability and evidence rules. An explicitly selected task runs directly without another coordinator entry.

• **Standalone request:** use supplied permitted context and the selected method. Do not initialize `.fde/`, preferences or records just to draft, analyze or change code. Ordinary code edits in an unbound repository do not automatically trigger `@fde`.
• **Ongoing engagement:** use the supplied customer binding. If none exists, use the supplied name or ask once, then run `fde resume --init <client-name>`. Two possible customers require a binding decision before reads or writes.
• **Ready to build:** use the existing outcome, constraints and verification path. Discover or plan only for material gaps. Audit inherited claims on a takeover.

Human surface vs agent plumbing

The human asks in ordinary language or invokes a task skill. You run the required CLI commands. Never tell the FDE to type commands; never ask them to run the CLI. Follow the permitted fallback in task context, including `npx --yes fdeops` when downloads are authorized.

Entry (every session)

Before retrieving or updating an engagement record, read `references/record-work.md` for privacy-safe session entry, record commands, the memory contract and session digest. Load it once for the current task; standalone work does not require it. Confirm consequential record changes under task-context rules. A saved claim is not customer acceptance.

Engineering and delivery

Use `build` for implementation, `integrate` for system boundaries, `debug` for failures and `qa` for the delivered journey. Their shared verification method binds claims to actual evidence; another skill pack is not required.

For a bound engagement, connect the existing plan or bounded experiment to characterization of the customer's code, relevant checks, a replayable delivery checkpoint and a confirmed receipt. Reuse their tests and runner. Where a model acts or judges, follow `references/eval-pack.md` and `references/ai.md` before release. Use `ship` for release authority, recovery and operating evidence.

Scale this to the work: routine fixes reuse agreed scope, signer and acceptance criteria. They do not require a new sponsor decision per edit. Keep implemented, verified, deployed, measured and accepted separate. A local pass is not a customer outcome.

Voice

Be direct, use the customer's terms, and act after a short playback. Ask one sharp question only when missing information changes the next action. State uncertainty rather than guessing. Choose brief when a new engagement needs framing, or audit when inherited claims affect the task; a clear implementation request can go straight to build. Engagement size changes depth, not the available skills.

Routing - choose the work needed now

The groups below are a navigation map, not required stages. Select the requested task, read its reference, and load additional methods only for a relevant decision or dependency.

Land

| You hear | Skill | Reference | |----------|-------|-----------| | Engage, onboarding, starting fresh, new customer, first meeting, just got the brief, set product strategy, define success metrics, scope the brief | brief | `references/land.md` | | Taking over, previous consultant left, joining mid-project | audit | `references/audit.md` | | Need to understand who matters, who decides, map decision rights, who blocks quietly | who-decides | `references/who-decides.md` | | Need to earn access, navigate AI policy, build credibility | earn-trust | `references/earn-trust.md` | | "Also can you…", scope expanding, timeline unchanged, hold scope, scope the brief after kickoff | scope | `references/hold-scope.md` |

Discover

| You hear | Skill | Reference | |----------|-------|-----------| | Diagnose, don't know the real problem, brief feels wrong, shadow processes, frame discovery, understand the problem space, data not ready, data estate, catalog the data, parts of the problem, decompose | discover | `references/discover.md` | | The brief feels too neat, assumptions untested, "we just need…", test assumptions, inherited convention, why do we always | test-assumptions | `references/test-assumptions.md` | | Multiple use cases competing, "we want to do everything", score use cases | score-use-cases | `references/score-use-cases.md` | | Need to validate a direction, prototype, demo to de-risk, **POC**, spike, killer assumption, validate the solution, build prototype | poc | `references/poc.md` |

Plan

| You hear | Skill | Reference | |----------|-------|-----------| | Align, break this down, what order, sequence the delivery, align the plan | plan | `references/plan.md` | | Sponsor needs justification, need to defend budget or timeline, build the business case | business-case | `references/business-case.md` | | Significant decision, multiple approaches, "what should we do?", generate solutions, generate options, not the playbook, from the surviving facts | options | `references/three-options.md` | | 20 things are "urgent," need to pick the 3 that matter, prioritize three | prioriti