Document a process with Claude before automating it

Define a process with Process Interviewer →

You want an AI to help you build a client-onboarding procedure, a request-handling workflow, or a template document for your practice. You phrase the request in one sentence — "automate our client request handling" — and the result, correct on the surface, systematically misses the edge case you could have mentioned if only someone had asked.

Documenting a process with Claude, before asking it to build anything, means getting asked those questions upfront rather than discovering them afterward, once the deliverable is already built and half unusable. The Process-Interviewer skill runs an interview in small batches of questions to surface a trigger, available data, decisions and an output, then delivers a plan — without building anything until that plan is approved.

This article details how that interview unfolds, what you get whether you work in Claude Code or a plain conversation, and where it deliberately stops before the build itself.

Summary

1. Why document a process before asking for a deliverable
2. How the Process-Interviewer interview unfolds
3. What you get, whatever your tool
4. Running the interview step by step
5. What Process-Interviewer does not do
6. Training to frame processes before automating them
7. Frequently asked questions

Why document a process before asking for a deliverable

A request phrased in one sentence — "automate our client request handling" — carries a clear intent but none of the concrete decisions that handling actually involves: who acts, with what information, and how a case outside the normal path gets resolved. Without those answers, Claude fills the gaps with plausible but potentially wrong assumptions, and the mismatch only shows up in use, once the document or workflow is already built.

The problem with "just automate this"

A process is not a list of tasks in order: it is a trigger, data available at that precise moment, decisions made from that data, and an output that depends on the decision reached. "Handle the request" describes none of these elements; it is a label, not a usable description. Asking directly for a deliverable built on that label is like asking someone to guess an internal policy that was never written down.

What a structured interview does that you would not do alone

Left to yourself, you will naturally describe the normal case — the one that comes to mind first — and forget the exceptions, precisely because they are rare and therefore less present in memory when writing. The interview reverses that tendency: it explicitly asks for incomplete cases, ambiguous decisions and the people involved, rather than waiting for you to think of mentioning them on your own.

How the Process-Interviewer interview unfolds

The skill runs the interview in small batches of questions rather than one block of twenty questions at once, so each answer can steer the next without overwhelming the person being interviewed. It systematically reuses answers already given in the conversation or in attached documents, instead of re-asking a question whose answer already exists elsewhere.

Small batches of questions, not an interrogation

The goal is not to collect the maximum amount of information but to make visible the decisions that would otherwise stay implicit. If a detail already appears in a supplied document, the interview reuses it and flags any contradictions, rather than asking again for information already available — a distinction that keeps the interview from turning into a mechanical questionnaire disconnected from the real context.

Connecting trigger, data, decisions and output

Every step of the process must answer four questions: what triggers it, what information is available at that moment, who decides and on what basis, and what comes out of that step to feed the next one. A properly framed process can be read back as a sequence of these four elements, with no gap where you have to guess what happens because it was never described.

What you get, whatever your tool

Process-Interviewer is one of the few skills in the catalog that works identically wherever you use it: the interview and the plan it produces are text, with no required file and no script to run. The only variable is how you keep the result once the interview is over.

A method that does not depend on a particular environment

This portability is no accident: Anthropic's official documentation on Agent Skills confirms that a skill's text content — its instructions and its output — stays available everywhere, unlike skills that depend on executed scripts or files written to disk. Process-Interviewer belongs to that first category: nothing in how it works assumes network access or the ability to write files.

Saving the plan once the interview is over

In a chat without automatic saving, explicitly ask for the plan in one copyable block at the end of the interview, rather than piecing together answers scattered across several messages. That document, reviewed and approved, is what serves as the basis for the next step — building the skill, the workflow or the template document — not the interview itself.

Running the interview step by step

Five steps structure an effective interview, whether you follow them manually or the skill drives them for you.

Step 1: Start from a real case, not a wish list of features. Describe a concrete situation you have already encountered rather than a process imagined in the abstract. A real case reveals constraints that a list of theoretical features never surfaces.

Step 2: Name the trigger and the data available at that moment. State precisely what launches the process and what is actually known at that point, without assuming information that will only arrive later in the flow.

Step 3: Describe every decision and who makes it. For each branch, name the person or role responsible and the criteria guiding their choice, rather than leaving the decision implicit in a vague phrase like "we look at it case by case."

Step 4: Cite incomplete cases and external failures. A request with no project number, a supplier who does not respond, information missing at the expected moment: these edge cases are exactly what a deliverable built without a prior interview almost always forgets.

Step 5: Have the plan reviewed by someone who actually runs the process. The final plan should be reviewed by a person who lives the process day to day, not only by whoever made the initial request — the two viewpoints rarely reveal the same blind spots.

What Process-Interviewer does not do

The skill builds nothing automatically: once the plan is delivered, building the document, workflow or skill that follows from it remains a separate step that must be explicitly requested. An interview meant only to frame a process should stop at the approved plan, without Claude carrying on to an implementation nobody asked for.

It also does not replace the business knowledge of the person being interviewed: the interview asks the right questions, but the answers come entirely from you. A process poorly understood at the outset will produce a plan that looks coherent but rests on a wrong description — review by someone who actually runs it remains the only safeguard against that risk.

In our exchanges with business owners about their automation projects, the blocker is almost never technical: it is the difficulty of writing down a process that only ever existed in the heads of two or three people, each with their own unwritten version. The interview serves as much to align those versions with each other as to prepare a deliverable.

Training to frame processes before automating them

Knowing how to run or guide this kind of interview — recognizing an edge case, surfacing an implicit decision, telling an exception apart from a design flaw — is a skill that is learned and practiced. Educasium's Master Claude training devotes modules to building skills and agents from real business processes, for profiles who have never used a terminal. For a business owner or a self-employed professional under the relevant scheme, the FIFPL covers part of the cost of a Qualiopi-certified training under the 2026 criteria set at €300/day and €900/year, with e-learning capped at 50% of the daily rate.

Frequently asked questions

Does Process-Interviewer build the workflow directly once the interview is done?

No, not unless explicitly asked. The skill's default behavior is to deliver a plan at the end of the interview and stop there; building the document, skill or automation that follows is a separate, later step that you must request once the plan has been reviewed and approved. To start that step, make an explicit request such as "build the skill from this plan" rather than assuming Claude will continue automatically.

Do I need a particular environment to use this skill?

No: the interview and the plan it produces are entirely text-based, which makes it usable in exactly the same way in Claude Code, on claude.ai, in ChatGPT or in Gemini. The only practical difference concerns saving the result — automatic in an environment with file access, manual copy-paste elsewhere. If you work outside Claude Code, ask for the plan in one copyable block at the end of the interview instead of piecing together answers scattered across several messages.

What if the interview does not ask the right questions for my field?

Supply the missing context explicitly rather than waiting for the interview to guess it: the names of the roles involved, regulatory constraints specific to your sector, an example of an edge case you have already faced. The skill works from what you give it; the more precise the real case you supply, the more relevant the following questions will be. Without that context, the interview stays generic and the final plan will need manual completion before you treat it as approved.

How long does a framing interview take with this skill?

That depends directly on the complexity of the process and the number of edge cases to cover, not on a fixed duration set by the skill. A simple process with few branches can be framed in a handful of exchanges; a process with several actors and frequent exceptions needs more back-and-forth for the final plan to stay faithful to what actually happens on the ground. Either way, plan to have someone who runs the process day to day review the plan before treating it as final.

Documenting a process before building it does not slow the project down: it avoids the rebuild — often far more costly in time — once a deliverable built on wrong assumptions turns out unusable in real use. That is exactly the role of the Process-Interviewer framing pack, which stops at the approved plan instead of guessing what was left unsaid.

Once the process is framed, comparing several ways to build it calls for a different method: our guide to deciding with Claude details how to make a choice's criteria and uncertainties visible, once the process itself is clear.

Training 100% fundable via OPCO/FIFPL. Qualiopi-certified programme. To frame your processes with AI as part of our Master Claude training, contact Educasium and specify your status (employee, self-employed, business owner) and your goal.