การสร้างโค้ดและประสิทธิภาพนักพัฒนา

This lesson maps to Scenario 4 — Developer Productivity, one of the eight exam scenarios. The architect's job here is to make Claude Code an effective teammate inside a real repository: investigating unfamiliar code, planning changes safely, and persisting team conventions.

Three pillars carry most of the exam weight in this scenario:

• CLAUDE.md — durable, shared project memory.
• Plan mode — explore and propose before editing.
• Built-in tools + incremental investigation — Glob, Grep, Read, Write, Edit, Bash used in a disciplined loop.

Get these decisions right and you'll handle most D3 (Config & Workflows) questions.

CLAUDE.md is persistent context loaded automatically into every session. There are three scopes, and choosing the right one is a frequent exam decision:

• User-level ~/.claude/CLAUDE.md — personal preferences. NOT shared via VCS, so new teammates never see it.
• Project-level ./CLAUDE.md or .claude/CLAUDE.md — committed to the repo and shared with the whole team.
• Directory-level — scoped to a subtree, loaded when working in that folder.

Rule of thumb: anything every contributor must follow belongs in the project-level file. Putting team conventions only in your user-level file is a classic trap answer.

A monolithic CLAUDE.md grows unwieldy and burns context tokens on every turn. Two mechanisms keep it lean:

• @path imports — pull in modular files, e.g. @./standards/coding-style.md, so shared standards live in their own versioned files.
• .claude/rules/ files — each carries YAML frontmatter with a paths glob, and loads only when you edit matching files. This saves context versus stuffing everything into one always-loaded CLAUDE.md.

Use rules for narrowly-scoped guidance (e.g. test conventions) that is irrelevant most of the time.

Two slash commands manage long-lived context:

• /memory edits CLAUDE.md directly and persists across sessions — use it to capture a hard-won convention so it's enforced next time.
• /compact compresses the current conversation to free context window. Beware: progressive summarization makes numbers, percentages, and dates vague. If exact values matter, keep them verbatim outside the summary rather than relying on /compact.

The exam likes to contrast durable memory (CLAUDE.md) with transient compression (/compact) — they solve different problems.

Plan mode lets Claude explore the codebase and propose an approach that you approve before any edits land. Reach for it when:

• The change is large or touches many files.
• There are multiple viable approaches to weigh.
• An architectural decision is involved.
• You want safe exploration of unfamiliar code first.

For a single-file fix or a clear stack trace, skip plan mode and go straight to direct execution — planning overhead there is wasted. Matching mode to task size is the core decision this scenario tests.

Investigation produces a lot of verbose output — file dumps, search hits, traces — that can crowd the main context window. The Explore subagent isolates that discovery work, returning a distilled summary instead of raw noise.

This is the same principle as a Skill with context: fork: run the messy, token-heavy part in an isolated context so the main session stays focused. Pair plan mode with an explore step for big, unfamiliar changes.

Claude Code ships a focused set of built-in tools. Knowing what each is FOR is exam-critical:

• Glob — find files by pattern, e.g. **/*.test.tsx.
• Grep — search file contents.
• Read — load a file into context.
• Write — create a file.
• Edit — a precise, unique-match change.
• Bash — run shell commands.

Glob finds files by name/pattern; Grep finds files by what's inside them. Mixing those two up is a common distractor.

Edit performs a precise change by matching a unique string in the file. If the target string is not unique, the edit fails — that's a safety feature, not a bug.

The correct fallback is to Read the file, then Write the full corrected version (or expand the match with more surrounding context to make it unique). Don't force ambiguous edits; that risks changing the wrong occurrence.

Edit is for surgical, unambiguous changes; Read+Write is for broader or ambiguous rewrites.

The exam rewards a disciplined investigation loop rather than dumping the whole repo into context. The canonical pattern:

1. Grep the entry points (where does this feature start?).
2. Read the relevant files you found.
3. Grep for usages of the symbols you discovered.
4. Read the consumers to understand impact.

This narrows scope step by step and avoids the lost-in-the-middle problem of over-stuffed context. Trim verbose tool output to the relevant fields as you go.

Built-in tools cover the local filesystem and shell. To reach external systems — a GitHub repo, a database, an issue tracker — connect an MCP server.

• Server primitives: Tools (actions), Resources (read-only data like schemas/catalogs), Prompts (templates).
• Scope: project .mcp.json (shared in VCS) vs user ~/.claude.json (personal).
• Secrets go through env vars like ${GITHUB_TOKEN} — never commit tokens.
• Prefer a maintained community MCP server over building a custom one for standard integrations.

Reusable workflows live in two places. .claude/commands/ is the legacy form; .claude/skills/ is the current one. Both follow the same scoping rule:

• Project scope (in the repo) — shared with the team via VCS.
• User scope (~/.claude/) — personal, not shared.

Skill frontmatter gives you real control: context: fork to isolate verbose output, allowed-tools to restrict capability (least privilege), and argument-hint to document inputs. Package a recurring investigation as a project-scoped skill so the whole team runs it consistently.

A scenario question on configuring Claude Code for a developer-productivity workflow.

Key takeaways for Scenario 4:

• CLAUDE.md scope: project-level (VCS-shared) for team rules; user-level is personal and unshared; directory-level for subtrees.
• Keep it lean: @path imports modularize, and .claude/rules/ with a paths glob load only when relevant.
• /memory persists conventions; /compact compresses but blurs numbers and dates.
• Plan mode for large, multi-approach, or architectural changes; direct execution for single-file fixes and clear stack traces. The Explore subagent isolates noisy discovery.
• Built-in tools: Glob (find by pattern), Grep (search contents), Read, Write, Edit (unique-match; fall back to Read+Write), Bash. Investigate incrementally: Grep entry points -> Read -> Grep usages -> Read consumers.
• MCP extends reach to external systems; prefer community servers, scope via .mcp.json, secrets through env vars.

Match the tool and mode to the task, and let durable config do the remembering.