---
name: process-to-automation
description: Turn a described business workflow into a build-ready automation specification. Use this skill whenever someone describes a manual, repetitive process (a handoff, an approval chain, data re-entry, a recurring report) and wants to automate it, or asks for an automation spec, an n8n or Zapier workflow outline, a process map, or says 'how would I automate this' or 'this is so manual'. Trigger even when the user just narrates a painful manual process without saying the word automation, because surfacing the automation opportunity is the point.
---

# Process to Automation

## What this does and why it matters
Every manual, repetitive process is unrealized leverage. This skill reconstructs a workflow from a plain-language description and produces a structured automation specification an engineer or a no-code builder can build from, capturing the trigger, the data flow, the decision points, and the failure modes. It is the clearest demonstration of the core thesis that a 40 hour work week can produce 168 hours of output: systematize the repeatable work and reclaim the time.

## Inputs to gather
Ask only for what is missing, do not interrogate:
1. What kicks the process off (the trigger) and how often it runs.
2. The systems and tools involved (CRM, email, spreadsheets, ATS, accounting).
3. The step-by-step actions a human takes today, in order.
4. The decision points (if X then Y) and who owns them.
5. What "done" looks like and where the output lands.

## Method

### 1. Restate the current process
Play it back as a numbered sequence so the user confirms you understood it. Flag every gap you had to assume, because unstated steps are where automations break.

### 2. Classify each step
Mark each as Automate, Augment (human in the loop), or Keep manual, with a one-line reason. Not everything should be automated; judgment-heavy and low-frequency steps often should not.

### 3. Map the data
For each handoff, name the fields moving and the source and destination system. Most automation work is data plumbing, so make it explicit.

### 4. Design the target state as nodes
Each node has a name, a type (trigger, action, transform, decision, notification), the system it touches, and its inputs and outputs. This maps directly to n8n-style tools.

### 5. Order the connections
List the flow node by node so it is unambiguous to build.

### 6. Surface risks and guardrails
Rate limits, auth, error handling, duplicate prevention, and every point where a human should approve before an irreversible or external action.

## Output format
ALWAYS produce:

# Automation Spec: [Process Name]
## Current state (confirmed, with assumptions flagged)
## Automation assessment (Automate / Augment / Keep manual, per step)
## Data map (field | source | destination)
## Target-state workflow (nodes)
## Connections (in order)
## Risks and guardrails
## Effort and prerequisites (access, credentials, testing)

Node shape:
- **Node N. [Name]** | type: [trigger|action|transform|decision|notification] | system: [tool] | in: [...] | out: [...]

## Anti-patterns to avoid
- Automating a broken process instead of fixing it first.
- Automating steps that need human judgment.
- No error handling or dedupe, so the automation fails silently or doubles up.
- Skipping human approval on irreversible actions.

## Guardrails
This produces a build specification, not a deployed automation. Note where credentials, API access, and sandbox testing are required before going live. Any step that sends external communications, moves money, or deletes data must be marked as requiring human approval in the target state.

## Example
"Every form submission gets copied to the CRM, then a templated email goes out, then a task is created." The spec sets the submission as the trigger, marks CRM creation and the email as Automate, marks the task as Augment, maps the fields, and lays out trigger to create-record to send-email to create-task with a dedupe check on email.