Menu
Validate direction before committing. Prototype fast, show it, pitch the outcome.
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.
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.
| name | fde-sketch |
| description | Validate direction before committing. Prototype fast, show it, pitch the outcome. |
Load context.md and reality.md only. Load terrain.md only if the prototype touches the existing codebase.
Build a throwaway first. Show it. Find out if you're solving the right problem before investing in a real build. Then translate what you found into business language the customer can act on.
In a transformation engagement, the question is not just "what are we prototyping" but "which of the five use cases on the whiteboard do we prototype first."
Score them before picking. Three dimensions:
Business value -- what does it cost the business if this is not solved? Score 1-5. A use case that saves 10 hours of manual work per week is a 2. A use case that eliminates a regulatory breach risk is a 5.
Implementation complexity -- how hard is this to build safely and maintain? Score 1-5 (5 = hardest). A rules-based classifier on structured data is a 1. A multi-model pipeline with real-time inference on unstructured data in a regulated environment is a 5.
Data readiness -- is the data available, labelled, clean, and in sufficient volume today? Score 1-5 (5 = fully ready). No data or heavily PII-restricted data that cannot be used for training is a 1.
Formula: (Value x Data readiness) / Complexity
The use case with the highest score gets prototyped first. A score of 5 value, 1 complexity, 5 data readiness = 25. A score of 5 value, 5 complexity, 2 data readiness = 2. Those two look equally compelling on a whiteboard. The formula makes the gap visible before you commit three days to the wrong one.
This is not perfect scoring. It is a forcing function to make trade-offs explicit before spending time on the wrong prototype. Use the same model from @fde-discover if use case scoring was done there -- do not re-score independently.
What's the belief that kills the project if it's wrong? Name it together — then prototype that, not the pretty demo.
Build the minimum thing that tests the assumption. No error handling. No tests. No polish. Just enough to show to a human and get a real reaction.
Show it the same day if possible. Rough is fine, rough is honest. A polished prototype tricks people into thinking it's further along than it is.
If the direction involves AI, test these assumptions first:
Kill it immediately if:
When you kill it, write down what you learned, not what you built. That learning is the asset.
After the prototype is validated, translate it into business terms:
Keep the stakeholder summary to 3 sentences. If you can't explain it in 3 sentences, you don't understand it well enough to build it.
Tell the FDE:
.fde/prototype-log.md: what was built, what was shown, what the reaction was, what was learned.
business-case.md: customer problem, cost of inaction, success metrics, trade-offs, 3-sentence stakeholder summary.