From AI assistant to development partner. Explains how Claude works and guides you through the Engineer Kit with real-world use cases and best/bad practices.
Claude Code is an agentic coding environment from Anthropic — not just a chatbot that answers questions, but an AI that can read files, run commands, edit code, and autonomously solve problems while you watch or work on something else.
| Traditional AI | Claude Code |
|---|---|
| You write code, AI reviews | You describe the idea, AI implements it |
| Copy-paste snippets back and forth | AI reads/edits files directly |
| Must guide every step manually | AI explores, plans, and executes on its own |
| No tool use | Full access: bash, git, file system |
Claude Code has a context window that holds the entire conversation: messages, files read, command outputs. Performance degrades when the context is full — this is the most important constraint to manage.
Solution: Use /clear frequently between unrelated tasks.
ClaudeKit is a set of workflow templates for Claude Code, consisting of 2 kits:
ClaudeKit is a paid product. I highly recommend this kit for its effectiveness and the maintainers' active support — it saves a lot of time compared to researching the countless configs and workflows scattered across the internet.
Buy ClaudeKit (20% off)Engineer Kit (claudekit-engineer) transforms Claude Code from an AI assistant into a development partner. Not a standalone app — it's a .claude/ folder you drop into your project.
Install the CLI first (once per machine):
If the .claude/.claude\ folder already exists, backup or merge files manually before init.
ck init
project/ ├── CLAUDE.md Template (customize after) ├── AGENTS.md Agent definitions ├── .gitignore ├── .repomixignore Repomix ignore patterns ├── release-manifest.json Kit version manifest ├── plans/ Plans directory ├── .opencode/ OpenCode compatibility └── .claude/ ClaudeKit config ├── .ck.json Kit metadata ├── settings.json Claude Code settings ├── metadata.json Deletion patterns ├── statusline.cjs Statusline config ├── .env.example Environment template ├── .mcp.json.example MCP config template ├── agents/ 14+ definitions ├── hooks/ 22+ hooks ├── rules/ Workflow rules ├── skills/ 90+ commands ├── scripts/ Utility scripts ├── schemas/ JSON schemas ├── output-styles/ Response formats └── session-state/ Session tracking
ck new and ck init (default "Update everything: Yes") automatically create the CLAUDE.md template. Only when you choose "Update everything: No" and untick, CK will skip this file.
After CK creates the template, you can further customize it for your project:
/init inside Claude Code to regenerate from the codebase (if CLAUDE.md already exists, /init only suggests improvements, won't overwrite) Keep it under 200 lines. Long files consume context and cause Claude to miss rules (reduced adherence). Only write what's essential: build commands, coding standards, key conventions. If instructions grow, split them into @import or files in .claude/rules/.
Inside a Claude Code session, run the /ck:coding-level command (no arguments) to open an interactive selector to choose 1 of 6 levels. Or set directly: /ck:coding-level 3.
Alternative — Output Styles (native): Claude Code has its own Output styles feature — run /config → select "Output style" → pick from menu. This is an independent Claude Code feature that happens to have some style naming similar to CK coding levels.
Mechanism differences:
/ck:coding-level writes to .ck.json, guidelines are injected via SessionStart hook each time you open a session.outputStyle in .claude/settings.local.json, takes effect from the next session to keep prompt cache stable). Choose one — use /ck:coding-level or native Output styles, don't enable both at the same time to avoid overlapping guidelines.
| Level | Name | Style |
|---|---|---|
| 0 | ELI5 | Explain as if talking to someone with no coding background |
| 1 | Junior | Explains WHY, mentor style |
| 2 | Mid-level | Design patterns, system thinking |
| 3 | Senior | Trade-offs, architecture decisions |
| 4 | Tech Lead | Risk & business impact |
| 5 | God Mode | Zero hand-holding (default, for 15+ years experience) |
God Mode assumes you are an expert (15+ years or a domain specialist) — you already know the answer, you just need validation/second opinion/fast typing. Claude acts as force multiplier, not teacher.
If you're new to Claude Code, set level 1 or 2 for explanations. God Mode optimizes velocity but assumes you can debug when Claude is wrong.
.claude/rules/For large projects, split instructions into multiple small files inside .claude/rules/ instead of cramming everything into one CLAUDE.md. Rules can scope by file paths via YAML frontmatter — only load into context when Claude touches files matching the pattern, saving context space.
.claude/ directory anatomyRules are just one part — .claude/ holds many types of config. Summary of Project scope (shared with team via git) vs Global scope (personal, per-machine):
./CLAUDE.md # project instructions (hoặc ./.claude/CLAUDE.md) ./CLAUDE.local.md # personal — gitignored ./.mcp.json # MCP servers (team-shared) ./.worktreeinclude # copy gitignored files vào worktree mới (optional) ./.claude/ ├── settings.json # permissions, hooks, model ├── settings.local.json # personal — auto-gitignored ├── rules/*.md # topic rules (path-scopable) ├── skills/<name>/ # /skill-name + bundles ├── commands/*.md # /command (legacy — prefer skills) ├── agents/*.md # subagents ├── agent-memory/ # project subagent memory (memory: project) └── output-styles/*.md # system-prompt styles
.\CLAUDE.md # project instructions (hoặc .\.claude\CLAUDE.md) .\CLAUDE.local.md # personal — gitignored .\.mcp.json # MCP servers (team-shared) .\.worktreeinclude # copy gitignored files vào worktree mới (optional) .\.claude\ ├── settings.json # permissions, hooks, model ├── settings.local.json # personal — auto-gitignored ├── rules\*.md # topic rules (path-scopable) ├── skills\<name>\ # /skill-name + bundles ├── commands\*.md # /command (legacy — prefer skills) ├── agents\*.md # subagents ├── agent-memory\ # project subagent memory (memory: project) └── output-styles\*.md # system-prompt styles
~/.claude.json # app state, personal MCP, UI prefs ~/.claude/ ├── CLAUDE.md # global instructions ├── settings.json # default settings ├── keybindings.json # custom shortcuts ├── rules/*.md # user-level rules ├── skills/ # personal skills ├── commands/ # personal commands ├── agents/ # personal subagents ├── agent-memory/ # subagent memory (memory: user) ├── output-styles/ # personal styles ├── plugins/ # installed plugins (auto-managed) └── projects/<project>/memory/ # auto-memory (Claude tự ghi)
%USERPROFILE%\.claude.json # app state, MCP, UI prefs %USERPROFILE%\.claude\ ├── CLAUDE.md # global instructions ├── settings.json # default settings ├── keybindings.json # custom shortcuts ├── rules\*.md # user-level rules ├── skills\ # personal skills ├── commands\ # personal commands ├── agents\ # personal subagents ├── agent-memory\ # subagent memory (memory: user) ├── output-styles\ # personal styles ├── plugins\ # installed plugins (auto-managed) └── projects\<project>\memory\ # auto-memory (Claude tự ghi)
Add YAML frontmatter to the top of a rule file to limit its scope. Claude only loads the rule into context when working with files that match the glob pattern — reduces context bloat while keeping domain-specific guidance (auth, db, UI, tests…).
Rules (and CLAUDE.md) are instructions Claude reads, not Claude Code config that enforces. Claude may not follow if instructions conflict or are ambiguous. For guaranteed behavior, use:
settings.json) — scripts that run before/after tool calls| CLAUDE.md + rules | settings.json |
|---|---|
| Concatenated into context — global + project + local are all read | Key-level override — project overrides global, local overrides project |
| On conflict: the last-loaded file wins (last read) | Arrays (permissions.allow) combine; scalars (model) take the most specific value |
skills/<name>/SKILL.md — bundle SKILL.md + supporting files (checklists, scripts, reference docs). If a skill and command share the same name, skill wins.~/.claude/projects/<project>/memory/MEMORY.md (first 200 lines / 25KB loaded each session). Topic files lazy-load. Toggle: /memory or autoMemoryEnabled setting.| CLAUDE.md | .claude/rules/*.md |
|---|---|
| General instructions for the whole project | Modular instructions split by topic/path |
| Always loaded into context at launch | No paths: loaded at launch · With paths: lazy-loaded when files match |
| Target: under 200 lines | One topic per file (code-style.md, testing.md...) |
| Build commands, general conventions | Domain rules: API, frontend, security, DB... |
| Single file | Multiple files, recursive subdirectories |
Use YAML frontmatter with a paths field so the rule is only active when Claude touches matching files:
Rules without a paths field load unconditionally. With paths, they trigger when Claude reads files matching the pattern.
.claude/rules/i18n-rules.md for a multilingual app.When opening a session, Claude reads memory files from top to bottom, then concatenates all of them into context — they don't overwrite each other.
Rules with paths frontmatter only activate when Claude touches a file matching the pattern — they aren't loaded at startup. This lets you write directory-specific rules without bloating CLAUDE.md.
Anthropic recommends CLAUDE.md should be under 200 lines. Longer files will cause adherence to drop — meaning Claude will miss or ignore more of your rules because it has too much information to process. Rule files should also be kept short. When CLAUDE.md approaches 200 lines, split it into .claude/rules/ by topic (e.g. api-design.md, testing.md, security.md). Name files descriptively so both your team and Claude can quickly find them via Grep.
For large projects or when you want to share rules across multiple repos, you have 4 context-expansion mechanisms. The diagram below shows how each mechanism pulls additional files into the base CLAUDE.md.
@import syntax
Embed other files directly into CLAUDE.md
In CLAUDE.md, write @docs/coding-standards.md or @~/.claude/my-prefs.md to embed the file's content at that location. Claude supports both relative and absolute paths, with a maximum depth of 5 nested imports (hops). Use this to split long content into separate files while keeping CLAUDE.md concise.
--add-dir flag
Open additional working directories in the same session
By default, Claude Code only reads files in the directory you launched it from (working directory). The --add-dir flag lets you open additional directories in the same session — useful for monorepos or when you need to reference directories like ../shared, ../design-system outside your current project.
All three activation methods are equivalent: the --add-dir flag at launch, the slash command /add-dir during a session, or declaring additionalDirectories in settings.json.
Important note: by default, Claude does not load CLAUDE.md or CLAUDE.local.md files from directories added via --add-dir — to maintain backward compatibility with older projects. If you want Claude to apply memory from those directories, enable this environment variable before launching:
Once enabled, every CLAUDE.md or CLAUDE.local.md in added directories will be loaded alongside the main project, allowing Claude to understand the conventions of each workspace within the same session. This feature is available from version 2.1.20 and is opt-in for backward compatibility reasons.
CLAUDE.local.md
Personal notes, not committed to git
File for your personal preferences within the project (sandbox URLs, test accounts, personal debug commands). Add CLAUDE.local.md to .gitignore to keep it out of commits. Claude loads this file alongside CLAUDE.md but it's only visible on your machine — your team won't see it.
The .claude/rules/ directory supports symlinks — keep your team's canonical ruleset in one place and link it into each project. When you update a rule, all projects get it simultaneously. Claude detects circular symlinks and skips them automatically.
--fast: Skip research | --auto: Skip all review gates
Single highest-leverage tip.
/ck:cook already includes testing. Use /ck:test [path] separately when you need to test a specific folder.
Use /ck:plan directly when:
Use /ck:brainstorm before: you don't know which approach is best, you need trade-off analysis (WebSockets vs SSE), or a new feature without precedent.
For UI-heavy features, add a mockup step to review first:
HTML mockups with mock data are faster than the real implementation. Catch design issues early, avoid rework.
When to use /clear:
Fix: /clear between each unrelated task
Fix: After 2 failed corrections → /clear and write a better prompt
Fix: /ck:plan --fast for lightweight planning
Fix: /ck:test + manual testing + code review → then ship
Fix: Specific symptom + location + expected behavior
This cheat sheet lists 14 commonly used commands. See the full reference table, detailed syntax, and real-world examples for all commands at vividkit.dev/guides/commands.
| Situation | Command |
|---|---|
| Explore options | /ck:brainstorm [question] |
| Plan feature | /ck:plan [description] |
| Implement feature | /ck:cook [description] |
| Quick small fix | /ck:cook --fast [fix] |
| Fix bug | /ck:fix [symptom] |
| Technical question | /ck:ask [question] |
| Run tests | /ck:test [path] |
| Explore codebase | /ck:scout [path] |
| Code review | /ck:code-review [path|--pr N] |
| Review changes | /ck:watzup |
| Commit | /ck:git cm "message" |
| Full ship pipeline | /ck:ship |
| Clear context | /clear |
| Set beginner mode | /ck:coding-level 1 |