I'm debugging an issue in a [language/framework] application. Help me find the root cause.

Error message:
[paste full error message]

Stack trace:
[paste full stack trace]

Code where the error occurs:
[paste the function/method — ideally 20–60 lines of context]

What I expected to happen:
[describe expected behavior]

What actually happens:
[describe actual behavior]

What I've already tried:
[list any debugging steps you've already taken]

Please:
1. Identify the most likely root cause (not just the symptom)
2. Explain WHY this error occurs in plain terms
3. Suggest 2–3 possible fixes with trade-offs for each
4. Flag any related issues you notice in the code, even if not causing this error

I have an intermittent bug that may be a race condition or async ordering issue. 
Language/framework: [language]
Async model: [callbacks / promises / async-await / goroutines / threads]

Affected code:
[paste the relevant async code sections]

Symptom: The bug occurs when [describe trigger — e.g. "multiple users submit the form simultaneously"].
Frequency: approximately [X% of the time / only under load / only in production].

Please:
1. Identify potential race conditions or ordering issues in this code
2. Explain the scenario under which each could trigger
3. Suggest fixes that eliminate the race condition, not just reduce its frequency
4. If relevant, suggest how to write a test that reliably reproduces the issue

I have profiler output from a [Node.js / Python / Java / Go] application that's performing 
slower than expected.

Performance target: [e.g., "API response under 200ms, currently averaging 900ms"]

Profiler output / flame graph summary:
[paste profiler output, top N functions, or describe where time is spent]

Database query analysis (if available):
[paste slow query log or EXPLAIN output]

Relevant code sections for the hot paths:
[paste the functions showing up in the profiler]

Please:
1. Identify the top 3 performance bottlenecks by likely impact
2. For each: explain the cause and suggest a specific fix
3. Estimate the order-of-magnitude improvement each fix might yield
4. Flag any anti-patterns that could cause future performance regressions

I'm investigating a memory leak in a [language/runtime] application.

Symptoms:
- Memory grows from [X MB] to [Y MB] over [time period]
- [Any other observations: GC behavior, heap dumps, specific operations that trigger growth]

Heap snapshot / memory profile summary (if available):
[paste key data — e.g., object type counts, retained sizes]

Code sections I suspect (or common leak patterns for this framework):
[paste relevant sections, e.g. event listener setup, closure-heavy code, caches]

Our environment:
- Runtime version: [e.g., Node.js 22, Python 3.12]
- Long-running process: [yes/no]

Please:
1. Identify likely leak sources based on the symptoms and code
2. Explain the retention mechanism for each (why the GC can't reclaim it)
3. Suggest targeted fixes
4. Recommend monitoring strategies to confirm the fix in production

I'm dealing with a dependency conflict in a [npm / pip / cargo / maven] project.

Error output:
[paste the full dependency resolution error]

My package manifest (package.json / requirements.txt / Cargo.toml):
[paste full file or relevant sections]

What I'm trying to add / upgrade:
[package name and target version]

Constraints:
- Cannot upgrade [specific dependency] past [version] due to [reason]
- Must maintain compatibility with [Node.js / Python / etc. version]

Please:
1. Explain exactly what the conflict is and why it exists
2. Suggest the minimum set of changes to resolve it
3. Flag any compatibility risks with the suggested resolution
4. If a clean resolution is impossible, explain the trade-offs of each compromise option

Review this [language] code before it goes into a pull request. Be thorough and honest.

Code:
[paste the code]

Context:
- This is part of [describe the feature/module]
- It will handle [describe the scale: e.g. "~1000 requests/hour" or "batch job running nightly"]
- Current test coverage for this module: [%]

Review for:
1. Bugs and logic errors (be specific about conditions under which they trigger)
2. Security issues (injection, exposure, improper auth, etc.)
3. Edge cases that aren't handled
4. Performance issues that matter at the stated scale
5. Readability and maintainability concerns
6. Missing or inadequate error handling

Format your response as:
- CRITICAL: [issues that must be fixed before merge]
- IMPORTANT: [issues that should be fixed]
- MINOR: [suggestions and style notes]
- LOOKS GOOD: [what's done well — be specific]

Perform a security audit on this [language] code. Focus exclusively on security issues.

Code:
[paste the code]

Context:
- Entry point: [is this user-facing? internal API? admin only?]
- Authentication: [how is the caller authenticated?]
- Data handled: [PII / financial / public / internal]
- External integrations: [databases, third-party APIs, file system, etc.]

Specifically check for:
- Injection vulnerabilities (SQL, command, LDAP, etc.)
- Authentication/authorization bypasses
- Sensitive data exposure (logging, error messages, API responses)
- Input validation gaps
- Insecure direct object references
- Missing rate limiting or abuse prevention
- Cryptographic issues (weak algorithms, predictable tokens, etc.)

For each finding: severity (CRITICAL / HIGH / MEDIUM / LOW), description of the attack vector, and recommended fix.
Do not include style or performance feedback — security only.

I need to refactor legacy [language] code. Help me create a safe, incremental plan.

Current code:
[paste the code]

Problems I'm aware of:
- [known issue 1]
- [known issue 2]

Constraints:
- Cannot change the public interface / existing callers depend on current API signatures
- Test coverage: [describe current state — low / moderate / high]
- Risk tolerance: [e.g., "this is called in the payment flow, changes must be very safe"]

Please:
1. Identify all refactoring opportunities in priority order
2. Suggest an incremental refactoring sequence (which changes to make first, second, etc.)
3. For each step: describe what changes, what risk it introduces, and what tests to add before making the change
4. Flag any refactorings that look tempting but are actually risky given the constraints

Analyze this [language] code for code smells and design issues. Don't fix anything — 
just identify and explain the problems.

Code:
[paste the code]

For each issue found:
- Name the specific anti-pattern or code smell (e.g., "God Class," "Shotgun Surgery," "Feature Envy")
- Explain why it's a problem in this specific context
- Rate the severity of leaving it as-is: [High / Medium / Low]
- Suggest the appropriate refactoring pattern to address it (name the pattern, don't implement it)

Focus on structural issues, not style preferences.

Simplify this [language] code without changing its behavior or public interface.

Code:
[paste the code]

Goals (pick what applies):
□ Reduce lines of code
□ Remove unnecessary abstractions
□ Flatten nested conditions
□ Remove dead code paths
□ Replace verbose constructs with language idioms

Hard constraints:
- Do not change function signatures
- Do not change error handling behavior
- Do not introduce new dependencies
- Must pass the same tests as the original

Output:
1. Simplified code
2. For each change: what you changed and why it's equivalent
3. Any behavior changes I should verify manually

Write comprehensive unit tests for this [language] code using [Jest / pytest / Go testing / JUnit].

Code to test:
[paste the function/class/module]

Testing framework conventions (paste one example test from your codebase):
[paste example]

Required coverage:
1. Happy path: all valid inputs producing expected outputs
2. Boundary conditions: min/max values, empty inputs, single-element collections
3. Error cases: invalid inputs, missing required fields, type mismatches
4. Null/undefined/None handling
5. [Any domain-specific edge cases you know about]

Mocking:
- Mock these external dependencies: [list databases, APIs, file system, etc.]
- Use [your mocking library, e.g. jest.mock / unittest.mock / testify/mock]

Do NOT:
- Test implementation details (test behavior, not internals)
- Write tests that only pass in isolation (no global state assumptions)
- Add comments explaining what each test does — the test name should be self-explanatory

Test naming convention: [describe your convention, e.g. "should_[expected]_when_[condition]"]

Write integration tests for the following user journey using [Playwright / Cypress / Supertest].

User journey to test:
1. [step 1, e.g. "User submits login form with valid credentials"]
2. [step 2, e.g. "System redirects to dashboard"]
3. [step 3, e.g. "User creates a new resource via the form"]
4. [step 4, e.g. "Resource appears in the list view"]

API endpoints or UI components involved:
[list the endpoints / pages / components]

Test database state (what should exist before the test runs):
[describe seed data needed]

Also write tests for these failure scenarios:
- [failure scenario 1, e.g. "login with incorrect password"]
- [failure scenario 2, e.g. "submit form with missing required field"]

Cleanup: [describe how to reset state after each test — delete created records, reset mocks, etc.]

Analyze this code and its existing tests to identify coverage gaps.

Production code:
[paste the code]

Existing tests:
[paste the test file]

Current coverage report (if available):
[paste coverage output or describe uncovered lines]

Please:
1. Map out all the code paths through this function/module
2. Identify which paths are NOT covered by existing tests
3. For each uncovered path: explain the risk of not testing it (Low / Medium / High) with reasoning
4. Write the missing tests in order of risk priority
5. Flag any existing tests that are testing the wrong things or are likely to produce false confidence

Generate comprehensive API documentation for this endpoint / function.

Code:
[paste the endpoint/function]

Target audience: [internal developers / external API consumers / both]
Documentation format: [OpenAPI 3.0 YAML / Markdown / JSDoc / Python docstring]

Include:
- Purpose and when to use this endpoint
- All parameters with types, constraints, and whether required or optional
- Request body schema with field descriptions
- All possible response codes and what triggers each
- Response body schema with field descriptions
- At least 2 realistic usage examples (curl for APIs, code for functions)
- Known limitations or gotchas
- Related endpoints/functions

Do NOT include implementation details or internal logic — this is for consumers of the API, not maintainers.

Generate a README.md for this project.

Project description: [what it does in one sentence]
Target users: [who this is built for]
Tech stack: [languages, frameworks, key dependencies]

Key information to include:
- Prerequisites and system requirements
- Installation steps (tested, sequential, copy-pasteable)
- Configuration (environment variables with examples)
- Basic usage examples (real commands, not placeholders)
- How to run tests
- How to contribute (if open source)
- License

Context from the codebase (paste package.json / pyproject.toml / README draft if any):
[paste]

Tone: [technical and concise / friendly and approachable]
Do NOT use marketing language, vague descriptions, or placeholder examples.
Every command in the README must actually work.

Help me write an Architecture Decision Record (ADR) for the following decision.

Decision to document: [e.g., "Which message queue to use for our event-driven system"]

Options I'm considering:
1. [Option A, e.g. "RabbitMQ"] — [brief description of why it's a candidate]
2. [Option B, e.g. "Apache Kafka"] — [brief description]
3. [Option C, e.g. "AWS SQS"] — [brief description]

Our constraints and requirements:
- Scale: [e.g., "~50,000 events/day, expected to reach 1M within 18 months"]
- Team expertise: [e.g., "team has experience with X, not Y"]
- Operational: [e.g., "managed service preferred — no dedicated ops team"]
- Cost: [e.g., "under $X/month at current scale"]
- Existing infrastructure: [e.g., "already on AWS, using ECS"]

Format as a proper ADR with sections: Status, Context, Decision, Consequences (positive and negative), Alternatives Considered.

Critique this system design. Be honest and specific — I want the problems, not validation.

System description:
[describe the proposed architecture — components, data flow, key decisions]

(Optional) Architecture diagram description or ASCII diagram:
[paste if available]

Scale targets:
- Users: [e.g., "10,000 concurrent users, 500,000 registered"]
- Data volume: [e.g., "2TB of documents, growing 20GB/month"]
- Availability target: [e.g., "99.9% uptime"]

Please evaluate:
1. Single points of failure
2. Scalability bottlenecks (where will this break first under load?)
3. Data consistency risks
4. Security surface area concerns
5. Operational complexity (will a small team be able to run this?)
6. Cost at the stated scale

Rate overall design risk: Low / Medium / High, with reasoning.
Be specific. "This could have issues" is not useful — name the issue.

Explain [concept/feature/pattern] to me. My background: [your experience level and relevant context].

I want to understand:
1. What problem this solves (specifically — not just "it makes code better")
2. How it works internally (one level below the surface API)
3. When to use it vs. [common alternative]
4. When NOT to use it (the cases where it's the wrong choice)
5. The most common mistakes developers make with it
6. One non-trivial example that shows something you can't do without this concept

Keep examples in [language]. Use the level of detail appropriate for someone who [describe your level, e.g., "understands closures and async/await but hasn't worked with Rust's borrow checker"].

I need to understand this code I didn't write (or haven't read in a long time). 
Give me a thorough explanation oriented toward someone who needs to modify it safely.

Code:
[paste the code]

Please explain:
1. What this code does at a high level (purpose and context, if inferrable)
2. Walk through the logic step by step — don't skip parts that look obvious
3. What the key assumptions are (what inputs, state, or environment does it depend on?)
4. What would break if [specific thing you might want to change]
5. What parts of this code are fragile or surprising
6. What you'd want to know from the original author before touching this

Do not rewrite or improve the code — just explain it.