Before I dive into the technical stuff, I should tell you who’s writing this: I’m a nobody with a blog.
I’m not chasing clicks or trying to go viral. There are no ads here, no tracking pixels, no shady analytics—and there never will be. I’m not sponsored by Anthropic or anyone else. Honestly, they’d probably laugh if I emailed asking for sponsorship. “And WHO are you anyway?”
I’m not trying to convince anyone to use Claude Code or to adopt my specific workflow. In fact, I’d advise against blindly copying anyone’s setup. Gain the knowledge, then implement it into a workflow that works for you.
Truthfully? I’m just an Autistic developer who loves coding, is fascinated by AI and the trajectory we’re on, and wants to share experiences that others might find useful. That’s it. That’s the whole agenda.
The Minimalist Approach to CLAUDE.md
I don’t use an elaborate, complex CLAUDE.md file. No sprawling global configuration. No intricate user-level setup that tries to anticipate every possible scenario. Just the bare minimum that Claude needs to understand the project.
My philosophy is simple:
- No global user-level
CLAUDE.md—every project gets its own tailored configuration - Never write from scratch—I start with a plugin that closely matches my needs, then modify it as I discover gaps
- Iterate constantly—the file evolves as I learn what the project actually requires
Here’s the complete CLAUDE.md for one of my active projects—a REST API wrapper for Claude Code CLI:
# Claude Code REST API
REST API wrapper for Claude Code CLI. Exposes HTTP endpoints
for session management and query execution.
## Commands
npm run dev # Development server with auto-reload (port 3000)
npm run build # TypeScript compilation to dist/
npm start # Production server
npm test # Run all tests
npm run test:unit # Unit tests only
npm run test:watch # Watch mode for TDD
## Architecture
3-layer architecture: Routes → Services → Infrastructure
src/
├── routes/ # HTTP endpoints (sessions.ts, query.ts, health.ts)
├── services/ # Business logic (SessionService, QueryService)
├── infrastructure/ # CLIExecutor, SessionStore (SQLite), RequestQueue
├── middleware/ # Express middleware (validation, error handling)
├── types/ # TypeScript definitions
└── utils/ # CLI args builder, stream parser, logger
## Key Files
- src/infrastructure/CLIExecutor.ts - Spawns claude CLI processes
- src/infrastructure/SessionStore.ts - SQLite session persistence
- src/services/SessionService.ts - Session CRUD, per-session queue
- src/utils/cliArgs.ts - Maps API request options to CLI flags
## Critical Requirements
- Node.js 20 required (better-sqlite3 native bindings)
- Claude CLI must be installed and authenticated
## Code Patterns
- ESM modules ("type": "module" in package.json)
- Strict TypeScript with noUnusedLocals, noUnusedParameters
- Zod for request validation
- Winston for logging
- Vitest + Supertest for testingThat’s it. Commands, architecture, key files, critical requirements, patterns. Claude has enough context to navigate the codebase and make informed decisions without being overwhelmed by noise.
Plugins Are Your Friends—But Only If You Curate Them
Plugins are a powerful extension mechanism for Claude Code. They can add new skills, commands, and behaviors. They can also be a minefield.
When I adopt a plugin, I never use it as-is. I review the code, look for inconsistencies, and refactor to fit my style and needs. This isn’t paranoia—it’s pragmatism.
You cannot trust that plugins are well-built or maintained. Not even the official ones.
Case in point: Anthropic’s own plugin-dev plugin is incomplete and not properly tested. I had to do significant work to get it to a usable state. That work became my own claude-plugin-development plugin, which I’ve shared back with the community.
Is my version perfect? No. It runs error-free at least, but there are still rough edges I need to clean up. That’s the point—plugins require ongoing curation. Keep them in a marketplace you control, review them regularly, and improve them as you find issues.
The Hidden Cost: Token Consumption
Here’s something that surprised me: plugins consume tokens and bloat your prompts. Be very careful about how many you add.
The numbers are sobering:
- Claude Code’s baseline tools context: ~18,000 tokens on each session start
- System prompt: ~3,000 tokens
- Combined: Over 20% of your token quota consumed before you’ve even typed anything
Each plugin you add increases not just token usage but the chance of conflicts and unexpected behavior. Plugins should be composable, tested, and maintained to work well together. This isn’t optional—it’s essential.
Testing LLM Prompts
This brings up an important question: how do you test an LLM prompt?
Traditional unit tests don’t quite fit. The output is non-deterministic. The same input can produce different outputs. Quality can vary wildly between runs.
This is why I built prompt-bench and include it in my curated plugin list. It lets me create test suites for prompts and run them automatically to verify expected behavior.
If you’re using multiple plugins that might conflict, prompt testing isn’t a nice-to-have—it’s necessary hygiene.
My Curated Plugin Stack
Use this as inspiration, not a copy-paste solution. Review the code. You’ll find mistakes and gaps I’ve left. Iterate on those gaps. Improve them to fit your own style.
It’s perfectly fine to grab someone else’s plugin, pull it into your own marketplace, and modify it. That’s the whole point.
Setting Up the Marketplace
/plugin marketplace add astrosteveo/marketplaceInstalling Plugins
/plugin install claude-plugin-development@astrosteveo-claude-plugins
/plugin install prompt-bench@astrosteveo-claude-plugins
/plugin install claude-code-setup@astrosteveo-claude-plugins
/plugin install claude-md-management@astrosteveo-claude-plugins
/plugin install feature-dev@astrosteveo-claude-plugins
/plugin install frontend-design@astrosteveo-claude-pluginsHow I Actually Work
After all this setup talk, here’s what daily usage looks like.
Trivial Tasks: Just Ask
For simple, self-contained tasks, I don’t reach for any special tools or modes. I just ask Claude directly:
❯ design and implement Winston for logging in my Claude Code REST API
project, ensuring logs are written to both console and a file with
appropriate log levelsClaude has enough context from the CLAUDE.md to understand the project’s patterns and constraints. It knows we use ESM modules, strict TypeScript, and Vitest for testing. It can make informed decisions without me spelling everything out.
Complex Tasks: Plan Mode
For anything with architectural implications or multiple moving parts, I use /plan to enter plan mode before implementation:
❯ /plan build a new and improved desktop site landing pageIn plan mode, Claude explores the codebase, understands existing patterns, and proposes an implementation strategy before writing any code. I can review, ask questions, and course-correct before any files are touched.
For frontend work, I invoke specific skills during implementation:
❯ build a new and improved desktop site landing page, during implementation,
please use Task tool and invoke the frontend-design skillThe skill brings domain-specific knowledge about design patterns, accessibility, and modern CSS techniques that generic prompting would miss.
The Meta Point
The specific tools and plugins I use will evolve. The underlying philosophy won’t:
- Stay minimal—complexity has costs that compound over time
- Curate everything—don’t trust defaults, even official ones
- Test your prompts—LLM behavior needs verification like any other code
- Build your own workflow—what works for me won’t work for you without adaptation
I’m not an authority. I’m just someone who’s spent time figuring out what works in my particular context. Take what’s useful, ignore what isn’t, and build something that fits your brain.
This is the workflow I’ve developed over time. It’s not prescriptive—it’s descriptive. If you’ve found approaches that work better for your situation, that’s exactly how it should be.