Command → Agent → Skill Architecture

Command → Agent → Skill three-layer architecture

User input / command trigger
       │
       ▼
┌──────────────┐    Command (entry point) 
│  /command    │    .claude/commands/*.md
└──────┬───────┘
       │ Agent tool
       ▼
┌──────────────┐    Agent (executor) 
│  Agent       │    .claude/agents/*.md
└──────┬───────┘
       │ Preload/invoke Skill
       ▼
┌──────────────┐    Skill (knowledge) 
│  Skill       │    .claude/skills/*/SKILL.md
└──────────────┘

• Command — User entry point. Orchestrates Agent call order. 82 built-in custom

• Agent — Independent context executor. Can run in parallel. 5 built-in custom

• Skill — Reusable instruction pack. Loaded or invoked. 10 built-in custom

Comparison

Decision guide: Need to orchestrate multi-step flows chaining multiple Agents → Command. Need independent context, parallel execution, tool isolation → Agent. Need reusable instruction packs loaded across scenarios → Skill.

Relationships and use cases

Why Harness Matters

Output quality formula: quality = f(effective_context, model_capability, iteration_loops) Harness directly impacts “effective context” and “iteration loops”.

Harness: 10 Core Capabilities

“Skills, Commands, Subagents all become prompts in the end, so strong prompts are enough?” — Technically true, practically false. Here’s what Harness does at layers prompts can’t reach:

User input: "Write a recursive flatten function"     ← (a) ~6 tokens

What the model actually sees:                       ← (b) ~15,000 tokens
  ├── CLAUDE.md (Project specs)
  ├── Matched .claude/rules/*.md (paths trigger)
  ├── Modular system prompt fragments (110+)
  ├── Tool definitions
  ├── Environment context (cwd, git status, platform)
  ├── Previous conversation turns
  ├── Files read via Read/Grep
  └── User's 6-token request

Subagents

5 Built-in Types

Custom Agent Frontmatter (16 Fields)

Commands System (82 Built-in)

Claude Code has 82 built-in slash commands, organized into 11 categories. Custom commands go in .claude/commands/*.md.

Custom commands: Place in .claude/commands/*.md, supports 16 frontmatter fields (name, description, argument-hint, arguments, context, etc.). Use “!`command``` for dynamic context injection.

Orchestration Patterns

Weather Reporter full orchestration flow animation

User: /weather-orchestrator
       │
       ▼
┌──────────────────────────┐
│  weather-orchestrator    │  ← Command (entry point) 
│  1. Ask temperature unit C/F   │
│  2. Call weather-agent   │
│  3. Call svg-creator     │
└──────┬───────────────────┘
       ▼
┌──────────────────────────┐
│  weather-agent           │  ← Agent
│  preload: weather-fetcher │  ← Skill (preloaded) 
└──────┬───────────────────┘
       ▼
┌──────────────────────────┐
│  weather-svg-creator     │  ← Skill (invoked) 
│  output: weather.svg         │
└──────────────────────────┘

Tasks System

Claude Code’s built-in task tracking system supports creation, querying, updates, and dependency management. Works with Subagents and Skills.

4 Core Tools

Task Lifecycle

pending → in_progress → completed
                 ↘ deleted

Dependencies

• addBlocks — Marks “specified task cannot start until this task completes”
• addBlockedBy — Marks “this task must wait for specified task to complete before starting”
• Forms a DAG (Directed Acyclic Graph), ensuring execution order

Environment Variable: CLAUDE_CODE_TASK_LIST_ID identifies current task list, file persisted in ~/.claude/tasks/.

Skills System

Key insight: A Skill is a folder (not just a Markdown file). It can contain scripts, data, resources, config templates — anything an Agent can discover, read, and manipulate. SKILL.md is the entry point, but not the whole picture. See Orchestration for a real example.

Skills live in .claude/skills/<name>/SKILL.md with auto-discovery and triggering. At session start, Claude scans all available skill description fields to match the current task.

• Progressive Info Loading — Tell Claude what files are in the folder via SKILL.md; it reads details only when needed. Avoids loading all info at once and wasting context.

• Description Is for the Model — The description field isn’t a summary — it’s a trigger condition description. Write clearly “when should this skill be used,” and Claude auto-matches accordingly.

9 Config Patterns

2 Loading Modes

• Preload Mode (Agent Skills) — Loaded via Agent’s skills: field. Auto-injected at Agent startup.

• Invoke Mode (Invoked Skills) — Triggered via Skill tool or /skill-name. Claude can also auto-match and invoke.

9 Usage Categories

Distilled from hundreds of internal Anthropic skills (Thariq, 2026.03). A good skill belongs to one category; skills spanning multiple usually need splitting.

16 Frontmatter Fields

10 Built-in Skills

Hooks System

Lifecycle event-driven automation scripts. Configured in .claude/settings.json or Agent frontmatter.

4 Hook Types

Agent Frontmatter limitation: Only 6 Hook events are available in Agents: PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest, Stop, SubagentStop. The other 21 events are only available in the main session.

27 Lifecycle Events

Grouped by function. All events support async and timeout options.

Config Examples

Hooks are configured in Settings, or via Skill frontmatter per-need activation.

{
  "hooks": {
    "Stop": [{
      "type": "command",
      "command": "python3 .claude/hooks/scripts/hooks.py --event Stop"
    }],
    "PostToolUse": [{
      "type": "command",
      "command": "python3 .claude/hooks/scripts/hooks.py --event PostToolUse"
    }]
  }
}

Advanced Tool Usage

Prompt-to-Code (PTC) — Paradigm Shift

Instead of stuffing instructions into the system prompt, PTC compiles them into executable code rules that run in a sandbox. Result: shorter prompts, more precise reasoning, ~37% token savings.

{
  "type": "code_execution_20250825",
  "name": "data_processor",
  "allowed_callers": ["code_execution_20250825"],
  "input_schema": {
    "type": "object",
    "properties": {
      "task": { "type": "string" }
    }
  }
}

PTC Advanced Patterns

• Batch Processing — Loop through multiple records in a single PTC call, reducing tool invocations. Ideal for batch translation, classification, etc.

• Early Termination — Add conditional checks in code to return immediately when threshold is met. Avoids unnecessary computation.

• Conditional Branching — Dynamically select different processing branches based on input type, instead of defining separate tools for each.

PTC Constraints

Dynamic Tool Filtering

Web Search / Web Fetch results are pre-processed by code before entering context, rather than injected raw. Requires beta header anthropic-beta: code-execution-web-tools-2026-02-09.

Tool Search

Mark infrequently used tools with defer_loading: true; the model searches and loads them on demand, reducing tool definitions by ~85%.

// Tool definitionsExample
{
  "name": "specialized_analyzer",
  "defer_loading": true,
  "description": "..."
}

// Claude Code environment variable
ENABLE_TOOL_SEARCH=auto:5  // Keep 5 common tools, defer the rest

Tool Use Examples

Add an input_examples array (1-5 items) to tool definitions with real data samples. Model call accuracy jumps from 72% to 90%.

{
  "name": "query_database",
  "input_examples": [
    { "sql": "SELECT * FROM users WHERE active = true LIMIT 10" },
    { "sql": "SELECT COUNT(*) FROM orders WHERE date > '2026-01-01'" }
  ]
}

Availability in Claude Code

CLI User Priority: Configure Tool Use Examples and Tool Search in CLAUDE.md first (ENABLE_TOOL_SEARCH=auto:5). These provide the most benefit for CLI users. PTC and Dynamic Filtering are primarily for SDK/API deep integration scenarios.

Settings 5-Layer Priority

Managed Settings Delivery Methods

Core Settings

Deny rules always have highest priority — deny at any level overrides all allow rules. Array settings are merged and deduplicated across levels, not replaced.

Managed Layer Internal Priority

Within the managed layer, sources are used in this order (only one source, no cross-layer merging):

v2.1.126 Change: /config now persists changes to ~/.claude/settings.json instead of keeping them in memory only. Edits via the interactive Config UI survive restarts.

Permission Modes

Configure via permissions key in Settings.

Tool Permission Syntax

Path Prefixes

Matching Rules

• Compound commands: Split by &&, ||, ;, |, each sub-command matches independently. Bash(safe-cmd *) does not cover safe-cmd && other-cmd
• Wildcard position: * can appear as prefix, suffix, or infix. Bash(* install) matches npm install; Bash(git * main) matches git push main
• Word boundary: Bash(ls *) (with space) does not match lsof; Bash(ls*) (no space) matches both
• Symlinks: allow requires both symlink and target both in allowed dirs; deny triggers on either
• Process wrappers: timeout, time, nice, nohup stripped before matching. watch, find -exec always prompt

Global vs Project Config

• Global ~/.claude/ — settings.json Global settings CLAUDE.md All project instructions Best for: personal preferences, general config, shell aliases

• Project .claude/ — settings.json Team shared (committed) settings.local.json Personal override (git-ignored)) CLAUDE.md Project instructions agents/ SubAgent definitions skills/ Skill definitions commands/ Custom commands

6 Configuration Dimensions

Directory Structure

~/.claude/                          .claude/
├── settings.json      ← Global settings    ├── settings.json      ← Team shared
├── settings.local.json               ├── settings.local.json ← Personal override
├── CLAUDE.md          ← Global instructions    ├── CLAUDE.md          ← Project instructions
├── mcp.json           ← Global MCP    ├── agents/            ← Subagent definitions
├── agents/            ← Global agents    │   ├── reviewer.md
│   ├── explorer.md                   │   └── coder.md
│   └── researcher.md                 ├── skills/            ← Skill definitions
├── skills/            ← Global skills    │   ├── lint-check/
│   └── deploy-check/                 │   │   └── SKILL.md
├── commands/          ← Global commands    │   └── test-runner/
│   └── review.md                     │       └── SKILL.md
├── plans/             ← Plan files    ├── commands/          ← Custom commands
├── tasks/             ← Task persistence  │   └── commit.md
├── memory/            ← Auto memory    ├── rules/             ← Conditional rules
└── plugins/           ← Plugin installs    │   ├── tests.md
                                      │   └── security.md
                                      └── mcp.json           ← Project MCP

6 Design Principles

Global-Only Features

• allowedPlugins / deniedPlugins — Plugin allowlist/denylist
• managedSettings — IT-deployed org-level config
• autoUpdatesChannel — Update channel control
• cleanupPeriodDays — Session auto-cleanup
• pluginRegistry — Custom plugin source
• plansDirectory — Global plan files directory
• autoMemoryEnabled — Memory system toggle

CLAUDE.md Specification

CLAUDE.md is the single most impactful configuration in Claude Code. A well-structured CLAUDE.md improves output quality more than any Settings tuning.

4 Storage Locations

.claude/rules/ Conditional Loading

• With paths: frontmatter — Lazy-loaded only when operating on matching paths. Ideal for framework-specific rules, e.g. paths: ["src/**/*.test.ts"] loads only when editing test files.

• Without frontmatter — Loaded every session, equivalent to CLAUDE.md. Best for project-wide rules.

Writing Guidelines

• Keep under 200 lines — compliance drops beyond this
• Write WHY not WHAT — code already explains WHAT; document hidden constraints, subtle invariants, workarounds for specific bugs
• Negative instructions are more effective — “don’t use pattern X” is clearer than “use pattern Y”
• Don’t state the obvious that code already expresses — CLAUDE.md’s value is pushing Claude out of default thinking
• Don’t save code patterns, architecture snapshots, or git history — these are derivable from code
• Include project-specific constraints: build order dependencies, known incompatible library versions, special deployment processes

claudeMdExcludes

Use claudeMdExcludes setting to skip unwanted CLAUDE.md files:

{
  "claudeMdExcludes": [
    "**/vendor/**/CLAUDE.md",
    "**/node_modules/**/CLAUDE.md"
  ]
}

Exclusion applies to user, project, and local memory only; managed policy files cannot be excluded.

Monorepo Loading Mechanism

CLAUDE.md loading mechanism in monorepos (Boris Cherny original)

• Ancestor Loading — At startup, traverses upward and immediately loads all CLAUDE.md files. Immediate

• Descendant Loading — Subdirectory CLAUDE.md files load only when operating in that directory. Lazy

Scenario Comparison

Assume monorepo structure: frontend/CLAUDE.md, backend/CLAUDE.md, api/CLAUDE.md, root CLAUDE.md.

Scenario 1: Start from root cd /mymonorepo && claude

Scenario 2: Start from component directory cd /mymonorepo/frontend && claude

Best practice: Shared conventions in root CLAUDE.md, component-specific instructions in component CLAUDE.md. Personal preferences in CLAUDE.local.md (git-ignored).

Auto Memory

Claude Code ‘s auto memory system persists information across sessions. Memory files are stored in the project .claude/ directory or global ~/.claude/, organized in YAML frontmatter + Markdown format.

4 Memory Types

Memory File Structure

Each memory is an independent Markdown file using YAML frontmatter:

---
name: feedback-testing
description: Testing preferences and corrections
metadata:
  type: feedback
---

Integration tests must use a real database, not mocks.
**Why:** Last quarter a migration failed due to mock/production environment divergence. 

[[testing-patterns]]  ← link to related memory

MEMORY.md Index

All memories are managed via the MEMORY.md index file, kept under 200 lines. Index format per line:

- [Title](filename.md) — one-line summary

What NOT to Save

• Code patterns, architecture, file paths — derivable from code
• Git history, recent changes — git log is authoritative
• Debug solutions — the fix is in code, context in commit message
• Content already covered in CLAUDE.md
• Ephemeral task details — use Task or Plan instead

Configuration

Agent Memory 3 Scopes

With Subagents, Memory can persist knowledge across agents.

Keep the MEMORY.md index file under 200 lines.

MCP Services

Common MCP Services

MCP Settings Keys

Configuration Example

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-context7"]
    },
    "always-on-server": {
      "type": "http",
      "url": "https://mcp.example.com",
      "alwaysLoad": true
    }
  }
}

Key Features

• alwaysLoad (v2.1.121) — Set "alwaysLoad": true in server config to load all tools immediately instead of lazy discovery. Only for small tool sets needed every turn.

• Hot Reload (v2.1.139) — /mcp Reconnect re-reads .mcp.json without restarting the session. Also injects CLAUDE_PROJECT_DIR into stdio server environment.

Environment Variable Expansion

Use ${ENV_VAR} syntax in .mcp.json to reference environment variables, avoiding hardcoded secrets:

{
  "mcpServers": {
    "my-api": {
      "url": "https://mcp.example.com/mcp?token=${MCP_API_TOKEN}"
    }
  }
}

workspace is a reserved MCP server name (v2.1.128). User-defined servers with this name will be skipped with a warning.

OAuth-compatible servers complete authentication automatically (following RFC 9728), no manual apiKeyHelper config needed.

RPI Workflow

Research → Plan → Implement, each phase has a validation gate. Orchestrates multiple agent roles via Subagents.

Step 1: RESEARCH   → RESEARCH.md (GO / NO-GO) 
Step 2: PLAN       → PLAN.md + pm.md + ux.md + eng.md
Step 3: IMPLEMENT  → IMPLEMENT.md (phased, each phase has test gates) 

8 Agent Roles

3 Commands

rpi/{feature-slug}/
├── REQUEST.md              # Feature description
├── research/RESEARCH.md    # GO/NO-GO analysis
├── plan/
│   ├── PLAN.md             # Implementation roadmap (3-5 phases) 
│   ├── pm.md               # Product requirements document
│   ├── ux.md               # UX design draft
│   └── eng.md              # Technical specification
└── implement/IMPLEMENT.md  # Implementation log (per-phase verification) 

CRISPY Method

C — Clarify      Define requirements
R — Research     Technical research
I — Ideate       Brainstorm solutions
S — Structure    Architecture design
P — Plan         Create plan
Y — Yield        Produce implementation
  + Iterate      Iterate & refine

CRISPY is an evolution of RPI, adding Ideate and Structure phases, emphasizing that solution design matters more than implementation.

Cross-Model Collaboration (Claude + Codex)

Claude Code (Opus) + Codex CLI (GPT) cross-model 4-step collaboration workflow

STEP 1: PLAN          Claude Code Opus · Plan Mode
STEP 2: QA REVIEW     Codex CLI GPT · Review plan, insert findings
STEP 3: IMPLEMENT     Claude Code Opus · Phase-by-phase implementation
STEP 4: VERIFY        Codex CLI GPT · Verify against plan

**Core idea:**Different models review each other. Codex appends “Codex Finding” annotations without rewriting the original plan.

Agent Teams

Agent Teams multi-agent collaboration workflow

Coordinate multiple agents via shared task list (TaskCreate/TaskUpdate). Ideal for large refactors decomposable into independent subtasks.

Team Coordination Pattern

Take Time Orchestration as an example — three roles build in parallel, sharing a data contract {time, timezone, formatted}:

Agent Teams Component List

---
name: time-agent
description: Get current Dubai time (Asia/Dubai, UTC+4) 
tools: Bash
model: haiku
color: blue
maxTurns: 3
skills: time-fetcher
---
Use Bash to execute `TZ='Asia/Dubai' date`, return time/timezone/formatted fields. 

---
description: Get Dubai time and generate SVG time card
model: haiku
---
1. Agent(time-agent) → fetch {time, timezone, formatted}
2. Skill(time-svg-creator) → generate SVG card
Note: Must execute sequentially, cannot parallelize. 

---
name: time-fetcher
description: Fetch current Dubai time via bash
user-invocable: false
---
Command: TZ='Asia/Dubai' date '+%Y-%m-%d %H:%M:%S %Z'
Return format: { time: "HH:MM:SS", timezone: "GST (UTC+4)", formatted: "full output" }

---
name: time-svg-creator
description: Create Dubai time SVG card
allowed-tools: Write, Read
---
Receive time/timezone/formatted, generate self-contained SVG card. 
Output: agent-teams/output/dubai-time.svg + output.md

Scheduled Tasks

# CronCreate Parameters
cron: "*/5 * * * *"     # Standard 5-field cron (local timezone) 
prompt: "Check CI status"   # Prompt executed on trigger
recurring: true          # true=recurring, false=one-shot
durable: true            # true=persist to file

Goal-Driven

Automatically decompose and track progress with the task system.

1. User sets a goal
2. Claude decomposes into subtasks and creates a task list
3. Implement step by step, updating status each step
4. Request user input when blocked

Community Goal Tips

Session Management

Context Rot starts appearing at ~300-400k. Revert > Correct.

LLM Performance Degradation Analysis

Daily fluctuations in LLM output quality

9-Layer Inference Stack (Frozen Weights ≠ Frozen Behavior)

┌──────────────────────────────────────────────┐
│  User session context              ← In-session degradation    │
│  System Prompt                    ← Periodically updated      │
│  Post-Training (RLHF/fine-tuning)  ← Can update silently    │
│  Sampling params (temperature/top-p) ← Server-adjustable    │
│  Speculative Decoding (draft model) ← Quality fluctuation      │
│  MoE routing / batch composition   ← ±8-14% variance   │
│  Hardware routing (TPU/GPU/Trainium)← Different failure modes  │
│  Quantization level (FP16/INT8/INT4)← May change under load │
│  Compiler & runtime (XLA:TPU/CUDA) ← Confirmed bugs  │
├──────────────────────────────────────────────┤
│  Model weights (frozen) ← This layer does not change                    │
└──────────────────────────────────────────────┘

Key Findings

Anthropic 2025.9 Post-Mortem: 3 Infrastructure Bugs

Bug #1 — Context Window Routing Error

Bug #2 — TPU Output Corruption

Bug #3 — XLA:TPU Compiler Miscompilation (Most Tricky)

Claude runs on three different hardware platforms (AWS Trainium, NVIDIA GPU, Google TPU), each with different failure modes, compilers, and precision behavior. Your requests may hit different hardware on different days.

MoE Routing Variance (Scale AI Research)

In MoE (Mixture of Experts) architecture, the query composition of other users in the batch determines which experts your request is routed to — and this composition is non-deterministic.

Specific example: the same model scored 77% on jailbreak resistance one day and 63% the next — a 14-point swing with zero bugs, zero changes.

System Prompt & Post-Training Updates

Stanford Study (2023) — and Its Controversy

Chen/Zaharia/Zou’s landmark study found GPT-4 accuracy on “prime number judgment” dropped from 97.6% to 2.4% (Mar→Jun 2023), but had methodological issues:

• March version used temperature 0.0, June version used temperature 1.0 — a fundamental confounding variable
• Only 500 queries per task — sample size too small
• “Math problems” were actually yes/no questions, model guessing pattern changed rather than math ability declining
• Changes may be intentional post-training safety updates, not unintentional degradation

Psychological Factors

Codex 5.3 Comparison Analysis

When Claude has short-term degradation, Codex 5.3 may appear significantly better, reasons:

1. Product-Goal Fit — Codex is optimized for code generation, producing better coding results even at equal model strength
2. Reasoning Strategy Differences — Each provider independently tunes latency/reasoning depth/decoding defaults
3. Service Path Isolation — Different routing layers/compilers/release pipelines, one failing doesn’t affect the other
4. Release Timing — One provider mid-release while another is stable can create large temporary quality divergence

Degradation Hypothesis Ranking

Practical Recommendations

1. Lock model snapshots when available (instead of using floating aliases)
2. Store request metadata (model ID, parameters, latency, error rates)
3. Run fixed daily canary tests, alert on regression
4. Reset or compact long sessions after multiple failures
5. Maintain backup provider/model paths
6. Separate “model quality” from “service reliability” in internal dashboards

**The single most important action:**When quality feels degraded, use /compact or start a fresh session. This is the most effective single action — most “Claude got dumber” is context pollution, not model degradation.

Harness Importance

Common misconception: skill/command/subagent/hook all end up as prompts, so writing good prompts is enough. **This is wrong.**At the engineering level, the Harness is a prompt construction system + deterministic execution system + context architecture system.

Harness 10 Capabilities (cannot be replicated by prompts)

Output quality = f(effective context, model capability, iteration loops). Users control only a tiny fraction of effective context; the harness controls the rest and the entire iteration loop. Strong prompts are necessary but not sufficient.

Browser MCP Comparison

Recommended Workflow

# Install command
npx playwright install
claude mcp add playwright -s user -- npx @playwright/mcp@latest
claude mcp add chrome-devtools -s user -- npx chrome-devtools-mcp@latest

Playwright has the highest token efficiency (186.3k remaining), Chrome DevTools the lowest (181k remaining). Gap of ~5.3k tokens.

Monorepo Skill Discovery

Skills discovery/loading mechanism is different from CLAUDE.md: CLAUDE.md traverses upward (ancestor loading) , while Skills use nested directory auto-discovery (descendant discovery), and are only loaded on demand when editing files in the corresponding directory. See Monorepo Loading Mechanism.

Standard Skill Locations

CLAUDE.md vs Skills Loading Comparison

Character budget defaults to 15,000 characters, adjustable via SLASH_COMMAND_TOOL_CHAR_BUDGET environment variable. Use /context to check if any skills were excluded due to budget limits.

• General workflows go in root .claude/skills/
• Package-specific skills go in the corresponding package .claude/skills/
• Dangerous operation skills should set disable-model-invocation: true
• Use package name prefixes to avoid confusion (e.g. frontend-review, backend-deploy)

Usage & Limits

Monitoring Commands

Cost Optimization

• Use model: haiku for simple tasks
• effort: low reduces reasoning
• Background agent avoids blocking
• API key users use --max-budget-usd to control costs
• Configure extra-usage monthly cap to avoid unexpected charges

Fast Mode (/fast) counts as extra usage from the first token, not consuming subscription plan included quota. Must enable and fund extra-usage to use.

Spinner Verbs

Claude Code’s loading animation uses 179 random verbs. Common ones:

Learning Path

A complete learning journey building a Weather Reporter from scratch, through 5 major phases · 37 slides:

Phase Order (reordered by cognitive dependencies)

LEVELS Mapping (6 levels)

const LEVELS = {
  context:     '🔴 Context Window',   // context-window.jpeg, context.jpg
  claude_md:   '🟠 CLAUDE.md',   // Project instruction system
  agents:      '🟡 Agent System',     // Built-in + custom agents
  skills:      '🟢 Skills System',     // Skills framework
  commands:    '🔵 Commands System',     // Commands orchestration
  workflow:    '🟣 Full Workflow'    // End-to-end integration
}

37 Slides Outline

Resource Reuse

Redesign Accounting

• goToSlide() target: all 37 call sites need updated index numbers
• data-level attribute: each slide’s level marker needs mapping to LEVELS
• Navigation component: prev/next buttons need binding to new slide order
• Progress bar: 5-segment progress indicator maps to 5 phases

Start simple → compose gradually → full orchestration. Don’t build complex architecture from the start. Phase order is rearranged by cognitive dependencies: first understand “who” (Agents), then “what they can do” (Skills), then “environment” (Context), then “rules” (CLAUDE.md), finally “orchestration” (Commands).

SDK vs CLI System Prompts

Claude Code CLI and Agent SDK use different system prompt strategies:

Core Differences

SDK provides a modular prompt type, allowing tool descriptions to be added individually, saving many tokens over CLI’s full loading.

Billion Dollar Questions

13 unanswered deep questions from the community — if you have answers, these are billion-dollar insights.

Memory & Instructions (4 questions)

1. What should CLAUDE.md contain? — What to include, what to exclude?
2. If CLAUDE.md exists, do you still need constitution.md or rules.md?
3. How often should CLAUDE.md be updated? How to tell if it’s outdated?
4. Why does Claude still ignore instructions in CLAUDE.md — even with MUST in all caps?

Agents, Skills & Workflows (6 questions)

1. When to use Command vs Agent vs Skill — when is native Claude Code better?
2. How often should agents/commands/workflows be updated as models upgrade?
3. General-purpose vs role/function-specific subagents — does detailed persona actually improve quality?
4. Use Claude Code’s built-in plan mode, or build custom planning commands/agents to enforce team workflows?
5. How do personal skills and community skills coexist? Who takes priority on conflict?
6. **The ultimate question:**Can you convert an existing codebase to spec, delete the code, and have AI regenerate from spec alone?

Specs & Documentation (3 questions)

1. Should every feature in the repo have a spec file?
2. How often should specs be updated to stay current?
3. When implementing a new feature, how to handle cascading impacts on other features’ specs?

The answers to these questions will determine the direction of Agentic Engineering best practices. If you have insights, this is the frontier.

Boris Cherny — 13 Rules

Boris Cherny — Claude Code Core Engineer

Boris Cherny is a core engineer on Claude Code at Anthropic, where he leads development of the agentic coding tools used by hundreds of thousands of developers. He’s the author of Programming TypeScript (O’Reilly) and a frequent speaker on AI-assisted development workflows. The 13 rules below distill his most-repeated guidance from talks, demos, and PR comments — the same advice he gives teammates onboarding to Claude Code.

15 Hidden Features

15 lesser-known Claude Code features from Boris Cherny (Meta), each significantly changing how you use it.

12 Customization Tips

10 Advanced Tips

Code Review Tips

Test Time Compute: Code Review makes the model “think again” in an independent context, increasing output by 200%. Multi-Agent parallel review (security + performance + architecture) yields higher quality than single review.

PR Statistics (Boris Cherny’s Real Data)

Boris has approximately 100% new code written by AI, humans review and guide direction. Key is independent commits per file for clearer history.

2 Merge Tips

6 Opus 4.7 Efficiency Tips

6 core efficiency improvement methods summarized by Boris Cherny after Opus 4.7 release.

Auto Mode Best Practice: Use with effort: high and /focus, let Agent work autonomously at high reasoning depth, reporting only key decision points.

Thariq — Skill Design

Thariq Koya is an engineer on the Claude Code team at Anthropic, where he focuses on skill design, session management, and practical agentic workflows. The sections below distill his most-cited guidance — from internal Anthropic skill reviews (March 2026) and his field notes on real-world Claude Code usage. They’re the same patterns he follows when designing skills for production teams.

Thariq — Practical Tips

Session Management — Deep Guide

Thariq’s deep Session management framework: understanding context degradation, branching strategies, subagent garbage collection.

Context Rot: At approximately 300k-400k tokens the model starts “forgetting” earlier conversation, output quality drops significantly. This is not a bug, but a mathematical property of attention.

5 Branching Strategies

• StrategyScenarioDescription continueContinue from lastRestore full context to continue conversation rewindReturn to a pointUndo to specified step and restart clearFresh startClear context, start from scratch compactCompress & retainIntelligently compress while retaining key info subagentIsolated executionDispatch subagent, no main context pollution

Key Decision Table

• ScenarioRecommended Action Context > 50%/compact or dispatch subagent Wrong directionrewind to divergence point, don’t correct in place Poor quality after compactUse /compact [brief] with summary instructions, or directly clear + CLAUDE.md Need to preserve historySubagent handles new tasks, main conversation stays lean Subagent context bloatSubagents have built-in GC — auto-collected after completion, no impact on main session

Compact vs Fresh: If conversation history is highly relevant (e.g. debugging chain), use compact + brief; if topic has completely shifted, clear and rebuild context from CLAUDE.md is more efficient. Typical cause of bad compact: vague compression instructions causing key constraints to be dropped.

83 Categorized Tips

From community practices and official recommendations, organized into 16 tool categories. Core references: CLAUDE.md conventions, Subagents parallelism, RPI Workflow.

Video Highlights

Boris Cherny × Ryan Peterman — Career story of Claude Code's creator Beginner

Boris Cherny × Lenny's Podcast — Birth of Claude Code and product philosophy Product

Karpathy × AI Engineer — From Vibe Coding to Agentic Engineering Advanced

Matt Pocock Workshop — 2-hour Claude Code practical workshop Tutorial

Common Commands (82 built-in)

CLI Flags (16 categories)

Complete CLI startup flags reference, organized by function.

Environment Variables

Config Templates

# Project Name

## Tech Stack
- Frontend: React + TypeScript
- Backend: Node.js + Express

## Coding Conventions
- File naming: kebab-case
- Components: functional + hooks
- Testing: Vitest

## Constraints
- Do not use any type
- Do not skip tests
- API must have error handling

{
  "permissions": {
    "allow": ["Bash(npm run *)","Bash(git status)","Read","Grep","Glob"],
    "deny": ["Bash(rm -rf *)","Bash(git push --force)"]
  }
}

---
name: my-agent
description: Perform specific task
tools: "Bash,Read,Write,Edit,Grep"
model: sonnet
maxTurns: 20
memory: project
---

# My Agent
1. Read relevant files
2. Analyze code
3. Implement changes
4. Verify results

---
name: my-skill
description: What to do
arguments: filename
allowed-tools: "Read,Write,Edit"
paths: "src/**/*.ts"
---

Process $filename: 
1. Read → 2. Transform → 3. Write back

Workflow Cheatsheet