DEV Community: UNTAKA corp

How I structured Claude Code to run 6 autonomous agents without losing control

UNTAKA corp — Sun, 24 May 2026 16:28:10 +0000

This is Part 2 of Building with Claude Code. Part 1 covers the basic .claude/ folder setup for freelance web dev.

I've been using Claude Code for several months. Like most developers, I started by using it as a fast autocomplete — type a question, get code, repeat.

The problem: every session started from scratch. No memory of the project state, no way to pick up where I left off, no structure that would hold across sessions.

So I built a structured system. Here's the architecture and the key insight that made it work.

The Core Problem With "Chatbot Mode"

When you use Claude Code as a chatbot, you're implicitly rebuilding context every single session. You re-explain the project, re-explain the constraints, re-explain where you are. It's fast — but you're paying the setup cost every time.

The other problem: a chatbot doesn't have a decision framework. It improvises. Sometimes that's great. For long-running autonomous work, improvisation is the failure mode.

The Architecture: 4 Components

1. CLAUDE.md as Project DNA

This is the mandatory startup file. Claude Code reads it first, before any action.

A good CLAUDE.md has five sections:

Identity — what the project is, what stack, who operates it
Startup sequence — exact steps to execute at session start (read this file, read RUNBOOK.md, run diagnostic)
Autonomous permissions — what Claude can do without asking, what requires human approval
Current state — 3 lines: current phase, last action, next action
Rules — 5-10 non-negotiable constraints

The autonomous permissions section is the one most people skip. It's the most important. Without it, the system either asks permission for everything (annoying) or assumes permission for everything (dangerous). With it, you define the boundary precisely.

The current state section updated at every session end means any new session orients in 30 seconds.

2. Specialized Agents with YAML Frontmatter

Agents live in .claude/agents/. Each is a markdown file with YAML frontmatter:

---
name: judge
description: "Scores opportunities 0-100, selects Top5/Top3. Read-only access."
tools: Read, Glob, Grep
model: sonnet
permissionMode: default
---

The key insight: give each agent exactly the tools it needs for its role, nothing more.

Scout: WebSearch, WebFetch, Write (to data/pipeline/ only)
Judge: Read, Glob, Grep (scoring only, no writes)
Builder: Read, Write, Edit — but only inside experiments/<id>/
Compliance: Read everything, write only to docs/swarm/COMPLIANCE_REVIEW_*.md
Treasury: Read data/portfolio/, Write data/portfolio/ only

Constraints are features. They make the system predictable. A Builder that can't touch governance files is a Builder you can trust to run autonomously.

Model layering matters for cost:

Scout runs on Haiku: cheap, fast, good enough for web search and extraction
Judge and Builder run on Sonnet: better reasoning for decision-critical steps
Not everything needs the most expensive model

3. settings.json as the Safety Layer

This is where governance becomes real — not just documented, but enforced at runtime:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(curl *)"
    ],
    "ask": ["Bash(*)"],
    "allow": ["Read", "Write", "Edit", "Glob", "Grep"]
  }
}

The .env files are unreadable at the runtime level — not just documented as off-limits. Any Bash command requires human approval before execution. The deny list is the actual safety boundary.

4. RUNBOOK.md as the Heartbeat

One file, always current:

# RUNBOOK
Last updated: 2026-03-31 14:32

## Current Phase: Build — exp_002
## Last Action: Builder completed guide at 14:32
## Next Action: Human to create ZIP and upload to Gumroad
## Scheduled: /portfolio-review at D+1, /kill-or-scale at D+14

Any agent reading this knows exactly what's happening. No re-explaining. 30-second context restore.

The Decision Pipeline

The system runs every idea through a pipeline before touching code:

DISCOVERY → SCORING → COMPLIANCE → DECISION → BUILD → LAUNCH

Each stage has explicit rejection criteria. The pipeline has killed more ideas than it's built — that's the point.

Scoring model: 10 dimensions

Buyer clarity (does the buyer know they have this problem?)
Urgency (does it hurt now, or is it a nice-to-have?)
Build speed (can it ship in under 8 hours?)
Support burden (will this generate support tickets?)
Stack fit (can we build it with what we have?)
+ 5 more

Auto-reject rules: score < 50, build time > 8 hours, support burden > 2 hours/month.

The result: you only build things that have a real shot at working.

What I Learned Running This

The governance layer is the most valuable part, not the least. Writing hard prohibitions forces clarity about what the system is for. "No paid advertising spend" and "no daily manual intervention required" aren't constraints — they're design decisions made in advance, when you're thinking clearly, before you're in the middle of a build and tempted to cut corners.

RUNBOOK.md matters more than I expected. Every time I skipped updating it, the next session was painful. Every time I kept it current, the next session started in 30 seconds.

Model layering saves real money. Running discovery on Haiku and only escalating to Sonnet for actual decisions made the whole system sustainable at scale.

The Quick Start (3 Files, 10 Minutes)

You don't need the full 6-agent system. Start with this:

CLAUDE.md — identity, startup sequence, autonomous permissions, current state, 5 rules
RUNBOOK.md — current phase, last action, next action
.claude/settings.json — deny .env, deny rm -rf, ask on all Bash

10 minutes of setup. Your next Claude Code session will feel fundamentally different.

How I organized my Claude Code workflow with skill folders (and stopped wasting 10 minutes per session)

UNTAKA corp — Tue, 19 May 2026 15:43:05 +0000

If you're using Claude Code for freelance web dev, you've probably experienced this loop:

Open Claude Code
Spend 10 minutes explaining your stack, conventions, and project structure
Start working
Close session
Tomorrow: repeat from step 1

I was doing this 3-4 times a day across client projects. That's 30-40 minutes of pure context-setting — per day. So I built a system that eliminates it entirely.

This isn't a tutorial on prompting. It's a tutorial on the native Claude Code configuration system that most developers use at 20% capacity.

The fix: CLAUDE.md + Agents + Skills

Claude Code has three configuration layers that work together:

CLAUDE.md — A markdown file at your project root. Claude Code reads it automatically at every session start. Think of it as your project's "brain download" for the AI. Stack, conventions, rules, current state — all of it. One read, zero explaining.

Agents — YAML-fronted markdown files in .claude/agents/. Each defines a specialized AI role with specific tools, model settings, and instructions. The key insight: give each agent only the tools it needs. A code reviewer doesn't need Bash. A client communicator doesn't need file write access.

Skills — Markdown files in .claude/skills/. These create slash commands (/code-review, /deploy-vercel, etc.) that package your most repeated workflows into a single invocable command.

Example: My freelance CLAUDE.md

Here's a stripped-down version of what I use for Next.js + Supabase + Tailwind projects:

# CLAUDE.md — Freelance Web Dev Project

## Project Identity
- **Stack**: Next.js 14+ (App Router) · TypeScript (strict) · Tailwind CSS · Supabase
- **Deploy**: Vercel
- **Package manager**: pnpm

## Code Conventions
- Server Components by default. "use client" only when necessary.
- Zod for validation. react-hook-form for forms.
- Absolute imports with @/ prefix.

## Session Rules
- Read this file first. Read RUNBOOK.md second.
- Never touch .env files.
- Run `pnpm build` before any commit.

## Current State
- Phase: [fill in at session end]
- Last action: [fill in at session end]
- Next action: [fill in at session end]

Claude reads this in under 2 seconds. Session starts with full context. The "Current State" section at the bottom is the most underrated part — update it at session end, and the next session orients in 30 seconds instead of 10 minutes.

Example: A code review agent

---
name: senior-dev
description: "Code review before client delivery. Invoke with: @senior-dev review <path>"
tools: Read, Glob, Grep
model: sonnet
---

You review code for: TypeScript errors, missing error handling,
Supabase RLS configuration issues, client/server split correctness,
accessibility (ARIA labels, keyboard nav), and security (XSS, unsanitized input).

Output: severity-rated findings (CRITICAL / WARNING / INFO).
Flag anything that would be embarrassing to deliver to a client.

Type @senior-dev review src/ and you get a structured pre-delivery report. I caught a Supabase RLS misconfiguration this way before a client saw it.

Two points worth noting:

tools: Read, Glob, Grep — no write access, no Bash. The agent can review but cannot modify or execute anything.
model: sonnet — this is the model that costs more. I only use Sonnet for review, not for scaffolding. Model layering saves real money at scale.

Example: A feature scaffolding skill

---
description: "Scaffold a new feature with consistent structure."
argument-hint: "<feature-name>"
allowed-tools: Read, Write, Glob
---
# /dev-kickstart

Creates: component file, page route, Zod type definitions, custom hook.
Follows naming conventions from CLAUDE.md.
Includes loading.tsx and error.tsx in every route segment.

Type /dev-kickstart auth-flow and Claude scaffolds the entire feature following your project conventions. Not a generic scaffold — your conventions, your structure.

The result

Before: 10 min context per session, inconsistent outputs, no pre-delivery safety net.

After: 0 min context, consistent patterns across all client projects, automated code review before every delivery.

The ROI math: 10 minutes saved × 4 sessions/day × 20 working days = 13+ hours/month. That's a full billing day recovered.

The full setup

I run 3 CLAUDE.md templates (freelance, SaaS MVP, e-commerce), 3 agents (senior-dev, qa-tester, client-communicator), and 7 skills (dev-kickstart, code-review, deploy-vercel, generate-api-route, create-component, fix-bugs, write-tests).

If you want to build your own: the format above is everything you need. Start with a single CLAUDE.md and one agent. Add skills when you notice yourself doing the same workflow three times.

If you'd rather start from a working setup: I packaged everything above as a $19 bundle — Claude Code Skill Folders on Gumroad. Drop-in, 2-minute install.

Questions or variations welcome in the comments — especially curious what agents other freelancers have found useful.

Part 2: The Blueprint Method — how to turn Claude Code into a full autonomous operating system (agents, hooks, decision pipeline, governance layer). Coming next week.

Stop re-explaining your stack to Claude Code: a project-scoped skill folder system

UNTAKA corp — Wed, 01 Apr 2026 03:26:02 +0000

Stop re-explaining your stack to Claude Code

If you use Claude Code daily, you know the ritual.

You open a session, and for the next 10 minutes you type variations of:

"This is a Next.js 14 project using App Router, TypeScript strict mode, Tailwind for styling, Supabase for auth and database, we deploy to Vercel, the file structure follows..."

Across 3-4 sessions a day, that's 30-40 minutes of pure context-setting. Multiply by working days in a month and you get roughly 12 hours per month re-explaining the same thing to the same tool.

This article shows a small, boring, permanent fix. No prompts to copy-paste. No tool you have to remember to invoke. No subscription. It uses three Claude Code primitives you might already know about but likely haven't fully wired up: CLAUDE.md, agents with YAML frontmatter, and SKILL.md folders.

We'll build a minimal working example, then I'll show what a fully loaded setup looks like.

The three primitives

Claude Code automatically reads configuration from your project root on every session start. The three important pieces:

File	Location	What it does
`CLAUDE.md`	Project root	Free-form markdown. Claude reads it every session. Put your stack, conventions, commands, and "rules I'm tired of repeating" here.
Agents	`.claude/agents/*.md`	YAML-fronted markdown files. Each one defines a sub-agent with its own system prompt, model, and tool restrictions. Invoked with `@agent-name`.
Skills	`.claude/skills/<name>/SKILL.md`	Slash-command workflows. A SKILL.md file becomes `/name`. Great for repetitive multi-step work.

The win is that all three load automatically. You don't remember to use them — they're just there.

Step 1 — A real CLAUDE.md for freelance work

Here's a stripped version of what lives in my client projects:

# CLAUDE.md — Next.js client project

## Stack
- Next.js 14 (App Router) · TypeScript strict · Tailwind · Supabase (SSR)
- Deploy: Vercel · Package manager: pnpm

## Conventions
- Server Components by default. `"use client"` only where actually required.
- Zod for all user input validation. `react-hook-form` for forms.
- Absolute imports with `@/` prefix.
- Every `app/*` route must have `loading.tsx` and `error.tsx`.
- Never commit `.env*` files. Never log Supabase service role keys.

## Commands you can run
- `pnpm dev` — dev server
- `pnpm build` — production build (must pass before I commit)
- `pnpm type-check` — tsc --noEmit
- `pnpm lint` — ESLint

## Behavior
- Before any code change, run `type-check` and `lint`. If they fail, fix first.
- After any code change affecting routes, show me the diff before applying.
- Never assume a package is installed. Read `package.json` first.

That's it. Save it at the project root. Close your session. Reopen it. Claude now knows your stack without you typing a word.

The subtle but important part is the Behavior section. Most devs stop after listing the stack. The real value is encoding your own review rituals — the stuff you keep catching yourself reminding the model about.

Step 2 — A sub-agent for pre-delivery code review

Create .claude/agents/senior-dev.md:

---
name: senior-dev
description: Code review before client delivery
tools: Read, Glob, Grep
model: sonnet
---

You are a senior full-stack reviewer. Your job is to review code
BEFORE it ships to a paying client.

Check for, in priority order:
1. TypeScript errors or `any` that should be typed
2. Missing error handling on async boundaries
3. Supabase RLS issues — queries that bypass row-level security
4. Client/Server component split correctness (no client-only code
   in Server Components, no secrets in Client Components)
5. Accessibility regressions (missing aria-labels, bad contrast,
   non-semantic HTML)
6. XSS / unsanitized input in forms or URL params

Output format: a table with file:line, severity (high/med/low),
issue, and a one-line fix suggestion. No prose. No praise.

The tools: Read, Glob, Grep line matters — it means this agent is read-only. You can invoke it on a repo without worrying it'll edit files. Defense in depth for an LLM.

Now in any session you can type:

@senior-dev review src/app/dashboard

And you get a terse, structured report. No more "Claude I know you want to be encouraging but please just tell me what's broken."

Step 3 — A slash command for scaffolding

Create .claude/skills/dev-kickstart/SKILL.md:

---
description: Scaffold a new feature with consistent project structure
argument-hint: <feature-name>
allowed-tools: Read, Write, Glob
---

# /dev-kickstart

Given a feature name, create the full scaffolding:

1. `app/<feature>/page.tsx` — route using Server Component pattern from CLAUDE.md
2. `app/<feature>/loading.tsx` and `error.tsx` (per project convention)
3. `components/<feature>/<Feature>Client.tsx` — client component only if needed
4. `lib/<feature>/types.ts` — Zod schemas + inferred TS types
5. `lib/<feature>/queries.ts` — Supabase query helpers

Follow the naming conventions and import aliases from CLAUDE.md.
Do not install new dependencies. Do not commit. Show me the tree
of created files at the end.

Now /dev-kickstart auth-flow scaffolds a complete feature following your conventions, not generic ones.

The key difference versus a prompt template: this is a Claude Code native format. The YAML frontmatter tells Claude Code which tools to permit and how to label the command in the UI. It's a first-class citizen, not a string hack.

Why this beats prompt libraries

Prompt libraries (the "100 prompts for developers" PDFs you see everywhere) have three problems:

You have to remember to use them. A prompt sitting in a Notion page is functionally dead.
They're not scoped. A general prompt for "code review" can't know your Supabase tables or your import aliases.
They can't restrict tools. A prompt can ask nicely. A skill with allowed-tools: Read, Glob, Grep literally cannot write files.

Skill folders fix all three. They live in the repo, they load automatically, and they can scope capabilities.

What a fully loaded setup looks like

After using this pattern across a few projects, my client-work template grew into this shape:

your-project/
├── CLAUDE.md                          ← stack, conventions, rituals
└── .claude/
    ├── settings.json                  ← security defaults (block .env reads, etc.)
    ├── agents/
    │   ├── senior-dev.md              ← pre-delivery review
    │   ├── qa-tester.md               ← bug + a11y hunting
    │   └── client-communicator.md     ← drafts client emails
    └── skills/
        ├── dev-kickstart/SKILL.md     ← scaffold features
        ├── code-review/SKILL.md       ← full repo review
        ├── deploy-vercel/SKILL.md     ← pre-deploy checklist
        ├── generate-api-route/SKILL.md
        ├── create-component/SKILL.md
        ├── fix-bugs/SKILL.md
        └── write-tests/SKILL.md

Nothing fancy. Just boring discipline, encoded once.

The 15-minute starter

If you want the fastest version of this:

Create CLAUDE.md at your project root with sections: Stack, Conventions, Commands, Behavior. Write each section as bullet points of things you're tired of explaining.
Create .claude/agents/senior-dev.md with the template above, adapted to your stack.
Close your Claude Code session. Reopen it in the same project. Type @senior-dev review src/ on a random file.
Watch it work.

That's it. From here you add agents and skills as you catch yourself repeating instructions.

If you want the full bundle

I packaged my complete setup — 3 project templates (freelance Next.js, SaaS MVP, e-commerce Stripe), 3 agents, 7 skills, and a hardened settings.json — as a drop-in bundle. It's on Gumroad for $19 if you'd rather not assemble your own.

But honestly, the real value is in the pattern, not the bundle. Everything above is enough to get started. Copy the templates, adapt them to your stack, and watch your session start-up time drop to zero.

If you build your own skill folder, drop a comment with what's in it — I'm curious how other people structure theirs.