When A guideline must apply to all team members (current and future) → Place it in project-level .claude/CLAUDE.md or .claude/rules/, NOT in user-level ~/.claude/CLAUDE.md.

When CLAUDE.md exceeds 400+ lines mixing multiple concerns → Split into topic-specific files in .claude/rules/ (e.g., testing.md, api-conventions.md).

When A new team member is not receiving project guidelines → Verify the guideline exists in project-level config, not just in existing developers' user-level config.

When A skill produces verbose output that causes Claude to lose track of the original task → Add context: fork to the skill's frontmatter to run in an isolated sub-agent context.

When A developer wants a personal variant of a team skill without affecting teammates → Create a personal skill in ~/.claude/skills/ with a DIFFERENT name (project skills shadow same-named personal ones).

When Context is only useful for a specific workflow (e.g., endpoint generation) and not general work → Create a skill with the exemplar code; invoke on-demand via slash command instead of putting it in CLAUDE.md.

When Different coding conventions apply to different file types (React components vs API handlers vs tests) → Create .claude/rules/ files with YAML frontmatter paths glob patterns for each file type.

When Test files are spread throughout the codebase alongside source files → Use path-specific rules with **/*.test.tsx glob rather than subdirectory CLAUDE.md files.

When You want conventions to apply to terraform files in any directory → Use paths: ['terraform/**/*'] in rule frontmatter instead of a terraform/CLAUDE.md file.

When Task involves ambiguous requirements with multiple valid integration approaches (e.g., adding Slack support) → Enter plan mode to explore options and architectural implications before implementing.

When Task is a well-understood change with clear scope (e.g., bug fix with a clear stack trace) → Use direct execution -- no need for plan mode.

When Discovery phase generates verbose output that fills the context window → Use the Explore subagent to isolate verbose output and return a concise summary to the main conversation.

When Claude interprets prose requirements differently each iteration, producing inconsistent output structure → Provide 2-3 concrete input/output examples showing the expected transformation.

When You are implementing in an unfamiliar domain and want to surface edge cases → Use the interview pattern: have Claude ask about design considerations before implementing.

When Multiple bugs interact with each other → Describe all interacting issues in a single message rather than fixing them sequentially.

When Running Claude Code in an automated CI pipeline → Use the -p flag for non-interactive mode; use --output-format json with --json-schema for structured output.

When The same Claude session generated code and you need a review → Use a second, independent Claude instance without access to the generator's reasoning context.

When Re-running review after developer pushes fixes, and getting duplicate findings on already-fixed code → Include prior review findings in context, instructing Claude to only report new or still-unaddressed issues.