HTEC CLOUD INFRASTRUCTURE · FORWARD DEPLOYED ENGINEERING

Client conversations,
turned into working prototypes.

A Claude Code plugin for the discipline of forward-deployed engineering: reconcile what the client actually said, pick the right lane to build in, ship a real prototype, and hand it off clean — instead of improvising all four.

install
$ brew install jq
$ claude plugin marketplace add htecgroup/fde
$ claude plugin install fde@fde-internal
THE FLOW

Four stages, in order, every time

Not a checklist bolted on after the fact — the sequence a prototype actually has to move through, with each stage's output feeding the next.

Discover

Raw transcripts, notes, and shared docs become a structured evidence base — sources, claims, contradictions, and the open questions that actually matter.

Decide

The lane, the hosting, and the auth model get picked from what the evidence supports — and written down, not carried in someone's head.

Build

A golden-path template, a local dev environment, a CI pipeline, and a deploy target — wired together from the start, not assembled the night before the demo.

Handoff

A dossier the receiving team can actually trust: the API surface, the data model, the decisions made, and an honest account of what still isn't production-ready.

TWO LANES

Every prototype declares which one it is

Before any code exists — because the two lanes trade speed for durability in opposite directions, and mixing them up is how a demo becomes a liability.

Lane A

Evidence

Built purely for speed, on the understanding that it gets thrown away.

  • Throwaway
  • Synthetic data
  • No real auth
  • Fastest path
Lane B

Seed

Built to be inherited, constrained to what the receiving team can absorb.

  • Inherited
  • Containerized
  • Real auth
  • Portable by design
THE TOOLKIT

What's actually in the plugin

Most skills reach for themselves when the moment calls for them. The ones that close a gate never do — a person invokes those deliberately, at a specific point in the flow.

Skills

fde-prep-brief

Forms an honest best guess from whatever exists before the first conversation — and names what is still unknown.

fde-market

Researches how the problem is already solved elsewhere, and where nobody solves it well.

fde-questions

Turns those findings into questions someone can actually ask out loud, in the right order.

fde-session

Reconciles several people's notes into one record, and preserves exactly where the picture is contested.

fde-hypothesis

Resolves the contradictions and commits to a view of the problem — then revises it when the build disagrees.

fde-risk

Ranks what to build first by what would invalidate everything else if it turned out wrong.

fde-persona

Drives the running prototype as one of the client's actual users, and reports what broke.

fde-critic

Drives it as the person hardest to convince, so the objection lands before the demo does.

fde-init

Creates the engagement workspace and the editor config for reading it as a graph.

fde-ingest

Turns raw client material into a structured evidence base.

fde-interview

Preps, supports, and debriefs the requirements interview.

fde-stack-selector

Picks the lane, hosting, and auth model — and records why.

fde-data

Decides where the data comes from, models the domain once, and generates the rest from it.

fde-retrieval

Decides whether grounding is needed at all, then builds and tunes it against real test cases.

fde-tools

Decides when an integration should be something the model can call, and draws that boundary.

fde-agent

Shapes a multi-step agent and the point at which a human has to approve before it acts.

fde-observe

Makes the prototype explain itself when an answer is wrong and the logs don't say enough.

fde-ui

Settles the visual brief — theme, palette, layout — then turns approved scope into screens, each connected to real data rather than to a copy beside it.

fde-local

Stands up the local dev environment for the lane in play.

fde-build

Wires the CI pipeline that builds and publishes the image.

fde-deploy

Configures the actual deployment target, whichever platform fits.

fde-vault

Maps the engagement, renders one architecture page from the decisions already recorded, and keeps every cross-reference honest.

Gate skills — invoked, never inferred

/fde-spec

Turns the evidence base into an approved spec, or an honest reason it isn't one yet — then into work items, in the repo or in your tracker.

/fde-demo

Answers whether this is genuinely ready to show a client, and writes the script it gets walked from.

/fde-validate

Records what the client decided — including a stop, which is the outcome most processes lose.

/fde-handoff

Packages the prototype for a handoff the next team can actually work from.

/fde-teardown

Takes a finished prototype's environment down on demand — keeping the record, revoking the access.

/fde-next

Reports where an engagement actually stands and what to run next — read from the workspace, never from memory.

Agents

architect

Reads every decision the engagement has recorded and renders one page with diagrams — including, deliberately, what isn't real yet.

screen-builder

Builds one screen from a brief that names what it must demonstrate and which files are its own — several run at once, which is the point.

workspace-scanner

Reads a whole engagement workspace and returns only the conclusions — what exists, what is missing, what no longer resolves.

STAYING CURRENT

Updating an install

The marketplace cache and an already-installed copy update independently — pulling the latest commit doesn't reach a session that's already running, and an installed plugin doesn't notice a new commit until it's told to look.

update
$ claude plugin marketplace update fde-internal
$ claude plugin update fde@fde-internal

Then restart the session — neither command applies to one already running.