// 287 tips tagged "productivity"
When Claude writes error messages, button labels, validation text, or onboarding flows, it defaults to generic developer-speak. Add a "Users" section to your CLAUDE.md describing who your actual users are — their technical level, industry jargon, and what they care about — so Claude writes copy that makes sense to THEM, not to developers.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.
When you have a written specification — a PRD, a requirements doc, a technical design, or even detailed meeting notes — pipe it directly into Claude Code as context. Claude reads the full document, understands every requirement, and implements the feature exactly as specified instead of you re-explaining it piece by piece.
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.
Claude can read your application code — the jobs, queues, API endpoints, scheduled tasks, and critical business logic — and generate monitoring rules that alert on the things that actually matter: failed payments, queue backlogs, stale cron jobs, error rate spikes, and slow endpoints, all tailored to your real system.
Good comments explain why, not what. Tell Claude to read your complex code and add inline comments that explain the reasoning behind non-obvious decisions — why this algorithm was chosen, why this edge case exists, why the order matters — so the next developer (or future you) understands the intent without reverse-engineering the logic.
Use the --agent flag with custom markdown files in .claude/agents/ to launch purpose-built Claude sessions with restricted tools and scoped system prompts.
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.
Got a module with zero tests? Point Claude at the code and it reads the implementation, identifies every behavior — the happy path, edge cases, error conditions, and boundary values — then writes a comprehensive test suite that documents what the code actually does and catches regressions if anything changes.