The skill, in full

Before writing any code, ask the user targeted questions until you are at least 95% confident you understand exactly what they want. Do not assume scope, stack, naming, edge cases, or “obvious” defaults — ask. If you catch yourself filling a gap with a guess, turn it into a question instead.

Do not move on to the next to-do item until you are 95% confident the current one is complete and correct. Verify it (run it, read the diff, test the behavior) before advancing. No batched “I’ll fix it later” hops between tasks.

Delegate work to subagents more often than you naturally would — research, searches, isolated implementation chunks, verification passes. For these subagents, use the Haiku model (claude-haiku-4-5-20251001) unless the task clearly needs Opus/Sonnet reasoning. This keeps the main thread focused and reduces cost.

Use Haiku subagent for

• File search / glob / locating code
• Reading files and extracting facts
• Grep for symbols, usages, patterns
• Running linters, formatters, type checks
• Taking and inspecting UI screenshots
• Simple verification passes (does X exist, does Y match Z)

Keep on the main model (Opus / Sonnet) for

• Architecture decisions and design tradeoffs
• Debugging complex / multi-layer bugs
• Security review and threat modeling
• Cross-file refactors needing holistic understanding
• Anything requiring judgment over multiple unknowns

Every time you make a meaningful change to the project, update the project’s CLAUDE.md at the end of that change.

Update triggers — only update when one of these happens

• New dependency added (production or dev)
• New script added to package.json (or Cargo.toml, pyproject.toml, Makefile)
• New top-level folder created
• Build, run, test, or deploy command changed
• New convention introduced (naming, structure, pattern, lint rule)

If the change does not match one of these triggers — skip the update. Do not log routine bug fixes, refactors, or task progress in CLAUDE.md.

Rules for content

• Only add things that are important for future sessions — architecture, conventions, gotchas, run commands, non-obvious decisions.
• Do not add transient notes, task logs, or anything derivable from reading the code.
• Keep total length between 150 and 200 lines maximum. If a new entry pushes it over, prune or compress older entries first.

Any time you build or modify a website, dashboard, component, or anything with a visible UI:

• Run it.
• Take screenshots at all three viewports: 375px mobile, 768px tablet, 1440px desktop.
• Inspect each layout — alignment, spacing, hierarchy, responsiveness, broken elements, overflow, touch targets on mobile.
• If any viewport has issues, fix them and screenshot again.
• Repeat until all three viewports look correct. Desktop-only screenshots are not enough.
• Do not report a UI task complete based only on “the code compiles” or “tests pass.”

You may create extra documentation files in the project (architecture.md, decisions.md, data-flow.md, api.md) when content does not belong in CLAUDE.md — too long, too detailed, or outside its 150–200 line scope.

Rules

• Create these files only when there is real information worth capturing — not preemptively.
• Store them at project root or in a docs/ folder.
• In CLAUDE.md, add one line pointing to each supplementary doc with a short hook describing when to read it.
• Do not read these docs by default at session start. Open them only when the current task needs them.

- architecture.md — read when changing module boundaries or data flow
- decisions.md — read when revisiting a past tradeoff or choosing a similar one

This keeps context lean: CLAUDE.md is the always-loaded index; deep docs load on demand.