Copy Your AI Collaboration System in One Prompt: How to Hand Synapse to a Colleague
Copying an AI Collaboration System in One Prompt
When I built Synapse, I never thought about “how do I let other people use this.” The system was running, the team workflow was smooth, the intelligence pipeline pushed itself, the CEO Agent reported on schedule — felt great. Until one day a friend asked me: “This thing you have, can I just use it?”
I paused. How do I hand it to him? Send a pile of YAML files? Write an install doc? Or clone the entire git repo to his machine and sit with him for three days of debugging? That question made me realize: whether an AI workflow system can be reused, and how good the system itself is, are two almost completely independent things.
Where the Problem Lies: The System Is “Alive,” Documentation Is “Dead”
Traditional software tools propagate this way: write good docs → user follows them to install → configure → run. AI collaboration systems are different. Synapse’s core isn’t code, it’s the CLAUDE.md harness configuration file — it defines AI roles, decision tiers, execution prohibitions, dispatch rules, cross-session state management. In other words, the behavior rules and the deployment configuration are the same file.
That’s the key: the prompt itself is the deployment doc. When CLAUDE.md says “Lysander is explicitly forbidden from directly invoking Bash tools,” that’s not a comment, not a description — Claude reads it, and the rule takes effect. I don’t need to additionally write “how to install this restriction.” The restriction lives inside the configuration text.
So when the friend asked “how do I use it,” the right answer wasn’t to send docs. It was: send him CLAUDE.md, have him replace Lysander, 刘子杨, Synapse-PJ with his own info, and open a fresh Claude Code session in the project. The whole system — AI role positioning, execution chain flow, decision tiering, dispatch system — loads and takes effect with that one file.
The Prerequisite for Portability: Cohesive Rules, Not Scattered
There’s a design lesson here. Early Synapse rules were scattered — some in CLAUDE.md, some in Python scripts, some in shell commands triggered by hooks. Every time I wanted to explain “why does the AI behave this way,” I had to pull up three or four files. A friend wanting to reuse it would have to understand all of them before changing anything.
I later did a consolidation: returned all behavior rules to CLAUDE.md, demoted code-layer artifacts (hook scripts, interceptors) to execution tools rather than rule definers. The rules have one authoritative source. After that, the propagation cost dropped sharply — I could say: you only need to understand this one file.
Concretely, Synapse’s CLAUDE.md now carries three things: Guides (feedforward control, defining how AI should act), Workflow (structured flow, defining execution chain steps), Constraints (the constraint system, defining what AI cannot do). These three layers are cohesive, not scattered.
Personalization: One Replacement Table Solves the Adaptation Problem
The second practical issue is personalization. My Synapse contains my name, my CEO name, my company designation. The friend doesn’t want to take over an AI called “Lysander” — he wants it called by his own AI CEO name.
The solution is crude but effective: at the top of CLAUDE.md, place a configuration replacement table. List clearly which words need a Ctrl+H global replacement, what each config item means, estimated time 3 minutes. That’s it. No environment variables, no .env file, no runtime configuration injection — because AI reads text, and what’s written in the text is what it knows.
The cognition behind this design decision: the “config file” of an AI workflow is natural language, and modifying it doesn’t require code knowledge. The friend’s PM colleague doesn’t know Python, doesn’t know YAML schema — but he can do Ctrl+H. The system is usable for him.
The Remaining Friction: State and Tool Dependencies
Of course it’s not zero-friction. Two parts of Synapse aren’t in CLAUDE.md: cross-session state (active_tasks.yaml, recording in-progress tasks) and external tool dependencies (n8n scheduled triggers, Slack notifications, Claude Code Scheduled Agents).
The state file can start empty — a new user’s first run doesn’t need historical state, so this isn’t a big issue. Tool dependencies are real cost — if the friend hasn’t configured n8n, the scheduled intelligence pipeline can’t run. But that’s functional degradation, not system collapse. Without automation, manually running the same prompt still keeps the core execution chain and decision system functioning.
This led me to a principle: the system’s core behaviors must run with minimum dependencies; automation is enhancement, not prerequisite. An AI collaboration framework that simply doesn’t run without webhooks has a very high propagation cost.
Conclusion: Three Principles of Prompt-as-Deployment-Doc
Back to the original question — how do I hand this to a colleague? My current answer: send the repo, have them read the personalization config block at the top of CLAUDE.md, complete the replacements within 5 minutes, open a fresh session, system goes live.
Three reusable principles behind this:
1. Cohesive rules, single authoritative source. Behavior rules live in one place. Scattered rules are propagation killers.
2. Natural-language configuration, not code-ified. AI reads text; configuration goes in text. Personalization via replacement, not environment variables.
3. Core functionality with minimum dependencies; automation layered on demand. The system’s essential behaviors must run without external tools. Automation is acceleration, not prerequisite.
If you’re building an AI engineering team, take a look at our open-source Synapse framework. It’s not another AI chat interface — it’s an engineering practice for “how to make AI collaborate stably inside a team”: role system, execution chain, decision tiering, cross-session state management, all included.