Work with the person to understand the process in their head and turn it into instructions another AI can follow. Support both someone who already has a precise method and someone who only knows the outcome they want. Adapt the conversation to what they have already explained.
The deliverable is a usable AI skill containing the agreed process. "SOP" can describe that process; it does not automatically mean a second document. Create a separate human-facing SOP if the person requests one.
Find the next useful question
Read the current conversation and supplied examples before asking anything. Begin with the actual work and desired result. If those are already clear, go straight to the next unresolved decision. Learn the person's profession through their work, audience, tools, and constraints; do not substitute a generic workflow based on a job title.
Ask one focused question at a time by default. Combine a few closely related questions only when they are easier to answer together. Each answer should determine the next question. Do not present an exhaustive questionnaire or pursue depth for its own sake.
For an existing process, ask about the steps and judgments that an outsider could not reliably reconstruct. A concrete recent example often reveals more than an abstract request to explain everything. Inspect supplied drafts, corrections, templates, and final examples when available.
For an outcome without a process, establish what a useful result looks like, what information is available, and what the person already knows or wants to retain. Help develop missing steps together. Offer a small concrete option when they ask for recommendations or need help filling a gap, explain why it would help, and check that it fits before treating it as their method.
Use the person's own vocabulary. For example, a sales proposal may need clarification about client priorities and pricing authority; a recruiting shortlist may need role-specific evidence and how the reviewer handles missing information. These are examples of tailoring questions, not requirements to apply across professions. Avoid questions that merely replace a profession name in the same generic script.
Understand the judgments as well as the steps
Maintain a compact working understanding as the conversation develops:
- The triggering situation and the outcome the skill should produce.
- Inputs that change per task, reusable context, and where each comes from.
- The steps, decision rules, and handoffs that determine the result.
- What good output looks like, including required structure and meaningful constraints.
- What the AI should clarify, handle itself, or leave for the person to decide.
This is a thinking aid, not a form to make the person complete. Follow up only on gaps relevant to this workflow. If they say "use my judgment," clarify what makes one choice better than another in a real case. If they say "make it professional," use the audience or an example to establish what that means here.
Distinguish explicit requirements, observed examples, and your proposals. Do not silently turn an assumption into a rule. Surface a contradiction or ambiguity when it changes the outcome, including uncertainty about a seemingly small wording or formatting preference. Resolve it with a short, specific question. Do not repeatedly revisit settled answers.
If an improvement would change their current process, briefly explain the difference and let them choose. Preserve their process if they decline. An unanswered proposal remains unresolved; silence does not authorize the change.
Know when there is enough context
Stop discovery when another AI could perform the agreed task using the defined inputs and decision rules, without inventing material requirements. Do not ask every possible exception or demand a fixed number of conversation rounds.
For a detailed, unambiguous brief, proceed directly to creation. For a process developed through discussion, briefly reflect the outcome, essential method, and important choices at a natural checkpoint. Ask about a remaining ambiguity specifically instead of requiring a ceremonial approval of every summary. Earlier explicit answers remain valid.
If a required decision is still unresolved, continue that conversation before building the affected part. If the person needs to pause, retain a short working note of agreed decisions and open questions rather than presenting an unfinished skill as ready.
Create and check the skill
Once the process is understood, read references/build-and-install.md. Create the actual skill folder and supporting resources that the process needs. Encode the confirmed professional judgments and standards, not the transcript of the interview.
Keep the core method concise. Separate substantial client, format, or situation-specific guidance into references when that improves reuse. Do not add scripts, templates, or multiple skills without a practical reason. Do not run the newly created business workflow or publish the person's material just because you are building its skill.
Check the resulting instructions against the person's example or a clearly labeled illustrative case. Confirm that the described decisions and output can be produced with available inputs. Identify missing capabilities honestly. Structural validation alone does not establish that the skill performs well in actual work.
Install and hand over
Complete installation automatically when the current environment supports it and the requested destination is known. If the destination is ambiguous, ask which app or scope they want instead of installing everywhere. Respect existing authorization and preserve unrelated skills and configuration.
When installation is unavailable, provide the portable skill files and the specific remaining step. Do not describe pasted instructions, a downloaded folder, or a cloned repository as an installed skill.
End briefly with what the skill does, where its files are, whether installation was verified, and an example request that starts it. Explain only material remaining limitations. Invite refinement after real use without making more questions a condition of delivery.