Your AI coding agent forgets your client every morning. fdeops remembers.
Memory + methodology + skills, in one kit. Skill packs - BMAD, Spec-Kit, mattpocock/skills - teach your AI agent how to build. None of them remember who the client is, what you promised them, or who agreed it was delivered. FDEOps adds the missing layer: a private fieldbook per engagement (.fde/), a field methodology (land → close), and one @fde skill that routes it all.
Built for Forward Deployed Engineers, and anyone embedded in client work: consultants, agency developers, solutions architects, fractional CTOs. Feels like a second brain; behaves like a defensible record (dated, sourced, yours).
land discover plan build ship close
| | | | | |
+-----------+-----------+---------+----------+---------+
the fieldbook (.fde/) - one per engagement
written as a side effect of the work
You talk in plain language with @fde. The agent (and an optional CLI) handles the boring memory work. You still confirm anything that goes into the record.
Day to day you only need @fde and normal English. No command cheat sheet.
| When | What you say | What you get |
|---|---|---|
| Start of week | Open your AI coding agent (nothing to paste) | It already knows where you left off - trust, phase, what's next |
| After a meeting | @fde debrief these notes (paste or attach them) |
Proposed updates to the record - you review, then confirm |
| Pull from tools | @fde connect Granola (once) · then @fde pull today's Acme transcript |
Wire any source MCP you choose; FDEOps stages → proposes → you confirm. Recipes: mcp/recipes/ |
| Before a stakeholder meeting | @fde prep me for tomorrow's meeting with the sponsor |
A short brief from what you already logged - not a blank chat |
| Someone disputes scope | @fde when did we agree to drop that feature? |
Dated answers from the record (or a clear gap if nothing was logged) |
| End of week | @fde draft the sponsor update from the record |
Status grounded in what actually happened |
Same client folder every time (~/fde-engagements/<client>/.fde/). Your AI coding agent reads it on every session.
npx fdeops demoWalks one fake engagement end to end with the real commands: messy kickoff notes → proposed updates → you confirm → cold session reload → meeting prep → dated receipts → the fieldbook page. Nothing of yours is read, nothing leaves the machine, and it lives in a throwaway ~/fde-engagements/.demo/ that never appears in your portfolio. Remove it with npx fdeops demo --clean.
Or watch it first. One real session below - day 1 kickoff notes, the next morning's cold start, and "when did we agree to that?" six weeks later. Every line is the CLI's own output; only the typing pace is staged, and you can re-record it yourself with media/record-session.sh:
Note the two things a chat window cannot do: nothing is written until you confirm the routing, and the <private> block in those notes lands sealed on disk as (private - redacted) - it never appears in resume, prep, receipts, or the dashboard.
1. Install. Claude Code gets session hooks (context loads before you type); everywhere else the same fieldbook loads when you ask.
/plugin marketplace add suboss87/fdeops # Claude Code
/plugin install fdeops@fdeops
npx skills add suboss87/fdeops # Cursor, Codex, and skills-compatible agents2. Bind once - inside the client workspace (setup only; not a daily habit):
npx fdeops resume --init garvey # creates ~/fde-engagements/garvey engagement + binds workspaceCheck it worked:
npx fdeops resume # prints a short "where we are" for this client3. Work - talk normally:
@fde I just got the brief. New client, payments platform, they want it live before their Q3 audit.
@fde routes and updates the fieldbook - you confirm judgment. Full workflow: docs/USAGE.md.
It's working if npx fdeops resume prints this client's phase, trust signal, and next action - and tomorrow's session starts from that instead of a blank chat.
Other install paths · scan · env
- Cursor / Codex / Copilot / Gemini CLI:
npx fdeops adapters .- adapters/ - Local LLMs (Ollama, LM Studio, llama.cpp): load
skills/fde/SKILL.mdas the system prompt - guide - Manual / air-gapped:
git clone https://github.com/suboss87/fdeops.git && cd fdeops && node bin/install.js - Try without install:
npx fdeops demo- the whole loop on a fake client ·npx fdeops scan- day-1 recon of this repo (heuristic leads, not findings) - Requires: Node.js >= 18 for the CLI and adapters
- Advanced:
FDEOPS_ENGAGEMENToverrides the workspace registry. Full matrix: docs/install.md
- You describe the situation with
@fde(or plain language once the skill is loaded) - Session start / end - small hooks load where you left off and capture what changed (no re-paste)
- Local CLI - memory writes, search, and status with no model tokens; the agent runs it. You do not need to learn it for daily use (docs/USAGE.md)
- Pluggable pull (ingest) - FDEOps is the sink, not a connector pack. You add any source MCP (Granola, Notion, Drive, …) in Cursor/Claude; say
@fde connect …for a guided config + recipe, then pull in plain language. Raw text →.inbox/→ propose → you confirm →.fde/. No ambient sync; nothing unreviewed enters the fieldbook. See mcp/recipes/.
fdeops complements repo memory: CLAUDE.md holds how the code works; the fieldbook holds how the client engagement works.
The fieldbook lives on disk at ~/fde-engagements/<client>/.fde/ - not inside Claude, Cursor, or any other tool. Change AI coding agents and the same client record is still there.
On the new tool:
- Install
@fdefor that tool (plugin,npx skills add suboss87/fdeops, ornpx fdeops adapters .- see adapters/) - Open a workspace already bound with
npx fdeops resume --init <client>(or bind once if this checkout is new) - Talk with
@fdeor runnpx fdeops resume
Same fieldbook. Claude Code gets the fullest ride (session start/stop hooks). Elsewhere the memory and CLI are the same; context usually loads when you ask @fde / resume, not automatically. Details: docs/install.md.
Phase verbs (land → close)
| Verb | When |
|---|---|
| land | First days at a new client - interrogate the brief, map stakeholders, define success |
| discover | The brief feels wrong - find the real problem, with evidence from the repo |
| plan | Scope agreed - sequence it backwards from success, in PR-sized slices |
| build | Ready to write code - declare blast radius, log deliveries as you ship |
| ship | Going to production - pre-flight, canary, tested rollback |
| close | Engagement ending - handoff doc, retrospective, receipts that survive you |
Overlays for regulated domains (AI, fintech, healthcare, government) activate on signal. Full matrix: docs/skills.md.
You never pick one - you describe the situation and @fde routes. They are listed here because the methodology is the product, and it should be readable before you install anything. 37 methods across 6 domains, each one a method (the thinking, the artifact it drafts, the checkpoint with you), not advice:
| Domain | Methods |
|---|---|
| 1. Embed & Trust - first days, access, credibility | land · audit · stakeholder-radar · trust-engineering · scope-defense |
| 2. Discover & Diagnose - find the real problem | discover · assumption-audit · use-case-scoring · sketch |
| 3. Plan & Align - sequence it, sell it | plan · business-case · options-analysis · initiative-triage |
| 4. Build & Guard - the work, and not breaking their business | build · incremental-build · test-on-legacy · blast-radius · debug · rescue · security-audit · observability |
| 5. Ship & Verify - production, with a way back | ship · review · rollback-drill · qa-live |
| 6. Operate & Close - the part that decides renewals | status · demo-prep · debrief · exec-narrative · dashboard · multi-customer-ops · close · handoff-engineering · pattern-extract · red-team · ingest · ingest-connect |
Plus five overlays that activate on signal rather than being chosen - ai · artifacts · fintech · healthcare · gov - which add the checks that domain demands to whatever method is already running.
Every method, with the exact phrases that route to it: docs/skills-reference.md.
The fieldbook is the system of record for the embed - one folder per client, plain markdown you can read, grep, and take with you:
| File | Holds |
|---|---|
context.md |
Where you are - loaded first every session |
brief.md / success.md |
What they asked for; what "done" means and who signs it off |
reality.md / terrain.md |
The real problem; the codebase map |
stakeholders.md |
Champions, resistance, [signal:green|amber|red] trust tokens |
trust-profile.md |
Sacred data, AI policy, approval chain |
decisions.md / risks.md / delivery.md |
Choices with dates; live risk register; what shipped and its rollback |
Every entry is dated and sourced, so you can defend it in front of skeptical stakeholders. Schema: docs/schema.md.
Open the system of record in a browser - trust, phase, next action, and the full record in one local page. Ask @fde for the dashboard, or run npx fdeops dashboard (current engagement by default; --all for the portfolio).
| You are... | What fdeops does for you |
|---|---|
| Forward Deployed Engineer | The role this was built for - the full lifecycle, first meeting to final handoff |
| Consultant or contractor at a client site | Remembers the engagement so you stop re-explaining it |
| Solutions architect / engineer | Methods for the politics as well as the architecture |
| Agency developer running 3-5 clients | One .fde/ per client - details stop blurring |
| Fractional CTO doing client work | The fieldbook is your system of record for the embed - and your audit trail for billable work |
- Local only. Pure
git+ file reads - no network calls, no telemetry, no account. Works air-gapped. - Plain markdown. No database, no lock-in.
- No new data path. The AI sees client code only when you point your agent at it.
<private>tags are redacted from CLI/dashboard/hook output; do not feed raw private blocks into the model (file tools bypass that redaction). - Nothing enters the record unreviewed. The model drafts, you confirm (
fde debrief --dry-runshows the routing first); the hooks record only git facts. Your fieldbook stays yours to defend. - Know your sync surface.
~/fde-engagementslives in your home directory - your backup and cloud-sync setup now covers client notes.fde resume --initwarns if the folder sits in a synced path. Read PRIVACY.md before your first NDA'd engagement.
Details: PRIVACY.md · SECURITY.md
- The artifact is the memory - producing work and recording it are one action
- Methods, not autonomy - each skill tells you what to check; the judgment, the trust, and the consequences stay yours
- Brief is a hypothesis - discover before building the wrong thing
- Evidence on every claim - these files get defended in front of skeptical clients
- One customer, one folder - context never bleeds
# Plugin / skills install: re-run the install command from Quickstart
# From a git clone:
cd fdeops && git pull && node bin/install.jsBuilt and maintained by Subash Natarajan. Share your feedback via Issues - see CONTRIBUTING.md.
Thanks to builders whose craft helped sharpen the thinking behind this kit, among them Andrej Karpathy's engineering guidelines and the agentic engineering workflow notes from David Ondrej / Michael Shimeles. FDEOps itself is handcrafted for field work; any resemblance is inspiration, not a fork.
What we won't build: SaaS sync or Slack/Notion connectors inside the CLI, CRM as core, hardware capture, or generic code-craft skill packs (TDD/review already exist elsewhere - FDEOps owns the engagement, not the keyboard). The fde CLI stays local-only.
FDE Methodology - SECURITY.md - PRIVACY.md - Repo layout - Skills matrix - MIT