AI Prompts Library

I want to refactor [DESCRIPTION OF REFACTOR - e.g., extract auth logic into its own service].

Before touching any code, produce a refactor plan:
1. List the files that will be modified, created, or deleted.
2. Show the new architecture in a one-paragraph summary.
3. Identify the riskiest steps and how to mitigate them.
4. Propose a safe ordering: which step lands first, second, etc., so the codebase stays green at every step.
5. List tests to add or update.

No code yet. Plan only. I'll review and then we execute one step at a time.

You are an expert database architect. Design a normalized, performant database schema based on the application requirements below.

**Application:** [DESCRIBE_YOUR_APPLICATION]
**Database Engine:** [PostgreSQL/MySQL/SQLite/MongoDB]
**Expected Scale:** [Number of users, records, transactions per day]
**Key Requirements:** [LIST_MAIN_FEATURES]

**Your schema design must include:**

1. **Entity-Relationship Diagram** (describe in text format):
   - All entities with their attributes and types
   - Primary keys, foreign keys, and unique constraints
   - Relationship types (1:1, 1:N, M:N) with cardinality
   - Junction tables for M:N relationships

2. **Table Definitions** (SQL CREATE statements):
   - Proper data types (VARCHAR lengths, DECIMAL precision, ENUM values)
   - NOT NULL constraints where appropriate
   - DEFAULT values (timestamps, UUIDs, boolean flags)
   - CHECK constraints for data validation
   - Proper indexing strategy (B-tree, GIN, GiST where appropriate)
   - Composite indexes for common query patterns
   - Partial indexes for filtered queries

3. **Normalization Analysis**:
   - Confirm the schema is at least in 3NF
   - Document any intentional denormalization with justification
   - Identify potential data anomalies and how they are prevented

4. **Performance Considerations**:
   - Index recommendations based on expected query patterns
   - Partitioning strategy if tables will exceed 10M rows
   - Materialized views for complex reporting queries
   - Connection pooling and caching recommendations

5. **Migration Script**: A versioned migration script (using a tool like Alembic, Flyway, or Prisma) that creates the schema from scratch.

6. **Seed Data**: Sample INSERT statements with realistic test data for development.

7. **Common Queries**: Write the 5 most common queries the application will need, with EXPLAIN analysis notes.

You are a senior engineer who writes clear, persuasive technical RFCs (Request for Comments). Create an RFC document for the described technical proposal.

**RFC Details:**
- Title: [PROPOSAL_TITLE]
- Author: [YOUR_NAME]
- Status: Draft
- Problem: [WHAT PROBLEM ARE WE SOLVING]
- Proposed Solution: [HIGH-LEVEL SOLUTION]
- Impact: [WHAT SYSTEMS/TEAMS ARE AFFECTED]

**RFC Document Structure:**

1. **Summary** (1 paragraph):
   - What is being proposed and why
   - Expected outcome

2. **Motivation:**
   - Current state and its problems
   - Business impact of the problem (cost, velocity, reliability)
   - Why we need to solve this now (urgency justification)
   - What happens if we do nothing

3. **Detailed Design:**
   - Architecture overview with component descriptions
   - Data flow and sequence descriptions
   - API changes or new APIs
   - Database schema changes
   - Configuration changes
   - Migration strategy

4. **Alternatives Considered:**
   - For each alternative:
     - Description of the approach
     - Pros and cons
     - Why it was not chosen
   - Include at minimum: the proposed solution, a simpler approach, a more complex approach, and "do nothing"

5. **Implementation Plan:**
   - Phases with milestones
   - Estimated effort (person-weeks)
   - Dependencies on other teams
   - Feature flag strategy
   - Rollout plan (percentage-based, canary, blue-green)

6. **Risks and Mitigations:**
   - Technical risks
   - Operational risks
   - Business risks
   - For each risk: likelihood, impact, and mitigation strategy

7. **Observability and Testing:**
   - Metrics to track success
   - Alerting conditions
   - Test plan (unit, integration, load, chaos)
   - Rollback plan

8. **Open Questions:**
   - Decisions that need input from reviewers
   - Areas of uncertainty

**Output**: Complete RFC document in Markdown format, ready for review.

You are a senior system design interviewer at a top tech company. Walk through a complete system design for the described problem.

**Design Problem:** [e.g., Design Twitter, Design a URL shortener, Design a chat system, Design a ride-sharing service]
**Scope:** [What specific features to focus on]
**Scale:** [Expected users, requests per second, data volume]

**Walk through the design using this structure:**

1. **Requirements Clarification (5 minutes):**
   - Functional requirements (what the system does)
   - Non-functional requirements (latency, availability, consistency, durability)
   - Constraints and assumptions
   - Back-of-envelope calculations:
     - Storage requirements (per day, per year)
     - Bandwidth requirements
     - Read vs. write ratio
     - QPS (queries per second) for each operation

2. **High-Level Design (10 minutes):**
   - System architecture diagram description (components and data flow)
   - API design (REST endpoints with request/response schemas)
   - Data model (key entities, relationships, storage choice justification)
   - Choose appropriate technologies for each component with reasoning

3. **Deep Dive (15 minutes):**
   - Database design: Schema, sharding strategy, replication, indexing
   - Caching strategy: What to cache, cache invalidation, cache-aside vs. write-through
   - Message queues: When and why to use async processing
   - CDN strategy for static content
   - Search functionality (if applicable)
   - Notification system (if applicable)

4. **Scalability (5 minutes):**
   - Horizontal scaling strategy
   - Database scaling (read replicas, sharding, partitioning)
   - Load balancing (algorithm choice, health checks)
   - Rate limiting and throttling
   - Auto-scaling policies

5. **Reliability and Fault Tolerance (5 minutes):**
   - Single points of failure and how to eliminate them
   - Replication and redundancy
   - Graceful degradation strategy
   - Circuit breaker patterns
   - Data consistency model (strong vs. eventual)

6. **Monitoring and Operations:**
   - Key metrics to monitor
   - Alerting strategy
   - Deployment strategy (blue-green, canary)

**Output**: Complete system design walkthrough with diagrams, calculations, and trade-off discussions.

You are a data engineering expert who designs scalable, reliable data pipelines. Design a complete data pipeline architecture for the described use case.

**Use Case:** [DESCRIBE WHAT DATA NEEDS TO FLOW WHERE]
**Data Sources:** [LIST: databases, APIs, files, streams, etc.]
**Data Volume:** [Records per day, GB per day]
**Latency Requirements:** [Real-time / Near-real-time / Batch / Mixed]
**Data Consumers:** [Analytics dashboards, ML models, reporting, other services]
**Budget Constraints:** [If any]
**Current Stack:** [Existing tools and infrastructure]

**Design the following:**

1. **Architecture Overview:**
   - Source systems and their data formats
   - Ingestion layer (how data enters the pipeline)
   - Processing layer (transformation, enrichment, validation)
   - Storage layer (data lake, data warehouse, feature store)
   - Serving layer (how consumers access processed data)
   - Orchestration layer (scheduling and dependency management)

2. **Technology Selection:**
   - For each layer, recommend specific tools with justification
   - Consider: Apache Kafka, Apache Spark, dbt, Airflow, Dagster, Snowflake, BigQuery, Redshift, Delta Lake, Apache Flink
   - Explain trade-offs between choices

3. **Data Modeling:**
   - Raw layer schema (landing zone, minimal transformation)
   - Staging layer (cleaned, standardized, deduped)
   - Curated layer (business logic applied, star/snowflake schema)
   - Data catalog and metadata management approach

4. **Data Quality:**
   - Validation rules at each stage
   - Data quality metrics to track
   - Alerting on quality degradation
   - Dead letter queue for failed records
   - Data lineage tracking

5. **Reliability and Monitoring:**
   - Exactly-once vs. at-least-once processing guarantee
   - Idempotency strategy
   - Retry and backfill procedures
   - Pipeline health metrics and dashboards
   - SLA definitions for data freshness

6. **Security and Governance:**
   - PII handling and masking
   - Access control per data layer
   - Encryption in transit and at rest
   - Data retention policies
   - Audit logging

**Output**: Complete architecture document with diagrams, technology choices, and implementation roadmap.

(masterpiece, 8k) [modern/classical/futuristic] architecture, [residential/commercial/public] building, exterior view, [time of day], [weather conditions], photorealistic rendering, detailed materials, landscaping, people for scale, professional architectural photography style

[modern/classical/futuristic] [residential/commercial/public] interior design, [specific room], [design style: minimalist/bohemian/industrial/scandinavian], natural lighting through [windows/skylights], [materials: wood/concrete/glass], [color palette], photorealistic architectural visualization, magazine quality, professional rendering, --ar 16:9 --v 6 --q 2