Here is the entry point of my project and its package.json.

[paste your main file + package.json]

Write a complete README.md following this structure:
1. Project name and one-line description
2. Why this exists (problem it solves)
3. Prerequisites
4. Installation (exact commands)
5. Quick start with a working code example
6. Configuration options (table format)
7. Contributing guidelines
8. License

Use GitHub-flavored markdown. The audience is mid-level developers who will fork this for their own use.

Here is a function written by a previous developer. Add inline comments that explain:
- What each block of logic is doing
- Why non-obvious decisions were made (infer from context)
- Any edge cases being handled
- TODOs for anything that looks risky

Keep comments concise — one line max unless the logic genuinely requires explanation. Do NOT add comments for self-evident code.

[paste function]

typescript// Use sliding window instead of fixed window to prevent burst attacks at window boundaries
const windowStart = Date.now() - WINDOW_MS;

// Filter requests within the current window — O(n) but n is capped by MAX_REQUESTS
const recentRequests = requestLog.filter(ts => ts > windowStart);

// TODO: Move this to Redis for multi-instance deployments — in-memory won't work in production clusters
if (recentRequests.length >= MAX_REQUESTS) {
  throw new RateLimitError(`Limit of ${MAX_REQUESTS} requests per ${WINDOW_MS}ms exceeded`);
}

Add complete JSDoc annotations to each function below. Include:
- @description — what the function does, not how
- @param — for each parameter, including constraints (e.g., "must be positive", "ISO 8601 format")
- @returns — what the return value represents
- @throws — any errors thrown and under what conditions
- @example — one working usage example

[paste your TypeScript file]

typescript/**
 * Calculates compound interest over a given period.
 *
 * @description Applies the standard compound interest formula (A = P(1 + r/n)^nt).
 * Rounds to 2 decimal places to avoid floating point drift in financial contexts.
 *
 * @param principal - Initial investment amount in USD. Must be positive.
 * @param annualRate - Annual interest rate as a decimal (e.g., 0.05 for 5%). Must be between 0 and 1.
 * @param years - Investment duration in years. Must be a positive integer.
 * @param compoundingsPerYear - Number of times interest compounds annually. Defaults to 12 (monthly).
 * @returns Final value after interest, rounded to 2 decimal places.
 * @throws {RangeError} If principal or years is negative, or if annualRate is outside [0, 1].
 *
 * @example
 * compoundInterest(10000, 0.07, 10) // Returns 19671.51
 */
function compoundInterest(
  principal: number,
  annualRate: number,
  years: number,
  compoundingsPerYear = 12
): number { ... }

Here are my Express route handlers for the /users resource.

[paste routes]

Generate a complete OpenAPI 3.0 YAML spec for these routes. Include:
- Path parameters and query string params with types and validation rules
- Request body schema (infer from the handler logic)
- Response schemas for success and error cases (400, 401, 404, 500)
- Security scheme (Bearer token, inferred from the auth middleware)
- Example request and response values

Here is a git diff for a sprint's worth of changes.

[paste git diff or list of commit messages]

Write a CHANGELOG.md entry following the Keep a Changelog format:
- Version and date at the top
- Group changes under: Added, Changed, Fixed, Deprecated, Removed, Security
- Each entry should explain the user/developer impact, not just what changed
- Flag anything that is a breaking change with [BREAKING]

Search this codebase for all environment variable references (process.env.*, import.meta.env.*).

[paste relevant files or a list of env vars]

Generate:
1. A .env.example file with placeholder values and comments explaining each variable
2. A "Configuration" section for the README that groups variables by category (database, auth, external APIs, feature flags) and marks which ones are required vs optional

bash# ─────────────────────────────────────────────
# DATABASE
# ─────────────────────────────────────────────

# Neon PostgreSQL connection string (required)
# Format: postgresql://user:password@host/database?sslmode=require
DATABASE_URL=

# Connection pool size per serverless instance (optional, default: 5)
DATABASE_POOL_SIZE=5

# ─────────────────────────────────────────────
# AUTHENTICATION
# ─────────────────────────────────────────────

# NextAuth.js secret — generate with: openssl rand -base64 32 (required)
NEXTAUTH_SECRET=

# OAuth callback URL — must match provider settings exactly (required)
NEXTAUTH_URL=http://localhost:3000

I made the following architectural decision: [describe the decision, e.g., "switched from REST to tRPC for our internal API layer"].

Write an Architecture Decision Record (ADR) in the Nygard format:
- Title
- Status (Accepted)
- Context — what problem we were solving and constraints
- Decision — what we chose and why
- Consequences — what becomes easier, what becomes harder, what we're accepting as a trade-off

Here is additional context about why we made this choice:
[explain your reasoning]

markdown## Documentation Rules
- After writing any new exported function, generate JSDoc annotations
- After merging a feature branch, generate a CHANGELOG entry
- If a new environment variable is added, update .env.example immediately