A growing, open-source collection of practical n8n workflows — built, tested, and used in real projects, then published here for anyone to import and adapt.
Every workflow ships as a ready-to-import .json file, its own README covering setup, and a structured Contract — what it needs, what it's allowed to touch, and how it recovers when something breaks. Not just prose you have to trust; a declared behavior spec you can check.
The n8n workflow is the implementation, not the point. What's actually reusable is the pattern underneath it — fetch → classify → route → notify, or detect → judge → approve → act — the same shape whether it's built in n8n, LangGraph, or something that doesn't exist yet.
Every workflow here documents that pattern explicitly, so the ideas are portable even if you never touch n8n. This came directly out of a community discussion where several people independently converged on the same conclusion: the missing piece in agentic automation isn't more agents, it's a shared, checkable contract for what they're allowed to do.
Instead of just a prose README, each workflow's documentation includes:
- Inputs — what data goes in
- Permissions Required — exactly what it can read/write, nothing implied
- Side Effects — every action it can take, explicitly listed
- Approval Points — where a human has to say yes before anything irreversible happens
- Recovery Behavior — what it does when a dependency fails, instead of failing silently
This is what "human-in-the-loop by default" actually means in practice — not a slogan, a checkable spec per workflow.
n8n_workflows/
├── workflows/
│ ├── github-debugger-agent/
│ │ ├── workflow.json
│ │ └── README.md
│ ├── telegram-github-antigravity-pipeline/
│ │ ├── workflow.json
│ │ └── README.md
│ ├── duplicate-issue-detector/
│ │ ├── workflow.json
│ │ └── README.md
│ ├── competitor-feature-parity-watcher/
│ │ ├── workflow.json
│ │ └── README.md
│ └── <next-workflow>/
│ ├── workflow.json
│ └── README.md
├── LICENSE
├── CONTRIBUTING.md
└── README.md ← you are here
Each workflow lives in its own folder under workflows/, so the collection can grow indefinitely without the root becoming cluttered.
| Workflow | Description | Stack |
|---|---|---|
| GitHub Debugger Agent | Scans a repo for bugs/inefficiencies with an LLM, reports to Discord, fixes only on approval | n8n, OpenAI/GPT-4o, GitHub API, Discord |
| Telegram → GitHub → Antigravity Pipeline | Message an issue number on Telegram; a local LLM reasons about it, Antigravity codes the fix, you approve, it pushes | n8n, Ollama/llama.cpp, GitHub API, Antigravity CLI, Telegram |
| Semantic Duplicate Issue Detector | Flags likely-duplicate GitHub issues using semantic similarity, comments with the match — never closes/labels without review | n8n, OpenAI Embeddings, Qdrant, GitHub API |
| Competitor Feature-Parity Watcher | Watches competitor changelogs weekly; an LLM scores relevance against your own feature list, filtering signal from noise | n8n, OpenRouter, Google Sheets, RSS |
(New workflows are added regularly — see open issues or watch this repo for updates.)
Every workflow here follows the same core principle: human-in-the-loop by default. None of them auto-commit, auto-merge, or take irreversible action without an explicit approval step from a real person. Automation should remove the tedious part of the work, not the judgment.
Prerequisites (common to most workflows in this repo):
- An n8n instance — self-hosted (Docker) or n8n Cloud (v1.28+ recommended for native Ollama support)
- Git and a GitHub account, with a fine-grained Personal Access Token scoped to the specific repo you're automating
- Any workflow-specific requirements — see that workflow's own README (LLM provider, messaging platform, etc.)
To use any workflow:
- Open the workflow's folder under
workflows/ - Read its README for its Contract, prerequisites, and setup steps
- In n8n: Workflows → Import from File, select that workflow's
workflow.json - Fill in the credentials and placeholder values called out in its README
- Test on a throwaway/sandbox repo before pointing it at anything important
Workflow files can embed logic that touches credentials, files, and external services. Before importing anything from this repo (or anywhere else):
- Open the raw
workflow.jsonand skim everyhttpRequestnode's URL — does every destination make sense for what the workflow claims to do? - Check every node with a credential attached — does it request only the permissions its Contract says it needs?
- Look for anything that sends data to an unfamiliar or unexplained external domain
- Never import a workflow that asks for broader credential scope than its stated Contract requires
This applies to every workflow in this repo too — if you spot something that doesn't match its documented Contract, please open an issue.
Contributions are welcome — new workflows, fixes to existing ones, or clearer documentation. See CONTRIBUTING.md for the process. In short:
- Fork the repo
- Add your workflow under
workflows/<your-workflow-name>/, including aworkflow.jsonand aREADME.mdwith a Contract section describing it - Open a pull request
If your workflow handles credentials, tokens, or personal data anywhere in its JSON, scrub them and replace with placeholders (e.g. REPLACE_ME) before committing — see the Security Note below.
n8n exports can embed credential references but not raw secrets by default — still, always double-check your exported JSON before committing. Never commit:
- API keys, tokens, or webhook secrets
- Real chat IDs, user IDs, or email addresses
- Real repo names/paths if they reveal something private
Use placeholder values (REPLACE_ME, YOUR_CHAT_ID, etc.) in anything published here.
Distributed under the MIT License — see LICENSE for details. You're free to use, modify, and redistribute any workflow here, including commercially, with attribution.
Check the open issues labeled good first issue or
help wanted — pick one, and see CONTRIBUTING.md
for the branch → PR → review process.
Built and maintained by Shinjan Das — issues and PRs welcome.