Process to Automation

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.

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.

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.

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: [...]

• 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.

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.

"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.