Use # Comments in Your Prompts to Add Notes That Claude Ignores
Long, multi-line prompts get hard to read. Lines starting with # are treated as comments — Claude sees them but ignores them, so you can annotate your prompts without affecting the output.
# This is the auth refactor task — started Monday
# Skip the OAuth part for now, we'll do that in a separate PR
Refactor the authentication middleware to support API tokens.
# Don't forget to update the tests
Write tests for the new token validation.
Claude reads and executes the non-comment lines while skipping the # lines. Your notes stay visible in your prompt history but don't confuse the AI.
This is useful for:
# Temporarily disabling part of a prompt
"Fix the login validation.
# Also add rate limiting — come back to this later
Write a test for the fix."
# Documenting why you're asking for something
"# The client reported this breaks on Safari 16
Fix the CSS flexbox layout in the checkout form.
# See ticket PROJ-456 for details"
# Annotating complex multi-step instructions
"# Step 1: Schema changes
Create the migration for the audit log table.
# Step 2: Model and relationships
Create the AuditLog model with the polymorphic relationship.
# Step 3: Service
Create the audit logging service.
# Step 4: Integration (only after steps 1-3 pass tests)
Add audit logging to the OrderController."
Comments pair well with custom slash commands — add # lines to explain what each section of the command does for the next developer who reads it.
When you use up arrow to recall a previous prompt, the comments help you remember why you structured it that way.
Comments in code explain the code. Comments in prompts explain the prompt — use # to make complex instructions self-documenting.
via Claude Code
Log in to leave a comment.
Before jumping to implementation, describe the problem conversationally and let Claude be your thinking partner. It asks clarifying questions, surfaces tradeoffs you haven't considered, suggests approaches, and pokes holes in your plan — so by the time you say "ok, build it," both of you know exactly what to build and why.
Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.
When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.