How Engineering Teams Use AI Prompts to Ship Better Documentation

You are a senior backend engineer writing a technical specification for an internal audience of backend and platform engineers.

CONTEXT:
We are building Billing Sync v3 to replace the current cron-based reconciliation between our PostgreSQL billing records and Stripe. The current system has a 4-hour reconciliation window, which causes support tickets when customers see stale invoice data. We use an event-driven architecture (Kafka) for most inter-service communication. The payments team owns the Stripe integration and has limited bandwidth until mid-Q3.

OBJECTIVE:
Write a technical specification covering:
- Problem statement with quantified impact (support ticket volume, SLA breach frequency)
- Proposed architecture with data flow diagram description
- API contract changes (list breaking vs. non-breaking)
- Migration strategy from v2 to v3 with rollback plan
- Telemetry and alerting requirements
- Testing plan (unit, integration, E2E, load test targets)
- Dependencies on other teams with expected timelines
- Open questions that need resolution before implementation

CONSTRAINTS:
- Must maintain backward compatibility with existing webhook consumers
- Reconciliation latency target: under 60 seconds
- Zero-downtime deployment required
- Budget: no new infrastructure beyond existing Kafka cluster

FORMAT:
Use markdown with H2 sections matching each objective item. Include a summary table of risks and mitigations at the end.

You are a staff engineer writing an Architecture Decision Record for a mixed audience of senior engineers, engineering managers, and the VP of Engineering.

CONTEXT:
We evaluated message brokers for our new event-driven pipeline that handles billing events, user activity tracking, and real-time notification delivery. Current throughput is ~2,000 events/second with projected growth to 15,000/second over 18 months. Team has strong PostgreSQL and Redis expertise but limited Kafka operational experience. We are running on AWS with a preference for managed services where possible.

OBJECTIVE:
Write an ADR following the standard format:
- Title (ADR-### format)
- Status: Accepted
- Context: Why this decision was needed now
- Options Considered: Kafka (MSK), SQS + SNS, RabbitMQ (AmazonMQ) -- include specific pros/cons for each given our context
- Decision: What we chose and the primary reasons
- Consequences: Both positive and negative, including operational burden
- Migration Plan: How we will phase adoption across services
- Review Date: When to reassess this decision

CONSTRAINTS:
- Be honest about trade-offs. Do not oversell the chosen option.
- Include cost estimates where relevant (rough order of magnitude)
- Address the operational learning curve explicitly since we are a Kafka-new team

FORMAT:
Markdown ADR format. Use tables for option comparison. Keep total length under 800 words.

You are a senior engineer writing a pull request summary for two reviewers: a backend engineer who owns the auth service, and a platform engineer who owns the deployment pipeline.

CONTEXT:
This PR migrates our session management from Redis-stored JWTs to database-backed sessions with Redis caching. Motivation: we need per-device session revocation for SOC 2 compliance (audit deadline: August 15). The PR touches 14 files across the auth service, the API gateway middleware, and the session cleanup worker.

OBJECTIVE:
Write a PR summary that includes:
- One-paragraph motivation and approach
- List of files changed grouped by concern (auth logic, middleware, worker, tests)
- Key design decisions made in this PR and their rationale
- Areas where reviewer attention is most needed (flag specific files or functions)
- Testing done and testing gaps (what is covered, what still needs manual verification)
- Deployment notes (feature flag name, rollback procedure, monitoring to watch)

FORMAT:
Markdown with collapsible sections for file groups. Use a callout block for deployment notes. Keep the top-level summary under 200 words so reviewers get the picture fast.

You are a tech lead writing a summary of a major infrastructure change for three audiences: the product team (cares about feature impact and timeline), the customer success team (cares about customer-facing changes and support implications), and the VP of Engineering (cares about risk, cost, and team capacity impact).

CONTEXT:
We are replacing our batch data ingestion pipeline with a streaming architecture. Currently, data imports run nightly and take 2-6 hours depending on volume. The new system processes records within 30 seconds of receipt. This affects the Import feature used by 40% of enterprise customers. The migration will run both systems in parallel for 4 weeks before cutover.

OBJECTIVE:
Write three versions of the same update, one for each audience:
1. Product team: Focus on feature capabilities, what is now possible, timeline
2. Customer success: Focus on what customers will see change, potential questions, support playbook
3. VP of Engineering: Focus on risk assessment, resource allocation, rollback strategy

CONSTRAINTS:
- No jargon in the product and CS versions (avoid: Kafka, event-driven, microservices, throughput)
- Include concrete numbers (latency improvement, affected customer %)
- Each version should be under 250 words

FORMAT:
Three clearly labeled sections with the audience name as H3 header.