Claude Code

Knowledge of

• Rules as standing instructions/conventions Claude Code should always follow in a repo, often expressed in CLAUDE.md
• Skills as packaged, reusable capabilities defined by a SKILL.md (instructions plus optional scripts/resources) that Claude loads when relevant
• Commands as slash commands -- built-in (/clear, /init, /help) and custom Markdown prompt files in .claude/commands/
• Agents as subagents with focused roles/tool sets that Claude Code can delegate to
• Agent Memory as persisted context, notably CLAUDE.md, that survives across turns/sessions

Skills in

• Distinguishing which of the five component types (Rules, Skills, Commands, Agents, Agent Memory) fits a given operational need
• Recognizing a SKILL.md-defined capability as a Skill rather than a Command or Agent
• Recognizing a delegated, focused-role subtask as an Agent rather than a Command
• Locating custom slash commands as Markdown files under .claude/commands/

Knowledge of

• CLAUDE.md as a special Markdown file Claude Code automatically pulls into context as project memory
• The four hierarchy levels -- enterprise/system, user (~/.claude/CLAUDE.md), project (./CLAUDE.md), and subdirectory -- and that more specific files layer on top of broader ones
• That project-level CLAUDE.md is checked into version control so the whole team shares the same guidance
• /init as the command that bootstraps a starter CLAUDE.md from an existing codebase
• The distinction between CLAUDE.md (memory/instructions loaded into context) and settings.json (executable configuration/permissions)

Skills in

• Choosing the correct CLAUDE.md level (enterprise, user, project, or subdirectory) for a given piece of guidance
• Committing project-level CLAUDE.md to version control so conventions are shared team-wide
• Running /init to bootstrap a starter CLAUDE.md for an existing repository
• Not placing permissions, hooks, or tool allow/deny rules in CLAUDE.md

Knowledge of

• settings.json location at ~/.claude/settings.json (user) and .claude/settings.json (project)
• What settings.json configures: tool allow/deny lists, hook definitions, environment variables, model selection, and MCP servers
• settings.json as a deterministic control surface -- an allow/deny rule or hook can block a dangerous command regardless of what the model proposes
• The clean separation between CLAUDE.md (context/memory) and settings.json (behavior/permissions)

Skills in

• Placing tool allow/deny rules, hooks, environment variables, model selection, and MCP server config in settings.json rather than CLAUDE.md
• Using a settings.json allow/deny rule or hook as a deterministic guardrail against a dangerous action, independent of model behavior
• Locating the correct settings.json file (user-level vs. project-level) for a given scope of configuration

Knowledge of

• Session management: conversations persist as resumable sessions; /clear resets context to keep it focused
• Headless mode: non-interactive execution (e.g., claude -p) for scripting, CI pipelines, and automation, with no interactive TUI
• Streaming mode: incremental output emission, including structured stream-JSON, for programmatic consumption
• Auto-mode: reduced-friction autonomous operation with less step-by-step confirmation, which should be paired with permission rules and hooks
• The gather context -> make a plan -> act -> verify best-practice loop, and tightening it with custom commands/hooks rather than long, brittle prompts

Skills in

• Choosing headless mode for CI/scripting scenarios where no interactive prompt should appear
• Choosing streaming mode when output needs to be consumed incrementally/programmatically
• Pairing auto-mode with settings.json permission rules and hooks rather than relying on it unguarded
• Applying the gather-context, plan, act, verify loop and tightening it via custom commands and hooks
• Distinguishing headless mode (non-interactivity) from auto-mode (autonomy level) when a scenario could be misread as either