morrislu-taipei/tigerai-n8n-skill-pack/code-to-workflow

Code2n8n — Code → n8n Workflow

The marquee Code2n8n skill. Input: an existing program or system (Python / TypeScript / Apps Script / Netlify Functions / Express / Flask / shell pipelines / Lambda). Output: an n8n workflow (or set of workflows) that performs the same behaviour, plus the SDD / FIELD-MAPPING / PROVENANCE / CREDITS / install docs that make it deployable, auditable, and handover-ready.

This skill encodes the methodology proven by the three case studies in this pack:

Read at least one before using this skill — they are the empirical ground truth behind every step below.

Restricted Agent mode (Portal)

Check for the host marker [PORTAL-RESTRICTED-AGENT-MODE v1] (system prompt or session context; rules in `spec/agent-restricted-mode.en.md`). No marker: this Skill applies as written. Marker present: the adjustments below override the steps they name. This text is only a hint; real enforcement is the host's tool allowlist, and the Skill's behavior here is "comply with the host's restrictions".

• Scope: the Agent only outputs workflow JSON (Layer 3 note and node notes included). It does not write files, commit, push, import into n8n, or activate. Input is what the user pastes or what host read-only tools return (names per the host); do not clone or fetch on your own.
• Step 1.5 (security audit): still runs as analysis. Put the findings in the Layer 3 note and the conversation; do not write a SECURITY-CAVEATS.md file.
• Step 5 (workflow design): unchanged, except credentials. Reference only names from the host's credentialMap. No STUB- fake credentials and no invented names. A needed credential that is not in the map gets no credentials field, and "Administrator must create: type=..., suggested name=..." goes into the node notes and the Layer 3 "Credentials to be added".
• Step 6 (3-layer funnel): Layer 2 (local n8n REST import roundtrip, _n8n_import_test.mjs) is not available; the Agent has no n8n access and no shell. Use the host's static check tool as the substitute, at most N rounds (set by the host), and say plainly that Layer 2 and Layer 3 are pending. The line "do not declare done until Layer 1 + 2 both pass" means here: do not claim done, passed, or ready; restate the host's result as it is.
• Step 7 (documentation outputs) and hard rule 7: no document files are written; active stays false. Put the essentials (portability verdict, known gaps, credentials needed) in the Layer 3 note, and offer longer SDD-style text in the conversation only if the user asks.
• Closing blocks: the security scan result is a faithful restatement of the host's check result, or "Security scan not run: <reason>".

When to trigger

Hard rules

1. Never strip the upstream license / attribution. Code2n8n is a derivative-work pattern. Always copy LICENSE, write a CREDITS.md, and record the attribution chain (upstream → derivative changes → this pack). The MIT case study (line-ai-customer-service-onprem) is the template.
2. Scrub secrets before commit. Real API keys, JWTs, OAuth tokens, hard-coded passwords in .env* / docker-compose.yml / config.*.json / source code must be replaced with env-var placeholders. Do a grep -rn "sk-[a-zA-Z0-9]\{20,\}\|ghp_\|AIza\|password.*=.*[a-zA-Z0-9]\{8,\}" pass before staging.
3. Audit auth + injection before calling the port "enterprise-grade". Most AI-coded POCs ship with /me-always-returns-true style auth stubs, plaintext passwords, missing middleware, and identifier-injection patterns (raw req.body keys concatenated into SQL). The real-world example `line-ai-customer-service-onprem` has all of these — see its `SECURITY-CAVEATS.md`. If you find these and don't fix them, you MUST publish a SECURITY-CAVEATS.md (or equivalent), downgrade any "enterprise-ready" / "production" wording, and tell the reader exactly what to harden before deploying. Disclose, don't silently patch — silent patching misrepresents the case study and lets the next porter inherit the same blind spot.
4. Don't claim n8n can replace a UI. If the input has a React SPA / admin dashboard / interactive console, n8n cannot host that natively. Use the frontend portability decision tree (Step 4 below) and document the choice honestly in the SDD.
5. Preserve fidelity. If the upstream has "10 default tasks" / "14 dropdown choices" / "5 reminder offsets", the port keeps those exactly — and PROVENANCE.md maps each preserved item to the upstream line number, pinned to a specific commit SHA.
6. Always validate before declaring done. Run the 3-layer funnel (Step 6 below) — especially the local n8n REST import. Lint passing alone is not enough.
7. Tag local imports. Any workflow imported into the user's local n8n must carry [Claude YYYY-MM-DD] name prefix + claude-import-YYYY-MM-DD tag + active: false. See the memory note n8n-local-import-marking.
8. Security review is a real gate, not a caption. Run `n8n-security-governance` during Step 1.5. Record evidence, severity, status, owner, target version, and a PASS / CONDITIONAL / BLOCKED decision.
9. Every release must be traceable and reversible. The reviewed workflow JSON, SDD, security artifacts, tests, Git commit SHA, workflow internal version, n8n release tag, and rollback target must describe the same release.

The 7-step methodology

Step 1 — Source inventory

Read the upstream repo and list:

Step 1.5 — Security audit (mandatory before any "enterprise" claim)

Run `n8n-security-governance` for the full security, version-control, CI/CD, and rollback gate. Most AI-coded POCs ship with severe auth / injection holes that you MUST detect before you tell the user the port is deployable. Minimum checklist:

If any check fails and you do not fix it, you MUST publish a `SECURITY-CAVEATS.md`-style file in the example folder with: the file/line of each issue, repro instructions, the correct fix pattern, and a "DO NOT DEPLOY AS-IS" banner in the README. The on-prem LINE CS case in this pack is the template — read it before doing your own audit so you know what the artifact looks like.

If you do fix something the upstream had wrong, the patches must show up in your CREDITS.md as your contribution, separate from the upstream's design.

For a small repo (<2000 lines) this fits in one Python snippet:

import json, glob, re
for f in sorted(glob.glob("src/**/*.*", recursive=True)):
    body = open(f, encoding="utf-8", errors="ignore").read()
    entries = re.findall(r"(app|router)\.(get|post|put|delete)\(['\"]([^'\"]+)", body)
    fetches = re.findall(r"fetch\(['\"]([^'\"]+)", body)
    if entries or fetches:
        print(f, "::", entries, "::", fetches[:3])

Output: a markdown table that becomes the basis of docs/field-mapping.md.

Step 2 — Partition decision (the rubric)

For each piece of logic, decide one of three fates: