Claude Quiz
25 questions. One certificate.

Answer: C. Explore, plan, build, verify

What. Explore (read the code and explain it back), plan (agree the steps), build (in small steps), verify (run tests, read the diff). Why. Each step catches a different kind of mistake before it gets expensive. How. Start every task with "read how X works, change nothing", then ask for a plan before any edit.

Covered on Day 1.

Answer: A. Commands to test and lint, team conventions, and things to avoid

What. CLAUDE.md is a short briefing that loads at the start of every session: commands, conventions and mistakes to avoid. Why. Every line costs context, and a long file gets ignored. Secrets never belong in it, because it is committed to git. How. Run /init in the terminal or the VS Code panel, then trim the draft. If Claude gets something wrong twice, add a line.

Covered on Day 2.

Answer: B. The extension bundles its own copy for the chat panel but does not add claude to your PATH

What. The panel and the command-line tool are two doors to the same engine, but only the standalone install puts claude on your PATH. Why it matters. Commands such as claude mcp add and claude -p need the CLI. How. Run the native installer once (irm https://claude.ai/install.ps1 | iex on Windows PowerShell, curl -fsSL https://claude.ai/install.sh | bash on macOS, Linux and WSL), then open a new terminal and check claude --version.

Covered on Day 3.

Answer: B. Press Esc straight away and tell it what you want instead

What. Esc stops Claude mid-turn and keeps the work so far. Why. Every extra step on a bad path costs time and tokens, and its dead ends stay in the context. How. In the terminal press Esc; in VS Code use the stop button. Then say what to do instead. Esc twice (or /rewind) goes back to an earlier checkpoint.

Covered on Day 4.

Answer: B. When the change touches several files, the code is unfamiliar, or you cannot describe the diff in one sentence

What. In plan mode Claude reads and proposes but cannot edit until you approve. Why. Reading a plan takes a minute; undoing the wrong build takes an afternoon. A one-line rename does not need it. How. Terminal: claude --permission-mode plan, /plan or Shift+Tab. VS Code: pick Plan from the mode indicator under the prompt box.

Covered on Day 4.

Answer: A. Side effects of shell commands, such as deleting files with rm or changing a database

What. /rewind restores the code edits Claude made with its own edit tools, the conversation, or both. Why it matters. It does not track changes made by shell commands or outside the session, so it is a quick undo, not a backup. How. Keep using git as the permanent safety net (Day 6): commit before big tasks.

Covered on Day 4.

Answer: C. /clear

What. /clear starts a new conversation with an empty context; /compact summarises the current one. Why. Old, unrelated chat clutters the context and is sent again with every request. How. /compact (with a line on what to keep) when it is the same task but long; /clear when the task changed. Use /rename first if you want to find the old session later.

Covered on Day 5.

Answer: B. It is blocked, because deny is checked first

What. Rules are evaluated in order: deny, then ask, then allow, and the first match decides. Why. An allow rule can never carve an exception out of a deny rule, so a deny is a dependable fence. How. Open /permissions in the terminal or VS Code panel to see and edit the rules. Note that Bash(git *) allows every git command including push, while Bash(git log *) allows only git log.

Covered on Day 5.

Answer: D. .claude/settings.json in the project

What. Rules live in three places: .claude/settings.local.json (yours, not committed), .claude/settings.json (shared, committed) and ~/.claude/settings.json (all your projects). Why. Shared rules give a team one safe setup without a wiki page. How. Put team rules in the project file and review changes to it in a pull request like code.

Covered on Day 5.

Answer: D. A deny rule such as Read(./.env) in settings

What. CLAUDE.md shapes what Claude tries; permission rules are enforced by Claude Code itself. Why. An instruction can be forgotten or misread, a deny rule cannot. How. Add "deny": [ "Read(./.env)" ] under permissions in .claude/settings.json. For rules that must run every time, Day 9 adds hooks.

Covered on Day 5.

Answer: D. /code-review (alias /review) on your current changes

What. /code-review reviews the current diff for bugs; pass a PR number or branch, or a level such as high. Why. It catches the obvious problems before a human spends time. Treat each finding as a lead to check, not an order. How. Terminal or VS Code panel: type /code-review. Also try /security-review on a branch.

Covered on Day 6.

Answer: C. git push --force and git reset --hard

What. Force-push and hard reset are the two commands that destroy work. Why. Read-only git (status, diff, log) is safe to allow; commit and push are worth a look, so leave them on ask. How. "deny": [ "Bash(git push --force *)", "Bash(git reset --hard *)" ] in .claude/settings.json. Also work on a branch, never on main.

Covered on Day 6.

Answer: D. In .mcp.json at the project root, with the token as an environment variable like ${API_KEY}

What. Project scope stores servers in .mcp.json, which you commit (add with --scope project). Why. A committed file is visible to everyone with the repo, so a pasted token is a leaked token. How. Write "Authorization": "Bearer ${API_KEY}"; each person sets the variable on their own machine. Teammates are asked to approve the server the first time they open the project.

Covered on Day 7.

Answer: D. Claude, based on the tool descriptions the server lists

What. A server only lists tools and runs them when called. Why it matters. The server is plain code, not the AI, and connected does not mean safe: some tools write, delete or send. How. Keep write tools on the ask list in your permission rules (they are named mcp__server__tool), and use a read-only database user for database servers.

Covered on Day 7.

Answer: C. Only its one-line description

What. A skill is a folder with a SKILL.md: a short header plus Markdown instructions. Why. Only the description is listed until the skill is used, so you can keep many skills for almost no context. That is also why the description matters most: if it does not match how you ask, the skill never loads. How. Check what is loaded with /skills in the terminal, or type / in the VS Code panel.

Covered on Day 8.

Answer: D. Add disable-model-invocation: true to the header

What. By default both you and Claude can run a skill. Why. Anything with side effects, such as deploys, pushes and messages, should only fire when you decide. How. Add disable-model-invocation: true to the SKILL.md header. Rule of thumb: if running it twice by accident would hurt, gate it.

Covered on Day 8.

Answer: B. It works in its own fresh context, and only a short result comes back to your main chat

What. A subagent is a separate Claude with its own context window, tools and optionally its own model. Why. The files it read and the dead ends it explored never fill your main context (Day 5). You can also limit what it may do, for example a read-only reviewer. How. Ask for one in plain words ("use an Explore agent to find where login errors are handled") or create .claude/agents/name.md.

Covered on Day 9.

Answer: A. A PreToolUse hook that exits with code 2

What. A hook is your command, run by Claude Code at a fixed moment. PreToolUse runs before the tool and can block it: exit code 2 blocks, and what you write to stderr goes back to Claude as the reason. Why. PostToolUse runs after the action, so it can react but cannot undo it. How. Define it in settings under hooks with a matcher such as Edit|Write, then check it with /hooks.

Covered on Day 9.

Answer: B. In .claude-plugin/plugin.json, and only that file belongs in .claude-plugin

What. A plugin bundles skills, subagents, hooks and MCP servers behind one manifest. Why. The classic mistake is putting skills/, agents/ or hooks/ inside .claude-plugin/; they sit at the plugin root instead. How. Test locally with claude --plugin-dir ./my-plugin and read the Errors tab in /plugin if something does not load.

Covered on Day 10.

Answer: D. Runs one prompt, prints the answer and stops, with no back and forth

What. -p (short for --print) is headless mode. Why. It lets scripts and CI call Claude Code like any other command, and you can pipe data in and read JSON out with --output-format json. How. Works in any terminal, including VS Code's integrated one: git diff main | claude -p "list any typos".

Covered on Day 11.

Answer: A. It is denied, because nobody is there to approve it

What. Headless runs start in the normal permission mode, and anything that would prompt is simply denied. Why. Every tool you allow is something a robot can do at 3 a.m., so start with the smallest list that finishes the job. How. Grant tools up front with --allowedTools "Read,Edit" or a mode like --permission-mode dontAsk for locked-down CI.

Covered on Day 11.

Answer: B. Only people with write access to the repository (and bots only if you list them)

What. The Action checks the commenter before it starts. Why. Otherwise a stranger could spend your API money from a public issue. How. Set it up with /install-github-app inside Claude Code (or the manual steps on Day 11), keep keys in repository secrets, and put your standards in CLAUDE.md.

Covered on Day 11.

Answer: C. Uses Opus while planning, then Sonnet when it starts executing

What. A hybrid alias. Why. The hard decision happens in the plan, which uses few tokens; most tokens go into reading files and writing edits. Put the expensive model on the decision and the cheaper one on the typing. How. /model opusplan in a session, or click the model name under the VS Code prompt box. Aliases such as sonnet and opus always mean the latest of that kind.

Covered on Day 12.

Answer: B. claude --worktree fix-rounding

What. A git worktree is a second folder with its own files on its own branch, sharing the same history. Why. Two sessions in one folder edit each other's files. How. claude -w name creates .claude/worktrees/name/ on a branch called worktree-name. The repo needs at least one commit, and add .claude/worktrees/ to .gitignore. List them with git worktree list.

Covered on Day 12.

Answer: A. At least three sessions' worth of tokens, because each reloads the project context

What. Parallel sessions save your waiting time, not tokens. Why. Each session carries its own context, and merge conflicts erase the time you saved if the sessions touch the same files. How. Run only as many as you can review carefully (two or three is plenty), give each its own worktree, and check the spend with /usage.

Covered on Day 12.