Claude Code Workflow Cheatsheet: CLAUDE.md, Skills, and Hooks
Claude Code is a terminal coding agent — useful only when the repo teaches it how you work. That teaching lives in CLAUDE.md, layered memory files, skills, hooks, permissions, and optional subagents.
This cheatsheet is a practical 2026 workflow: install and /init, shape memory, add skills/hooks safely, then a daily plan → implement → compact loop. For skill ideas across domains see [Top 50 Claude Skills](/blog/top-claude-skills); for the capability ladder see [From LLM to Agentic AI](/blog/from-llm-to-agentic-ai).
Running example: a Next.js app where Claude knows npm run dev, App Router layout, and never reads .env.
Getting started: install and /init
Install Claude Code (Node 18+), then open a project and bootstrap memory. A typical path: run the official install script, cd into the repo, start claude, and run /init so it scans the codebase and creates a starter memory file.
When to use /init: every new repo before long sessions. When not to: skipping init and dumping a 2,000-line dump into chat — prefer curated CLAUDE.md.
Quick reference
- Install via the official Claude install script (Node 18+).
cdinto the project →claude→/init.- /init drafts CLAUDE.md from what it can infer.
- You still edit gotchas Claude cannot see (secrets locations, flaky tests).
Remember this
I can install Claude Code and bootstrap a repo with /init.
CLAUDE.md: what, why, and how
CLAUDE.md is persistent project memory — loaded automatically. Structure it as What (stack, directory map, architecture), Why (module purpose, design decisions), and How (build/test/lint commands, workflows, gotchas).
Example notes: npm run dev for local, /app for Next.js App Router. Keep it specific; reference files with @filename when useful.
Best practices: run /init first, add gotchas Claude cannot infer, stay concise, never paste secrets.
Quick reference
- What: tech stack, dirs, architecture.
- Why: purpose and design decisions per module.
- How: commands, workflows, known pitfalls.
- Be specific; prefer short bullets over essays.
Remember this
I can write CLAUDE.md as What / Why / How without dumping the whole repo.
Memory file hierarchy
Memory stacks in four tiers: Global ~/.claude/CLAUDE.md (all projects), Parent monorepo root, Project ./CLAUDE.md (shared on git), Subfolder e.g. ./frontend/CLAUDE.md (scoped). Subfolder files append context; they should not overwrite parent rules.
Keep each file roughly under ~200 lines. Long files fight the context window and confuse priorities.
Quick reference
- Global → parent → project → subfolder (narrower wins for local detail).
- Commit project CLAUDE.md; keep personal prefs in ~/.claude.
- Append scoped context; do not contradict parent safety rules.
- Trim ruthlessly — under ~200 lines per file.
Remember this
I know the four-tier CLAUDE.md hierarchy and the append-not-overwrite rule.
Project layout, skills, and skill ideas
Typical layout: root CLAUDE.md, .claude/settings.json (+ local overrides), skills/, commands/ (e.g. deploy.md), agents/, plus src/ and .gitignore.
Skills are markdown guides Claude auto-invokes from natural language. Project skills live in .claude/skills/; personal in ~/.claude/skills/. A clear description field is what enables auto-activation.
Useful engineer skills: code-review, testing patterns, commit messages, docker-deploy, codebase visualizer, API design.
Quick reference
- .claude/ holds settings, skills, commands, agents.
- Skills = auto-invoked know-how packs.
- Description field matters for matching.
- Start with two skills you run weekly — not twenty empty stubs.
Remember this
I can place skills under .claude/skills and know why descriptions matter.
Hooks, permissions, and safety
Hooks are deterministic callbacks — PreToolUse, PostToolUse, Notification. Match a tool (e.g. Bash) to a script; exit 0 allows, exit 2 blocks. Use them for secret scans and policy gates.
Permissions allow safe defaults (read files, git, write .md) and deny dangerous paths (.env, sudo). Prefer deny-lists for secrets even if CLAUDE.md says “be careful.”
Quick reference
- PreToolUse / PostToolUse / Notification hooks.
- Exit 0 = allow; exit 2 = block.
- Allow: reads, git, markdown writes as needed.
- Deny: .env* and privileged shell (sudo).
Remember this
I can use hooks as safety gates and deny .env / sudo in permissions.
Four layers and the daily workflow
Architecture stack: L1 CLAUDE.md (persistent rules) → L2 Skills (auto knowledge) → L3 Hooks (safety/automation) → L4 Agents (subagents with their own context).
Daily pattern: cd + claude → enter Plan Mode → describe intent → Auto Accept when ready → /compact to clean context → Esc Esc to rewind → commit often and start a new session per feature.
Quick commands: /init, /compact, Shift+Tab for modes, Tab for extended thinking, Esc Esc for rewind. (Exact keybindings can vary by version — check /help in your install.)
Quick reference
- L1 memory → L2 skills → L3 hooks → L4 agents.
- Plan before auto-accept on large changes.
- /compact when context gets noisy.
- One feature ≈ one session; commit frequently.
Remember this
I can run a plan → implement → compact daily loop on the four-layer stack.
Claude Code compounds when memory, skills, hooks, and permissions are deliberate — not when you paste the whole repo into chat. Start with /init, trim CLAUDE.md, add two skills and one PreToolUse safety hook, then practice the plan/auto-accept/compact loop.
Your homework: in a real repo, run /init, cut CLAUDE.md under ~200 lines with What/Why/How, deny .env*, and add one skill you will actually invoke this week.
Related Articles
Explore this topic