Claude for Engineering: Beyond Autocomplete

<task>Write a system design document for [system]</task> <requirements> - Functional: [describe] - Scale: [users, requests, data volume] - SLAs: [latency, availability] - Constraints: [budget, team, tech stack] </requirements> <output> 1. Problem statement + goals 2. Non-goals (explicit scope limits) 3. High-level architecture diagram (describe components) 4. Data model 5. API design (core endpoints) 6. Scalability analysis (how it handles 10x, 100x load) 7. Failure modes + mitigations 8. Observability plan (metrics, logs, traces) 9. Security considerations 10. Migration strategy (if replacing existing) 11. Open questions + risks </output>

<task>Write an ADR for [decision]</task> <context> - Decision: [describe] - Forces: [competing concerns] - Options considered: [list] </context> <output> Standard ADR format: 1. Title + status (proposed/accepted/deprecated) 2. Context (what problem, what forces) 3. Decision (what we chose) 4. Alternatives considered (each option with pros/cons) 5. Consequences (positive + negative) 6. Compliance (what monitoring confirms decision is working) </output>

<task>Design a REST API for [feature]</task> <requirements>[describe use cases]</requirements> <output> 1. Resource model (nouns + relationships) 2. Endpoints (method + path + request/response) 3. Authentication + authorization 4. Versioning strategy 5. Pagination, filtering, sorting 6. Error responses (format + codes) 7. Rate limiting 8. Idempotency 9. Example request/response for each endpoint 10. Deprecation strategy for future changes </output>

<task>Design database schema for [domain]</task> <requirements> - Entities: [list] - Relationships: [describe] - Scale: [rows, queries per second] - Database: [PostgreSQL, MySQL, etc.] </requirements> <output> 1. Tables with columns + types + constraints 2. Primary keys + foreign keys 3. Indexes (with justification for each) 4. Normalization level (3NF, denormalized, hybrid) 5. Common query patterns + their performance 6. Migration path for schema changes 7. Sharding / partitioning strategy (if applicable) 8. Soft-delete vs hard-delete policy 9. Audit/history considerations </output>

<task>Decompose this monolith into microservices</task> <current_system>[describe]</current_system> <pain_points>[what's broken today]</pain_points> <output> 1. Service boundaries (by domain, not by tech layer) 2. Data ownership per service 3. Inter-service communication (sync vs async) 4. Shared concerns (auth, logging, etc.) 5. Migration strategy (strangler fig pattern?) 6. Team structure implications (Conway's Law) 7. Failure modes introduced by distribution 8. Cost/benefit honest assessment 9. When NOT to decompose </output>

<task>Review this code as a senior engineer</task> <code>[paste]</code> <context>[what it does, who uses it]</context> <output> 1. Bugs (correctness issues) 2. Security issues (injections, auth bypasses, data leaks) 3. Performance concerns (N+1 queries, unbounded loops) 4. Readability / maintainability 5. Test coverage gaps 6. API design (if public interface) 7. Edge cases not handled 8. Would I approve this PR (yes/changes/no) 9. Nits (style, minor suggestions) </output> <constraints>Point to specific lines. Don't rewrite — suggest.</constraints>

<task>Plan a refactor of [component]</task> <current_code>[paste or describe]</current_code> <goal>[what should be better after refactor]</goal> <output> 1. Current pain points (specific) 2. Target state (what good looks like) 3. Refactor approach (incremental steps vs big-bang) 4. Test strategy (how to ensure behavior preserved) 5. Ordered sequence of changes 6. Risks per step 7. Rollback plan 8. How to demonstrate value to stakeholders </output>

<task>Help me understand this legacy code</task> <code>[paste]</code> <context>[what it's supposed to do, if known]</context> <output> 1. Plain-English explanation of what it does 2. Key design decisions visible 3. Assumptions the code makes 4. Places where behavior is surprising or undocumented 5. Dependencies (internal + external) 6. What to be careful modifying 7. Tests that should exist but probably don't </output>

<task>Identify code smells in this codebase</task> <code_samples>[paste several files]</code_samples> <output> Common smells to check: - Long methods / functions - Duplicate code - Feature envy - God classes - Primitive obsession - Data clumps - Inappropriate intimacy - Middle-man classes - Conditional complexity Per smell found: location, severity, refactor suggestion, priority.

<task>Security-review this code</task> <code>[paste]</code> <context>[what it does, auth model]</context> <output> OWASP Top 10 checks: - Injection (SQL, command, XSS) - Broken authentication - Sensitive data exposure - XXE - Broken access control - Security misconfiguration - Insecure deserialization - Vulnerable components - Insufficient logging Per issue: severity, specific location, example exploit, remediation.

<task>Help me debug this issue</task> <symptom>[what's happening — error, bad output, crash]</symptom> <context>[when it started, what changed recently]</context> <code>[paste relevant code]</code> <logs>[paste error logs / stack traces]</logs> <output> 1. Top 5 hypotheses for the cause (ranked by likelihood) 2. For each: how to verify/eliminate 3. Additional data I should gather 4. Quick-win checks first (cheap to verify) 5. What's most likely if nothing else narrows it down </output>

<task>Interpret this stack trace and suggest fixes</task> <stack_trace>[paste]</stack_trace> <language_framework>[specify]</language_framework> <output> 1. What the error means in plain English 2. Where exactly the error originates (root frame) 3. How the call chain reached that point 4. Likely root cause (not just symptom) 5. Common causes of this error 6. Immediate fixes 7. Deeper fixes to prevent recurrence 8. How to write a test that catches this </output>

<task>Analyze this performance profile</task> <profile_data>[paste or describe hot spots]</profile_data> <context>[what the code does, performance target]</context> <output> 1. Top bottlenecks ranked by impact 2. Per bottleneck: why it's slow, fix options 3. Quick wins (low effort, high impact) 4. Deeper architectural fixes 5. Where micro-optimization is pointless 6. Measurement plan to verify improvements </output>

<task>Help me diagnose a flaky test</task> <test>[paste or describe]</test> <symptoms>[how often it fails, when, on what]</symptoms> <output> 1. Common causes of flaky tests (race conditions, time dependencies, shared state, external services, ordering) 2. Which causes fit this test's pattern 3. How to reproduce the flake deterministically 4. Specific fixes 5. If test should be deleted (some flaky tests are truly un-fixable) 6. How to prevent similar flakes in the codebase </output>

<task>Write a blameless postmortem</task> <incident> - What happened: [describe] - Impact: [users affected, duration] - Timeline: [key events] - Resolution: [what fixed it] </incident> <output> 1. TL;DR 2. Timeline (UTC) 3. Impact (specific) 4. Root cause (technical + systemic) 5. What went well (detection, response) 6. What went wrong (delays, gaps) 7. Action items (owner + date) 8. Lessons for similar incidents Tone: blameless, factual, focused on systems not individuals.