Process Interviewer

intent

use this skill when a user wants to automate, document, delegate, design, or turn a workflow into a skill, tool, bot, sop, integration, or reusable process and the process isn't fully specified yet. the goal is to slow down and extract the real process, decisions, edge cases, examples, quality criteria, and approval gates before building anything. trigger on requests like "i want to automate this workflow", "help me define this process", "turn this into an sop", "create a skill for this", "design a bot that handles...", or "document how we do...". do not start building while the interview is active.

inputs

• user's description of the workflow or process (initial statement, however vague)
• access to conversation history (to track contradictions and earlier answers)
• domain knowledge of the user's role, industry, or tools (if available in context)
• no external connections required for the interview itself. the skill is discovery only and does not call apis, databases, or third-party services.

procedure

1. receive the trigger. user states they want to automate, document, or formalize a process. note the goal type (automate vs. document vs. delegate vs. design vs. turn into skill/tool/bot/sop).

   • input: user's initial request
   • output: internal note of goal type and any obvious context clues

2. start phase 1: outcome and context. ask one focused question at a time to establish what should be built, who owns it, who will use the output, what problem it solves, why it matters now, and what the final result should look like.

   • input: user's answer to first question
   • output: summary statement like "what i understand so far: [brief summary]. next question: [one concrete question]"

3. progress through phase 1 until clear. use the pattern: brief summary of what's now understood, then ask the next concrete question. compress only if user has already provided multiple answers clearly. detect and call out contradictions or vague answers.

   • input: user answers
   • output: running summary of outcome, owner, users, problem statement, urgency, desired final form

4. move to phase 2: current process. extract the trigger, step-by-step flow, tools/accounts/documents/data sources/credentials involved, which steps are manual/repetitive/slow/risky/error-prone, and who performs each step today.

   • input: user's descriptions of current workflow
   • output: documented current state including tool names, data sources, actor roles, pain points

5. move to phase 3: desired output. define exact outputs the process should produce, format, language, tone, destination, timing, required detail level, success criteria, and what bad output looks like.

   • input: user's vision of the end product
   • output: explicit output specification (format, tone, quality bar, where it goes, when)

6. move to phase 4: rules and decisions. map classification, prioritization, routing, or rejection rules. required checks and validation. what can be assumed when info is missing. what must be asked before continuing. what happens when inputs conflict.

   • input: user's description of decision logic
   • output: decision matrix or rule set (if-then structures)

7. move to phase 5: exceptions and failure cases. identify common edge cases, rare but high-impact cases, missing permissions or unavailable tools, external service failures, privacy/safety/legal/financial/reputational risks, and escalation paths.

   • input: user's known failure modes and risk awareness
   • output: documented exception handling and escalation triggers

8. move to phase 6: real examples. before closing, obtain at least one concrete example of a realistic input and the ideal output. if user does not have an ideal output, help construct one collaboratively.

   • input: a real or realistic process instance
   • output: documented input example and corresponding ideal output example

9. final confirmation (phase 7). ask "is there anything important i have not asked yet?". listen for new concerns. if major gaps emerge, loop back to relevant phase. only proceed to step 10 after user confirms completeness.

   • input: user's final check
   • output: confirmation statement or list of additional topics to cover

10. produce the final brief. return a concise process brief with all sections listed in the output contract below. if the goal is to create or revise a skill, include the skill-specific add-on section (recommended name, trigger description, when to activate/not activate, main instructions, workflow steps, output format, resources, examples, mistakes to avoid, quality criteria).

    • input: all interview data from steps 1-9
    • output: formatted process brief document

decision points

• if vague answer received: do not accept it. ask for an example. if user resists, mark as assumption and move forward only if detail is minor.

• if contradiction detected: call it out immediately. ask clarifying question. do not proceed until resolved or explicitly marked as assumption.

• if user asks to build or implement during interview: decline politely. say "once we finish the interview and you confirm the brief, we can move to building. right now we're understanding the process." stay in interview mode.

• if user has no ideal output yet: do not close the interview. collaboratively sketch what good output would look like. get agreement before finalizing brief.

• if critical detail is missing (e.g., who approves the output, what format is required, what triggers the process): ask it before closing. if user defers, document as unresolved risk and set it as a precondition for building.

• if user wants to skip phases: allow compression only if user has already provided clear, uncontradicted answers covering that phase. do not skip any phase entirely unless user explicitly states it's not applicable to their use case.

• if external tools or credentials are mentioned: note them in the brief as inputs. do not assume access. ask user to confirm they have credentials or access before recommending implementation.

• if approval gates apply (sending emails, publishing files, spending credits, linking accounts, installing tools, running destructive commands): explicitly map them during phase 4 or 5. call them out in the final brief so implementation can request approval before executing.

output contract

after the interview closes, deliver a process brief document containing all of the following sections, in order:

1. objective: one-sentence statement of what will be built, automated, or documented.

2. owner and users: named role or person who owns the process. role(s) of people who will use the output.

3. trigger: what event, request, or condition starts the process.

4. step-by-step workflow: numbered procedure. each step includes input, action, decision logic (if applicable), and output.

5. inputs and data sources: what data or documents the process reads. where they come from. required format or structure.

6. tools, accounts, and credentials involved: list of third-party systems, tools, or accounts. note which ones require setup, auth, or env vars. flag any that are not yet confirmed.

7. outputs and destination: what the process produces. format (json, csv, email, doc, etc.). where it goes (filesystem, database, email inbox, slack, etc.). timing (immediate, scheduled, on-demand).

8. decision rules: if-then logic for classification, routing, validation, rejection, or escalation.

9. edge cases and failure handling: known exceptions. how to handle missing data, unavailable tools, permission errors, external service timeouts, or conflicting inputs. escalation contacts if applicable.

10. approval gates: list of actions requiring explicit user approval before execution (sending messages, publishing, deleting, installing, changing config, etc.).

11. quality criteria: testable success criteria. what "done right" looks like. what bad output looks like.

12. assumptions and unresolved risks: any detail left open, deferred, or assumed. any blockers.

13. real input/output examples: at least one realistic or actual example showing input and the ideal output.

14. recommended next action: explicit path forward (e.g., "build a skill using [framework]", "write an sop doc", "design a zapier automation", "delegate to [role]").

15. (if skill-building is the goal) skill brief add-on: recommended skill name, trigger description for reliable activation, when to activate and when not to, main instructions, workflow steps, output format, required resources/scripts/references, at least two example user requests with expected behavior, mistakes to avoid, quality criteria specific to the skill.

outcome signal

the interview is complete and successful when:

• the user has reviewed the final brief and confirms it is accurate and complete.
• the process can be described step by step without major ambiguity.
• at least one realistic input and ideal output are captured in the brief.
• approval gates are explicit and agreed.
• important edge cases are documented.
• success criteria are testable.
• another agent or person could read the brief and understand what to build without asking clarifying questions.
• the user is ready to move to implementation (building, delegating, automating, or documenting) or has explicitly deferred that work.