# FDEOps ships 35 skills and a readme pointing at files the package omits

> A prompt-and-skills package for consultants and delivery teams, installed through four different surfaces into whatever AI coding agent you already use. The manifest registers two binaries, generates its own skill files from a script, and ships no documentation at all, even though the front page links a dozen documentation pages. Its privacy guarantee is carefully bounded: the command line tool makes no network calls, and what your agent sends to a model is your agent's business.

**suboss87/FDEOps** — Forward deployed engineering skills for AI coding agents.

- Repository: https://github.com/suboss87/FDEOps
- Website: https://fdeops.io/
- Stars: 949 · Forks: 106
- Language: JavaScript
- License: MIT
- Published: 2026-09-11 · Updated: 2026-09-11 · Language: en
- Canonical page: https://hysenlabs.com/projects/suboss87-fdeops

## Two installs, and only one of them fills the agent menu

There are two ways to install this, and they are not equivalent. One command pulls the coordinator, another pulls a single named task skill:

```bash
npx skills add suboss87/fdeops --skill fde
```

```bash
npx skills add suboss87/fdeops --skill build
```

The page then states the difference plainly: installing the coordinator includes all the underlying instructions, but it does not add the thirty-five separate task names to your agent's menu. So the coordinator is the smaller surface in the picker and the larger surface in behaviour, and a team that wants people choosing tasks from a list installs the skills one at a time. It also notes that a single task skill works on supplied project context without creating a customer record and without the coordinator being installed at all. Installation needs Node.js and Git, and the optional record command line needs Node.js 18 or newer, which is also the engine floor in the manifest.

## The manifest sits one patch ahead of the newest tag

Two version signals sit beside each other and they do not match. The three most recent releases are v5.1.21 dated 2026-09-25 and then v5.1.20 and v5.1.19 both dated 2026-09-22, while the package manifest declares version 5.1.22. That is the ordinary state of a repository between a release and the next one, and it also means the manifest number is not a release number, so an install resolved from the registry may be a patch ahead of anything with a tag. The last push on the repository is dated 2026-10-02. One small thing worth knowing before you script a clone: the default branch is named with a capital M rather than the usual lower case, which matters for any tooling that hardcodes a branch name.

## The privacy boundary is drawn at the command line, not at the skill

The page is careful about data, and the careful part is a distinction rather than a promise. It states that customer records stay in local files, that the FDEOps command line tool makes no network calls, and that your AI coding agent's settings determine what gets sent to a model provider, with the instruction to use data approved for that setup. So the guarantee covers the tool and stops at the boundary where the agent talks to a model. That is the honest place to draw it, and it is why the same block links a setup page for before-customer work, a privacy and masking page, and a section on local-model results. Two of the manifest's keywords name local model runners, which lines up with the recommendation to use a customer-approved local model for regulated and production work. The records themselves are Markdown files under a per-customer directory in your home folder.

## A passing test is explicitly not customer acceptance

One sentence carries more weight than any other on the page. In the engineering section, describing what the build, debug, review, ship, and handoff skills cover, it says that a passing local test does not establish deployment or customer acceptance, and points at a page titled verification and its limits. The same discipline shows up in the fieldbook description, which lists what that view displays and includes results awaiting acceptance as a category rather than only work that is finished. The reporting expectation is spelled out in the same sentence as what passed on which revision and in which environment, what remains unproven, and what the operating team needs before rollout. Read together with the dashboard description, the project is drawing a line between evidence a machine produced and evidence a customer gave, and it is deliberate about which claims it will make on its own.

## The skills are generated and the documentation is not shipped

The manifest tells you two things about how the package is assembled. First, the skill files are output rather than source: a generate script runs a skill generator and then a catalog document writer, which is the pipeline you would expect behind thirty-five consistent skill files and one catalog page. Second, the published file list includes the binaries, the skills, hooks, templates, adapters, an MCP directory, two markdown templates, and two JSON configuration files. The documentation directory is not in that list. So the front page links a dozen documentation pages, and anyone who installs from the registry gets a package whose own readme points at files that are not inside it. Publishing is gated too: a prepublish hook runs the same check script and the same test command that a plain check target runs, so a broken skill set should not reach the registry.

## Four distribution surfaces and five policy documents at the root

One repository presents the same content several ways: as a registry package with two registered commands, as a set of skills installed by name through a skills installer, as a plugin directory for one agent, and as an MCP configuration with a server directory of its own. The manifest registers two binaries, and the split is deliberate: one entry is the installer and the other is the coordinator, so the thing that puts the tool on a machine and the thing that runs an engagement are separate entry points. Alongside them sit five documents at the root covering security, privacy, a product description, a code of conduct, and contributing, plus an agents file and a template for one. The tree also carries an evaluation directory with a routing check and a live smoke test, wired into a test script of their own rather than into the default suite.

## Four worked examples and a saved dependency scan

The examples directory holds four named customer-shaped scenarios as directories, one standalone notes file, and two saved text files, one apparently the output of scanning a named web framework's pinned dependencies and one a more general scan result. That the scan output is committed at all is the useful part, because it means the skill set covers inspecting what a project already depends on and the result is meant to be reviewable rather than thrown away. The demo command is the cheapest way to see any of this working, and it is unusually explicit about its own limits: it runs on Node.js 18 and Git, it creates or resets its own separate workspace, and it calls no AI model at all, turning fictional meeting notes into a review and a browser view of the resulting record. The browser view has a matching caveat, since it is regenerated after record updates and an action is copied back into the agent rather than acted on in place.

## Conclusion

FDEOps fits a consultant or forward deployed engineer who already has customer access, a codebase, and an agent, and who wants a method rather than another tool. Its strongest suit is the honesty in it: the page says outright that a passing local test does not establish deployment or customer acceptance, and it separates what the tool guarantees from what your agent does afterwards. Three things to settle first. The privacy boundary sits at the command line, not at the skill, so use sample data or a customer-approved local model and read the masking guidance before you point it at live records. The two installs are not equivalent, since the coordinator bundles the instructions without adding thirty-five task names to your agent's menu. And the package ships no documentation, so read the pages on the repository site before you install rather than after.

## FAQ

### What is FDEOps and what does it contain?

It is a package of skills for forward deployed engineers, consultants, and delivery teams, used through an AI coding agent. It ships 35 task skills plus one coordinator named fde. The task skills cover strategy, architecture, and engineering, and the coordinator selects the relevant method as the work changes while carrying customer context between sessions.

### How do I install FDEOps?

Two commands, one for each route. npx skills add suboss87/fdeops --skill fde installs the coordinator, and npx skills add suboss87/fdeops --skill build installs a single task skill. Installation needs Node.js and Git, the optional record command line needs Node.js 18 or newer, and the README notes that installing the coordinator does not add the 35 task names to your agent's menu.

### Does FDEOps send customer data anywhere?

The command line tool itself makes no network calls and records stay in local Markdown files under a per-customer directory. The page is explicit that your agent's settings determine what is sent to a model provider, and it recommends a customer-approved local model for regulated and production work. Privacy and masking guidance is linked alongside a security setup page for before-customer work.

### Where does FDEOps store customer records?

In a local Markdown record under a per-customer directory in your home folder, carrying decisions, evidence, and next steps between sessions. The fieldbook is a read-only browser view of next actions, risks, evidence gaps, and results awaiting acceptance, regenerated after record updates, and you copy an action back into the agent to continue.

### How do I try FDEOps without using a model or real customer data?

There is a demo command that turns fictional meeting notes into a review and a fieldbook and calls no AI model at all. It needs Node.js 18 or newer and Git, may download the package through npx, and creates or resets its own separate demo workspace. The installation section also suggests trying individual skills with sample data before any customer work.

## Sources

- [License: MIT](https://github.com/suboss87/FDEOps/blob/Main/LICENSE)
- [Project website](https://fdeops.io/)
- [README](https://github.com/suboss87/FDEOps/blob/Main/README.md)
- [Releases](https://github.com/suboss87/FDEOps/releases)
- [suboss87/FDEOps on GitHub](https://github.com/suboss87/FDEOps)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/suboss87-fdeops