@ericrisco/rsc 0.1.37 → 0.1.39

package/README.md

@@ -12,7 +12,7 @@
   ██    ██   ███████     ███████ 
 ```
 
-# `rsc` — 243 agent skills, one CLI, zero bloat
+# `rsc` — 248 agent skills, one CLI, zero bloat
 
 **A self-recommending skill catalog for 17 coding assistants** — Claude Code,
 Codex, GitHub Copilot, Cursor, Gemini, Windsurf, Cline, Antigravity, Zed and more.
@@ -243,7 +243,7 @@ just asks in plain language.
 
 ## The catalog
 
-244 skills, grouped by what you're trying to do. Click any skill to read its
+249 skills, grouped by what you're trying to do. Click any skill to read its
 `SKILL.md`. It fires on its own when a task matches.
 
 ### 🧭 Core & control plane
@@ -306,6 +306,12 @@ Each with a `02-DOCS` feedback loop that learns from your own results. `remotion
 
 [stripe](skills/stripe/) · [email-connector](skills/email-connector/) · [google-workspace](skills/google-workspace/) · [notion-connector](skills/notion-connector/) · [whatsapp-telegram](skills/whatsapp-telegram/) · [automation-flows](skills/automation-flows/) · [api-connector-builder](skills/api-connector-builder/) · [webhooks](skills/webhooks/) · [data-scraper](skills/data-scraper/) · [spreadsheet-ops](skills/spreadsheet-ops/) · [calendar-scheduling](skills/calendar-scheduling/) · [document-processing](skills/document-processing/) · [e-signature](skills/e-signature/)
 
+### ⚙️ Automation
+
+Operate the big automation platforms **programmatically or via MCP** — create and manage automations *dynamically*, not just design them on a canvas. `automation-strategy` decides whether / what / which platform; the platform skills drive the live REST API or MCP server (harness connectors ship for each). Complements `automation-flows` (visual design + importable workflow JSON).
+
+[automation-strategy](skills/automation-strategy/) · [n8n](skills/n8n/) · [make](skills/make/) · [zapier](skills/zapier/) · [power-automate](skills/power-automate/)
+
 ### 📊 Data & analytics
 
 [analytics](skills/analytics/) · [dashboard](skills/dashboard/) · [kpi-framework](skills/kpi-framework/) · [reporting](skills/reporting/) · [ab-testing](skills/ab-testing/) · [forecasting](skills/forecasting/) · [data-cleaning](skills/data-cleaning/) · [business-intelligence](skills/business-intelligence/)

package/manifest.json

@@ -1,7 +1,7 @@
 {
-  "version": "0.1.37",
+  "version": "0.1.39",
   "counts": {
-    "skills": 244
+    "skills": 249
   },
   "skills": [
     {
@@ -302,16 +302,49 @@
         "integrations"
       ],
       "recommends": [
+        "automation-strategy",
+        "n8n",
+        "make",
+        "zapier",
+        "power-automate",
         "webhooks",
         "api-connector-builder",
+        "error-handling",
         "stripe",
         "notion-connector",
         "google-workspace",
-        "whatsapp-telegram",
-        "error-handling"
+        "whatsapp-telegram"
       ],
       "profiles": []
     },
+    {
+      "id": "automation-strategy",
+      "description": "Use when deciding whether a process is worth automating, choosing an automation platform, sizing ROI / build-vs-buy, designing an automation strategy, or diagnosing why a fleet of automations keeps breaking — the discipline layer that runs BEFORE anyone builds. Triggers: 'should we automate this?', 'is this worth automating', 'n8n vs Make vs Zapier vs Power Automate — which do we pick', 'custom script or no-code platform', \\\"what's the ROI on automating X\\\", 'design our automation strategy', 'our automations keep breaking', 'automating this cost more than it saved', '¿merece la pena automatizar esto?', 'qué plataforma de automatización elegimos'. NOT building the flow on a platform (design + importable artifact is automation-flows; driving a live platform API/MCP is the n8n / make / zapier / power-automate skills), NOT a typed API client with auth/pagination/backoff (api-connector-builder), NOT the inbound endpoint that receives webhook events in your app (webhooks).",
+      "tags": [
+        "automation",
+        "strategy",
+        "roi",
+        "build-vs-buy",
+        "platform-selection",
+        "orchestration",
+        "idempotency",
+        "n8n",
+        "make",
+        "zapier",
+        "power-automate"
+      ],
+      "recommends": [
+        "automation-flows",
+        "n8n",
+        "make",
+        "zapier",
+        "power-automate"
+      ],
+      "profiles": [
+        "core",
+        "full"
+      ]
+    },
     {
       "id": "aws-essentials",
       "description": "Use when standing up the core AWS surface a small product needs — create a private S3 bucket for uploads, provision an encrypted RDS Postgres, choose ECS Fargate vs EC2 for a container, put CloudFront in front of S3, write or tighten an IAM policy, or harden a fresh account (root MFA, no long-lived keys). Triggers: 'set up an S3 bucket for user uploads', 'this role has AdministratorAccess, scope it down', 'spin up Multi-AZ Postgres on RDS', 'my bucket is public and I don't know why', 'this role can do everything', 'I can't encrypt RDS now', 'Fargate or EC2 for a low-traffic app', 'monta un bucket S3 privado', 'permisos mínims a IAM', 'posa CloudFront davant del bucket'. NOT the CI pipeline that ships your container (that is deployment), NOT app-code access-control review (that is secure-coding).",
@@ -2655,6 +2688,30 @@
       ],
       "profiles": []
     },
+    {
+      "id": "make",
+      "description": "Use when operating Make.com (formerly Integromat) programmatically — driving its REST API v2 or the Make MCP server from code or an agent to create, read, update, activate, run, clone, or delete scenarios, connections, hooks, and data stores. Triggers: 'create a Make scenario via the API', 'export a scenario blueprint, mutate it, and push it back', 'start/stop/run a Make scenario from a script', 'clone this Integromat scenario into another team', 'connect the Make MCP server so an agent runs my scenarios as tools', 'my valid Make API token returns an auth error' (zone trap), 'automatiza escenarios de Make.com desde la API'. NOT designing what the flow should do — trigger, branching, mapping, dedup, error path (automation-flows), NOT choosing Make vs n8n vs Zapier by billing model (automation-strategy), NOT operating n8n / Zapier / Power Automate (their skills), NOT a generic typed REST client with pagination/backoff (api-connector-builder) or an inbound webhook receiver in your own app (webhooks).",
+      "tags": [
+        "make",
+        "integromat",
+        "automation",
+        "scenarios",
+        "blueprint",
+        "mcp",
+        "no-code",
+        "api",
+        "workflows"
+      ],
+      "recommends": [
+        "automation-flows",
+        "automation-strategy",
+        "api-connector-builder",
+        "webhooks"
+      ],
+      "profiles": [
+        "full"
+      ]
+    },
     {
       "id": "market-research",
       "description": "Use when you need a defensible picture of a MARKET as a whole — sizing it with TAM/SAM/SOM, cutting it into reachable segments, and proving demand is real and moving — with a dated source behind every number. Triggers: 'how big is the market for X', 'size this market', 'what's our TAM', 'is there real demand for this', 'who are the segments', 'where's the beachhead', 'sanity-check this TAM before the raise', 'top-down or bottom-up', '¿qué tamaño tiene el mercado de X', 'calcula el TAM', 'hay demanda real para esto', 'quina mida té aquest mercat'. NOT profiling specific named rivals and their moves (that is competitor-watch), NOT building a named list of accounts to sell to (that is lead-gen).",
@@ -2858,6 +2915,28 @@
       ],
       "profiles": []
     },
+    {
+      "id": "n8n",
+      "description": "Use when operating a live n8n instance programmatically — driving its public REST API (`{host}/api/v1`, `X-N8N-API-KEY`) or the n8n-mcp server to create, validate, test, activate/deactivate, list, update, or delete workflows and read executions, on self-host or `*.app.n8n.cloud`. Triggers: 'deploy this workflow to my n8n over the API', 'push my workflow JSON to n8n with curl', 'I set active:true in the create call but it stays inactive', 'connect n8n-mcp / n8n_create_workflow to Claude', 'validate and autofix my n8n workflow', 'run an n8n workflow by id from a script', 'delete a workflow via the API', 'automatiza n8n por API', 'desplega el workflow a n8n.cloud'. NOT designing the flow's trigger-step-error logic or hand-building the importable workflow JSON (that is automation-flows), NOT operating Make / Zapier / Power Automate (their own skills), NOT a typed API client with auth+pagination+retry (api-connector-builder), NOT the inbound webhook receiver in your own app (webhooks).",
+      "tags": [
+        "n8n",
+        "automation",
+        "workflows",
+        "mcp",
+        "rest-api",
+        "no-code",
+        "integrations"
+      ],
+      "recommends": [
+        "automation-flows",
+        "automation-strategy",
+        "api-connector-builder",
+        "webhooks"
+      ],
+      "profiles": [
+        "full"
+      ]
+    },
     {
       "id": "neon",
       "description": "Use when you picked Neon (serverless Postgres) and need to connect it correctly from a serverless/edge runtime, wire database branching into dev/preview/CI, or stop getting burned by scale-to-zero cold starts and pooler limits — code imports @neondatabase/serverless, DATABASE_URL points at *.neon.tech, or you must choose HTTP neon() vs WebSocket Pool. Triggers: 'connect to Neon from a Cloudflare Worker / Vercel edge', 'too many connections from my serverless function', 'first request after idle is slow' (scale-to-zero cold start), 'which connection string for migrations vs app queries', 'a database branch per pull request', 'pooled vs direct -pooler endpoint', 'conexión serverless a Postgres en Neon', 'branca de base de dades per cada PR'. NOT generic Postgres schema/index/EXPLAIN/RLS/migration engine work (that is postgresdb).",
@@ -3262,6 +3341,30 @@
       ],
       "profiles": []
     },
+    {
+      "id": "power-automate",
+      "description": "Use when operating Microsoft Power Automate cloud flows programmatically — creating, enabling, updating, listing or deleting flows through the Dataverse Web API (the workflow table, category 5) with Entra ID / OAuth2 auth, or reading action-level run history via the third-party FlowStudio MCP. Triggers: 'create a Power Automate cloud flow with the Dataverse API', 'enable my flow by code / set statecode to 1', 'why can't I create or edit a My Flow programmatically', 'PATCH the workflow clientdata', 'automatizar el despliegue de un flujo de Power Automate desde código'. NOT designing the flow or authoring its definition (automation-flows), NOT choosing a platform by billing model (automation-strategy), NOT a generic typed REST client with auth/pagination/backoff (api-connector-builder), NOT the endpoint receiving an HTTP-trigger POST in your app (webhooks), NOT scripting Microsoft 365 / Graph mail & calendar directly (no first-party skill — api-connector-builder, or google-workspace).",
+      "tags": [
+        "power-automate",
+        "dataverse",
+        "microsoft",
+        "flows",
+        "entra",
+        "oauth",
+        "mcp",
+        "m365",
+        "automation"
+      ],
+      "recommends": [
+        "automation-flows",
+        "automation-strategy",
+        "api-connector-builder",
+        "webhooks"
+      ],
+      "profiles": [
+        "full"
+      ]
+    },
     {
       "id": "presentations",
       "description": "Use when building a presentation deck — a pitch deck, sales deck, product/keynote talk, investor deck, board/QBR review, or a leave-behind one-pager — and you need a stunning, on-brand result exported to PDF and/or an editable PPTX. Covers two production pipelines: design-led Markdown decks (Marp/Slidev themed from the project's design tokens, exported to PDF + PPTX) and native editable PowerPoint via python-pptx (masters, layouts, native charts, tables, speaker notes). Grounds copy in the brand study and visuals in the design tokens; defers the WORDS to `marketing` and the visual system to `design`. Triggers: 'make a deck', 'build a pitch/sales/investor deck', 'slides for my talk', 'turn this doc into slides', 'export to PowerPoint/PPTX', 'Marp', 'Slidev', 'python-pptx', 'keynote deck', 'one-pager'. NOT a video skill (motion is used with restraint, not as the medium).",
@@ -5037,6 +5140,29 @@
         "design"
       ],
       "profiles": []
+    },
+    {
+      "id": "zapier",
+      "description": "Use when operating Zapier from an agent through the official hosted Zapier MCP server — Bearer-key connect, then discover an app's actions, enable one, and invoke a read or write action (or fire a Zap Catch Hook trigger) across 9,000+ apps like Slack, Gmail, Notion, HubSpot by natural language. Triggers: 'connect Zapier MCP to Claude/Cursor', 'run a Zapier action to post to Slack / create a HubSpot contact', 'let my agent search my Gmail through Zapier', 'invoke Zapier actions from my tool', 'how many tasks does a Zapier MCP call cost', 'ejecuta una acción de Zapier desde el agente', 'connecta Zapier MCP al meu agent'. NOT programmatically creating/reading/updating/deleting your own Zaps — Zapier has NO public API for that on a normal account, so say so and route to n8n or make, which have full workflow CRUD APIs. NOT deciding what a flow should be or its error/dedup design (that is automation-flows). NOT a SaaS vendor embedding Zapier via the Partner/Workflow API (rare; see references).",
+      "tags": [
+        "zapier",
+        "mcp",
+        "automation",
+        "integrations",
+        "no-code",
+        "actions",
+        "workflows"
+      ],
+      "recommends": [
+        "automation-flows",
+        "automation-strategy",
+        "n8n",
+        "make",
+        "api-connector-builder"
+      ],
+      "profiles": [
+        "full"
+      ]
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ericrisco/rsc",
-  "version": "0.1.37",
+  "version": "0.1.39",
   "description": "Eric Risco's agent-skills catalog as a granular, self-recommending CLI installer.",
   "type": "module",
   "bin": {

package/scripts/lib/domains.js

@@ -12,6 +12,7 @@ export const DOMAINS = [
   { title: 'Market & brand', ids: ['marketing', 'seo-geo', 'content-engine', 'social-publisher', 'brand-voice', 'brand-identity', 'newsletter', 'landing-copy', 'ads', 'article-writing', 'case-studies', 'video-shorts', 'podcast', 'market-research', 'competitor-watch', 'press-kit', 'community', 'webinar', 'review-management'] },
   { title: 'Grow a channel (YouTube / TikTok / Reels / LinkedIn / Medium)', ids: ['youtube-api', 'youtube-strategy', 'youtube-ideation', 'youtube-thumbnails', 'youtube-packaging', 'remotion-video', 'tiktok-api', 'instagram-api', 'shortform-strategy', 'shortform-ideation', 'shortform-packaging', 'shortform-editing', 'linkedin-api', 'linkedin-strategy', 'linkedin-content', 'linkedin-carousels', 'linkedin-outreach', 'medium-writing', 'medium-publishing', 'medium-strategy'] },
   { title: 'Connect & automate', ids: ['stripe', 'email-connector', 'google-workspace', 'notion-connector', 'whatsapp-telegram', 'automation-flows', 'api-connector-builder', 'webhooks', 'data-scraper', 'spreadsheet-ops', 'calendar-scheduling', 'document-processing', 'e-signature'] },
+  { title: 'Automation platforms', ids: ['automation-strategy', 'n8n', 'make', 'zapier', 'power-automate'] },
   { title: 'Data & analytics', ids: ['analytics', 'dashboard', 'kpi-framework', 'reporting', 'ab-testing', 'forecasting', 'data-cleaning', 'business-intelligence'] },
   { title: 'AI — build it in', ids: ['building-agents', 'rag', 'embeddings-search', 'prompt-engineering', 'llm-pipeline', 'agent-eval', 'chatbot', 'ai-media', 'replicate-images', 'structured-extraction', 'agent-safety', 'cost-tracking'] },
   { title: 'AI — run it on', ids: ['replicate', 'runpod', 'modal', 'huggingface', 'ollama', 'together-fireworks', 'fal'] },

package/scripts/lib/recommend.js

@@ -21,6 +21,11 @@ const OUTCOMES = {
   unreal: 'Your game (Unreal)',
   'game-design': "Design a game that's fun",
   'fable-operator': 'Reason it through, reliably',
+  'automation-strategy': 'Decide what to automate',
+  n8n: 'Automate with n8n (API/MCP)',
+  make: 'Automate with Make (API/MCP)',
+  zapier: 'Automate with Zapier (MCP)',
+  'power-automate': 'Automate with Power Automate',
 };
 
 export function hasOutcome(id) {

package/skills/automation-flows/SKILL.md

@@ -2,7 +2,7 @@
 name: automation-flows
 description: "Use when building or fixing a no-code automation on n8n, Make, or Zapier — wiring a trigger to multi-app steps with branching, data mapping, retries, and an error path, or choosing the platform by its billing model. Triggers: 'wire up a Zap / Make scenario / n8n workflow that does X when Y happens', 'new Stripe payment → Notion row → Slack message in n8n', 'my Zap keeps failing silently, add error handling and retries', 'should I use Make or Zapier for 50k runs a month', 'my automation bill exploded', 'give me the JSON to import into n8n', 'automatiza esto en Make sin código', 'munta un workflow a n8n amb gestió d'errors', 'por qué se me dispara el Zap dos veces'. NOT writing a typed API client in code with auth/pagination/backoff (that is api-connector-builder), NOT building the inbound endpoint that receives and verifies webhook events in your own app (that is webhooks), NOT scripting one vendor's SDK directly (that is stripe / notion-connector / google-workspace / whatsapp-telegram)."
 tags: [automation, n8n, make, zapier, no-code, workflows, error-handling, integrations]
-recommends: [webhooks, api-connector-builder, stripe, notion-connector, google-workspace, whatsapp-telegram, error-handling]
+recommends: [automation-strategy, n8n, make, zapier, power-automate, webhooks, api-connector-builder, error-handling, stripe, notion-connector, google-workspace, whatsapp-telegram]
 profiles: []
 origin: risco
 ---

package/skills/automation-strategy/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: automation-strategy
+description: "Use when deciding whether a process is worth automating, choosing an automation platform, sizing ROI / build-vs-buy, designing an automation strategy, or diagnosing why a fleet of automations keeps breaking — the discipline layer that runs BEFORE anyone builds. Triggers: 'should we automate this?', 'is this worth automating', 'n8n vs Make vs Zapier vs Power Automate — which do we pick', 'custom script or no-code platform', \"what's the ROI on automating X\", 'design our automation strategy', 'our automations keep breaking', 'automating this cost more than it saved', '¿merece la pena automatizar esto?', 'qué plataforma de automatización elegimos'. NOT building the flow on a platform (design + importable artifact is automation-flows; driving a live platform API/MCP is the n8n / make / zapier / power-automate skills), NOT a typed API client with auth/pagination/backoff (api-connector-builder), NOT the inbound endpoint that receives webhook events in your app (webhooks)."
+tags: [automation, strategy, roi, build-vs-buy, platform-selection, orchestration, idempotency, n8n, make, zapier, power-automate]
+recommends: [automation-flows, n8n, make, zapier, power-automate]
+profiles: [core, full]
+origin: risco
+---
+
+# Automation strategy — decide whether, where, and how before anyone builds
+
+This is the discipline layer of the automation suite. It answers three questions that come *before* the first node is wired: **should this be automated at all?**, **on what platform, and is a platform even the right tool vs code?**, and **what orchestration guarantees does every automation have to meet so the fleet doesn't rot?** No platform API, no importable JSON, no code lives here — the moment the decision is made, you route to the skill that builds it.
+
+Building the flow (design + importable artifact) → `../automation-flows/SKILL.md`. Driving a specific platform's live API/MCP → `../n8n/SKILL.md`, `../make/SKILL.md`, `../zapier/SKILL.md`, `../power-automate/SKILL.md`. A typed API client in code → `../api-connector-builder/SKILL.md`. Receiving webhooks in your own app → `../webhooks/SKILL.md`.
+
+Every fact about pricing and platform capability below moves fast. Treat the `≈` figures as hedges and re-check the vendor page at author time; the honest limits (Zapier can't create Zaps via public API; Power Automate can't create end-user "My flows" cleanly via API) are called out where they matter and expanded in the references.
+
+## 1. Should you automate at all?
+
+Most "we should automate this" instincts are wrong — not because automation is bad, but because the process underneath isn't ready, or the payoff isn't there. Gate on four factors, all of them, before writing a line:
+
+- **Frequency** — how many times per week/month does this run? A once-a-quarter task rarely earns its maintenance cost.
+- **Time saved per run** — minutes of human toil removed each time. Two minutes × 1,000 runs beats an hour × 3.
+- **Error rate of doing it by hand** — high manual error rate (typos, missed steps, missed SLAs) is often a bigger win than the time saved. Automation's real product is *consistency*, not just speed.
+- **Stability of the process** — how often do the steps, the systems, or the rules change? An unstable process is the one thing that turns automation into a liability.
+
+Rough gate: automate when it is **frequent AND stable AND** either saves meaningful time-per-run *or* removes a costly manual error rate. If it's frequent but unstable, or high-value but requires judgment on every run, do not automate yet — see below. Full scoring rubric with worked numbers: `references/automate-decision-and-roi.md`.
+
+### The trap: automating a broken or unstable process
+
+Automating a bad process just makes you produce bad output faster, and now nobody can see the badness because a machine hides it. **Fix and standardize the process first, then automate the standardized version.** If the steps aren't written down the same way twice, if it "depends", if three people do it three ways — you are not ready. Standardize on paper, run it manually a few times against the written steps, *then* encode it. Automating chaos gives you automated chaos with a maintenance bill.
+
+### Human-in-the-loop: what you deliberately do NOT fully automate
+
+Some steps should stay manual by design, wrapped in an approval gate rather than removed:
+
+- **Judgment calls** — pricing exceptions, hiring decisions, content that carries brand/legal risk, anything where "usually right" isn't good enough.
+- **Irreversible or high-blast-radius actions** — sending money, deleting data, emailing your whole list, publishing publicly, terminating accounts. Automate the *preparation*, require a human click for the *commit*.
+- **Low-frequency, high-stakes** — the payoff is small and the cost of a silent wrong run is huge.
+
+The pattern is *assisted*, not autonomous: the automation gathers, drafts, and stages; a human approves the commit. Cheap insurance against the day the automation is confidently wrong at scale.
+
+## 2. ROI and build-vs-buy
+
+### Payback math
+
+```text
+build cost      = hours to build  × loaded hourly rate
+monthly saving  = (runs/month × time saved per run × loaded rate)
+                  − monthly platform/run cost
+                  − monthly maintenance cost   ← the line people forget
+payback (months)= build cost / monthly saving
+```
+
+Two rules of thumb: if **payback > ~12 months**, the process is probably too rare or too cheap to bother; if **maintenance eats > ~30–50% of the gross saving**, you've built a pet, not a tool. Maintenance is not optional — APIs change, auth expires, edge cases surface. Budget it explicitly or the ROI is fiction. Worked examples: `references/automate-decision-and-roi.md`.
+
+### No/low-code platform vs custom code
+
+| Choose a no/low-code platform when… | Choose custom code when… |
+| --- | --- |
+| Gluing 2–8 SaaS apps with pre-built connectors | Logic is genuinely complex, algorithmic, or stateful |
+| Business owner needs to read/edit the flow | High volume where per-run platform billing dominates TCO |
+| Speed to first version matters more than control | You need version control, tests, code review, CI on the logic |
+| Volume is modest and connectors exist | The vendor has no connector and you need deep API control |
+
+The honest middle: platforms win on **time-to-first-version and readability**; code wins on **complex logic, testability, and cost at scale**. Many mature setups are hybrid — a platform orchestrates and a small custom service (or `api-connector-builder` client) does the hard part.
+
+### Total cost of ownership
+
+TCO is not the sticker price. Count: the **platform bill under your real volume and its billing unit** (this is where surprises live — see §3), build time, ongoing maintenance, the cost of an outage when it fails silently, and the switching cost if you outgrow the platform. A "free" automation that a senior engineer babysits monthly is not free.
+
+## 3. Platform selection
+
+Pick on **billing unit first** — it's the axis that dictates cost at scale, and choosing on familiarity instead is the classic 10× mistake. Then filter on data residency, ecosystem, programmatic maturity, and portability. This is a routing decision: once chosen, hand off to that platform's skill.
+
+| Axis | n8n | Make | Zapier | Power Automate |
+| --- | --- | --- | --- | --- |
+| **Billing unit** | per **execution** (whole run = 1, any # of steps); self-host = $0 | per **credit** (each module action = 1; was "operations", renamed 2025-08-27) | per **task** (every action counts) | per **user** or per **flow** (premium); bundled with many M365 plans |
+| **Best cost shape** | few long/complex flows, high volume | moderate multi-step flows | many short simple flows | teams already paying for M365 |
+| **Self-host / data residency** | **yes** — your infra, your data | no (EU/US regions only) | no | Microsoft cloud / Dataverse regions |
+| **Ecosystem fit** | technical teams, raw HTTP, code nodes | mid-market, deep per-app modules | widest app catalog (~9,000+) | **native to Microsoft 365** — Teams, SharePoint, Outlook, Dataverse |
+| **Programmatic + MCP maturity** | public REST API to CRUD workflows; community MCP; strongest for code-driven ops | management API + MCP support maturing | rich API for actions + Zapier MCP to expose actions to agents — **but no public API to create Zaps** | Flow management APIs + solutions/ARM — **but no clean public API to create end-user "My flows"** |
+| **Portability** | high — export/import JSON + self-hostable runtime | medium — blueprint export/import, but runs only on Make | low — no portable export | low — tied to MS solutions |
+
+**Routing shortcuts:** already living in Microsoft 365 → **Power Automate** (`../power-automate/SKILL.md`). Data must stay on your own infra, or high volume where execution-billing wins → **n8n** (`../n8n/SKILL.md`). Obscure app, non-technical owner → **Zapier** (`../zapier/SKILL.md`). Deep per-app modules, mid volume → **Make** (`../make/SKILL.md`).
+
+**Two capability limits to state honestly, not paper over:** you can drive Zapier's actions programmatically and via MCP, but you **cannot create a Zap through a public API** — Zap authoring is UI-only. Power Automate exposes flow *management* and solution deployment, but there is **no clean public API to author an end-user's personal "My flows"**. If a plan depends on API-creating either, the plan is wrong. Full matrix, MCP notes, and caveats: `references/platform-selection-matrix.md`.
+
+## 4. Orchestration strategy (engine-agnostic)
+
+These are the guarantees every automation must meet regardless of platform. This is the *policy*; the per-platform *recipe* lives in `../automation-flows/SKILL.md` and the platform skills. Deep dive: `references/orchestration-and-antipatterns.md`.
+
+- **Idempotency & dedup.** Delivery is at-least-once and retries replay; assume every event can arrive twice. Require a **stable dedup key** (event id / external id) checked *before* any non-idempotent write (charge, email, insert). No dedup on a non-idempotent write = duplicate charges waiting to happen.
+- **Error paths, retries & backoff.** Every automation has a defined destination for failure. Retry **transient** errors (timeouts, 429/5xx) with backoff and a cap; do **not** retry **permanent** errors (400/validation) — route them out. A flow with no error path isn't finished.
+- **Dead-letter.** After retries are exhausted, the failed item lands in a durable place a human can inspect and replay — a queue, a table, an "incomplete executions" store. Dropped-on-the-floor failures are invisible data loss.
+- **Observability & alerting.** Emit success/failure counts; put a **heartbeat on scheduled jobs and alert on silence** (a cron that stops firing is the failure you never hear about). Route alerts to a named owner, not a dead inbox.
+- **Secrets handling.** Credentials in the platform's credential store / a vault, referenced by name — never pasted inline where an export leaks them. Least privilege, and a rotation plan. Engineering detail → `../secure-coding/SKILL.md`.
+- **Versioning & environments.** Separate **dev/staging from prod**; export before you edit; keep a rollback. Changes to a live automation are production changes and deserve the same care.
+- **Avoid fan-out storms.** Cap concurrency, batch, and rate-limit. Watch for **echo loops** (flow A writes a record that triggers flow B that triggers flow A) and for a single event fanning out into thousands of downstream calls that trip rate limits or blow the bill.
+
+## 5. Anti-patterns
+
+| Anti-pattern | Why it bites | Do instead |
+| --- | --- | --- |
+| **No error path** | First API hiccup, the run dies; you learn from an angry customer | Define a failure destination + alert before shipping |
+| **Silent failure** | Failures that don't alert erode trust worse than no automation — everyone assumes it worked | Alert on failure *and* on silence (heartbeat) |
+| **No kill-switch** | When it misfires at scale, there's no fast way to stop the bleeding | Every outward-writing automation gets a documented pause/disable toggle |
+| **Over-automation** | Automating rare / low-value / judgment work costs more to maintain than doing it by hand | Gate on §1; leave judgment steps human-in-the-loop |
+| **Automating a broken process** | You produce bad output faster and hide the badness behind a machine | Standardize the process first, then encode it |
+| **Hidden single point of failure** | One personal token / one undocumented flow everyone depends on | Service accounts, documented dependencies, no personal-account glue |
+| **No owner** | Orphaned automations rot; nobody notices the break or knows how it works | Name an owner + a one-page runbook per automation |
+| **Choosing platform by familiarity** | Bill 10× higher than the right billing unit; "our automation bill exploded" | Pick by billing unit for your run shape (§3) |
+
+## Related skills
+
+- `../automation-flows/SKILL.md` — **build layer**: designs the flow and emits the importable artifact once this skill has decided *whether* and *where*. Strategy decides; automation-flows designs.
+- `../n8n/SKILL.md`, `../make/SKILL.md`, `../zapier/SKILL.md`, `../power-automate/SKILL.md` — **operate layer**: drive that platform's live API/MCP to CRUD, activate, and run. Route here after §3.
+- `../api-connector-builder/SKILL.md` — when the answer is custom code, not a platform: typed client with auth/pagination/backoff.
+- `../webhooks/SKILL.md` — when you need to *receive* events in your own app (this skill treats webhooks as triggers, it doesn't build the receiver).
+- `../secure-coding/SKILL.md` — secrets/rotation engineering behind the orchestration policy in §4.
+
+## Checklist
+
+- [ ] Ran the §1 gate: frequency × time-saved × error-rate × **stability** — and confirmed the process is standardized, not chaos being paved.
+- [ ] Identified any judgment / irreversible / high-blast-radius step and kept it human-in-the-loop with an approval gate.
+- [ ] Computed payback including **maintenance**, and confirmed it's under the rule-of-thumb ceiling.
+- [ ] Decided platform vs custom code on the build-vs-buy criteria, not on what's familiar.
+- [ ] Chose the platform by **billing unit for the real run shape**, then data residency / ecosystem / portability — and did NOT assume a capability the platform lacks (Zap creation, PA "My flows").
+- [ ] Specified the orchestration guarantees §4 requires (idempotency key, error path, dead-letter, heartbeat/alert, secrets store, dev/prod split, fan-out caps) as requirements handed to the build skill.
+- [ ] Every automation has a named owner, a runbook, and a kill-switch.
+- [ ] Routed the actual build to `automation-flows` / the chosen platform skill — no flow was built inside this skill.

package/skills/automation-strategy/evals/README.md

@@ -0,0 +1,16 @@
+# Evals — automation-strategy
+
+`cases.yaml` holds three groups. `should_trigger` covers the decisions this skill owns: whether to
+automate (with the stability trap), four-way platform selection, ROI / build-vs-buy, fleet-health
+"our automations keep breaking", ecosystem-fit selection, and TCO/over-automation post-mortems, with
+Spanish phrasing. `should_not_trigger` lists adjacent prompts routed to the sibling that owns them —
+concrete builds/artifacts → automation-flows, driving a live platform → the n8n/make skills, code
+clients → api-connector-builder, webhook receipt → webhooks, secrets engineering → secure-coding.
+`capability` is one end-to-end strategy scenario whose `must_include` rubric checks the §1 gate,
+human-in-the-loop on the irreversible step, maintenance-inclusive payback, billing-unit + ecosystem
+platform routing, the honest Zapier/Power-Automate API-creation limits, the orchestration guarantees,
+and that it defers the build (no JSON/API code emitted here).
+
+No automated runner. Score by judgement: feed each prompt to the routing layer and confirm it
+activates or routes to the listed sibling; for `capability`, have the skill produce the strategy
+recommendation and check every `must_include` item by hand.

package/skills/automation-strategy/evals/cases.yaml

@@ -0,0 +1,48 @@
+skill: automation-strategy
+
+should_trigger:
+  - prompt: "Should we automate our weekly invoice-reconciliation process? It changes a bit every month."
+    why: The core whether-to-automate decision — and the "changes every month" signals the stability trap this skill exists to catch.
+  - prompt: "n8n vs Make vs Zapier vs Power Automate — which one should we standardize on as a company?"
+    why: Platform selection across all four engines by billing model and ecosystem fit; a strategy/routing decision, not a build.
+  - prompt: "What's the ROI on automating this task, and should we build a custom script or use a no-code platform?"
+    why: Payback math plus build-vs-buy — squarely §2, before anyone builds.
+  - prompt: "Our automations keep breaking and nobody knows why. Help us design a proper automation strategy."
+    why: Fleet-health / orchestration-discipline diagnosis — missing error paths, ownership, observability across a fleet.
+  - prompt: "We're a Microsoft 365 shop. Does it even make sense to pay for Zapier, or use what we have?"
+    why: Ecosystem-fit selection (MS 365 → Power Automate) and TCO reasoning; a platform-choice decision.
+  - prompt: "¿Merece la pena automatizar esto o me sale más caro de mantener que hacerlo a mano?"
+    why: Spanish; ROI / maintenance-cost gate — the "pet not a tool" payback question.
+  - prompt: "Automating this last quarter cost us more than it saved. What did we get wrong?"
+    why: TCO / over-automation post-mortem — the maintenance-eats-the-ROI and over-automation anti-patterns.
+
+should_not_trigger:
+  - prompt: "Give me the importable n8n JSON for a webhook → Notion → Slack flow with error handling."
+    route_to: automation-flows
+    why: A concrete build/artifact request; automation-flows owns design and the importable workflow JSON.
+  - prompt: "Use the n8n API to create and activate this workflow on my instance."
+    route_to: n8n
+    why: Driving a specific platform's live API to CRUD/activate — the n8n platform skill, not the strategy layer.
+  - prompt: "Write a TypeScript client for the Acme REST API with OAuth, pagination, and exponential backoff."
+    route_to: api-connector-builder
+    why: Generic typed API client in code; that is api-connector-builder, not automation strategy.
+  - prompt: "Build the Express endpoint that receives and verifies Stripe webhook signatures."
+    route_to: webhooks
+    why: Building the inbound receiver in your own app; webhooks owns receipt, this skill treats webhooks only as triggers.
+  - prompt: "Set up the Make scenario: on new HubSpot deal, create a Trello card and email the owner."
+    route_to: automation-flows
+    why: A specific flow to build on a named platform — design goes to automation-flows, operation to the make skill; not a strategy question.
+  - prompt: "How do I rotate and store the API keys my flow uses securely in code?"
+    route_to: secure-coding
+    why: Secrets-engineering implementation detail; §4 sets the policy but secure-coding owns the how.
+
+capability:
+  - scenario: "A 30-person Microsoft 365 company asks: 'We do a manual monthly vendor-payment run — pull approved invoices, pay them, notify finance. Should we automate it, on what platform, and how do we not screw it up?' Produce the strategy recommendation."
+    must_include:
+      - "Runs the §1 gate on frequency × time-saved × error-rate × stability before recommending automation."
+      - "Flags the payment/commit step as irreversible/high-blast-radius and keeps it human-in-the-loop behind an approval gate (automate prep, human clicks to pay)."
+      - "Payback math that explicitly includes ongoing maintenance cost, not just time saved."
+      - "Recommends a platform by billing unit and ecosystem fit — notes Microsoft 365 fit points to Power Automate — and routes the build to that platform skill / automation-flows rather than building here."
+      - "States the honest limit that Power Automate has no clean public API to author end-user 'My flows' (and Zapier can't create Zaps via API), so a plan can't depend on API-creating them."
+      - "Specifies orchestration guarantees as requirements: idempotency/dedup key, error path + retry/backoff, dead-letter, heartbeat/alert to a named owner, secrets in a vault, dev/prod split, and a kill-switch."
+      - "Does NOT emit importable workflow JSON or platform API code — defers the build to automation-flows / the platform skill."

package/skills/automation-strategy/references/automate-decision-and-roi.md

@@ -0,0 +1,118 @@
+# Automate decision & ROI — the numbers behind §1–§2
+
+Depth for "should we automate this, and does it pay back?" Engine-agnostic. Once the answer is
+yes, route the build to `../../automation-flows/SKILL.md` or the chosen platform skill.
+
+## The decision scorecard
+
+Score each factor honestly. None of these is a magic threshold — they're a forcing function to
+stop you automating on vibes.
+
+| Factor | Ask | Weak signal (lean NO) | Strong signal (lean YES) |
+| --- | --- | --- | --- |
+| **Frequency** | runs per week/month | a handful per quarter | dozens+ per week |
+| **Time saved / run** | minutes of human toil removed | seconds, or "it's quick anyway" | many minutes, or a context-switch tax |
+| **Manual error rate** | how often a human gets it wrong | near-zero, low stakes | frequent, or costly when wrong |
+| **Stability** | how often steps/systems/rules change | changes most months | unchanged for many months |
+| **Toil / morale** | is it soul-crushing repetitive work | mildly annoying | actively burning out a person |
+
+**The gate:** automate when **frequent AND stable AND (meaningful time-per-run OR costly manual
+error rate)**. Instability vetoes everything else — a high-value process that changes monthly will
+cost more in rework than it saves. When in doubt, the tie-breaker is stability, then frequency.
+
+### Why stability is the veto
+
+Automation encodes *today's* process. Every change to the underlying process is now a change to
+code/config someone has to make, test, and redeploy. On a stable process that's rare. On a churning
+process it's a second job. If the process is still being figured out, keep it manual and cheap until
+it stops moving.
+
+## The unstable / broken-process trap
+
+Automating a broken process gives you **automated brokenness at higher throughput**, plus a machine
+that now obscures the brokenness from the humans who used to feel it.
+
+Sequence to do it right:
+
+1. **Write the process down** — the exact steps, inputs, decision rules, outputs.
+2. **Standardize** — if three people do it three ways, pick one way. Remove the "it depends" branches
+   or make them explicit rules.
+3. **Run it manually against the written steps** a few times. Fix the doc where reality diverges.
+4. **Only now automate** the standardized version.
+
+Smell tests that you're not ready: the steps can't be written without "usually" or "it depends";
+different people produce different outputs from the same input; the systems involved are mid-migration.
+
+## Human-in-the-loop taxonomy
+
+Keep these steps assisted, not autonomous. The automation stages the work; a human commits it.
+
+| Step type | Example | Pattern |
+| --- | --- | --- |
+| **Judgment** | pricing exception, hiring, brand/legal-sensitive content | draft + route for approval |
+| **Irreversible** | send money, delete data, terminate an account | prepare automatically, require a human click to commit |
+| **High blast radius** | email the whole list, publish publicly, mass update | stage + preview + explicit go |
+| **Low-freq / high-stakes** | quarterly filing, contract renewal | checklist-assist, human executes |
+
+Rule of thumb: if a wrong autonomous run would be expensive *and* hard to undo, insert an approval
+gate. It costs one click and buys you the day the automation is confidently wrong.
+
+## Payback math (worked)
+
+```text
+build cost      = build hours × loaded hourly rate
+gross saving/mo = runs/month × time saved per run (hrs) × loaded hourly rate
+net saving/mo   = gross saving/mo − platform cost/mo − maintenance cost/mo
+payback (months)= build cost / net saving/mo
+```
+
+**Loaded rate** = salary + overhead (benefits, tooling, management), not the bare wage — usually
+1.3–2× the wage. Use it for both build cost and time saved so the comparison is fair.
+
+### Example A — clear win
+
+- Task runs 800×/month, saves 4 min each → 53.3 hrs/month saved.
+- Loaded rate $60/hr → gross saving ≈ $3,200/month.
+- Build = 20 hrs × $60 = $1,200. Platform ≈ $30/month. Maintenance ≈ 1 hr/month = $60.
+- Net saving ≈ $3,200 − $90 = $3,110/month. **Payback ≈ 0.4 months.** Build it.
+
+### Example B — a pet, not a tool
+
+- Task runs 6×/month, saves 15 min each → 1.5 hrs/month.
+- Gross saving ≈ $90/month. Build = 25 hrs × $60 = $1,500. Maintenance ≈ 1.5 hrs/month = $90.
+- Net saving ≈ $90 − $90 = **~$0/month.** Payback = never. Don't automate; write a checklist.
+
+### The two rules of thumb
+
+- **Payback > ~12 months** → the process is probably too rare or too cheap. Reconsider.
+- **Maintenance > ~30–50% of gross saving** → you've built something that eats its own ROI. The
+  fragile-integration tax (auth expiry, API changes, edge cases) is real; if it's this high, either
+  simplify the flow or question whether it should exist.
+
+Maintenance is the line people omit and the reason ROI projections lie. Budget it explicitly.
+
+## Build vs buy (platform vs custom code)
+
+| Dimension | No/low-code platform | Custom code |
+| --- | --- | --- |
+| Time to first version | hours | days+ |
+| Readable by non-engineers | yes | no |
+| Complex/stateful/algorithmic logic | awkward, hits ceilings | natural |
+| Testability, review, CI | weak | strong |
+| Cost at high volume | per-run billing can dominate | marginal cost near zero |
+| Vendor/connector coverage | huge | you build each integration |
+| Portability / lock-in | often locked in | yours |
+
+**Hybrid is normal and often best:** a platform orchestrates the glue and human-readable flow; a
+small custom service or an `api-connector-builder` client does the one hard, high-volume, or
+algorithmic part. Don't force either extreme.
+
+## Total cost of ownership checklist
+
+- Platform bill **at your real volume, in the platform's billing unit** (tasks vs credits vs
+  executions vs seats — see the platform matrix; this is where the surprise lives).
+- Build hours (loaded).
+- Ongoing maintenance hours/month (loaded) — the honest number, not the hopeful one.
+- Cost of a silent outage: what does one undetected failure cost, and how likely is it?
+- Switching cost if you outgrow the platform (low portability = high later pain).
+- The babysitting tax: a "free" flow a senior engineer nurses monthly is not free.