TutorialsHands-On: Three Prompts That Open the Process Up
Working through a customer repair ticket as the main case, three prompts in relay produce the state machine, step table, boundary list and automation assignment — with each prompt in full and the one thing to watch.
Main case: a customer repair ticket process — from one sentence to a runnable SOP.
The raw description: "A customer reports a fault in the group chat, we send someone to look at it, they write up a plan, the customer confirms and we fix it, then the customer signs off after the repair."
Both of us understand that sentence, but it is not executable. The three prompts below are the three relay stages that turn it into an executable document.
Install the Skill
The three prompts used in this lesson are packaged as a Skill. Once installed, the Agent will read the Skill first and then walk you through a real workflow step by step — the full text of each prompt is still kept in this lesson, so you can read what each stage does.
Copy the prompt below to any SkillHub-compatible Agent to install automatically:
First check whether SkillHub is installed. If not, follow https://skillhub.cn/install/skillhub.md to install SkillHub (CLI only), then install the [AI Workflow Breakdown](https://skillhub.cn/team-skills/workflow-decomposition) skill. If already installed, directly install the [AI Workflow Breakdown](https://skillhub.cn/team-skills/workflow-decomposition) skill.Once installed, use the prompt below to let the Agent first understand the Skill, then execute it step by step:
Read this file — it is a skill. Analyze what steps it contains, what the standard is for each step, and how I should work with you.How the three prompts relate
Prompt A: let AI do the first breakdown
It produces the state machine, step table and data flow — turning spoken description into structure. This stage does not probe boundaries; it only builds the trunk.
Prompt B: let AI find the boundary cases you missed
Hand it A's output; it plays QA and sweeps six classes of gaps, sorted by severity. This stage is dedicated to "what if".
Prompt C: label the automation split
It judges each step as fully automated / semi-automated / manual and ranks the three most worth doing first. Only here do tools and investment come into play.
The three prompts must run in order. Skip A and ask B, and AI has nothing to check. Skip B and ask C, and you will label a set of leaky steps "fully automated" — amplifying the risk rather than removing it.
Prompt A: the first breakdown (state machine + step table)
When to use it: you only have a spoken description, or you yourself are unsure what is missing.
You are a business process analyst, skilled at breaking down vague spoken descriptions into executable workflow SOPs.
My raw process description:
[describe your process in one passage, the way you would hand it over to a new colleague]
Please output in this format:
1. State machine: list every state of this work object from creation to closure, and the transition condition between each state (as an arrow diagram)
2. Step table: one row per step, listing [step number | trigger | input | action | output | executor (person/system/AI)]
3. Data flow: what the key fields of each object are, where they are stored, who writes and who reads them
Requirements:
- No more than 10 steps
- Every decision branch must be written as "yes -> path X" and "no -> path Y"
- If there is a waiting stage (waiting for an external reply, waiting for a physical operation), mark its duration separately
Before you start, ask me the three questions you think I am most likely to have overlooked.The one thing to watch
That final request for questions is the real output of this stage.
For a repair ticket, what AI usually asks is: how long does the customer have to confirm? What if the customer never replies? Who has the authority to declare acceptance passed? — You will most likely be unable to answer all three, or you will answer "that does not usually happen".
"That does not usually happen" is the gap. Rewrite it as a rule and the process actually exists.
What the output looks like
After running A you get three things:
| Output | Form | How to check it |
|---|---|---|
| State machine | Pending → assigned → under repair → awaiting acceptance → closed | Pick any moment and ask which state it is in — there should be exactly one answer |
| Step table | Roughly S1 to S7, one row per step | The output column of every row must have something in it |
| Data flow | Key field list plus readers and writers | Could someone else continue using only the system records? |
Prompt B: the boundary cases you missed
When to use it: A's output looks reasonably complete and you are thinking about going live.
You are an experienced QA (quality assurance) engineer, skilled at finding gaps and boundary cases in process design.
Here is the breakdown of a workflow:
[paste the output of Prompt A]
Please check the following 6 classes of boundary problems item by item, and where you find a problem give the scenario description and a suggested handling method:
1. Concurrent conflicts: what if the same record is operated on by several people at once?
2. Abnormal interruption: if a step fails, do we retry or roll back? Who notices?
3. Timeout handling: what if a step waits longer than expected? Does it need an escalation notice?
4. Missing / null values: if a key input is missing (no photo, no number), do we reject or guess?
5. State rollback: if a later stage finds an earlier mistake, can it be returned? To where?
6. Permission isolation: which steps can each role see or operate? Is there any risk of excess authority?
Output format:
| No. | Boundary type | Concrete scenario | Problem in the current process | Suggested handling |
No more than 15 items, sorted by severity.The six classes, and how each one fails
| Type | Example in a repair ticket | What happens if it is left unclear |
|---|---|---|
| Concurrent conflict | The supervisor and the customer both confirm | Duplicate dispatch, two repair technicians sent |
| Abnormal interruption | The technician arrives and the model is wrong | The record sits there and nobody knows |
| Timeout | The customer does not respond for three days | The ticket stays in "awaiting acceptance" forever |
| Missing value | The customer sent no device number | AI guesses a number and writes it into the system |
| State rollback | Wrong part discovered at acceptance | A new ticket has to be opened and the history breaks |
| Permission isolation | Can the technician see the quotation? | The quotation leaks to the customer early |
What if there are more than 15 items: have AI sort by severity and handle only the top five. For the rest, write "not handling in this version" explicitly — far safer than pretending they do not exist.
Prompt C: labelling the automation split
When to use it: after the boundaries are covered, when deciding which work AI takes and which stays with people.
You are an AI adoption consultant, skilled at judging which parts of a business process are suitable for AI to take over and which must stay with people.
Here is a complete workflow (with state machine and step table):
[paste the step table]
Please label each step:
- Fully automated: pure rule-based judgement, information handling, format conversion, template filling
- Semi-automated: AI produces a draft or suggestion, a person makes the final call or supplies information
- Manual: requires creativity, business decisions, physical operations or complex human communication
Give a one-line reason for each judgement.
Finally, output an "automation priority" recommendation: which 3 steps are most worth automating first, and why?Classification is not the point; priority is
For a repair ticket the result usually looks like this:
| Step | Level | Basis |
|---|---|---|
| Receive the report, extract device number and fault description | Fully automated | Information handling, clear inputs and outputs |
| Dispatch (match technician by area and trade) | Fully automated | Rules can be encoded |
| On-site inspection and repair plan | Manual | Physical work plus on-site judgement |
| Quotation and customer confirmation | Semi-automated | AI drafts the quotation note, a person confirms the amount |
| Repair complete, photo upload | Manual | Physical work |
| Customer acceptance and closure | Semi-automated | AI checks the materials are complete, exceptions go to a person |
Do not mistake "easiest to automate" for "should be done first". The criterion is payoff — which step, once automated, saves the most manual time and removes the most arguing. For repair tickets the usual first move is "receive the report + dispatch", because it is the compulsory entry point of every run.
The demo material
Paste this fuller description live to reproduce the classroom effect:
A customer says in the group chat that a device is broken. We send a technician on site, they produce a repair plan and a quotation, the customer confirms and we repair it, then we photograph the result and post it in the group, and once the customer says it is fine we close the ticket.
Then check yourself: could you answer the questions AI asked? Which of the six boundary classes hit? Do you agree with the automation priority?
Classroom note: anonymise before practising with a real case — replace customer names, device numbers and prices with placeholders. The process structure is unaffected by sensitive information, but what you send out cannot be taken back.
Key points from this lesson
| Remember this | Because |
|---|---|
| The three prompts are a relay, not a choice | Without A's structure, B has nothing to check; without B's gap-filling, C amplifies risk |
| A's value lies in that final question | It surfaces what you did not know you had left unsaid |
| B handles only the top five severe problems | Turning a long list into "not handling" is safer than pretending |
| C's priority output matters more than the levels | Automating everything at once usually lands nothing |
| Anonymise practice material first | The process structure is not sensitive, but what you send out cannot be taken back |
The Groundwork: Four Concepts and One Formula
State machine, data flow, routing rules and automation boundary in plain language — then the heart of the lesson, the six-step breakdown formula, unrolled step by step.
Take-Home Practice: Five Templates and the Red Lines
Five prompt templates ordered by when you use them, two blank tables you can use immediately, three general red lines and two specific to this lesson.