small-council

They advise, they decide, and you stop guessing.

"When you play the game of thrones, you win or you die."

When you ship a vibe-coded AI product, you get a VC-backed startup or a broken localhost demo.

Every king has a council he needs to hear from. This is yours.

Small Council is a suite of two skills that sit on either side of the moment your AI product's architecture gets decided — the moment vibe coders skip straight past, every time.

Baelish and Tywin force the architecture into existence, structured, in writing, before any code gets touched. Tyrion, Stannis, and Bronn — with Varys synthesising — tear it apart before you build on it. No consensus. No cheerleading. Just the small council dealing with "small matters".

Why small-council

Issues with Vibe-coding and Coding Agents:

1. the temptation to start coding. If a vibe-coder enters a vague prompt describing an idea they want to build, the coding agent moves to complimenting the idea, providing a generic outline of how the flow might look, and asking the user if it should writing the code (which is too hard to resist). It goes on to figure things out as it's writing, based off of the vague prompt, and the minimal flow it thought of. This takes up time, tokens, and seldom produces a deploy-ready app.

2. assumptions and decisions. The coding agent figures out the code as time goes, but to get to the code, it makes convenient assumptions, and these assumptions drive decision-making that can make or break the app. To make it worse, as the coding agent continues excessively spending tokens on making these assumptions and decisions, it increasingly loses the original context, and start straying away from the intent. There is no sight more frustrating than seeing your token usage accelerate as Claude Code runs around in circles to make a minor decision in the middle of writing code.

3. flawed planning. asking the coding agent to plan out is a seemingly decent fix. However, planning out, unless you invoke a well-written pre-installed skill, isn't very structured. It is trapped between divergence and convergence. That is, between exploring different possibilities and choosing one answer for the user, when in reality, it should find all possibilities, and intelligently narrow down to the best. Maybe I'm wrong, and the coding agent can actually do that on its own. But again, how can it think of possibilities without making the right assumptions that separate possibilities? And how can it narrow down intelligently if it loses your intent? Surely, you can ask the agent to review its answer again and strengthen it. But then, it could either reassure that the architecture is extremely intact with just one tiny flaw (like a student grading their own paper and giving themselves a 99 instead of a 100), or take an entirely new view, disdaining every single token while still commending one minor positive.

The solution:

Just the concept of planning before writing ideally resolves the first two issues. However, for issue three, great structure is a necessity. After a lot of careful thinking and extensive testing, I ended up with two skills: blueprint and audit. blueprint solves issues one (by forcing detail into its response) and two (by making structured assumptions leading to plausible distinct possibilities), as well as the first half of issue three (by splitting convergence and divergence, ensuring that divergence makes the right assumptions and convergence makes the right decisions). audit had to be more intricate, as it should serve as the final gate to heaven, the freedom of letting the coding agent finally work its magic. It solves issue three's second half (by having the architecture torn apart from three different perspectives, and then having the findings themselves rechecked and synthesised). So, as a suite, small-council solves what I found to be the three primary issues with vibe-coding.

Your idea
   ↓
/small-council-blueprint   →  Baelish surfaces every real path. Tywin commits to the strongest one, in writing.
   ↓
[you build against a document, not a vibe]
   ↓
/small-council-audit  →  Tyrion, Stannis, and Bronn tear the architecture apart.
                          Varys tells you what survives and what doesn't.
   ↓
Ship knowing what you're carrying, not hoping you got lucky.

Install

/plugin marketplace add Nakshatra0707/small-council
/plugin install small-council@small-council

Or copy skills/small-council-blueprint/ and skills/small-council-audit/ into your ~/.claude/skills/ directory.

Beyond Claude

Both skills are plain SKILL.md files — the open Agent Skills format, not a Claude-specific one. The same two files work unmodified in Codex CLI, Gemini CLI, Cursor, GitHub Copilot, and every other tool that reads the standard. Only the install path changes:

Copy skills/small-council-blueprint/ and skills/small-council-audit/ into whichever directory matches your tool. Same files, same behavior, no edits needed.

The council, in order of appearance

Baelish — explores every path, recommends none. "Everything that happens will be something that you've seen before." His job is to make sure you see all the possibilities before Tywin picks one.

Tywin — commits. "A lion doesn't concern himself with the opinions of the sheep" No hedging, no "you could also." He answers to what you actually said you wanted, not to whichever path looked most impressive.

Tyrion — finds how it fails. "I drink and I know things" — mostly, how confident architectures meet production badly, including the silent kind: a leaked key, an unguarded endpoint, a prompt with no defense against the input it'll actually receive.

Stannis — demands proof. Doesn't care how good the demo looked. "The night is dark and full of terrors" — and so is your eval strategy, until you can show him the ground truth.

Bronn — finds the cheaper, simpler version. A sellsword who picks the crossbow when everyone else is jousting in full armour. "I've always been an expensive man, but I'm worth it." If your architecture is solving a problem you don't have yet, he'll say so, once, dryly, and move on.

Varys — serves no one. "I serve the realm, and the realm needs stability." Verifies every finding against the actual architecture before it reaches you — no unverifiable "this is already handled" allowed — then tells you what's real, what's already resolved, and where the council genuinely couldn't agree.

/small-council-blueprint — see it work

You: "build me a chatbot that remembers things"

That's it. That's the whole prompt. Most tools would hand this straight to implementation and let the stack get decided in real time, file by file, with only a surface-level understanding of what to do. Blueprint won't let that happen.

Baelish surfaces the paths — a minimal version (flat file or single table, last-N-messages context, ships today), a standard version (vector store for semantic recall, a new service and a new failure point), and where it's warranted, a scaled version (retrieval plus a verification pass, needed once the memory is actually being trusted). Each with a plain line on what it costs, what it buys, and what happens to it under real traction.

Tywin commits — picks one, states the full stack by name (no "a database," no "an API layer" — actual technologies), draws the data flow end to end, says exactly why the other paths lost, and discloses up front whether this path ages gracefully or eventually forces a rewrite.

You get a written architecture. Not a vibe. A genuine, engineered document.

/small-council-audit — see it work

Now hand that architecture — plus your original idea — to the council.

Three findings, ranked by how fast they hurt you and your idea, not just how severe they look in isolation — a smaller problem sitting on top of what you said mattered most outranks a bigger one sitting somewhere you never claimed to care about.

One line from Bronn, dry, once, wherever it's earned.

Every genuine disagreement the council couldn't resolve, surfaced in full — not smoothed into consensus, not capped at a tidy number. If Tyrion and Bronn actually disagree about whether a fix moves risk or just hides it, you see that fight, framed as the one-sentence decision it actually is.

Your architecture, rewritten with the fixes applied. Open decisions marked plainly. Then the model asks: "Shall we nail this down?" — walks you through what's still open, and only asks to start building once the architecture actually holds.

Technical notes

Why two skills, not one: Building and critiquing the same document in the same breath can make the critique a little weak — it's hard to be genuinely adversarial about something you just wrote. Small Council forces a seam: commit to the architecture on paper first, then let a distinct, adversarial pass run against it as a fixed target. Use Blueprint alone if you just want a clean-room architecture. Use Audit alone if you already have a written plan from somewhere else. Use both, in order, if you want the full council.

Complementing with grill-me: Small Council starts after you already have an idea. It doesn't help you find one, and it doesn't help you sharpen a vague one into a clear one — that's a different, earlier job. If your idea is still fuzzy, run grill-me first, or something like it, to get clarity before Blueprint ever sees it. A clear idea will provide better context and intent to a model. Although blueprint may work even on a superficial idea, its primary goal is to govern a model's formation of an architecture. Audit, without saying, works explicitly on well-defined architectures, to catch niche miscues, not spew out a list of basic ones.

On token cost: Running two personas in blueprint or three personas, a two-pass verification step, and a full architecture rewrite in audit is not cheap. This is not an accident or an oversight — it's a tradeoff. The alternative is silence: no review, no adversarial pass, a vibe coder shipping on a stack nobody stress-tested. Spend the tokens once, deliberately, before you build — or spend far more of them later, rebuilding something that broke in a way the skill would have caught. The expense is front-loaded on purpose. If it feels like a lot in the moment, that's the point; the alternative isn't cheaper, it's just deferred and usually more expensive when it finally shows up.

Personal note

I'm Nakshatra — A high-school senior student building things across hardware and AI, and trying to add some, perhaps fleeting, value to this ever-changing space. As a student who started coding in middle school, I have little formal education, just YouTube courses, websites, and snippets of docs. I've coded a fair chunk, albeit with just a couple of full-stack projects (hence my bare github profile), before coding agents took the world by storm.

So, with that, here are my two cents on vibe-coding: it's a genuinely good way to learn, prototype, and find out fast whether an idea is possible to bring to life. But trust me, this stuff does not fly. How do I know this? Good question, I just interned at an AI lab startup. I saw everyone using hybrids of Claude, OpenCode, and Cursor to code, and I tried the same when I was given a novel agentic project to take over myself. I was done with it on the first day itself, dreaming about the day I'd be the founder of a YC AI Startup. I called over my supervisor, and I kid you not, in a couple of minutes, he understood the codebase better than I did, even though I asked Claude for a summary. He found 10 flaws that immediately made my code unfeasible for implementation. I was determined to follow through, and day by day, I was getting better. I was learning. Soon, all methods, all implemented models, and every structural decision arose from my thinking and understanding; yes, it required me to spend excess time researching and fact-checking, but I just couldn't let it go. I didn't write a single line of code, but I knew every minute detail about what I had built. Believe me, the project I shipped after 3 weeks felt much more rewarding. So, use coding agents to automate, not ideate.

As for small-council, use it to ship faster and safer. Don't use it as a reason to stop learning or fact-checking, and definitely don't stop asking why?

License

Apache 2.0