Build Your FDE Toolbox: A Skill That Makes You Name the Problem Before You Design the Fix

The moment that separates a builder from an operator

A request lands. A stakeholder wants a dashboard, a teammate wants a retry queue, a client forwards a complaint with the fix already attached. And something in you starts designing immediately — because generating a solution is easy, and it feels like progress.

That reflex is the most common way real architecture and forward-deployed work goes wrong. Not a missing tool. Not a weak model. A sequencing mistake: the solution arrived before the problem was understood.

The people who stand out as Forward Deployed Engineers — the ones embedded with a customer's actual situation and accountable for what changes there — do one thing differently. They interrogate the problem before anyone designs against it. That's not a personality trait you either have or don't. It's a discipline, and a discipline can be written down.

“The move that distinguishes a builder from an operator happens earlier than the build.”

Why turn the habit into a skill

You already know you should pause and ask what the real problem is. Knowing has never been the hard part. The hard part is the third request of a busy Tuesday, when someone is waiting and the answer is right there.

A Claude skill is a way to stop relying on willpower in that moment. You write down, once, what should happen when a certain kind of request shows up — and the sequence is enforced every time, including the times you're tired. I call the result a toolbox: a skill named for your field that runs your best thinking on demand.

The design: two phases, in strict order

The toolbox has exactly two phases, and the first one is a gate. Phase 2 stays locked until Phase 1 is confirmed by a real person. No exceptions, no shortcuts when the request looks obvious. Obvious-looking requests are where the invisible assumptions hide.

Phase 1 — Problem Definition (the gate)

Before any solution is proposed, the skill works through five questions:

1. What is the one constraint that, if resolved, makes the other problems smaller or irrelevant? Name it as a specific mechanism, not a category. "Communication issues" is a category. "Two teams edit the same spreadsheet with no owner for the final number" is a mechanism.

2. Who decided this was the problem — and what would have to be true for it not to be one? Complaints often arrive with a diagnosis already attached. Someone chose that framing. Find out who, and why.

3. What assumption here is so obvious it's invisible? The most expensive assumptions are the ones nobody has ever said out loud.

4. What existing process, habit, or structure does this problem currently protect? Sometimes a "problem" is quietly holding something up. If you resolve it, what breaks?

5. Can you state it in one plain sentence, free of jargon, that the person who owns the problem can understand and confirm?

Then the skill stops. It does not move on until that sentence is explicitly confirmed. And if it can't be said in one plain sentence, the problem isn't ready — which is useful information, not a failure.

Phase 2 — Solution Architecture (unlocked by the confirmation)

Only now does design begin, and it stays concrete. The skill defines the boundaries: what is explicitly in scope and what is explicitly out. It names the actors individually — who or what initiates, processes, decides, and produces output. It states the tradeoffs openly rather than hiding them. And it's written for whoever implements this next: the engineer picking up the ticket, the manager rolling it out. Not for someone grading how thorough you look.

“Write for the person who has to build it on Monday, not the person judging your effort on Friday.”

The prompt that builds the skill

You don't hand-write the skill file. You write a prompt precise enough that Claude writes it for you. That reframes the exercise: the quality of your skill is the quality of your specification — which is, not coincidentally, the same muscle you use on the job.

The prompt opens with "Create a Claude skill named [your-domain]-toolbox," then fills in a handful of blanks. Each blank is a decision only you can make, and each one is where a weak prompt goes wrong.

Your context and trigger. Say what you do and — precisely — the moment the skill should fire. "When I have a problem to solve" fires on everything, so it effectively fires on nothing. "When someone hands me a request to build, fix, or redesign a system, or a bug report that already assumes a fix" is a moment you can actually recognize.

Who confirms the gate. Name a real person or role — my manager, the client, the requesting stakeholder. Even "myself, out loud, before I start typing a solution" counts. If nobody is named, the generated skill has nothing to stop on, and the gate quietly disappears.

Two to four tradeoffs from your own field. This is the part people rush and then regret. If you leave it blank, Claude invents generic ones like "scalability vs. simplicity" that belong to no one. Name the tensions you have actually lived through, and the skill becomes useful the second time you use it, not just the first.

Who implements next, and what you want back. Decide whether the output is a one-page brief, a ticket-ready spec, or a short walkthrough you can use in a stakeholder meeting. The skill will produce exactly that, every time.

A filled-in example: software architecture

Here is how a backend platform engineer might fill it in. Skill name: software-architecture-toolbox. Context: backend platform engineering, triggered whenever a stakeholder or teammate hands over a request to build, fix, or redesign a system, or a bug report that already assumes a fix.

Phase 1 runs the five questions, and the one-sentence problem statement is written so the requesting stakeholder can understand and confirm it. Phase 2 unlocks after that confirmation, with tradeoffs that recur in the field: build vs. buy, consistency vs. availability, coupling vs. duplication, and speed-to-ship vs. long-term maintainability. It's written for the engineer who picks up the resulting ticket. The output is prose-first with embedded structure, and the deliverable is a one-page architecture brief.

Swap in your own field and the same skeleton works. A clinical operations lead would name the nurse manager rolling it out. A marketing ops lead would trade off campaign velocity against data hygiene. The frame is portable; the specifics are yours.

This is really about identity

It's tempting to file this under productivity. I'd file it under identity. When AI makes a first draft of any solution nearly free, producing answers stops being what sets you apart. What sets you apart is being the person in the room who insists on the right question first — and who has a repeatable way of doing it.

Every time you run your toolbox, you're rehearsing who you are professionally: someone who earns the problem statement before touching the solution. Do that a hundred times and it stops being a skill you invoke. It becomes how you think.

So start small. Pick your field, name the one moment a request tends to pull you into solutioning too early, choose who confirms the gate, and write the prompt. Then run it on a real request this week — and notice how often the first problem statement turns out to be wrong.