Menu
End of engagement. Retrospective, pattern extraction, clean handoff so the team can sustain it.
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.
Safe implementation in any codebase. Characterisation tests first, Strangler Fig for fragile code.
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-close |
| description | End of engagement. Retrospective, pattern extraction, clean handoff so the team can sustain it. |
Load context.md, reality.md, success.md, delivery.md, and decisions.md. This skill needs the full picture -- it is the only one that does. Do not load terrain.md unless the handoff document requires codebase-specific guidance.
The engagement doesn't end at ship. It ends when the customer team can maintain what was built without calling you. This skill captures everything learned, encodes reusable patterns, and leaves the customer genuinely self-sufficient.
Handoff isn't a doc dump — it's "what will bite them when you're gone?" Ask that in plain language; their answer shapes everything you write.
1. The retrospective. What went well, what was harder than expected, what would you do differently. Blame-free. Specific. Useful for the next engagement.
Key questions to work through:
terrain.md?2. The pattern. If something happened in this engagement that will happen again, a compliance approach, a migration pattern, a stakeholder dynamic, encode it. Write it as a skill or a note others can use.
"If you do it twice, encode it."
3. The handoff document. Written for the person who takes over. Not technical documentation, operational knowledge. The 3 things that will break and how to fix them. The person who holds the tribal knowledge. The monitoring alerts and what they mean. The deployment process in plain language.
If AI components were built: include the model version in use, what "normal" output looks like so the team can recognise drift, what the fallback behaviour is, who owns retraining if the model degrades, and how to disable the AI path without taking down the whole feature. Without this, the team will turn it off the first time it misbehaves, and it will stay off.
A direct assessment:
success.md defined.fde/retrospectives/YYYY-MM-DD-[engagement].md: decisions, mistakes, surprises, lessons. Written inside a retrospectives/ subdirectory that this skill creates if it does not exist. File naming convention: 2026-05-06-acme-payments.md. One file per engagement close. Do not append to a single file -- separate files make patterns easier to scan across engagements.
patterns.md: reusable patterns extracted from this engagement.
handoff.md: operational knowledge for whoever maintains this: what breaks, who knows what, how to deploy, how to roll back.
A single build engagement ends when the code is in production and the team can maintain it. A transformation engagement ends when the organisation can make decisions about what to build next without you.
These are different handoffs. The first is operational. The second is institutional.
For transformation engagements, the close must answer four questions that do not exist in a single-build engagement:
Who owns AI governance after you leave? Not "who owns the codebase" -- who makes the decision about whether a model is performing acceptably? Who decides when to retrain? Who has the authority to pull an AI feature out of production if it starts producing harmful outputs? If nobody owns this, the AI will be left running in a degraded state until a failure becomes a crisis.
What is the retraining trigger? Define it explicitly before you leave. Not "when performance drops" -- that is not a trigger, it is a feeling. The trigger is: "When precision on the validation set drops below 0.82 for three consecutive weeks, the model owner initiates retraining." Write the number. Write the condition. Write the owner. Without this, nobody will retrain until it breaks.
What does the operating model look like at scale? Pilot had three use cases and one team. Scale has twenty use cases and five teams. Who coordinates? Who sets the standards? Who arbitrates when two teams want to use AI differently? The FDE who builds a great pilot and leaves without an operating model hands the customer a success that will fragment in six months.
What is the decision authority for new use cases? After you leave, who can approve a new AI use case? What is the intake process? What risk assessment is required? Without this, every new use case either gets blocked by excessive governance or gets built without any -- and both outcomes produce failures.
Write the answers to these four questions in handoff.md before the engagement closes.