FDEOps: a client delivery record for AI coding agents
Forward deployed engineering skills for AI coding agents.
At a glance
- What is it?
- FDEOps is an MIT-licensed skill pack that wraps an AI coding agent in the paperwork of forward deployed engineering: brief, decision rights, staging proof, sign-off, handover. It is a record-keeping layer, not a coding tool, and the README is explicit that notes stay on your laptop.
- Who is it for?
- Adopt FDEOps if you are a forward deployed or contract engineer who already runs an AI coding agent inside a client repo and keeps losing the thread between meetings: it gives each client a separate folder under ~/fde-engagements/ and a read-only dashboard you regenerate with npx fdeops dashboard --open. Do not adopt it if you want the agent to write or merge code for you, or if you cannot run Node.js 18+ and Git on the machine holding the notes.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap FDEOps is aimed at: work that happens around the agent's code
The README frames the problem in the second person. You are on a customer site, the agent writes code in their repo, and the kit is "the work around that code": the brief, who can say yes, proof on their staging then live, whether they signed off, whether they can run it after you leave. That list is a delivery record, not a development workflow. The intended user is a forward deployed engineer or consultant who sits inside a client's environment, uses an AI coding agent there, and has to account for what was promised and accepted once the engagement ends. The project does not try to replace the coding pack you already use. The README says to keep it and treat FDEOps as the layer that adds "the client brief, decisions, and evidence around that work." The scope boundary matters: nothing in the material suggests FDEOps reviews diffs, runs tests, or gates merges. It produces records and reports, and the human confirms each update.
How the record is built: one folder per client, a skill selected by situation
The mechanism is a per-client folder on your own machine plus a skill the agent loads. Naming a client in chat creates `~/fde-engagements/client01/.fde/` on your laptop. Notes you paste into the same thread are proposed as updates, and the README describes a review step: after a meeting you look at what changed, new asks, open questions and next actions, correct the proposal, then confirm. So the data flow is notes in, a proposed record change out, human confirmation before it is saved. The agent does not silently commit memory. Skill selection is by description rather than by menu. You describe the situation to `@fde` and it picks the relevant skill; the README gives examples such as "Prep me for the sponsor meeting" or "What did we agree about scope?" The 30 skills are grouped into six stages (Land, Discover, Plan, Ship, Outcome, Close), and each skill is documented as giving the agent steps to follow, a record or report to produce, and a checkpoint with you. The Claude Code plugin additionally exposes stage commands such as `/brief`, `/discover`, `/plan`, `/ship`, `/outcome` and `/close`, plus between-stage shortcuts like `/debrief`, `/prep`, `/trust`, `/receipts` and `/readout`. The README states that the plugin adds session hooks and that skill-only installation does not, which is the clearest architectural split in the material: the same skills, different host plumbing.
Getting it running: scan first, then install the skill
The documented entry point requires Node.js 18+ and Git, and is a read-only scan of a local checkout: `npx fdeops scan`. According to the README it prints what to look at on day one and the questions to ask, and it reads local files without changing them. The README also notes that `npx` may download the package, which is worth knowing on a locked-down client machine. Installing the skill is a separate command: `npx skills add suboss87/fdeops --skill fde`. From there you name the client in one chat thread with `@fde this is client01`, which creates the engagement folder. To read the record, `npx fdeops dashboard --open` renders read-only HTML of what was promised, measured, accepted and the supporting evidence; `npx fdeops dashboard --all --open` covers every client at once. The dashboard is a snapshot, so the README says to repeat the command after updating records. For Cursor, after the skill is installed you add the instructions to the open client workspace with `npx fdeops adapters .`. For hosts that cannot create and bind the client folder, the fallback is `npx fdeops resume --init client01` from the client workspace. Offline, you transfer an existing checkout to a machine with Node.js and Git and run `node bin/install.js` from that checkout. There is also `npx fdeops demo`, which runs fictional notes through review, needs no AI model, writes under `~/fde-engagements/.demo/` and can be removed with `npx fdeops demo --clean`.
The scan is a prompt generator, not an assessment
The most likely misreading of FDEOps is to expect the scan to tell you something about the codebase. The README describes it as printing what to look at on day one and the questions to ask, and states that it reads local files without changing them. That is the whole claim. It does not say the scan grades the repository, finds defects, or estimates effort, and no output sample is given beyond that description. Treat the scan as a structured first-day checklist driven by what is present in the checkout. The value it offers is consistency: the same opening questions on every engagement instead of whatever you remember to ask. Whether those questions are good ones cannot be judged from the material here, because the README does not reproduce them. That is a documentation gap worth flagging before you build a habit around it.
Where FDEOps is the wrong tool
Three cases stand out from the material. First, if your problem is code quality rather than delivery accountability, FDEOps is beside the point: it adds briefs, decisions and evidence around the agent's work, and the README explicitly tells you to keep your existing coding pack. Second, if you work on one long-lived product rather than a sequence of client engagements, the per-client folder model under `~/fde-engagements/` and the six-stage lifecycle (Land through Close) map poorly onto continuous maintenance. Third, if you cannot run Node.js 18+ and Git on the machine that holds the notes, the primary path does not apply; the README's offline route still assumes a machine with both, so there is no documented path for a fully air-gapped environment without them. There is also a structural constraint the README states plainly: notes stay on your laptop, in a separate record for each client, and you review the agent's proposed changes before saving them. That is a deliberate friction. If you want the agent to capture and commit context without a confirmation step, this design will feel like extra work, and the confirmation step is not optional in the documented flow.
How it differs from a plain agent memory or a project tracker
The obvious alternative is whatever memory or context feature your coding agent already ships, and the difference is scope and shape. Agent memory is typically a single running context for one repository; FDEOps partitions by client and drives the record through named stages with a checkpoint at each one. The README's own contrast is with the coding pack: keep the pack, add the client brief, decisions and evidence. Against a conventional project tracker, the difference is where the record lives and who writes it. FDEOps keeps the record in a local folder (`~/fde-engagements/client01/.fde/`) generated from conversation with the agent, then renders it as read-only HTML; a tracker expects you to type status into fields someone else defined. The trade-off is that FDEOps has no server, no shared view, and no access control beyond your filesystem. A colleague cannot open the dashboard without access to your machine, and the README does not describe any sync or export path. For a solo forward deployed engineer that is a feature. For a team of three on the same account, it is the first thing you would have to work around.
Maintenance, release cadence and the MIT licence
The release history supplied shows v3.28.0, v3.27.1 and v3.27.0 all dated 2026-09-10, with titles that read like reliability fixes: "daily workflow reliability", "safer daily updates", "Defensible daily delivery". The last push to the repository is 2026-09-11, one day after the most recent release. Three releases in a single day suggests active iteration on the CLI and update path, which cuts both ways: you get fixes quickly, and the surface you script against may move. If you wrap `npx fdeops dashboard` or `npx fdeops scan` in your own automation, pin the version rather than tracking latest. The project is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained; that is a summary of the licence text, not legal advice, and you should read the LICENSE file in the repository and check it against your client's own terms before shipping anything derived from it. Note that the licence covers the code and skill definitions in the repository. It says nothing about the client notes you generate with it, which remain your responsibility and, depending on the engagement, may be subject to your client's confidentiality terms. The README's design already assumes you keep those notes local and separate per client.
Editorial conclusion
Adopt FDEOps if you are a forward deployed or contract engineer who already runs an AI coding agent inside a client repo and keeps losing the thread between meetings: it gives each client a separate folder under ~/fde-engagements/ and a read-only dashboard you regenerate with npx fdeops dashboard --open. Do not adopt it if you want the agent to write or merge code for you, or if you cannot run Node.js 18+ and Git on the machine holding the notes. Verify first that your host can create and bind the client folder; if it cannot, the documented fallback is npx fdeops resume --init client01 from the client workspace. Also confirm the plugin path if you want session hooks, because the README states that skill-only installation does not add them.
Community notes