25 Claude Opus 4.7 Prompts for 1M-Context Codebase Review (Copy-Paste)

<task>
Scan the pasted codebase for hardcoded secrets, credentials, and sensitive 
values. Look for: API keys, tokens, passwords, private keys, connection strings, 
JWT secrets, and any string that looks like it should be in an environment 
variable but isn't.

For each finding:
- Quote the exact line verbatim (file:line format required)
- Classify: Critical (production secret), High (test/dev secret or key pattern), 
  Medium (placeholder that could become a real value), Low (commented-out value)
- Note whether the value appears in .gitignore-relevant files

Output format: markdown table with columns — Severity | File:Line | Type | 
Verbatim Excerpt | Recommendation

If a category is not found in the pasted files, write "not found" — 
do not infer from filenames alone.
</task>

<codebase>
<file path="src/config/env.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/auth/login.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Audit the authentication and session management implementation in the pasted 
codebase. Examine: login/logout flows, token generation and validation, session 
storage, password handling, and auth middleware.

For each issue found:
- Quote the exact code verbatim with file:line citation
- Assign severity: Critical / High / Medium / Low
- Describe the vulnerability or weakness
- Suggest the specific fix

Also produce a short "Auth Flow Summary" (3-5 sentences) describing how 
authentication works based solely on the pasted code — do not assume 
framework defaults that aren't visible.

If a component (e.g., token refresh, MFA) is not present in the pasted 
files, say "not found" — do not infer it exists elsewhere.
</task>

<codebase>
<file path="src/auth/login.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/auth/middleware.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/auth/session.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/users.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Hunt for injection vulnerabilities across the pasted codebase. Categories to 
check: SQL injection (raw query construction, string interpolation into queries), 
NoSQL injection, command injection (shell exec calls with user input), LDAP 
injection, and template injection.

For each risk:
- Quote the exact vulnerable expression verbatim with file:line
- Severity: Critical (directly exploitable) / High (likely exploitable with 
  attacker-controlled input) / Medium (needs specific conditions) / Low (theoretical)
- Describe the attack vector
- Show the safe rewrite

Output: findings table sorted by severity, then a "Safe Patterns Observed" 
section noting any parameterized query usage already present in the code. 
If a category is not found in the pasted files, say "not found."
</task>

<codebase>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/queries.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/search.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/users.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Review the pasted codebase for Insecure Direct Object Reference (IDOR) 
vulnerabilities and missing authorization checks. Specifically look for:
- Endpoints that accept resource IDs (user IDs, document IDs, order IDs) 
  without verifying the requesting user owns or has permission to access them
- Authorization checks that happen after data retrieval instead of before
- Missing role checks on sensitive operations
- Trust in client-supplied ownership fields

For each gap:
- Quote the exact lines verbatim with file:line
- Severity: Critical / High / Medium / Low
- Describe the access control bypass scenario
- Show the corrected authorization pattern

If authorization checks are present and correct for a given route, note that 
explicitly. Do not infer authorization logic from files not pasted.
</task>

<codebase>
<file path="src/api/documents.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/users.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/middleware/auth.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/permissions.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Review the pasted dependency manifest(s) and identify packages with known 
vulnerability patterns. For each package:
- Note the pinned version
- Flag any package known to have had critical CVEs in the version range visible
- Identify packages that appear significantly out of date relative to major 
  version availability
- Flag packages with abandoned maintenance signals (if visible in lock file metadata)

Output format: table with columns — Package | Pinned Version | Risk Level | 
Reason | Recommended Action

Also list any dependency hygiene issues: floating version ranges (^, ~, *), 
duplicate packages at incompatible versions, and dev dependencies installed 
in production scope.

Base findings strictly on the pasted manifest content. If you cannot confirm 
a CVE from the pasted information alone, note it as "requires live CVE database 
check" rather than asserting it.
</task>

<codebase>
<file path="package.json">
[PASTE FILE CONTENTS]
</file>
<file path="package-lock.json">
[PASTE FILE CONTENTS — or yarn.lock / pnpm-lock.yaml]
</file>
</codebase>

<task>
Build a module dependency map for the pasted codebase. For each file or module:
- List what it imports (internal modules only — ignore node_modules)
- List what imports it
- Identify any circular dependencies (A → B → A)
- Flag any module with more than 8 direct importers (high fan-in, change risk)
- Flag any module that imports more than 10 internal modules (high fan-out, 
  complexity signal)

Output: 
1. Adjacency list in markdown (module → [dependencies])
2. Circular dependency list with full cycle chain
3. High fan-in modules table
4. High fan-out modules table
5. One-paragraph summary of the dependency structure

Base the map only on import statements visible in the pasted files. 
If an imported path is not included in the paste, mark it as "[not pasted]."
</task>

<codebase>
<file path="src/index.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/auth/index.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/index.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
The intended layering for this codebase is:
[DESCRIBE YOUR INTENDED LAYERS — e.g., "API routes → Service layer → 
Repository layer → Database client. Routes should not call the database 
directly. Repositories should not call other repositories."]

Review the pasted code for layer violations. A violation is any import or 
function call that skips a layer or creates a downward dependency from a 
lower layer to a higher one.

For each violation:
- Quote the offending import or call verbatim with file:line
- Describe which layer rule it breaks
- Suggest the correct refactor path (introduce a service method, inject a 
  dependency, etc.)

Severity: Critical (business logic in persistence layer or vice versa), 
High (route calling DB directly), Medium (utility leaking domain knowledge), 
Low (minor organizational inconsistency)

If a layer structure cannot be confirmed from the pasted files alone, 
say "not determinable from pasted code."
</task>

<codebase>
<file path="src/api/orders.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/orderService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/orders.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Trace the hot path for [DESCRIBE THE OPERATION — e.g., "a user submitting 
a payment"] through the pasted codebase. Map every function call, database 
query, external API call, and transformation that happens from the entry 
point to the final response.

For each step in the trace:
- Quote the relevant function signature or call verbatim with file:line
- Note estimated cost (CPU-bound, I/O-bound, network call, DB query)
- Flag any synchronous blocking operations in an async context
- Flag any operations happening serially that could run in parallel
- Flag any missing error handling at that step

Output:
1. Numbered trace (function call chain with file:line each)
2. Bottleneck candidates table: Step | Cost Type | Issue | Optimization Suggestion
3. Missing error handler locations

Only trace code that is present in the pasted files. Where a call leads 
to a file not pasted, note "[file not pasted — trace ends here]."
</task>

<codebase>
<file path="src/api/payments.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/paymentService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/transactions.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/external/stripeClient.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Based on the pasted codebase, reverse-engineer the architectural decisions 
that shaped it. For each decision you can infer from concrete evidence:

Write an Architecture Decision Record (ADR) in this format:
- Title: [Decision name]
- Status: Inferred-from-code
- Context: [What problem this decision addresses, based on code evidence]
- Decision: [What was chosen, quoted from code with file:line]
- Consequences: [What this enables and what it constrains, based on what 
  you observe in the code]
- Evidence: [2-3 verbatim code quotes that confirm this decision was made]

Produce between 4 and 8 ADRs based on the most significant decisions visible 
in the code. Do not invent decisions not supported by the pasted code. 
If a common architectural concern (e.g., caching strategy) is absent from 
the pasted files, note "not determinable from pasted code."
</task>

<codebase>
<file path="src/index.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/middleware.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/authService.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Evaluate the coupling and cohesion of the pasted modules. For each module 
or class:

Cohesion assessment:
- Does this module do one thing? If not, what are the distinct responsibilities?
- Quote the function signatures that indicate mixed concerns (file:line)
- Suggest how to split or refocus the module

Coupling assessment:
- Count direct dependencies on other internal modules
- Identify "god modules" that everything depends on
- Identify modules that know too much about other modules' internals 
  (accessing fields directly rather than through methods)

Output:
1. Cohesion table: Module | Single Responsibility? | Issues | Split Suggestion
2. Coupling table: Module | Dependency Count | Concerns | Decoupling Approach
3. Top 3 highest-priority refactors with rationale

Use verbatim quotes with file:line for every identified issue. 
Do not assess modules not present in the pasted files.
</task>

<codebase>
<file path="src/services/userService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/authService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/users.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/users.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Identify dead code in the pasted codebase. Dead code includes: exported 
functions or classes with no visible importers in the pasted files, unreachable 
branches (conditions that are always true/false based on constant values), 
commented-out code blocks over 5 lines, and feature flags that are permanently 
set to enabled or disabled.

For each dead code instance:
- Quote the dead code verbatim with file:line
- Classify: Unused Export / Unreachable Branch / Commented-Out Block / 
  Dead Feature Flag / Other
- Confidence: High (definitely dead given pasted code) / Medium (dead in 
  pasted files but may have external callers) / Low (circumstantially dead)
- Recommendation: Delete / Archive / Confirm with team before deleting

Output a findings table sorted by confidence descending, then by file.
If you cannot confirm deadness from the pasted files alone, 
say "not determinable" — do not guess.
</task>

<codebase>
<file path="src/utils/formatters.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/utils/validators.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/legacyService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/index.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Find duplicated logic in the pasted codebase. Look for: identical or 
near-identical functions appearing in more than one file, repeated 
inline logic that should be extracted into a shared utility, copy-paste 
error patterns (same logic with slightly different variable names), and 
parallel data transformation chains doing the same thing in different places.

For each duplication:
- Quote both (or all) instances verbatim with file:line for each
- Similarity: Exact / Near-identical / Structurally similar
- Describe what shared abstraction would replace them
- Estimate risk of divergence (if these copies drift, what breaks?)

Output: findings list sorted by severity of divergence risk.
Do not report cases where similar-looking code serves genuinely 
different purposes — explain why if you skip something suspicious.
</task>

<codebase>
<file path="src/api/users.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/orders.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/products.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/utils/helpers.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Review the pasted TypeScript codebase for type safety gaps and produce 
an upgrade plan. Look for: `any` types, type assertions (`as X`) that 
paper over real type mismatches, missing return type annotations on 
exported functions, runtime values typed as `unknown` but cast without 
validation, and schema-validated inputs that aren't reflected in the type system.

For each gap:
- Quote the problematic type usage verbatim with file:line
- Severity: High (masks real type errors) / Medium (weakens inference) / 
  Low (style issue)
- Show the correct type or type guard that should replace it

Also produce a prioritized upgrade task list: which files to tackle first 
based on how many `any` types they export versus keep internal.

Do not suggest type changes for files not present in the paste.
</task>

<codebase>
<file path="src/api/middleware.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/dataService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/types/index.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Review the pasted codebase for callback-style async code, Promise chains 
that should be async/await, and any blocking synchronous I/O that should 
be non-blocking. Produce a migration plan.

For each pattern to migrate:
- Quote the current code verbatim with file:line
- Show the async/await equivalent
- Flag any cases where the migration is non-trivial (event emitter patterns, 
  streaming, recursive async, error boundary changes)
- Estimate migration effort: Small (direct swap) / Medium (requires refactor) / 
  Large (requires redesign)

Output:
1. Migration table: File:Line | Current Pattern | Target Pattern | Effort
2. High-risk migrations section (those flagged Large) with detailed notes
3. Recommended migration sequence (which files to migrate first to minimize 
   integration breakage)

Base the plan only on the pasted code. Do not assume callback patterns 
exist in files not included.
</task>

<codebase>
<file path="src/lib/fileProcessor.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/emailService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/workers/queue.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Identify the highest cyclomatic complexity functions in the pasted codebase. 
For each function, count: if/else branches, switch cases, ternary expressions, 
loop conditions, catch blocks, and early returns.

For each function with complexity > 7:
- Quote the function signature and first 5 lines verbatim with file:line
- Report the complexity score (branch count)
- List the specific conditions that drive the complexity
- Suggest a refactor strategy: extract-condition, strategy-pattern, 
  early-return simplification, lookup-table, or decompose-function

Output:
1. Complexity hotspot table: File:Line | Function Name | Complexity Score | 
   Primary Driver | Refactor Strategy
2. Top 5 most complex functions with full refactor sketches

Only score functions present in the pasted files.
</task>

<codebase>
<file path="src/services/billingService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/checkout.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/utils/validators.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/lib/ruleEngine.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Hunt for N+1 query patterns in the pasted codebase. An N+1 occurs when 
code fetches a list of records and then issues individual queries for each 
record inside a loop or map. Also look for: queries inside render loops, 
database calls inside Promise.all that could be batched, and missing 
eager-load or join opportunities.

For each N+1 or batching opportunity:
- Quote the loop and the database call inside it verbatim with file:line
- Estimated impact: Critical (unbounded N, no pagination) / High (bounded 
  but common code path) / Medium (rare path or small N) / Low (negligible)
- Show the batched/joined query that should replace it

If ORM is used, show the eager-load or include syntax appropriate for 
that ORM based on its usage pattern in the pasted code.
If no N+1 patterns are found in the pasted files, say "not found."
</task>

<codebase>
<file path="src/api/posts.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/feedService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/posts.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/users.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Review the pasted codebase for memory leak suspects. Look for: event 
listeners added without corresponding removal, subscriptions not cleaned 
up in component unmount or service teardown, closures that capture large 
objects unnecessarily, caches or maps that grow without eviction policies, 
and timers/intervals not cleared on shutdown.

For each suspect:
- Quote the problematic code verbatim with file:line
- Classify: Event Listener Leak / Subscription Leak / Cache Growth / 
  Timer Leak / Closure Capture / Other
- Severity: High (confirmed leak path) / Medium (likely leak under certain 
  conditions) / Low (minor retention)
- Show the corrected teardown or eviction pattern

If a lifecycle teardown already exists and is correct, note it as 
"correctly handled" rather than flagging it. Do not flag patterns 
in files not pasted.
</task>

<codebase>
<file path="src/services/websocketService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/lib/eventBus.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/workers/backgroundWorker.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/cache/inMemoryCache.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Review the pasted codebase for expensive operations that are not cached 
but should be, and for caching implementations that may be missing 
invalidation logic. Look for: repeated database queries for the same 
data within a request lifecycle, expensive computations called with 
identical inputs, external API calls that could be cached with reasonable 
TTLs, and cache keys that don't account for all relevant input dimensions.

For each caching opportunity or gap:
- Quote the uncached expensive operation verbatim with file:line
- Describe what data it fetches and how often it's likely called
- Suggest: cache key structure, TTL rationale, invalidation trigger
- Flag any existing cache implementations with missing invalidation 
  (quote the cache set without a corresponding invalidate)

Output: findings table + caching strategy recommendations per module.
</task>

<codebase>
<file path="src/services/productService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/catalog.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/cache/redisClient.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/products.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Audit the pasted codebase for missing or misconfigured timeout and retry 
logic on external calls. Look for: HTTP client calls without timeout 
configuration, database queries without statement timeouts, external API 
calls without retry logic, retry implementations without exponential 
backoff or jitter, and retry loops without a maximum attempt limit.

For each gap:
- Quote the call without timeout or retry verbatim with file:line
- Severity: Critical (unbounded external call on critical path) / 
  High (missing retry on transient-error-prone operation) / 
  Medium (timeout present but too high) / Low (retry present but suboptimal)
- Show the corrected implementation with specific timeout values 
  and retry configuration

Also flag any retries that could cause duplicate side effects (e.g., 
retrying a non-idempotent payment call). If timeout or retry configuration 
is correct, note it explicitly rather than ignoring it.
</task>

<codebase>
<file path="lib/external/stripeClient.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/external/emailProvider.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/workers/jobRunner.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Find error-handling gaps in the pasted codebase. Look for: unhandled 
Promise rejections, try/catch blocks that swallow errors silently 
(empty catch or catch that only logs), async functions called without 
await that could throw, error types that are caught too broadly 
(catching all errors when only specific ones should be recoverable), 
and missing error boundaries at service or API layer edges.

For each gap:
- Quote the problematic error handling verbatim with file:line
- Classify: Silent Swallow / Missing Await / Over-Broad Catch / 
  Unhandled Rejection / Missing Boundary
- Severity: Critical / High / Medium / Low
- Show the corrected pattern

Also produce a "Error Boundary Inventory": list the points in the 
pasted code where errors are currently caught and handled gracefully, 
and where they are expected to propagate to the caller.
</task>

<codebase>
<file path="src/api/middleware.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/orderService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/workers/notificationWorker.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Write a "repo tour" for a new engineer joining the team who has never 
seen this codebase. The tour should help them be productive within their 
first day, not teach them the language.

Include:
1. What this codebase does (2-3 sentences, based strictly on what the code does)
2. The three entry points they need to understand first (with file:line for each)
3. The mental model for the main data flow (describe it in 5-7 steps)
4. The 5 most important files and what each is responsible for 
   (quote the key function or export from each with file:line)
5. Three things that are non-obvious or surprising about how this code works 
   (with supporting quotes)
6. What not to touch without talking to a senior engineer first 
   (flag anything that looks fragile, tightly coupled, or poorly documented)

Base everything on the pasted code only. Do not reference external 
documentation or assume framework conventions not visible in the files.
</task>

<codebase>
<file path="src/index.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/index.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/index.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Produce a text-based architecture diagram description of the pasted 
codebase that an engineer could use to draw the actual diagram. 

Provide:
1. Component inventory: list every distinct component (service, module, 
   external dependency, data store) you can identify from the pasted files, 
   with the file or path that represents it
2. Connection list: for each connection between components, describe: 
   [Source] → [Target] | Protocol/Method | Data passing | File:Line where visible
3. Boundary groups: which components belong to the same layer or domain
4. External dependencies: any system outside this codebase that the 
   code calls (with file:line showing the integration point)
5. Mermaid diagram syntax for a component diagram based on your findings

Only include components and connections that are visible in the pasted files. 
Mark any component referenced but not pasted as "[external — not pasted]."
</task>

<codebase>
<file path="src/index.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/router.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/external/index.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Extract and define the domain-specific and project-specific vocabulary 
used in the pasted codebase. Include: custom type names, class names, 
function names that encode business concepts, enum values with domain 
meaning, and any jargon used in comments or identifiers.

For each term:
- The term as it appears in code
- File:line where it is defined or first meaningfully used
- Definition inferred from usage context (quote the key usage verbatim)
- Related terms it connects to

Output: alphabetical glossary in markdown, formatted as:
**TermName** (`file:line`) — Definition. See also: RelatedTerm.

Include 20-40 terms. Do not include generic programming terms 
(Promise, Array, etc.) — only terms specific to this codebase's domain. 
Do not define terms that appear only once with no contextual clues.
</task>

<codebase>
<file path="src/types/domain.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/billingService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/userService.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/schema.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Reverse-engineer a "how to build and run this project" guide from the 
pasted configuration and script files. A new engineer should be able 
to follow this guide to get the project running locally from scratch.

Include:
1. Prerequisites: languages, runtimes, tools, and versions inferred 
   from config files (quote the version requirement with file:line)
2. Environment setup: required environment variables and what each is for 
   (based on config files — do not invent variables not visible in the paste)
3. Dependency installation: exact commands based on the package files
4. Local development: the command to start the dev server and what it does
5. Testing: test commands and what each test suite covers
6. Build: production build command and output artifacts
7. Common local issues: anything in the config that suggests tricky 
   setup steps or known platform differences

Only include information derivable from the pasted files. 
If a step requires information not in the paste, write 
"[information not in pasted files — check with team]."
</task>

<codebase>
<file path="package.json">
[PASTE FILE CONTENTS]
</file>
<file path=".env.example">
[PASTE FILE CONTENTS]
</file>
<file path="tsconfig.json">
[PASTE FILE CONTENTS]
</file>
<file path="next.config.ts">
[PASTE FILE CONTENTS — or Dockerfile, docker-compose.yml, Makefile]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>

<task>
Read the pasted codebase as a senior engineer seeing it for the first time. 
Identify the things that would surprise, confuse, or concern a competent 
engineer who is unfamiliar with the project.

For each insight:
- Quote the relevant code verbatim with file:line
- Category: Unexpected Pattern / Non-standard Convention / Hidden Assumption / 
  Surprising Dependency / Implicit Constraint / Design Mismatch
- Explanation: why a typical engineer would be surprised and what context 
  they'd need to understand it
- Action: Document it / Refactor it / Leave it but add a comment / 
  Raise with the team

Output 8-15 insights ordered by how likely they are to cause confusion 
or incidents for someone unfamiliar with the codebase. 
Only cite code present in the paste. If nothing is surprising 
for a given category, say so — do not fabricate surprises.
</task>

<codebase>
<file path="src/index.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/api/middleware.ts">
[PASTE FILE CONTENTS]
</file>
<file path="lib/db/client.ts">
[PASTE FILE CONTENTS]
</file>
<file path="src/services/authService.ts">
[PASTE FILE CONTENTS]
</file>
[CONTINUE FOR ALL RELEVANT FILES]
</codebase>