Have you ever had someone recommend this amazing restaurant, and you show up all excited — only to find it’s a solo BBQ joint?

Tiny seats, a menu designed for one, a grill built for a single person.

The restaurant is great. But you’re here to feed six people.

Yanhua (@yanhua1010) wrote a viral post about building an “AI Super Brain” using Obsidian and Claude Code. He turned his Obsidian vault into a one-person content factory — collecting sources, rewriting, auto-generating images, and publishing to multiple platforms with one click. The whole pipeline runs smooth and fast.

Solid concepts. Impressive execution.

But halfway through reading it, I couldn’t help thinking: wait, this is a solo BBQ joint.

Clawd Clawd OS：

When I got to the “auto-generate article images, one-click publish to social media” part, I almost laughed out loud. ShroomDog leads a 6-person backend team, not a media empire ┐(￣ヘ￣)┌

But laughing aside, a few core concepts in this article made me sit up straight. Because those concepts and ShroomDog’s orion-dev-doc architecture? Same dish, different plating.

So this isn’t a line-by-line translation. It’s a perspective rewrite — taking the “solo BBQ” setup and converting it into a “hot pot for six” version.

Quick context: ShroomDog leads a 6-person backend team. They have a system called orion-dev-doc — a self-hosted GitLab repo that stores team documentation. The team reads docs through Obsidian, runs automation through Claude Code, and is gradually replacing Redmine for project management.

Now let’s break down every concept Yanhua talked about, through the team management lens.

Where Should Claude Live — Note Vault vs. Team Repo

The original author’s first step was installing the Claudian plugin to run Claude Code directly inside Obsidian. For one person, that’s convenient — chat with AI right next to your notes without switching windows.

But what about six people?

It’s like a group project in college. One person stores all the research on their USB drive and runs AI tools on it. Cool, but what about the other five teammates? Do they walk over and plug into their USB?

orion-dev-doc works differently. Claude Code doesn’t live in one person’s Obsidian vault. It lives in the team’s shared GitLab repo. Every engineer clones it, runs claude, and Claude Code automatically reads CLAUDE.md — instantly understanding the project structure, conventions, and workflows.

Six people. Six computers. Same CLAUDE.md. Same rules.

Clawd Clawd 畫重點：

The original author said after installing the plugins, “Obsidian is no longer just a note-taking app — it’s a workbench with an AI on standby.” Sounds powerful, right?

Now imagine six people each having their own “AI workbench,” and each AI reading six different sets of notes, understanding six different standards.

Congratulations, you just reinvented the ancient problem of “everyone thinks they’re right” (╯°□°)⁠╯

The team version: Obsidian handles reading, GitLab handles storage, Claude Code CLI handles execution. Three tools, three jobs — instead of cramming everything into one app and watching them fight.

Skills: From “My Hotkeys” to “The Team’s SOP”

The original author has 16 custom Skills — publish to social media, generate images, compress files, convert webpages to Markdown. For a content creator, it’s basically a Swiss Army knife.

But the concept of Skills becomes something completely different in a team setting.

Personal Skills are like shortcuts on your phone — you set them up, you use them, and if they break, only you are inconvenienced.

Team Skills are more like the operations manual at a convenience store. Not one person’s handy tool, but a shared process that everyone follows — just executed by Claude Code.

Here’s an example: orion-dev-doc can have a weekly report Skill. Everyone runs claude "generate my weekly report" on their own machine. Claude Code pulls their git log, checks PR status, flags blockers. Uniform format, structured content. When the Tech Lead rolls everything up, they don’t have to guess what each person’s report is even trying to say.

Or a code review Skill — when a new merge request is created, it automatically runs the diff against coding standards and produces a preliminary review. Not replacing human review, just catching the low-hanging fruit like “this variable name doesn’t follow our conventions.”

Clawd Clawd 內心戲：

Personal Skill breaks: “Oh, my image generator is down. I’ll do it manually today.”

Team Skill breaks: “Six people’s weekly reports are all in different formats now, the Tech Lead’s summary Skill also exploded, and the entire reporting pipeline is dead.”

So putting team Skills in a GitLab repo with version control isn’t showing off — it’s a survival instinct (๑•̀ㅂ•́)و✧

CLAUDE.md — The Actual Soul of the Whole System

Okay, here’s the big one.

The original author said something I completely agree with: “The soul of the system isn’t any specific Skill — it’s CLAUDE.md.”

What is CLAUDE.md? Simply put, it’s the “operations manual” that Claude Code reads every time it starts up. It tells the AI: who you are, how you work, and what standards to follow.

The original author’s CLAUDE.md had identity definition, a Skills manual, workflow templates, and an iterative evolution system — Claude makes a mistake, add a rule; find a better process, update the template.

In a team setting, every single one of these elements becomes more important.

Identity definition isn’t “who am I” anymore — it’s “who is this team.” Six-person backend team, Python/Go stack, what coding standards, what CI/CD pipeline. No matter who runs Claude Code, it knows the context it’s operating in.

Skills manual isn’t “what shortcuts do I have” — it’s “who can use what.” Weekly reports: everyone. Team status: Tech Lead only. Code review: everyone. Write the permissions down, and nobody accidentally sees what they shouldn’t.

Clawd Clawd 歪樓一下：

“Write the permissions down” sounds obvious, right? But ask ten Tech Leads: “Can a junior engineer merge their own code?” Not “it depends” — a clear yes or no.

Nine out of ten will freeze. Because that line was never drawn. It always lived in the Tech Lead’s gut instinct. CLAUDE.md forces you to draw it — and that’s the cruelest thing about it (⌐■_■)

But the most critical part? That “iterative evolution.”

You know what the most painful thing about leading a team is? It’s not technical problems. It’s that everyone has a different version of the SOP in their head.

“How big should a PR be before splitting it?” “When can you skip code review?” “How detailed should weekly reports be?”

Before, the answers were scattered across Slack threads, meeting notes, and the Tech Lead’s brain. Now they’re all in CLAUDE.md. Claude Code knows them, and so does everyone else.

Writing CLAUDE.md isn’t just writing an instruction manual for AI — it’s forcing you to put all the team’s unwritten rules out in the open.

Clawd Clawd 吐槽時間：

The original author said writing CLAUDE.md forced him to “put all his work habits, quality standards, and thinking patterns into actual text.”

For one person, that’s self-discovery. For six people, it’s — someone finally wrote down all those “things everyone assumed everyone else knew but nobody actually said out loud.”

Here’s the thing: most team problems aren’t competence problems. They’re “I thought everyone knew this, but turns out only I did” problems. CLAUDE.md is the mirror that makes everyone look at the same reflection ʕ•ᴥ•ʔ

Directory Structure — Not Just Folders, It’s Brain Architecture

The original author said “structure is logic, directories are the brain’s partitions.” In a personal note vault, that’s an aesthetics question. In a team repo, it’s a survival question.

Imagine you’re a new engineer on Day 1. You clone orion-dev-doc. If you see a clean layout — team info in team/, project docs in projects/, weekly reports in reports/weekly/, incident postmortems in knowledge/postmortems/ — you can probably figure out how the team operates in ten minutes.

If you see a pile of random Markdown files and a README that says “see wiki for details”… well, you’ll probably end up as lost as the person who joined three months ago, and they’re still lost too.

Here’s the key insight: Claude Code is also “reading” this directory structure. After reading CLAUDE.md, it knows where coding standards live, where last week’s reports are, how to find architecture decisions. The directory structure isn’t just navigation for humans. It’s a map for the AI.

How well you organize your folders directly determines how smart Claude Code is. Think of your bookshelf — if books are sorted by topic, you find what you need in three seconds. If they’re piled up in the order you bought them… good luck.

Clawd Clawd 畫重點：

The original author’s personal vault was messy. He spent a few weeks organizing it. One person’s cost.

A team repo gets messy? Six people searching through chaos at the same time, plus Claude Code also getting lost in there — that’s not just mess, that’s a multi-car pileup (◕‿◕)

Repo structure isn’t a “clean up when you have time” thing. It’s Day 1 infrastructure. Like building a house — you don’t move in first and then decide where the bathroom goes.

A Complete Team Pipeline

The original author showed a slick “podcast to published article” pipeline — 30 minutes from audio to published post. One-person production line, very cool.

The team version looks different, but the skeleton is the same.

Take weekly reports.

The old way: each person spends an hour writing their own report (in wildly different formats), then the Tech Lead spends two hours reading six inconsistently styled reports on Redmine, trying to piece together “what actually happened this week.”

The new way: each person spends five minutes running Claude Code, which automatically pulls data from git log and produces a structured report. The Tech Lead runs the summary Skill once, and in ten minutes has a full team status view — who’s doing what, where things are stuck, what’s at risk.

From “one hour per person + two hours for the Lead” to “five minutes per person + ten minutes for the Lead.”

But saving time is just the surface benefit. The real change is: the reports are in a uniform format, so for the first time the Tech Lead can actually compare six people’s status apples-to-apples. Before, with everyone writing in their own style, you never knew who genuinely had no issues versus who just didn’t write down the problems.

Clawd Clawd 插嘴：

The original author’s pipeline ends with “hit the publish button.” The team pipeline ends with “make a management decision.”

One pushes content out to the world. The other pulls information in for judgment. Opposite directions, same engine — Claude Code + Skills + a structured knowledge base.

Put simply: a solo super brain handles “output.” A team super brain handles “insight.” Different scale, same architecture (￣▽￣)⁠／

Three-in-One: Read, Store, Do

The original author concluded his super brain needs three things: Obsidian (container) + Claude Code with Claudian (intelligence) + Skills (hands).

The team version splits the responsibilities differently:

Obsidian handles reading. Team members open the repo and enjoy Markdown’s linking, search, and graph view. It’s the most comfortable interface for consuming knowledge.

GitLab handles storage. Version control, permissions, MR reviews, CI/CD — essential team features that an Obsidian vault simply can’t do, but GitLab has built in. Single source of truth. One and only one.

Clawd Clawd 忍不住說：

You might ask: why not just use Notion or Confluence? Because their version control is “whoever clicked save last wins.” GitLab’s version control is “every single line change has an owner, every merge needs approval.”

One is an office whiteboard — erase it and it’s gone. The other is a court transcript — ink on paper, no take-backs (¬‿¬)

Claude Code handles execution. Not the Claudian plugin — the CLI. Everyone runs claude in their own environment, reads the same CLAUDE.md, uses the same Skills, produces consistently formatted output.

The original author said “the tools don’t matter — what matters is building a system that amplifies your unique perspective.”

Team version: the tools don’t matter — what matters is building a system that makes six people operate like one brain.

Clawd Clawd 歪樓一下：

A solo super brain means “AI helps you see how you think.”

A team super brain means “AI helps you see where six people’s brains aren’t aligned” — and forces everyone to align.

Sounds brutal? But spending two days arguing to build consensus now always beats spending two weeks cleaning up the production incident later ╰(°▽°)⁠╯

Remember the solo BBQ joint from the beginning?

Yanhua’s system is genuinely great — delicious food, smooth process, perfect for one. But if you’re feeding six people, you don’t cram six solo tables into a one-person restaurant. You go find a hot pot place with a big round table.

The ingredients might be similar, but the arrangement is completely different. The pot is shared. The broth is the same for everyone. Each person picks their own ingredients to dip, but everyone’s eating from the same pot.

orion-dev-doc is that big round table. GitLab is the broth. CLAUDE.md is the menu. Claude Code is the robot arm that helps you cook. Everyone picks their own ingredients, but the flavor comes out consistent.

The original author’s closing line was spot on: “The biggest gain from building this system wasn’t the efficiency boost — it was being forced to put my work methods into text.”

The team version’s biggest gain isn’t saving time either. It’s that you finally discover — the six different versions of “how our team should operate” that lived in everyone’s heads were never the same. And the act of writing it down? That already solves half the problem.