Advanced prompting techniques

# Step 1: Reproducing the problem
"I'm encountering this issue: [precise symptom description].
Stack: [technologies]
Exact error: [complete error message]
Relevant code: [paste the minimal code that reproduces the issue]

Don't suggest a solution yet. First tell me:
1. What you understand about the problem
2. What additional information you'd need to diagnose it"

# Step 2: Isolation
"Here's the additional information: [answer Claude's questions].
Now list the 3-5 possible causes in order of likelihood.
For each cause, how can I validate it in 2 minutes?"

# Step 3: Targeted fix
"The cause is confirmed: [identified cause].
Generate only the minimal fix for this specific problem.
Don't refactor the rest of the code.
Explain why this fix solves the problem."

# Step 4: Regression test
"Fix applied and validated. Generate a test that would have caught this bug
before it reached production. The test should reproduce exactly
the conditions that triggered the bug."

# Step 1: Impact analysis
"Analyze this code [paste] and assess its current state:
1. What are the readability, testability, and maintainability issues?
2. Which files would be affected by a refactoring?
3. What regression risks exist?
4. Propose a refactoring plan in independent steps (each deployable separately)"

# Step 2: Progressive migration (for each step in the plan)
"Step 1 of the refactoring: [step title].
Constraints:
- Preserve the same observable behavior (tests must pass)
- Each step must be independently deployable
- No business logic changes in this step, only structure
Generate the code for this step only."

# Step 3: Validation
"Step 1 deployed. Before moving to step 2:
1. Which tests should I run to validate nothing has regressed?
2. Are there edge cases in step 1 I should check manually?"

# Complete prompt for a structured code review
"You are a senior developer. Review this code [paste] in 4 successive passes:

Pass 1: Structure:
- Is the organization of responsibilities clear?
- Are names expressive and consistent?
- Is readability good (nesting, function length)?

Pass 2: Logic:
- Are there potential bugs?
- Are edge cases handled (null, empty, boundary)?
- Is the business logic correct?

Pass 3: Security:
- Are there unvalidated inputs?
- Sensitive data exposed?
- Possible injections?

Pass 4: Performance:
- Are there N+1 queries?
- Computations that could be cached?
- Avoidable synchronous blocking operations?

For each issue: severity (CRITICAL/HIGH/MEDIUM/LOW), description, suggested fix."

# Step 1: Complete inventory
"Analyze the codebase to build a migration inventory [technology A] -> [technology B].

For each file/module:
- Name and path
- Estimated migration complexity (1 = trivial, 5 = complex)
- Dependencies that block migration
- Specific risks

Generate a table sorted: quick wins first (complexity 1-2), then complex ones."

# Step 2: Phased plan
"Based on the inventory, generate a phased migration plan.
Constraints:
- Each phase must leave the project in a deployable state
- Circular dependencies must be identified and resolved
- Duration estimate per phase for a team of [X] developers
- Define success criteria (metrics) for each phase"

# Step 3: Module-by-module execution
"Phase 1 validated. Start migrating [specific module].
Rules:
- Coexistence with the old version during transition
- Feature flag for progressive switching
- Parity tests: verify behavior is identical before/after"

# Step 4: Post-migration verification
"Migration of [module] complete.
Generate:
1. Smoke tests to validate the migrated module
2. Manual verification checklist
3. Rollback plan if an issue is detected in production"

# Step 1: Identifying test cases
"Before writing a single line of implementation, identify all test cases
for this feature: [feature description].

Classify them as:
- Nominal cases (happy path)
- Error cases (invalid inputs, non-existent resource)
- Edge cases (empty, boundary, concurrency)
- Regression cases (known bugs not to reintroduce)

For each case: description, input, expected output."

# Step 2: Writing tests (RED)
"Based on the identified cases, write tests with [Vitest/Jest/pytest].
Tests should fail for now (RED).
Use descriptive test names: 'should [expected behavior] when [condition]'
Mock only external dependencies (database, API)."

# Step 3: Minimal implementation (GREEN)
"Tests written. Now implement the minimum code to make these tests pass.
No premature optimization, no untested features.
The code can be 'ugly' as long as it's correct."

# Step 4: Refactoring (IMPROVE)
"All tests pass. Refactoring phase:
1. Clean up the code without changing behavior
2. Extract duplications
3. Improve names
4. Verify tests still pass after each change"

# Without chain-of-thought (mediocre result)
"What's the best architecture for our API?"

# With chain-of-thought (thorough result)
"Analyze our API architecture needs. Reason step by step:

1. Identify current constraints (volume, latency, cost)
2. List viable options (REST, GraphQL, tRPC, gRPC)
3. For each option, evaluate:
   - Performance with our data volume
   - Implementation complexity for the team
   - Compatibility with our Next.js/TypeScript stack
   - Ease of testing and documentation
4. Compare trade-offs in a table
5. State your recommendation with key arguments

Show your reasoning at each step."

Analyze React components to identify performance issues.
Here's how I want you to reason:

## Example 1
Component: a UserList that fetches on every re-render
Analysis: The component has no stable dependencies for its useEffect.
On every parent re-render, the fetch fires unnecessarily.
Impact: excessive network requests, UI flickering, server load.
Solution: extract the fetch into useSWR or React Query with a
stable cache key. Add a staleTime of 5 minutes.

## Example 2
Component: a Dashboard that renders 50 child components
Analysis: Every state change in the Dashboard triggers a
re-render of all 50 children, even those that haven't changed.
Impact: noticeable lag, especially on mobile.
Solution: React.memo on stable children, useCallback on
handlers passed as props, virtualization for long lists.

## Now analyze this component:
[Paste your component here]

# Bad (assumes context the subagent doesn't have)
"Check the security of the code we just wrote"

# Good (autonomous prompt for a subagent)
"You are an application security expert (OWASP Top 10).
Analyze the following files for vulnerabilities:
- src/controllers/auth.controller.ts
- src/services/auth.service.ts
- src/middlewares/auth.middleware.ts

Check specifically:
1. Injection (SQL, NoSQL, command injection)
2. Broken authentication (predictable tokens, no rate limiting)
3. Sensitive data exposure (password hash in responses)
4. XSS (input sanitization, CSP headers)

Output format:
| Severity | File | Line | Vulnerability | Fix |
|----------|------|------|---------------|-----|"

# In your main prompt, ask Claude to launch in parallel:

"Launch 3 analyses in parallel on the authentication module:

Agent 1 (code-reviewer):
- Code quality, patterns, maintainability
- Compliance with project conventions (CLAUDE.md)
- Improvement suggestions

Agent 2 (security-reviewer):
- OWASP Top 10 analysis
- Secret and token verification
- Attack surface of each endpoint

Agent 3 (tdd-guide):
- Current test coverage
- Critical missing tests
- Uncovered edge cases

Synthesize the results of all 3 agents into a unified report."

# Toggle Extended Thinking on/off
Alt+T (Linux/Windows) or Option+T (macOS)

# Configure via environment variable
export MAX_THINKING_TOKENS=10000

# View Claude's thinking
Ctrl+O (verbose mode)

# Activate Plan Mode then ask:
"I want to migrate our state management from Redux to Zustand.
Propose a detailed migration plan before starting.

For each step in the plan, indicate:
- Files affected
- Changes to make
- Regression risks
- Complexity estimate (simple/medium/complex)"

"Before coding, rephrase what you understood from my request:
- What is the main objective?
- What are the technical constraints?
- What output format is expected?
- What edge cases need to be handled?

If your understanding is correct, proceed. Otherwise, tell me what's unclear."

# Bad (starting over)
"No, that's not what I wanted. Start over."

# Good (targeted correction)
"The component is well structured. Here are 2 corrections:
1. The loading state should use a skeleton, not a spinner
2. Pagination should be cursor-based (not offset-based) because the list
   can be modified during navigation"

# Classic prompt (everything explicit)
"Create a Card component in React with TypeScript, Tailwind CSS,
that accepts these props: title, description, icon, variant..."

# Contextual prompt (builds on the codebase)
"Create a Card component that follows the same patterns as
src/components/ui/Callout.tsx (same prop structure, same
Tailwind styling, same variant handling with CVA).
Variants: default, accent, highlight.
Use the existing design system in globals.css."

"Create the GET /api/projects/:id/tasks endpoint following:
- The controller pattern in src/controllers/user.controller.ts
- The Zod validation like in src/schemas/user.schema.ts
- The tests like in src/controllers/__tests__/user.controller.test.ts

The only difference: add a status filter (query param ?status=todo)
and cursor-based pagination."