A ~/.claude Architecture With 200+ Skills: Keeping the System Prompt Under 50K Tokens and Paying $0.15 Per Session

• System prefix size: 40-50K tokens (CLAUDE.md 8K + rules 20-30K + descriptions 15K)
• Prompt caching savings: 10x ($0.15 per session instead of $1.50 without caching)
• Presentation turnaround: 6 minutes 14 seconds for 12 slides (3.8 MB PPTX)
• Protection against prompt injections: 5 isolated perimeters and 3 hard PreToolUse blocks

In spring 2025, when the term "vibe coding" had only just appeared and Claude Code installations hadn't yet topped fifteen million, I was solving a purely managerial problem. As CPO of AlpinaGPT, I was drowning daily in dozens of calls, email threads, and work chats — agreements kept getting lost at the seams between channels. I needed a round-the-clock digital brain over a single vector database that could link promises made on Zoom with emails and proactively remind me of deadlines — the prototype of what later grew into the OpenClaw architecture.

A bare terminal agent out of the box only knows basic file read and write operations. To turn it into an engineering workhorse, over a year of experimentation I built a seven-layer modular system in the `~/.claude/` directory: a navigational `CLAUDE.md`, persistent `rules/`, on-demand `skills/`, isolated subagents in `agents/`, explicit slash commands in `commands/`, external connectors via `mcp.json`, and event hooks in `hooks/`.

Why doesn't a library of 200+ skills blow out the context window or

drain your token budget?

The biggest mistake when configuring an agent is dumping all instructions into the root `CLAUDE.md`, bloating it to 4,000 lines. Any edit to such a monolith resets Anthropic's prefix cache, forcing you to pay full price at every step of the dialogue. In my setup, the size of the on-disk skill library and the size of the active context are fully decoupled.

At the start of a session, only a compact map of the terrain loads into memory: a root `CLAUDE.md` of 200-300 lines (about 8K tokens), 20-25 base rule files in `rules/` (20-30K tokens), and short annotations of skills and MCP servers (another 15K). The entire startup prefix fits within 40,000-50,000 tokens, while the main body of instructions and scripts — weighing in around 300K tokens — waits its turn on disk.

Because the prefix stays unchanged from request to request, prompt caching kicks in: a session costs $0.15 instead of $1.50, with a response time of 1-2 seconds.

The cardinal operating rule is to never edit files in `rules/` mid-conversation, and to compress history with `/compact` rather than wiping it entirely.

How does routing work through routing.md, and how do skills self-replicate?

The connective tissue of the whole configuration is the routing table `rules/routing.md`, running 300+ lines and working on a "key trigger → specific tool" principle. If a task comes up less than once a day, it has no business sitting in persistent rules — it gets packaged as a separate bundle in `~/.claude/skills/<name>/SKILL.md` with working scripts inside.

A clear example is the `manus-slides` presentation generator. When I type a request in the terminal for a 12-slide investor pitch in whiteboard style, the router picks up the trigger with 0.94 confidence, loads 4.2K tokens of instructions, and kicks off the pipeline. Claude builds the structure, fires off 12 parallel requests to `gemini-3.1-flash-image-preview`, and assembles the final `presentation.pptx` file (3.8 MB) via Python scripts. The entire cycle takes 6 minutes 14 seconds instead of a full workday.

The same principle powers a Telethon wrapper (`tg_client.py`, 50+ commands) for pulling analytics and mentions from Telegram channels into CSV, as well as the meta-skill `skill-creator`. Ask the agent once to build a skill for parsing bank PDF statements, and it creates the folder itself, writes the YAML frontmatter with triggers, drops in the script, and adds a line to `routing.md`. We cover this exact personal AI-workhorse architecture hands-on at [Hamidun Academy](https://academy.hamidun.com) and develop it further inside the engineering community [Vibe Club](https://hamidun.com/club).

How do you protect an autonomous agent running in bypassPermissions

mode from database wipes and prompt injections?

I work in `bypassPermissions` mode without manual confirmation at every step, because the safety net is pushed down to the execution environment level. When the agent reads someone else's email, web pages, or code, external data is always treated as untrusted content — never as commands.

Security rests on five lines of defense: 1. Physical isolation of keys: all secrets live in `~/.claude/.

credentials.master.env` outside the repository and get passed into scripts via `os.

getenv()` — the model never sees the actual values of `TELEGRAM_API_ID` or payment keys in the dialogue. 2. Hard PreToolUse hooks: `settings.

json` registers three lightweight interceptors that instantly return `exit 1` on any attempt to call `rm -rf`, `DROP DATABASE`, or `DROP TABLE`. 3. Read-only perimeter for reviewers: code-review and security-audit subagents only get `Read`, `Glob`, and `Grep` whitelisted — no write access, no shell calls.

4. Sanitizing the incoming stream: before passing an email's text to the model, the `gmail_search.py` script strips out constructs like "ignore previous instructions," replacing them with a `[REDACTED:injection]` marker.

5. Adversarial acceptance testing and delegation: before rolling out a new bot, I run it through a validation suite of attacks, and I split subagent tasks from Level 0 (do it myself) to Level 3 (orchestrator plus workers in `git worktree` with exact file-and-line references).