exam-a · Q52Claude Code workflow

Your team’s CLAUDE.md includes a rule: “Use 4-space indentation and always run Prettier formatting.” Despite this, code reviews reveal that roughly 30% of files Claude Code generates use inconsistent formatting – sometimes 2-space indentation, sometimes missing trailing commas. Adding emphasis (“IMPORTANT: You MUST use Prettier formatting”) reduces violations to about 15%, but doesn’t eliminate them. What is the most effective way to ensure all generated code is consistently formatted?

1. AConfigure a PostToolUse hook with an Edit|Write matcher that automatically runs Prettier on each file Claude modifies.
2. BSplit the formatting rules into path-scoped.claude/rules/files that load when Claude works on matching file types.
3. CExtract the formatting rules into a dedicated skill that Claude loads automatically when generating code, with more detailed examples of correct formatting.
4. DAdd a Stop hook with a prompt-based check that evaluates whether generated code follows formatting standards and prompts Claude to fix violations.

nobody has checked this keyWhy

exam-a · Q53Claude Code workflow

This requires adding a conditional statement to one existing function in a single file. What is the most appropriate approach?

1. AEnter plan mode first to create a detailed implementation strategy before making the change.
2. BEnter plan mode to analyze how the validation might impact other parts of the reservation flow.
3. CUse direct execution to make the change.
4. DStart with extended thinking mode enabled to ensure thorough reasoning about the validation logic.

nobody has checked this keyWhy

exam-a · Q54Claude Code workflow

Your infrastructure-as-code repository includes Terraform modules (/terraform/), Kubernetes manifests (/kubernetes/), and CI/CD pipeline scripts (/pipelines/). Each requires different conventions, but your single root CLAUDE.md has grown to 500+ lines. When developers work on Kubernetes files, Terraform-specific rules load into context unnecessarily, consuming tokens. What is the best approach to reorganize so only relevant guidance loads when editing specific file types?

1. ASplit content into subdirectory CLAUDE.md files (/terraform/CLAUDE.md, /kubernetes/CLAUDE.md), so Claude loads directory-specific guidance.
2. BKeep the root CLAUDE.md and use @path/to/import syntax to modularly include tool-specific guidance files from separate documents.
3. CRestructure the root CLAUDE.md into clearly labeled sections with headers (e.g, “## Terraform Conventions”), improving organization and readability.
4. DCreate files in.claude/rules/ with YAML frontmatter path-scoping (e.g., paths: [“terraform/**/*”]), loading rules only when editing matching files.

nobody has checked this keyWhy

exam-a · Q55Claude Code workflow

You’re implementing a complex graph traversal algorithm with specific performance requirements and edge cases to handle (disconnected nodes, cycles, weighted edges). You want to structure your workflow for efficient iterative refinement with Claude. What approach will most effectively enable progressive improvement across multiple iterations?

1. AHave Claude extensively research the algorithm and create a detailed implementation plan using extended thinking, then implement the complete solution based on that plan.
2. BProvide Claude with a reference implementation from documentation, then ask it to rewrite the code to match your codebase style and add the required edge case handling, comparing outputs against the reference.
3. CProvide Claude with a detailed natural language specification of the algorithm, including all requirements and edge cases. Review each output manually and provide descriptive feedback on what behavior needs to change.
4. DWrite a test suite covering expected behavior, edge cases, and performance requirements before implementation. Ask Claude to write code that passes the tests, then iterate by sharing test failures with each refinement request.

nobody has checked this keyWhy

exam-a · Q56Claude Code workflow

You’ve documented API error handling conventions in a CLAUDE.md file at your project root, specifying that endpoint handlers should use a custom ApiError class. After several sessions, you notice Claude Code sometimes follows these conventions and sometimes uses generic try/catch blocks with string messages. The inconsistency appears random across different coding sessions. What’s the most efficient first diagnostic step?

1. AAdd a more detailed code examples to your CLAUDE.md showing the exact ApiError usage pattern for different endpoint types.
2. BRun /memory to check which memory files are loaded and verify your CLAUDE.md is included.
3. CSearch for conflicting instructions in ~/.claude/CLauDe.md or ~/.claude/rules/ that might override your project conventions.
4. DCreate path-specific rules in.claude/rules/handlers.md with YAML frontmatter scoping the error handling instructions to your API handler files.

nobody has checked this keyWhy

exam-a · Q57Claude Code workflow

Your team has connected a custom MCP server that provides DevOps workflow templates. The server exposes several MCP prompts (such as deploy_checklist and incident_response) in addition to tools. How do these MCP prompts become accessible within Claude Code?

1. AThey are surfaced as @ -mentionable resources alongside files, fetched and attached to your message when referenced.
2. BThey are automatically prepended to every conversation as additional system-level context, influencing Claude’s behavior throughout the session.
3. CThey are added to Claude Code’s tool registry alongside the server’s tools, invoked automatically by the model when relevant to the task.
4. DThey appear as slash commands (e.g., mcp_servername_deploy_checklist) that you can invoke, with arguments passed after the command name.

nobody has checked this keyWhy

exam-a · Q58Claude Code workflow

You’re implementing a new payment processing module that must follow your project’s established patterns for database transactions, error handling, and audit logging. You’ve identified three existing modules that exemplify these patterns: db_utils.py, error_handlers.py, and audit_logger.py. This is a one-off integration task – these patterns are well-documented in your team wiki and don’t need additional project-level documentation. What’s the most effective approach?

1. AAdd documentation of each pattern to your CLAUDE.md file, establishing them as project conventions that Claude will apply automatically.
2. BDescribe the patterns from the three modules in natural language in your prompt, explaining the transaction handling approach, error format, and logging conventions Claude should follow.
3. CAsk Claude to explore your codebase to find and understand the transaction, error handling, and logging patterns before generating the new module.
4. DUse @ references to include the three modules directly in your prompt, giving Claude concrete code examples of the patterns to follow.

nobody has checked this keyWhy

exam-a · Q59Claude Code workflow

Your team is configuring MCP servers in Claude Code. You want to add a shared venue lookup server that all team members should have access to, and you personally want to add an experimental music playlist server that only you are testing. Which configuration approach correctly applies MCP server scopes?

1. AAdd both servers to your local ~/.claude.json
2. BAdd venue server to ~/.claude.json and playlist server to.mcp.json
3. CAdd venue server to.mcp.json and playlist server to ~/.claude.json.
4. DAdd both servers to the project-level.mcp.json file

nobody has checked this keyWhy

exam-a · Q60Claude Code workflow

Your monorepo contains shared coding standards in /docs/standards/: security-rules.md (for services handling user data), testing-petterns.md (for all packages), and api-conventions.md (for API-facing services). Your 15 packages are organized by feature domain (/packages/auth/, /packages/billing/, /packages/notifications/, etc.) without naming conventions indicating which handle user data or expose APIs. Package maintainers are expected to configure their own local development settings, as they understand their package’s domain requirements. Currently, all package CLAUDE.md files duplicate all three standards, applying irrelevant guidance. What’s the most effective approach?

1. ACreate.claude/rules/ files for each standard with YAML frontmatter paths listing every package directory where that standard should apply.
2. BPut all standards in the root CLAUDE.md with override instructions like “ignore security-rules.md when working in packages that don’t handle user data.”
3. CCreate a shared-stendards.md that uses @imports to combine all three standards, then have each package’s CLAUDE.md import that combined file.
4. DUse @imports in each package’s CLAUDE.md to reference only the specific standard files relevant to that package, based on the maintainer’s domain knowledge.

nobody has checked this keyWhy

exam-a · Q61Claude Code workflow

Your team has three requirements for Claude Code’s behavior in your project 1. Claude must never modify files in the db/migrations/ directory 2. Claude should prefer your custom logging module over console.log 3. All TypeScript files must be auto-formatted with Prettier after every edit All three are currently written as instructions in your project’s CLAUDE.md. During a complex refactoring session, a developer discovers that Claude edited a migration file, violating requirement #1. How should you restructure these requirements across Claude Code's configuration mechanisms?

1. AAdd Edit(./db/migrations/**) to permissions.deny in the project settings, keep the logging preference in CLAUDE.md, and add a PostToolUse hook on the Edit tool that runs Prettier on changed TypeScript files.
2. BMove all three requirements into.claude/rules/ as path-scoped rules: one targeting db/migrations/** that forbids editing those files, and others targeting **/*.ts for the logging convention and formatting instruction.
3. CRewrite all three requirements in CLAUDE.md using stronger directive language and add few-shot examples that demonstrate Claude refusing to edit migration files and running Prettier after edits.
4. DConfigure hooks for all three: a PreToolUse hook script that blocks Edit calls targeting db/migrations/,a PreToolUse hook script that adds logging convention context before edits, and a PostToolUse hook that runs Prettier after TypeScript edits.

nobody has checked this keyWhy

exam-a · Q62Claude Code workflow

Your team frequently migrates React components to Vue. You’ve written a step-by-step workflow for Claude Code to follow during each migration, and you want every developer on the team to invoke it by typing /migrate-component. The workflow should stay in sync as the team iterates on it. Where should you place the skill file?

1. AIn ~/.claude/skills/migrate-component/SKILL.md on each developer’s machine
2. BIn.claude/skills/migrate-component/SKILL.md at the project root, committed to version control
3. CIn the project’s.claude/settings.json using a skillOverrides entry to register and define the workflow
4. DAs a detailed instruction block in the project’s root CLAUDE.md file

nobody has checked this keyWhy

exam-a · Q63Claude Code workflow

You’ve asked Claude to write a data migration script, but the initial output doesn’t correctly handle records with null values in required fields. What’s the most effective way to iterate toward a working solution?

1. AManually edit the generated code to fix the null handling, then continue working with Claude on other parts.
2. BAdd “think harder about edge cases” to your prompt and request a complete rewrite of the migration logic.
3. CDescribe the null value problem in detail and ask Claude to regenerate the entire script with improved edge case handling.
4. DProvide a test case with example input containing null values and the expected output, then ask Claude to fix it.

nobody has checked this keyWhy

exam-a · Q64Claude Code workflow

You’re implementing a caching layer for API responses to speed up the /products endpoint. You have a rough idea–Redis with a 5-minute TTL–but you’re new to production caching and aren’t sure what other considerations a robust implementation requires. What’s the most effective way to start your iterative workflow?

1. AStart with a minimal request: “Add Redis caching to /products with 5-minute TTL.” Add features and fix issues through follow-up prompts as problems surface during testing.
2. BWrite a specification with your known requirements and “TBD” markers for uncertain areas, having Claude propose solutions for each TBD as it implements.
3. CAsk Claude to interview you about the caching requirements before implementing, surfacing considerations like invalidation strategies, cache layers, consistency guarantees, and failure modes.
4. DUse plan mode to analyze the current/products endpoint implementation, then provide your caching requirements once Claude explains how the existing code is structured.

nobody has checked this keyWhy

exam-a · Q65Claude Code workflow

Your team wants Claude to follow a detailed code review checklist (8 items covering API changes, test coverage, documentation, security, etc.) when reviewing pull requests. The team also uses Claude extensively for other tasks: writing new features, debugging production issues, and generating documentation. Currently, developers paste the checklist at the start of each review session. Which approach best addresses this workflow need?

1. ACreate a /review slash command containing the checklist, invoked when starting reviews.
2. BCreate a dedicated review subagent with the checklist embedded in its configuration.
3. CConfigure plan mode as the default for code review sessions.
4. DAdd the checklist to the project’s CLAUDE.md file under a “Code Review” section.

nobody has checked this keyWhy

exam-a · Q66Claude Code workflow

A critical bug is affecting production users. Error logs show exceptions in the OrderProcessing module with a clear stack trace pointing to a specific function. You haven’t worked with this module before. What’s the most effective approach?

1. AStart with direct execution to gather initial information, then switch to plan mode to design a comprehensive solution before implementing any changes.
2. BEnter plan mode to explore the module’s architecture and dependencies before attempting any fixes.
3. CUse plan mode to analyze the error in context of the module’s design, enumerate potential root causes, and prioritize fixes systematically.
4. DUse direct execution to examine the stack trace, read the relevant code, and implement a fix once you identify the root cause.

community says DWhy