How to Build a Reusable "Playbook" for Claude with a Simple Framework

Have you ever had one of those "Aha!" moments with an AI like Claude, where you finally craft the perfect prompt and it gives you exactly what you need? It feels amazing. But then, an hour later, you need it to do a similar task, and you're back to square one, trying to remember the magic words. It can feel like you're constantly reinventing the wheel.

I've been there more times than I can count. As a developer, I love consistency and reusability. So, I started wondering: what if we could build a kind of "playbook" for Claude? A set of pre-defined roles, commands, and styles that we could call up on demand, making our interactions more structured and predictable.

That's what led me down the rabbit hole of building a simple framework on top of Anthropic's API. I call it the "SuperClaude" framework, and it's surprisingly simple. It's not about complex code, but about using structured text files to give the AI a clear set of instructions. Today, I want to walk you through how it works and how you can build something similar. It’s all about making the AI work for you, not the other way around.

So, What's the Big Idea?

Think of it like this: when you talk to Claude normally, it's a blank slate. You have to provide all the context every single time. But with a framework, we give it a role, a task, and a style before we even ask our question.

The whole system is built on three simple concepts, all defined in plain Markdown (.md) files:

• Commands: These are the specific actions you want the AI to take. Think /brainstorm, /implement, or /analyze. Each command file tells Claude what to do and how to structure its output.
• Agents: These are the expert personas you want the AI to adopt. Maybe you need a frontend-architect, a security-engineer, or a business-strategist. The agent file gives Claude its role and expertise.
• Modes: These define the style of the response. Do you need a super-detailed deep-research mode, or a quick and concise token-efficiency mode?

By mixing and matching these, you can create highly specialized instructions on the fly without rewriting massive prompts. It’s like having a team of specialized assistants ready to go at a moment's notice.

Getting Our Workspace Ready

First things first, we need to get our hands on these pre-written playbooks. The whole framework lives in a public Git repository, so the first step is to just clone it onto our machine. A simple git clone command does the trick.

Once we have the files, we need a way to find all our commands, agents, and modes. I wrote a simple Python function that just walks through the folders and organizes all the Markdown files it finds into three buckets. It's like sorting your recipes into different categories so you can find them easily later.

After running the script, we can see our inventory: a whole collection of commands like brainstorm and implement, agents like frontend-architect, and modes like deep-research. Now we have our toolkit ready.

The "Conductor": A Python Class to Connect Everything

Okay, we have our "playbook" files. Now we need a way to actually use them. This is where a little bit of Python comes in to act as the bridge between our framework and the Anthropic API.

I created a Python class called SuperClaude. You can think of it as the conductor of an orchestra. Its job is to:

1. Take your request: You tell it the prompt, which command you want to use (e.g., /implement), which agent to be (e.g., frontend-architect), and any modes.
2. Build the System Prompt: This is the magic part. The class grabs the text from the corresponding Markdown files for your chosen command, agent, and modes. It then stitches them all together into a single, comprehensive "system prompt." This prompt essentially tells Claude, "Here is your exact identity and set of instructions for this specific task."
3. Talk to Claude: It sends this big system prompt, along with your actual user prompt, to the Anthropic API.
4. Handle the Conversation: It streams the response back and, importantly, can keep track of the conversation history.

I also added simple save() and load() methods. This is a game-changer for longer projects. You can have a multi-step conversation with Claude, save the entire session to a file, and then pick it up right where you left off later. No more context loss!

Let's See It in Action: A Few Test Runs

This is where the fun begins. Once the bridge was built, I started throwing different tasks at it to see how well it worked.

First, I tried a brainstorming session. I used the /brainstorm command and asked it to map out a personal finance app for college students. The response was incredible. Instead of a generic wall of text, it came back with a perfectly structured breakdown: target users, must-have features, differentiators, and risks—exactly what the brainstorm.md file instructed it to do.

Next, I got more technical. I activated the frontend-architect agent and used the /implement command to ask for a React component. The request was specific: an animated SVG budget ring with a tooltip, using TypeScript and Tailwind. The code it produced was clean, functional, and came with a usage example. It felt like I was working with a senior developer, not just a language model.

I even tested it on a security review. I gave it a snippet of vulnerable Python code, activated the security-engineer agent, and used the /analyze command. It came back with a ranked list of vulnerabilities, explaining the attack vector for each and providing the corrected code. This is the kind of specialized, role-aware behavior that's so hard to get from a generic prompt.

The Ultimate Test: Building a Tool from Scratch

Individual tasks are great, but the real power of this framework comes from chaining them together. To prove it, I decided to build a small command-line tool from start to finish in a single, continuous session.

The project: A tool that summarizes any GitHub repository from its URL.

1. Step 1: Brainstorm. I started with /brainstorm to define the scope and constraints.
2. Step 2: Design. Next, I used the /design command to have it map out the architecture, data flow, and even create a little ASCII component diagram.
3. Step 3: Implement. With the plan in place, I switched to /implement to get the core Python function written.
4. Step 4: Test. Then, I used /test to generate pytest tests for the code it just wrote, making sure to mock the network calls.
5. Step 5: Document. Finally, I used the /document command to write a solid README.md file for the project.

Each step built on the last, with the session history maintaining the full context. At the end, I had a complete, documented, and tested piece of code. I simply called sc.save() and the entire conversation was stored, ready for me to load back up anytime.

This is what I was looking for. It’s a flexible, powerful way to guide the AI through complex tasks, turning it from a simple chatbot into a true development partner. You can add your own commands, mix and match agents with different modes, and build workflows that are perfectly tailored to your needs. Give it a try—it might just change the way you work with AI.