What it is: the engagement layer for you (human FDE) + your AI coding agent - @fde routes skills; .fde/ holds client-scoped memory on your machine.
Terminology: README § Who this is for - "agent" = AI software, not a human.
Start here: README - installation, task choices and customer records.
Re-record: media/record-session.sh.
The examples below use fde as the short CLI form. Use npx fdeops in its place if the CLI is not on your PATH; for example, fde prep "sponsor sync" becomes npx fdeops prep "sponsor sync". See installation options.
Start with a fictional engagement so you can inspect the result before using customer information. Requires Node.js 18+ and Git; npx can download the package on first use.
npx fdeops demoThe demo uses fictional Acme payments notes in ~/fde-engagements/.demo/ and runs the actual CLI commands. It resets its own sandbox on each run. It does not require an agent or an AI account.
In the output, find REVIEW: stated asks, proposed scope, named signer, next action, and missing measurement/evidence/approval. Then inspect the applied decisions, meeting brief, and receipt about dropping the rewrite. A fictional PR#42 supplies a measured result; customer acceptance remains pending. The demo applies its fictional notes automatically to illustrate the loop. On your real engagement, review the agent's proposed interpretation before confirming it.
The example's success criteria are illustrative, not actual customer results. Notice the distinction between a target, a measurement, and customer acceptance.
Search by client or sponsor and filter by attention flags. On mobile, open Clients to switch engagements; the report keeps the selected client in view. Prompt buttons copy instructions for your agent. The dashboard is a local snapshot: rerun fde dashboard after changing engagement records.
Open the HTML path printed at the end. Find Acme's next action, recent decisions, risks, and available success criteria. The page is a local snapshot of the records generated during the demo.
To remove only the fictional demo later:
npx fdeops demo --cleanInstall the skill if you have not already:
npx skills add suboss87/fdeops --skill fdeWith your customer workspace open, send your agent:
@fde this is client01. Review these fictional meeting notes:
"Friday: show an alert for failed settlements. Keep the existing connector.
Priya might sign off but we haven't asked her. Tom will find the runbook.
Nobody has measured alert delay yet. Source: kickoff meeting 2026-09-10."
Show me the proposed scope, next action and missing evidence before saving.
The review should keep the connector, leave measurement and customer acceptance pending, and flag Priya's authority as unconfirmed. Tom finding the runbook is a next action; Friday is a requested deadline. Neither establishes that the delivery is feasible or accepted. Correct the proposal, then confirm when it matches the notes.
Your agent uses separate commands: fde debrief --smart notes.md to propose, fde debrief --review after reconciling the interpretation, and fde debrief --apply only after your confirmation. The CLI recognizes phrases; the agent helps interpret ordinary notes. Saving your reviewed record does not mean the customer approved its contents.
After saving, use fde defend to inspect claims and evidence gaps, then fde dashboard --open to see the next action and attention cues. Replace the fictional notes with your own permitted material when you are ready.
For more depth, follow the fictional Garvey Payments engagement from Day 1 to Day 10.
You do not pick a skill. @fde routes the AI and loads the relevant reference.
For free-form notes, ask @fde to help interpret them and review the proposed changes. The CLI's debrief --smart recognizes common phrases; “not detected” means it may have missed something, not that your notes contain no request or next action.
An unfinished proposal stays available for review. Apply it before starting another, or use fde debrief --smart --replace-proposal notes.md to explicitly discard it and review different notes. Exact sourced repeats are refused unless you deliberately override replay protection; paraphrased duplicates still need your review.
| Moment | What to ask | What to check |
|---|---|---|
| Start of day | @fde Where did we leave off with this client? |
Correct customer, current state, next action |
| Before a call | @fde Prep me for the sponsor meeting. |
Open questions, decisions, stakeholder context |
| After a call | @fde Debrief: <raw notes> |
Proposed changes match what was actually said |
| Before building | @fde Plan the smallest useful increment from the agreed success criteria. |
Scope, evidence, dependencies, acceptance owner |
| Before a readout | @fde Separate promised, measured, and accepted results, with sources. |
No unsupported outcome or approval claims |
Run these from a bound customer workspace:
npx fdeops dashboard --open # current customer
npx fdeops dashboard --all --open # portfolioIf your browser does not open automatically, open the HTML path printed by the command. No web server or account is required.
- Review attention cues for missing next actions and gaps in the available record. These are reminders to investigate, not conclusions about the customer.
- Open an engagement to review its context, decisions, risks, and value ledger. A measured result and an accepted result are different states.
- Use search to find an engagement or recorded detail.
- Copy a meeting-prep, debrief, or readout prompt into your agent to do the follow-up work. Copying a prompt does not execute it or change records.
- After applying notes or editing memory, repeat the dashboard command with the same
--alland--outoptions, if used, and reload the page. It is a read-only snapshot, not a live editor. Check the generation date before relying on it.
The HTML contains redacted engagement information, which can still be customer-confidential. Review it before sharing or presenting your screen. .fde/ remains the source of truth.
| You are… | Example message to the AI coding agent |
|---|---|
| Starting | @fde this is client01 then @fde First meeting tomorrow. Brief says: … |
| Unsure of real problem | @fde Workshop done. Ops says they use a spreadsheet nightly. |
| Just out of a meeting | @fde Debrief: <paste your raw notes> |
| Ready to code | @fde One change they can see by Friday in module X. Going live after Marco signs staging. |
| Production broken | @fde API 500 since 2pm deploy. |
| Sponsor went quiet | @fde VP stopped replying; still building old scope. |
| Handing off | @fde Engagement ends Friday. Need handoff doc. |
| Two clients | @fde This is for Project B - sponsor issue on payments. |
You type these. The AI routes the situation, investigates, and drafts. Review proposed judgments before recording them; obtain the customer approvals required before shipping.
The highest-frequency moment in client work: you walk out of a meeting with raw notes. Two ways in:
Via the agent: paste the notes to @fde. It removes the manual work of writing decision: / risk: / delivery: / contact: prefixes yourself (adding [signal:green|amber|red] on contact lines when the notes carry trust information) - it does not remove your review. It shows you the structured version first and only pipes it to fde debrief after you confirm.
Directly (zero tokens): write the prefixes yourself and run:
fde debrief meeting-notes.md # or pipe on stdin: pbpaste | fde debrief
fde debrief meeting-notes.md --dry-run # preview the routing, write nothingRouting is deterministic: decision: lines → decisions.md, risk: → risks.md, delivery: → delivery.md, contact: → stakeholders.md - each dated. Markdown dressing is tolerated (- decision:, * contact:, **Risk:** all route). Every unprefixed line lands as a dated debrief block in context.md, so nothing is lost. Use --dry-run the first few times to watch where lines go before trusting it.
Not sure which client a workspace writes to? fde resume --bind shows the binding and what actually resolves. Re-running fde resume --init <other-client> in a workspace replaces its binding (and says so) - a workspace writes to exactly one client, never two.
When a transcript or email is too large to paste, or lives in Granola/Slack/Notion:
Daily without MCP: paste to @fde or fde ingest stage a file. That is the complete product.
Optional pull: @fde I want to connect Granola (or Slack / Notion). You add that source MCP; FDEOps does not bundle it and does not push back. Then @fde pull today's client01 transcript. The agent fetches text and runs fde ingest in this bound workspace (stage → propose → you confirm → apply).
Directly (zero tokens, you already have the file):
fde ingest stage --source granola --title "Sponsor sync 2026-07-29" transcript.txt
fde ingest list
fde ingest propose <id-or-filename> # → .debrief-propose (same as debrief --smart)
fde ingest apply # after you review - same as debrief --applyRaw stays in ~/fde-engagements/<client>/.inbox/; dated facts land in .fde/ with optional via:<source> provenance. Optional MCP wrapper: mcp/fdeops-ingest (stdio tools mirror the verbs). Method detail: skills/fde/references/ingest.md.
Log stakeholder temperature as structured tokens, not vibes:
fde log contact "Denise gone quiet since the demo" --signal amberThat writes a [signal:amber] token into stakeholders.md. Trust is the worst active [signal:] across people (latest token per person) in fde status and fde dashboard; a green on one person does not clear amber or red on another. A signal older than 21 days shows as stale - a prompt to check in, not a verdict. With no tokens, the engagement reads new, not green.
You do not need these for daily work. Chat with @fde; the agent runs them. Use the terminal for one-time setup, air-gapped machines, or automation.
Humans - once / occasional (prefer chat: @fde this is client01):
npx fdeops resume --init <client> # fallback: create + bind this workspace from the terminal
npx fdeops resume # check "where we are"
npx fdeops scan # try day-1 recon with no install
npx fdeops dashboard # optional local HTML view of the fieldbookWhat you say → what the agent runs (you never have to type the right-hand side):
| You say | Agent runs |
|---|---|
| Debrief these notes | fde debrief --smart … → agent checks meaning, sources, and existing records → one review of the proposed changes → Save this update? (you accepted the record, not that the customer approved every ask) → --apply |
| Make sure we're up to date / pull from Granola or email | Capability check → source MCP fetch → fde ingest stage → propose → confirm → apply |
| Connect Granola / Notion / a new MCP / what can you pull | Guided mcp.json + mcp/recipes/; save/reload in host; test stage only |
| Prep me for the sponsor meeting | fde prep "…" |
| When did we agree to drop that? | fde receipts … |
| Draft the sponsor update | fde status (+ judgment in chat) |
| Log that the sponsor went quiet | fde log contact "…" --signal amber |
| Wrap the session / share the thinking / before the PR | Session digest into .fde/ (TL;DR, decisions & why) - not transcript sync |
Full command list (power users / scripts):
fde triage # short status (also injected by session hooks)
fde debrief notes.md # if notes already use decision: / risk: / … prefixes
fde debrief --smart notes.md # agent reconciles the proposal; review once; confirm → --apply
fde ingest stage [--source NAME] [--title TEXT] [file|-] # raw pull → .inbox/
fde ingest list # staged items
fde ingest propose <id> # → .debrief-propose (same smart path)
fde ingest apply # after confirm - same as debrief --apply
fde doctor # check the fieldbook for gaps
fde prep "sponsor sync" # walk-in brief from existing memory
fde log decision "…"
fde log contact "…" --signal amber
fde receipts "descope" # dated lines (ON RECORD)
fde dashboard --all # every client, sorted by trust
fde status [--all] # value ledger, then trust
fde vault [--redacted] [--out D] # derived Obsidian vault of the whole portfolio (disposable)
fde tidy [--apply] # propose safe consolidations (fde garden still works)
fde demo # the whole loop on a fake client (--clean removes it)Optional: export FDEOPS_ENGAGEMENTS_ROOT=~/path/to/engagements to isolate from ~/fde-engagements.
Each .fde/ is a local git repo (no remote, no telemetry). Writes stage only the files for that command - hand-edits to other records stay dirty until you review them.
Before applying, read the proposed interpretation rather than treating keyword routing as a decision. Ask/scope lines remain context; they do not become shipped work. A named signer records who has authority, not whether they accepted a result. Explicit source markers such as [source: meeting 2026-09-10] are retained from your input; the intake date is not proof of agreement.
From plan onward, fde doctor flags success definitions without both an observable acceptance check and a named customer-side signer. Put the check on **Done when:** or **Acceptance check:**, for example:
**Done when:** Replay a failed settlement in staging; its alert arrives within 15 minutes.
**Stakeholder who signs off:** Priya Shah [source: meeting 2026-09-10]Doctor checks the shape of a criterion, not whether the customer agrees or the test passes. If ordinary domain wording is not recognized, keep its meaning and use two explicit lines:
**Acceptance check:**
- Input: one month of settlement records on customer staging
- Pass when: zero duplicate settlements and 100% balanced totalsKeep the named customer signer alongside the check. Unknown inputs and subjective results still need clarification.
A boolean check also works: Given a revoked token, the request rejects every attempt. “Improve performance by 30%” alone does not specify a reproducible check. Doctor also labels dated decisions without source references as CLAIM. It reports gaps; it does not invent tests, grant approval, or block you from editing the record.
~/fde-engagements/<client-name>/
.fde/
context.md ← AI loads first each session (+ dated debrief blocks)
brief.md ← what they said (hypothesis)
reality.md ← what is actually true
stakeholders.md ← contacts + [signal:…] tokens
…
.inbox/ ← raw staged pulls (ingest); not the memory ledger
The workspace registry (written by fde resume --init) tells the AI and the hooks which engagement this workspace belongs to - no environment variable needed. (Advanced override: install.md § FDEOPS_ENGAGEMENT.)
cd ~/work/client-a && fde resume --init client-a
cd ~/work/client-b && fde resume --init client-bOne folder per client, one binding per workspace. Never merge contexts. fde status prints the value ledger (promised → measured → accepted), then trust; fde dashboard --all renders the portfolio into one offline HTML fieldbook; without --all, it shows the bound engagement.
fde vault # → ~/fde-vault, then: Obsidian → Open folder as vault
fde vault --redacted # → ~/fde-vault-redacted; review before sharingObsidian ignores any path starting with ., so pointing it at ~/fde-engagements shows nothing - every record lives inside .fde/. fde vault therefore writes a derived vault: a Portfolio page across all clients, one page per engagement (phase, trust, next action, timeline, people), a Questions page (gone quiet, value nobody accepted, stale signals), plus frontmatter and [[wikilinks]] so search and graph view work with no plugins installed.
The rules that keep it from becoming a second memory:
.fde/stays the only source of truth. The vault is never read back.- It is disposable - every run deletes and rebuilds it, so anything typed there is lost. Log to the fieldbook instead (
@fde, orfde log). - It is gitignored, and it refuses to build over
$HOME, your engagements root, a.fde/folder, a symlink, or any directory it did not write itself. --redacteddropsstakeholders.md,trust-profile.md, people pages, trust signals and contact notes - on top of the<private>redaction every FDEOps output already does.
The skills guide investigation and delivery; they do not make business decisions or establish customer approval for you. Concretely, fdeops does not:
- Replace you in meetings or politics
- Grant repo access or stakeholder buy-in
- Replace legal/compliance review (overlays are judgment aids only)
- Run on client infrastructure or shared git by default
- install.md - install matrix
- OPERATIONS.md - operating rules
- schema.md -
.fde/files - skills.md - the skills matrix + overlays
- skills-reference.md - the 35 task skills
fde resume returns at most 16 KiB of UTF-8 output by default, including its current-goal and risk excerpts. fde recall "retry approval" searches the active client's sanitized records and returns bounded matching lines with file references. It does not search other clients or send data to a model.
Use --max-bytes 4096 with either command for a smaller allowance (supported range: 4096-65536). These are byte ceilings, not exact token counts: models tokenize differently. The coding host's instructions, conversation and other tool output still consume its context window.
The active engagement identity is reserved ahead of the excerpts, including compact mode. Exceptionally long identity paths are explicitly marked as truncated. Truncation is explicit. A partial excerpt is not evidence that omitted constraints do not exist. Refine the query and verify source dates, conflicting decisions and approval scope before acting. References identify lines in the redacted view; private-block removal can change their position relative to the raw file. fde resume --full deliberately bypasses the output bound and can be large. Existing receipts remains available for a bounded literal record search.
A receipt is dated evidence supporting a claim. Short receipts retain a matched decision’s surrounding attribution, rationale and status, plus all explicit source references, with a warning when an excerpt or attribution is shortened. A value ledger tracks promised, measured and accepted outcomes; signal history records dated stakeholder observations, not inferred motives. Untouched template guidance is excluded from receipt matches. Sources remain recorded attributions, not proof of customer approval.
Measure the synthetic long-history behavior with node evals/context-budget/check.js. This reports bytes and matching records; it does not claim improved model accuracy or time saved.
For a standalone draft, ask your agent to use the handoff skill with your notes and project evidence. No customer record is required. The commands below export an existing customer record.
Run fde defend for accepted assertions, claims, source references, and gaps. Run fde handoff --out successor.md for a new portable Markdown snapshot; review it before sharing. Both are bounded and private-redacted, with no writes unless --out is explicit. They do not authenticate sources or confer customer approval.
Before planning or building, run fde doctor --ready. Record an observable pass/fail test and the named customer-side signer; vague improvement, a number alone, or a role is insufficient. This checks readiness without changing the phase.
A reviewed proposal can contain a structured delivery line using the existing ledger fields:
delivery: Staging replay | risk-mitigation | zero missing rows on staging | zero in 100 rows | pending | evidence/replay.csv | restore checkpoint
The agent checks the named fields with you before applying. This saves the ledger row in the same update; ordinary delivery prose remains a note. Missing approval stays pending. Pipe-separated rows must contain all seven fields so values cannot silently move into the wrong columns.
Use fde debrief --review to reopen the pending REVIEW after editing. If an exact statement with an explicit [source: ...] already exists, review the earlier record before applying it again. Intentional repeats require --allow-replay; this is not semantic deduplication, and it does not authenticate the source. The MCP apply tool keeps the refusal; use the CLI for an intentional replay override.
CLI and fieldbook mark explicit scope or withdrawal conflicts for review. A same-slice withdrawal leaves the historical rows intact and moves conflicting assertions out of current accepted value. Reused slice names can refer to different releases: clarify those records rather than assuming the tool knows which approval was withdrawn. These checks recognize explicit wording, not arbitrary legal authority or every possible contradiction. Check the named signer, scope and evidence before presenting an outcome.
After updating both the CLI and skill, run fde privacy to verify masking support. An older global executable does not gain protection from a skill update alone. Use the CLI to supply context to your agent. Supported identifier patterns are replaced with stable local aliases; original records stay intact, and confirmed updates restore known aliases locally. Preserve alias tokens exactly. The private dictionary in <engagements-root>/.privacy/ is not agent context.
This does not automatically recognize names or every sensitive identifier, and cannot intercept raw file tools, pasted chat, or source MCP responses. Mark sensitive prose <private> and read the privacy boundaries. Local fieldbook/vault files are human-facing exports, not a model-input channel. Setup can also mask supported identifiers in newly generated report content.
After binding your first client, your agent asks three short questions. Terminal users get the same choices through fde setup or npx fdeops setup.
| Question | Choices | What changes |
|---|---|---|
| How do you work? | One client / several clients / leading a delivery team | Focus on the current client, default to a portfolio overview, or emphasize ownership and handoff. Team mode does not add shared storage. |
| What would help you first? | Starting an engagement / continuing daily work / taking over existing work | Begin with discovery of the problem, the next useful action, or a review of inherited evidence. Current instructions and client records take precedence. |
| What should FDEOps hide before sharing context with your agent? | Common identifiers and secrets / those plus names and terms you specify | Both keep existing protection. Custom mode also hides the terms you supply locally. |
Answers are saved after confirmation and can be changed anytime. Skipping keeps existing defaults. fde setup --show displays your choices and saved term count, never the terms themselves. Hooks and scripts never wait for answers.
For custom masking, enter terms in your own terminal, one per line, or provide a local UTF-8 file. Do not paste sensitive terms into agent chat or ask the agent to open that file. The agent can pass its path directly:
fde setup --work single --start takeover --masking custom --terms-file /path/to/local-terms.txt --saveTerms match literally, ignoring letter case, at word boundaries. Longer terms match first. This does not discover names, spelling variants, abbreviations, or translated forms: supply the versions you need. Use 1-100 terms, each 2-128 characters. A new file replaces the saved list; omitting it keeps the list. Switching to standard masking disables custom matching but retains the list for reuse. Original records stay intact; confirmed writes restore the original text from aliases.
fde setup --settings keeps display, context and report options separate. Existing settings are preserved when adding personal setup. Standard context is capped at 16 KiB; compact uses 4 KiB. Explicit --max-bytes, --current and --all still override command defaults without changing the client binding. To mask newly generated report content too:
fde setup --view current --context compact --privacy reports --saveCustom terms and preferences live in <engagements-root>/.preferences.json, protected locally and excluded from normal engagement commits. Do not share this file or load it into an agent. Include it and the private alias dictionary in your retention and backup controls. Corrupt settings stop output rather than silently dropping protection; repair them locally. Setup does not configure a provider or grant permission to share client data. Raw file reads, pasted messages and other tools bypass masking. Existing exports are not rewritten, and masking does not guarantee anonymity.
Task commands now come directly from the corresponding skill. The plugin retains /outcome, /close, /prep, /trust and /receipts as compatibility shortcuts through fde; they are not additional task packages. In Claude Code, prefix them with fdeops: when invoking the plugin, for example /fdeops:brief. Plain task names such as discover also work directly from supplied notes or code.
| Shortcut | Use it to… |
|---|---|
/brief |
Clarify the initial request, success criteria and decision makers |
/discover |
Understand how the customer completes the task today |
/plan |
Sequence work around the agreed outcome |
/ship |
Prepare and verify an authorized release |
/outcome |
Compare promises, measurements and acceptance |
/close |
Transfer operation to the responsible team |
/debrief |
Review meeting notes before updating the record |
/prep |
Prepare for a customer meeting |
/trust |
Investigate a relationship or process concern |
/receipts |
Find a recorded claim and its source |
/readout |
Draft an evidence-backed sponsor update |
You can also describe the situation to fde in ordinary language. See installation and name conflicts.