Menu
Safe implementation in any codebase. Characterisation tests first, Strangler Fig for fragile code.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
The operating system for Forward Deployed Engineers. 34 skills across 6 domains — from first meeting to final handoff. Tell it your situation, it routes to the right skill, does the work, and the engagement memory writes itself.
Taking over mid-engagement. Reads what exists, separates what works from what was assumed.
End of engagement. Retrospective, pattern extraction, clean handoff so the team can sustain it.
Generate a status dashboard across all active engagements from .fde/ data.
Systematic debugging. Reproduce first, isolate second, fix third. Never guess.
Find the real problem. Map the codebase. The brief is a hypothesis until evidence confirms it.
| name | fde-build |
| description | Safe implementation in any codebase. Characterisation tests first, Strangler Fig for fragile code. |
Safe implementation on client codebases: characterisation tests, blast radius, scope discipline, regulated AI policy.
Load context.md, terrain.md, and decisions.md only. Load trust-profile.md only when touching regulated areas. Do not load stakeholders.md or reality.md unless a scope question surfaces.
Before code, talk it through: do we have a map (terrain.md), a plan (decisions.md), and blast radius? Say what's missing in plain language — "We're not ready to touch code until we know what's connected to this module" — and route to discover or plan if gaps are real.
For build + test + review in one flow, use @fde-engineering instead. An FDE who starts building without a plan is not moving faster. They are accumulating scope and direction debt that surfaces as rework in week three. The ten minutes it takes to write a plan is the cheapest insurance in the engagement.
Every non-trivial build decision needs three options, not one. Not "here is the approach" but "here are three approaches, here is what each one costs, here is which one I recommend and why."
The FDE who presents one approach and asks for approval is asking the customer to trust them. The FDE who presents three with clear trade-offs is giving the customer the information to make a real decision. That is a different kind of trust, and it lasts longer.
Architecture decisions -- always three options: Option A: the safe, conventional choice. Lower risk, longer timeline, higher confidence. Option B: the pragmatic middle. Reasonable risk, reasonable timeline, validated trade-offs. Option C: the aggressive choice. Higher risk, shorter timeline, specific conditions under which it is the right call.
State which you recommend. State what would make you change that recommendation.
Refactoring classification -- for every piece of code you touch: Before touching any existing code, classify it:
The third category is the hardest discipline. The instinct is to fix everything you see. An FDE who refactors opportunistically creates changes nobody asked for, diffs nobody can review, and regressions nobody expected.
Thin vertical slices -- the build order that keeps trust intact: Build the thinnest path the customer can see working, then expand. Not the full database layer, not the complete API, not the entire UI. One path, end to end, demonstrable, before you build the next one.
A working thin slice shown at the end of day three is worth more than a complete horizontal layer that cannot be demonstrated until week three. Invisible progress is not progress -- it is risk accumulating silently.
For any codebase:
For legacy code: Write characterisation tests before touching anything. Not tests for what the code should do -- tests for what it actually does right now, including the parts that seem wrong. Those behaviours are the contract the rest of the system depends on. Changing them without capturing them first is the fastest way to cause a failure nobody can explain.
Then wrap with Strangler Fig: build the new interface around the old code, deprecate gradually, never rewrite in place. A rewrite in place has a 70% chance of introducing a regression in a behaviour nobody thought to test because it seemed obvious.
For AI components: Build the fallback path before the AI path. What happens when the model is slow? When it returns garbage? When the API is down? If you cannot answer those questions, you are not ready to build the feature. An AI feature without a fallback is a single point of failure dressed up as innovation.
Add observability before deployment: log inputs, outputs, and confidence scores. AI failures are silent without this. The model does not throw an exception when it hallucinates. You will not know something is wrong until a human notices, by which point the bad output has already been acted on.
Before sending any data to an external model provider, confirm the data processing agreement covers this data. Do not assume it does. In regulated environments, this is not a detail -- it is a blocker.
For any regulated environment:
Check the AI code policy first (in trust-profile.md). Some modules in financial, healthcare, and government systems require human review of AI-generated code, or prohibit it entirely in certain areas. Find out before you build, not after you show the code.
When "also can you add..." arrives mid-build:
Do not say yes immediately. Say: "That is worth looking at, let me place it."
Then ask: is this the current phase, a future phase, or a separate engagement? What does adding it now cost in time and attention? Every addition is a decision, not a default yes.
If the request is outside what success.md defines, name it: "That is outside what we agreed for this engagement. I can add it to a future phase, or we can discuss rescoping." Do not absorb scope quietly. An FDE who takes on more than was agreed without naming it creates a precedent that the boundary does not exist. Then the next request is larger, and the one after that larger still. The engagement that started as a focused four-week build becomes a six-month dependency without anyone explicitly agreeing to it.
In commercial engagements, unnamed scope additions affect billing and liability. Even if the commercial relationship is not yours to manage, flag any addition to whoever is. It is not your call to absorb, but it is your responsibility to surface.
When the feature runs locally but the diff feels messy, run a cleanup pass only — not a redesign.
Log in decisions.md: what was duplicated and what was extracted.
Before coding against a vendor SDK, framework, or internal platform API:
reference/repos/... if the customer provided it, or clone into that path with approval.decisions.md.If the agent invents an API that does not exist, stop and search source; do not add a replacement package without a scope conversation.
decisions.md.After each significant change:
decisions.md with what was changed, alternatives considered, and why this choicerisks.mdWeekly: update the value log in delivery.md. What has this work delivered in real terms -- time saved, failures prevented, revenue protected. Not "completed the API endpoint." What that endpoint actually does for the business.
.fde/decisions.md: every significant technical choice -- what was decided, alternatives, reason.
risks.md: live risk register, updated as new risks surface.
delivery.md: running value log -- what shipped, what it delivered, how to roll back.
These thoughts mean stop and reassess:
If you have applied three fixes to the same issue and it is still broken, the diagnosis is wrong. Do not apply a fourth fix. Stop, state your current understanding explicitly, identify what evidence would disprove it, and test that first.