Design Your Agent's
Control Plane

Your coding agent doesn't need a bigger prompt — it needs a better control plane. Put every instruction in the layer where it belongs.

my-app/ ├── CLAUDE.md └── .claude/ ├── rules/ │ ├── frontend.md │ ├── api.md │ └── database.md ├── skills/ │ ├── deploy/SKILL.md │ ├── launch-copy/SKILL.md │ ├── seo-audit/SKILL.md │ └── release-notes/SKILL.md ├── agents/ │ ├── code-reviewer.md │ ├── security-auditor.md │ └── growth-researcher.md └── settings.json
01

CLAUDE.md

Always on

Always-on context: architecture, repository map, build & test commands, team conventions.

Example: npm test before completion
02

Rules

Load by scope

Context by scope: framework patterns, API contracts, database conventions — loaded only when relevant.

Example: frontend rules only for src/ui/**
03

Skills

Repeatable playbooks

Deployments, launch copy, SEO audits, release notes and other recurring workflows.

Use when you keep repeating the same workflow
04

Agents

Isolated specialists

Code review, security audits and research — separate context that doesn't pollute the main thread.

Use when noisy work should not pollute main context
05

Hooks

Deterministic control

Format after edits, block secrets, run tests, validate completion — enforced every time, not suggested.

Wired through settings.json

Where does the instruction go?

Always true?CLAUDE.md
File-specific?Rule
Repeatable?Skill
Needs own context?Agent
Must happen?Hook
Context tells. Skills teach. Agents delegate. Hooks enforce.
That's the move from "prompting Claude" to designing an agentic engineering system.
Roadmap: keep CLAUDE.md short · scope rules · package repeatable work as skills · delegate noisy work to agents · enforce with hooks