# Prompt Engineering Power Pack

> 55 expertly crafted prompt templates for code generation, data analysis, content creation, debugging, and more. Each prompt is tested, documented, and ready to drop into your workflow.

**By SURVIVE** | v1.0 | Last Updated: March 2026

---

## Table of Contents

1. [How to Use These Prompts](#how-to-use-these-prompts)
2. [Code Generation](#code-generation) (12 prompts)
3. [Data Analysis](#data-analysis) (11 prompts)
4. [Content Creation](#content-creation) (11 prompts)
5. [Debugging & Troubleshooting](#debugging--troubleshooting) (11 prompts)
6. [Miscellaneous & Advanced](#miscellaneous--advanced) (10 prompts)

---

## How to Use These Prompts

### Template Syntax

- `{variable}` — Replace with your specific value
- `[optional section]` — Include if relevant, remove if not
- `<!-- note -->` — Usage guidance (remove before using)

### Tips for Best Results

1. **Fill in all variables** before sending to the model
2. **Be specific** — "Python 3.12 FastAPI endpoint" beats "some code"
3. **Include context** — paste relevant code, data samples, or error messages
4. **Iterate** — use the output to refine your next prompt
5. **Chain prompts** — use one prompt's output as input for the next

---

## Code Generation

### CG-01: Function from Description

```
Write a {language} function that {description}.

Requirements:
- Input: {input_description}
- Output: {output_description}
- Handle these edge cases: {edge_cases}
[- Follow {style_guide} conventions]
[- Use only standard library (no external dependencies)]

Include:
1. The function with type annotations
2. A docstring explaining parameters and return value
3. 3 usage examples with expected output
```

**Usage Notes:** Works best when you specify the exact input/output types. For complex functions, break into sub-tasks.

**Example Output:** A complete, documented function with type hints and examples that you can paste directly into your codebase.

---

### CG-02: REST API Endpoint

```
Create a {framework} API endpoint with the following specification:

Endpoint: {method} {path}
Purpose: {what_it_does}

Request:
- Headers: {required_headers}
- Body: {request_body_schema}
[- Query params: {query_params}]

Response:
- Success (200): {success_response_schema}
- Error cases: {error_cases}

Requirements:
- Input validation for all fields
- Proper error responses with status codes
- {authentication_method} authentication
[- Rate limiting: {rate_limit}]
[- Pagination: {pagination_style}]

Include error handling for: database errors, validation failures, and authentication failures.
```

**Usage Notes:** Specify the framework explicitly (Express, FastAPI, Spring Boot, etc.) for idiomatic code. Include the DB schema if the endpoint interacts with a database.

**Example Output:** A production-ready endpoint file with request validation, error handling, auth middleware, and response formatting.

---

### CG-03: Database Schema & Queries

```
Design a database schema for {application_description}.

Entities:
{list_of_entities_with_key_fields}

Requirements:
- Database: {database_type}
- Include: table definitions, indexes, constraints, and foreign keys
- Optimize for: {primary_query_patterns}

Then write queries for these operations:
1. {operation_1}
2. {operation_2}
3. {operation_3}

For each query, explain the execution plan and suggest indexes if needed.
```

**Usage Notes:** Always specify the database type (PostgreSQL, MySQL, MongoDB, etc.) as syntax and best practices vary significantly. Include expected data volume for index recommendations.

**Example Output:** Complete DDL statements, optimized queries with explanations, and index recommendations based on your access patterns.

---

### CG-04: Unit Test Suite

```
Write a comprehensive test suite for the following {language} code:

```{language}
{paste_your_code}
```

Testing framework: {test_framework}

Cover these test categories:
1. Happy path — normal expected inputs
2. Edge cases — boundary values, empty inputs, max values
3. Error cases — invalid inputs, null values, type mismatches
4. [Integration — interaction with {external_dependency}]

For each test:
- Use descriptive test names that explain the scenario
- Include arrange/act/assert comments
- Mock external dependencies

Target: {coverage_target}% code coverage
```

**Usage Notes:** Paste the actual code you want tested. The model generates better tests when it can see the implementation. Specify your test framework for correct syntax (pytest, Jest, JUnit, etc.)

**Example Output:** A complete test file with organized test classes/functions, fixtures, mocks, and assertions covering the specified categories.

---

### CG-05: CLI Tool

```
Build a command-line tool in {language} that {purpose}.

Commands:
1. `{tool_name} {command_1}` — {description_1}
2. `{tool_name} {command_2}` — {description_2}
[3. `{tool_name} {command_3}` — {description_3}]

Global flags:
- `--verbose` / `-v` — Enable detailed output
- `--output {format}` — Output format (json, table, csv)
[- {additional_flags}]

Requirements:
- Argument parsing with help text
- Colored terminal output
- Error messages to stderr
- Exit codes: 0 for success, 1 for user error, 2 for system error
- [Config file support: {config_format}]

Include a README with installation and usage examples.
```

**Usage Notes:** For Python, specify if you want argparse, click, or typer. For Node, specify commander or yargs. Include sample data for testing.

**Example Output:** A complete CLI tool with argument parsing, help text, error handling, and a README.

---

### CG-06: Data Model / Type Definitions

```
Create {language} type definitions for the following domain:

Domain: {domain_description}

Entities:
- {entity_1}: {fields_and_descriptions}
- {entity_2}: {fields_and_descriptions}
- {entity_3}: {fields_and_descriptions}

Requirements:
- Strict typing (no `any` or `object`)
- Validation rules: {validation_rules}
- Include: types, interfaces, enums, and utility types
- [Serialization support: {format} (JSON, Protobuf, etc.)]
- [Generate from/to conversion methods]

Relationships:
- {entity_1} has many {entity_2}
- {entity_2} belongs to {entity_3}
[- {additional_relationships}]
```

**Usage Notes:** For TypeScript, the model generates interfaces, types, and Zod schemas. For Python, expect dataclasses or Pydantic models. Specify validation library if you have a preference.

**Example Output:** Type-safe model definitions with validation, serialization helpers, and utility types for transformations.

---

### CG-07: Authentication / Authorization

```
Implement {auth_method} authentication for a {framework} application.

Requirements:
- User registration with {registration_fields}
- Login returning {token_type}
- Token expiry: {expiry_duration}
- Password hashing with {algorithm}
- [Role-based access: {roles}]
- [Refresh token support]
- [Multi-factor authentication]

Security requirements:
- Rate limit login attempts: {limit}
- Token stored in: {storage_method}
- CORS configuration: {cors_policy}

Include:
1. Auth middleware/decorator
2. Registration endpoint
3. Login endpoint
4. [Token refresh endpoint]
5. Protected route example
```

**Usage Notes:** Always specify the auth method (JWT, session-based, OAuth2) and framework. Security requirements are critical — don't skip them.

**Example Output:** Complete auth implementation with middleware, endpoints, password hashing, token management, and security hardening.

---

### CG-08: React Component

```
Create a React component for {component_description}.

Props:
- {prop_1}: {type} — {description}
- {prop_2}: {type} — {description}
[- {prop_3}: {type} — {description}]

Behavior:
- {behavior_1}
- {behavior_2}
[- {behavior_3}]

Styling: {styling_approach}
<!-- Tailwind CSS, CSS Modules, styled-components, etc. -->

Requirements:
- TypeScript with strict types
- Accessible (ARIA labels, keyboard navigation)
- Responsive (mobile-first)
- [Loading state]
- [Error state]
- [Animation: {animation_description}]

Include:
1. The component file
2. Type definitions
3. Usage example in a parent component
```

**Usage Notes:** Specify whether you want a client or server component (Next.js), and whether to use hooks, context, or external state management. Include design references if possible.

**Example Output:** A production-ready React component with TypeScript types, accessibility, responsive design, and state handling.

---

### CG-09: Cron Job / Scheduled Task

```
Create a scheduled task that {purpose}.

Schedule: {cron_expression_or_description}
<!-- e.g., "Every 6 hours", "Daily at 3am UTC", "Every Monday at 9am" -->

Runtime: {language_and_runtime}

Steps:
1. {step_1}
2. {step_2}
3. {step_3}

Requirements:
- Idempotent (safe to run multiple times)
- Logging with timestamps
- Error notification: {notification_method}
- Lock mechanism to prevent concurrent runs
- Timeout: {max_duration}
- [Dry-run mode with --dry-run flag]

Include health check and monitoring hooks.
```

**Usage Notes:** Always make scheduled tasks idempotent — they will inevitably run twice due to retries, clock drift, or manual triggers. The lock mechanism prevents data corruption.

**Example Output:** A complete scheduled task script with locking, logging, error handling, monitoring, and dry-run support.

---

### CG-10: Middleware / Interceptor

```
Create a {framework} middleware that {purpose}.

Trigger: {when_it_runs}
<!-- e.g., "On every request", "On routes matching /api/*", "Before database queries" -->

Behavior:
- Before: {pre_processing}
- After: {post_processing}
[- Error: {error_handling}]

Configuration:
- {config_option_1}: {default_value}
- {config_option_2}: {default_value}

Requirements:
- Configurable (not hardcoded values)
- Doesn't modify the request/response unless intended
- Performance: adds < {max_latency}ms latency
- [Bypass option for specific routes: {bypass_condition}]

Include logging and metrics collection.
```

**Usage Notes:** Middleware order matters — specify where in the middleware chain this should run. Include performance benchmarks in your requirements.

**Example Output:** A configurable middleware with pre/post processing hooks, error handling, bypass logic, and performance-conscious implementation.

---

### CG-11: WebSocket Handler

```
Implement a WebSocket handler for {purpose}.

Events:
- Client → Server:
  - `{event_1}`: {payload_1} — {description_1}
  - `{event_2}`: {payload_2} — {description_2}
- Server → Client:
  - `{event_3}`: {payload_3} — {description_3}
  - `{event_4}`: {payload_4} — {description_4}

Requirements:
- Runtime: {framework_or_library}
- Authentication: {auth_method} on connection
- Heartbeat/ping interval: {interval}
- Reconnection logic (client-side)
- Message validation
- [Room/channel support: {room_logic}]
- [Rate limiting: {limit} messages per {period}]

Handle: connection, disconnection, errors, and timeouts.
```

**Usage Notes:** Always include heartbeat/ping logic to detect stale connections. Specify whether you need binary or text messages. Include your scaling requirements (single server vs. clustered).

**Example Output:** Server and client WebSocket code with event handling, authentication, reconnection, heartbeat, and error recovery.

---

### CG-12: Infrastructure as Code

```
Write {iac_tool} configuration for the following infrastructure:

Resources:
- {resource_1}: {specifications}
- {resource_2}: {specifications}
[- {resource_3}: {specifications}]

Cloud provider: {provider}
Region: {region}
Environment: {env}

Requirements:
- Use variables for all configurable values
- Include outputs for important resource identifiers
- Tag all resources with: environment, project, owner
- [VPC/networking: {network_config}]
- [Auto-scaling: {scaling_rules}]
- [Cost optimization: {budget_constraints}]

Security:
- Principle of least privilege for IAM
- Encryption at rest and in transit
- [Security groups: {access_rules}]
```

**Usage Notes:** Specify the IaC tool (Terraform, Pulumi, CloudFormation, CDK) and provider (AWS, GCP, Azure). Include the environment (dev/staging/prod) for appropriate sizing.

**Example Output:** Complete IaC configuration files with variables, outputs, security groups, and resource definitions ready to deploy.

---

## Data Analysis

### DA-01: Dataset Exploration

```
Analyze the following dataset and provide a comprehensive exploration:

Dataset description: {description}
Format: {format}
<!-- Paste a sample or describe the columns -->

Sample data:
```
{paste_sample_rows}
```

Provide:
1. **Structure**: Column names, types, and descriptions
2. **Quality**: Missing values, duplicates, outliers, inconsistencies
3. **Statistics**: Mean, median, std dev, min/max for numeric columns
4. **Distributions**: Describe the distribution of each key column
5. **Correlations**: Notable relationships between columns
6. **Recommendations**: What to clean, transform, or investigate further

Output format: {format}
<!-- Markdown report, Python code with pandas, SQL queries, etc. -->
```

**Usage Notes:** Always include sample data (at least 5-10 rows). If your dataset is large, describe the shape (rows × columns) and key columns. Specify whether you want analysis code or a written report.

**Example Output:** A structured report with summary statistics, data quality issues flagged, distribution descriptions, and actionable recommendations for next steps.

---

### DA-02: SQL Query Builder

```
Write a SQL query to answer this question:

Question: {business_question}

Tables available:
- {table_1}({columns_with_types})
- {table_2}({columns_with_types})
[- {table_3}({columns_with_types})]

Relationships:
- {table_1}.{fk} → {table_2}.{pk}
[- {additional_relationships}]

Requirements:
- Database: {database_type}
- Optimize for: {read_performance | write_performance | both}
- [Date range: {date_filter}]
- [Grouping: {group_by_fields}]
- [Sorting: {order_by_fields}]

Also provide:
1. Query explanation (what each part does)
2. Expected output format
3. Index recommendations for this query
```

**Usage Notes:** Include table schemas with data types for accurate queries. Specify your database engine (PostgreSQL, MySQL, SQLite, etc.) as syntax varies. For complex queries, break the question into sub-questions.

**Example Output:** An optimized SQL query with explanatory comments, expected output format description, and index suggestions for performance.

---

### DA-03: Data Visualization Recommendation

```
Recommend visualizations for the following data:

Data description: {what_the_data_represents}
Columns: {column_names_and_types}
Audience: {who_will_see_this}
Goal: {what_insight_to_communicate}

Sample data:
```
{paste_sample}
```

For each recommendation, provide:
1. Chart type and why it's appropriate
2. X-axis, Y-axis, color/size encodings
3. {visualization_library} code to create it
4. Title and label suggestions
5. What insight the viewer should take away
```

**Usage Notes:** Specify your visualization library (matplotlib, seaborn, plotly, D3, Chart.js, etc.). Including the audience helps tailor complexity — executives want simple, analysts want detail.

**Example Output:** 3-5 visualization recommendations with complete code, each targeted at communicating a specific insight from your data.

---

### DA-04: Statistical Test Selection

```
Help me choose and run the right statistical test.

Research question: {your_question}
Variables:
- Independent: {variable_name} ({type}: continuous/categorical/ordinal)
- Dependent: {variable_name} ({type}: continuous/categorical/ordinal)
[- Control: {variable_name}]

Data characteristics:
- Sample size: {n}
- Distribution: {normal | unknown | skewed}
- [Groups: {number_of_groups}]
- [Paired/independent: {paired | independent}]

Provide:
1. Recommended test and why
2. Assumptions to check (with code)
3. Code to run the test in {language}
4. How to interpret the results
5. What p-value / effect size to report
```

**Usage Notes:** If you're unsure about distributions, say "unknown" and the model will recommend non-parametric alternatives. Always check assumptions before interpreting results.

**Example Output:** Test recommendation with justification, assumption-checking code, test execution code, and a plain-English interpretation template.

---

### DA-05: ETL Pipeline

```
Design an ETL pipeline for the following data flow:

Source: {source_description}
<!-- e.g., "CSV files in S3 bucket", "REST API returning JSON", "PostgreSQL database" -->

Destination: {destination_description}

Transformations needed:
1. {transformation_1}
2. {transformation_2}
3. {transformation_3}

Requirements:
- Language/framework: {tool}
- Schedule: {frequency}
- Data volume: {rows_per_run}
- Idempotent (safe to re-run)
- Error handling: {strategy}
- [Incremental vs full load: {approach}]
- [Data validation rules: {rules}]

Include:
1. Pipeline code
2. Configuration/settings file
3. Logging and monitoring
4. Failure recovery mechanism
```

**Usage Notes:** Specify the volume to get appropriate batch sizing recommendations. For real-time needs, mention latency requirements. Include sample source data for accurate transformation code.

**Example Output:** A complete ETL pipeline with extraction, transformation, loading stages, error handling, logging, and a configuration file.

---

### DA-06: Regex Pattern Builder

```
Create a regex pattern that matches: {description_of_what_to_match}

Examples of strings that SHOULD match:
1. {match_example_1}
2. {match_example_2}
3. {match_example_3}

Examples of strings that should NOT match:
1. {no_match_example_1}
2. {no_match_example_2}

Requirements:
- Regex flavor: {flavor}
<!-- PCRE, Python re, JavaScript, etc. -->
- [Named capture groups for: {fields_to_capture}]
- [Case sensitivity: {case_sensitive | case_insensitive}]
- Performance consideration: {input_size}

Provide:
1. The regex pattern
2. Explanation of each part
3. Test code in {language} verifying all examples
4. Edge cases to watch for
```

**Usage Notes:** Always provide both matching and non-matching examples — this prevents overly broad patterns. Specify the regex flavor because syntax differs between engines.

**Example Output:** A precise regex pattern with inline comments explaining each part, test code, and warnings about potential edge cases.

---

### DA-07: Data Cleaning Script

```
Write a data cleaning script for the following dataset:

Dataset: {description}
Format: {CSV | JSON | database_table}
Known issues:
1. {issue_1}
2. {issue_2}
3. {issue_3}
[4. {issue_4}]

Column specifications:
- {column_1}: {expected_type}, {valid_range_or_values}
- {column_2}: {expected_type}, {valid_range_or_values}
- {column_3}: {expected_type}, {valid_range_or_values}

Cleaning rules:
- Missing values: {strategy}
  <!-- drop, fill with mean/median/mode, forward fill, flag -->
- Duplicates: {strategy}
  <!-- drop all, keep first, keep last, merge -->
- Outliers: {strategy}
  <!-- remove, cap, flag, keep -->
- [Date parsing: {expected_formats}]
- [Text normalization: {rules}]

Language: {language}
Output: cleaned {format} + quality report
```

**Usage Notes:** Provide a sample of the dirty data if possible. The more specific your cleaning rules, the better the output. Always generate a quality report comparing before/after metrics.

**Example Output:** A cleaning script that reads the data, applies each rule, logs changes made, and outputs both the cleaned data and a quality summary report.

---

### DA-08: Pivot Table / Aggregation

```
Create an aggregation query/script for the following analysis:

Data: {data_description}
Group by: {grouping_columns}
Aggregate: {measures_and_aggregation_functions}
<!-- e.g., "SUM(revenue)", "AVG(response_time)", "COUNT(DISTINCT users)" -->

Filter: {filter_conditions}
Time period: {date_range}

Additional requirements:
- [Subtotals: {yes/no}]
- [Percentage of total: {yes/no}]
- [Year-over-year comparison: {yes/no}]
- [Top N: show only top {n} by {metric}]

Output in: {format}
<!-- SQL, pandas, Excel formula, pivot table code -->
```

**Usage Notes:** Specify whether you want SQL, pandas, or spreadsheet formulas. For large datasets, mention if you need the query optimized for performance.

**Example Output:** An aggregation query/script with grouping, filtering, calculated columns, and formatted output ready for reporting.

---

### DA-09: A/B Test Analysis

```
Analyze this A/B test:

Test description: {what_was_tested}
Primary metric: {metric_name} ({metric_type}: conversion rate, average, count)

Results:
- Control (A): {sample_size_a} samples, {metric_a}
- Variant (B): {sample_size_b} samples, {metric_b}

[Secondary metrics:
- {secondary_metric_1}: A = {value}, B = {value}
- {secondary_metric_2}: A = {value}, B = {value}]

Provide:
1. Statistical significance (p-value)
2. Confidence interval for the difference
3. Effect size
4. Recommendation: ship, iterate, or discard
5. Sample size validation (was the test adequately powered?)
6. {language} code for the calculations

Significance threshold: {alpha}
<!-- Default: 0.05 -->
```

**Usage Notes:** Include both sample sizes and the actual metric values. If you have raw data, even better — paste a sample. Always check for adequate sample size before trusting the result.

**Example Output:** A complete A/B test analysis with statistical calculations, confidence intervals, a clear recommendation, and code to reproduce the analysis.

---

### DA-10: Dashboard Specification

```
Design a dashboard for {audience} to monitor {domain}.

Key questions the dashboard should answer:
1. {question_1}
2. {question_2}
3. {question_3}
[4. {question_4}]

Available data sources:
- {source_1}: {description_and_key_fields}
- {source_2}: {description_and_key_fields}

Requirements:
- Tool: {dashboard_tool}
  <!-- Grafana, Metabase, Tableau, custom React, etc. -->
- Refresh rate: {frequency}
- [Filters: {filter_options}]
- [Alerts: {alert_conditions}]

Provide:
1. Dashboard layout (wireframe in ASCII)
2. Widget specifications (type, data source, query)
3. SQL queries or data transformations for each widget
4. Color and formatting guidelines
5. Alert threshold definitions
```

**Usage Notes:** Focus on 5-8 key metrics maximum. Dashboards with too many widgets are ignored. Specify your dashboard tool for correct syntax and widget types.

**Example Output:** An ASCII wireframe layout, complete widget specifications with queries, and alert configurations ready to implement.

---

### DA-11: Time Series Forecasting

```
Help me forecast {metric_description} using time series analysis.

Data:
- Frequency: {daily | weekly | monthly | hourly}
- History available: {time_period}
- Forecast horizon: {how_far_ahead}

Characteristics:
- Trend: {upward | downward | flat | unknown}
- Seasonality: {description_or_unknown}
- [External factors: {factors_that_affect_the_metric}]

Sample data:
```
{paste_recent_data_points}
```

Provide:
1. Recommended model(s) and why
2. Data preprocessing steps
3. {language} code for the forecast
4. Accuracy metrics to evaluate
5. Visualization of forecast with confidence intervals
6. Assumptions and limitations
```

**Usage Notes:** Provide at least 2 full seasonal cycles of data (e.g., 2 years of monthly data). Mention any known anomalies (COVID, one-time events) so they can be handled.

**Example Output:** A forecasting pipeline with model selection rationale, preprocessing, training code, evaluation metrics, and a confidence-interval plot.

---

## Content Creation

### CC-01: Blog Post

```
Write a blog post about {topic}.

Target audience: {audience_description}
Tone: {formal | casual | technical | conversational}
Length: {word_count} words
Purpose: {educate | persuade | entertain | inform}

Key points to cover:
1. {point_1}
2. {point_2}
3. {point_3}

SEO requirements:
- Primary keyword: {keyword}
- [Secondary keywords: {keywords}]
- [Target search intent: {informational | transactional | navigational}]

Structure:
- Compelling hook in the first paragraph
- Headers for scannability (H2, H3)
- [Include a listicle section]
- Actionable conclusion with CTA: {call_to_action}

[Include: code examples | data points | quotes | analogies]
```

**Usage Notes:** The more specific your audience description, the better the tone matching. Include competitor articles as reference if you want to differentiate or improve on existing content.

**Example Output:** A complete blog post with SEO-optimized title, meta description, header hierarchy, embedded examples, and a strong closing CTA.

---

### CC-02: Technical Documentation

```
Write technical documentation for {subject}.

Documentation type: {reference | tutorial | how-to | explanation}
Audience skill level: {beginner | intermediate | advanced}

Cover:
1. Overview — what it is and why it matters
2. Prerequisites — what the reader needs before starting
3. {main_content_sections}
4. Examples — real-world usage
5. Troubleshooting — common issues and solutions
6. [API reference — endpoints, parameters, responses]

Requirements:
- Use {language/framework} for code examples
- All code examples must be runnable
- Include copy-paste-ready commands
- [Version: {version_number}]
- [Link to: {related_resources}]

Style:
- Use active voice ("Run the command" not "The command should be run")
- One concept per section
- Short paragraphs (3-5 sentences)
```

**Usage Notes:** Follow the Diátaxis framework: tutorials (learning), how-to guides (problem-solving), reference (information), explanation (understanding). Pick one type per document.

**Example Output:** A structured documentation page with clear sections, runnable code examples, prerequisites, and a troubleshooting FAQ.

---

### CC-03: Email Sequence

```
Write a {sequence_length}-email sequence for {purpose}.

Context: {background_situation}
Sender: {who_is_sending}
Recipient: {who_receives}
Goal: {desired_outcome}

Sequence:
1. Email 1 — {purpose_of_email_1} (send: {timing})
2. Email 2 — {purpose_of_email_2} (send: {timing})
[3. Email 3 — {purpose_of_email_3} (send: {timing})]
[4. Email 4 — {purpose_of_email_4} (send: {timing})]

Requirements:
- Subject lines optimized for open rates
- Each email: < {max_words} words
- Clear CTA in each email
- Tone: {tone}
- [Personalization tokens: {name}, {company}, {pain_point}]

Include A/B subject line variants for each email.
```

**Usage Notes:** For cold outreach, keep emails under 150 words. For nurture sequences, you can go longer. Always include one clear CTA per email — multiple CTAs reduce click rates.

**Example Output:** Complete email sequence with subject lines (A/B variants), body copy, CTAs, and timing recommendations for each email.

---

### CC-04: Product Description

```
Write a product description for {product_name}.

Product type: {category}
Target customer: {ideal_customer}
Price point: {price}

Key features:
1. {feature_1} — Benefit: {benefit_1}
2. {feature_2} — Benefit: {benefit_2}
3. {feature_3} — Benefit: {benefit_3}

Differentiator: {what_makes_this_unique}
Customer pain point: {problem_it_solves}

Format:
- Headline (< 10 words)
- Subheadline (1 sentence)
- Body (3-4 short paragraphs)
- Bullet points for features
- CTA: {call_to_action}

Tone: {tone}
Platform: {where_this_will_be_displayed}
<!-- Website, Amazon, Shopify, email, etc. -->
```

**Usage Notes:** Lead with benefits, not features. The headline should create desire or curiosity. Adapt length for the platform — Amazon listings need more keywords, website copy needs more storytelling.

**Example Output:** A complete product description with headline, body copy, feature bullets, and CTA optimized for your platform and audience.

---

### CC-05: Social Media Content Calendar

```
Create a {duration} social media content calendar for {brand/topic}.

Platforms: {platforms}
Posting frequency: {posts_per_week_per_platform}

Content pillars:
1. {pillar_1} — {description}
2. {pillar_2} — {description}
3. {pillar_3} — {description}
[4. {pillar_4} — {description}]

For each post, include:
- Platform
- Date/time slot
- Content type (text, image, video, carousel, poll)
- Caption/copy
- Hashtags (if applicable)
- CTA

Tone: {tone}
[Key dates to include: {events_holidays_launches}]
[Engagement strategy: {how_to_drive_interaction}]
```

**Usage Notes:** Mix content types for each pillar (80% value, 20% promotion). Include engagement hooks like questions, polls, and contrarian takes. Tailor copy length to each platform's norms.

**Example Output:** A week-by-week calendar grid with platform-specific posts, captions, hashtags, and content type recommendations.

---

### CC-06: Landing Page Copy

```
Write copy for a landing page that {goal}.

Product/service: {description}
Target visitor: {audience}
Traffic source: {where_visitors_come_from}
<!-- e.g., Google ads, social media, email, direct -->

Sections (in order):
1. Hero — Headline, subheadline, CTA
2. Problem — Pain points the visitor relates to
3. Solution — How your product solves it
4. Features — 3-4 key features with benefits
5. Social proof — Testimonial/review structure
6. FAQ — 3-5 common questions
7. Final CTA — Close with urgency

Requirements:
- Headline: clear value proposition in < 10 words
- Above-the-fold must communicate what + who + why
- [A/B variants for headline and CTA]
- [Urgency element: {scarcity_or_deadline}]
```

**Usage Notes:** Match the copy to the traffic source — visitors from ads expect the landing page to deliver on the ad's promise. Short-form for B2C, longer-form for B2B or high-price items.

**Example Output:** Section-by-section landing page copy with headlines, body text, CTA buttons, and FAQ content ready for design.

---

### CC-07: Video Script

```
Write a script for a {duration}-minute video about {topic}.

Video type: {explainer | tutorial | demo | testimonial | ad}
Platform: {YouTube | TikTok | Instagram | LinkedIn | course}
Audience: {audience}

Structure:
- Hook (first 5 seconds): {hook_approach}
- Introduction: {what_to_cover}
- Main content: {key_sections}
- CTA: {desired_action}

Requirements:
- Include [VISUAL] and [AUDIO] cues
- Conversational tone (written for speaking, not reading)
- {speaking_pace} words per minute
  <!-- Normal pace: ~150 wpm -->
- [B-roll suggestions]
- [On-screen text callouts]

Tone: {tone}
```

**Usage Notes:** Scripts for speaking should use shorter sentences and simpler words than written content. Include timing markers so the speaker knows the pace. Always write the hook first — it determines whether people keep watching.

**Example Output:** A timestamped script with speaker directions, visual cues, b-roll suggestions, and on-screen text callouts.

---

### CC-08: Case Study

```
Write a case study about {customer/project}.

Framework: Situation → Challenge → Solution → Results

Situation:
- Customer: {customer_description}
- Industry: {industry}
- Size: {company_size}

Challenge:
- {main_problem}
- {secondary_problems}
- Impact: {quantified_impact_of_the_problem}

Solution:
- What was implemented: {solution_description}
- Timeline: {implementation_timeline}
- Key decisions: {important_choices_made}

Results:
- {metric_1}: {before} → {after}
- {metric_2}: {before} → {after}
[- {metric_3}: {before} → {after}]
- Quote from customer: {testimonial}

Length: {word_count} words
Include: executive summary, pull quotes, and visual data suggestions
```

**Usage Notes:** Results should be quantified wherever possible (percentages, dollar amounts, time saved). Include a customer quote for credibility. The executive summary should be usable as a standalone piece.

**Example Output:** A narrative case study with executive summary, detailed sections following the S-C-S-R framework, pull quotes, and data visualization suggestions.

---

### CC-09: Release Notes / Changelog

```
Write release notes for {product_name} {version}.

Release type: {major | minor | patch | hotfix}
Release date: {date}

Changes:
New features:
- {feature_1}: {description}
- {feature_2}: {description}

Improvements:
- {improvement_1}: {description}
- {improvement_2}: {description}

Bug fixes:
- {fix_1}: {description}
- {fix_2}: {description}

[Breaking changes:
- {breaking_change}: {migration_instructions}]

Requirements:
- Audience: {developers | end_users | both}
- Include: impact level (high/medium/low) for each change
- Link to: {documentation | migration guide}
- Tone: {professional_and_clear}

Format: {markdown | HTML | plain_text}
```

**Usage Notes:** Write for your audience — developers want technical details and migration steps, end users want benefit descriptions. Always highlight breaking changes prominently. Keep each entry to 1-2 sentences.

**Example Output:** Formatted release notes with categorized changes, impact indicators, migration instructions for breaking changes, and links to documentation.

---

### CC-10: Comparison / Versus Article

```
Write a comparison article: {option_A} vs {option_B} [vs {option_C}].

Topic area: {domain}
Target reader: {audience_and_their_goal}

Compare on these dimensions:
1. {dimension_1}
2. {dimension_2}
3. {dimension_3}
4. {dimension_4}
[5. {dimension_5}]

For each dimension, provide:
- How each option performs
- Winner for that dimension and why
- When one option is better than the other

Requirements:
- Fair and balanced (not biased toward one option)
- Include a summary comparison table
- End with "Choose X if... Choose Y if..." recommendations
- Length: {word_count} words
- [Include pricing comparison]
- [Include real-world use case scenarios]
```

**Usage Notes:** Comparison content ranks well for "[X] vs [Y]" search queries. Be genuinely fair — readers lose trust if the comparison feels biased. Include a decision matrix table for scannability.

**Example Output:** A balanced comparison article with dimension-by-dimension analysis, a summary table, and situational recommendations.

---

### CC-11: Newsletter Issue

```
Write a newsletter issue about {theme_or_topic}.

Newsletter name: {name}
Audience: {subscriber_description}
Frequency: {weekly | biweekly | monthly}

Sections:
1. {section_1}: {description}
2. {section_2}: {description}
3. {section_3}: {description}
[4. {section_4}: {description}]

Content to include:
- {content_item_1}
- {content_item_2}
- {content_item_3}

Requirements:
- Subject line (with A/B variant)
- Preview text (< 90 characters)
- Each section: {max_words} words
- Tone: {tone}
- CTA: {desired_action}
- [Curated links: {number} relevant links with commentary]

Include a personal intro paragraph and sign-off.
```

**Usage Notes:** Newsletters with personality outperform generic ones. Add a brief personal anecdote or opinion in the intro. Curated links with your commentary add more value than links alone.

**Example Output:** A complete newsletter with subject line, preview text, personal intro, content sections, curated links, and sign-off.

---

## Debugging & Troubleshooting

### DT-01: Error Diagnosis

```
Help me diagnose this error:

Error message:
```
{paste_error_message_and_stack_trace}
```

Context:
- Language/framework: {language_and_version}
- What I was trying to do: {action}
- When it happens: {trigger_conditions}
- What changed recently: {recent_changes}

Code that triggers the error:
```{language}
{paste_relevant_code}
```

Provide:
1. What the error means in plain English
2. Most likely root cause (and 2 alternatives)
3. Step-by-step fix for the most likely cause
4. How to verify the fix works
5. How to prevent this error in the future
```

**Usage Notes:** Always paste the FULL error message and stack trace. Include the version of your language/framework. Mention what changed recently — most bugs are caused by recent changes.

**Example Output:** A clear explanation of the error, ranked root causes, a step-by-step fix with code, a verification command, and prevention tips.

---

### DT-02: Performance Profiling

```
Help me diagnose a performance issue:

Symptom: {what_is_slow_and_how_slow}
Expected: {what_performance_should_be}
Environment: {language, framework, infrastructure}

Relevant code:
```{language}
{paste_slow_code}
```

[Metrics:
- Response time: {current_value}
- CPU usage: {value}
- Memory usage: {value}
- Database query time: {value}]

Provide:
1. Analysis of likely bottlenecks in the code
2. Profiling strategy (what to measure and how)
3. {language} profiling code I can run
4. Top 3 optimization recommendations (ranked by impact)
5. Before/after comparison approach
```

**Usage Notes:** Include actual metrics when available. "It's slow" is less useful than "API response time is 3.2s, target is <500ms." If you can narrow it down to a specific function or query, include that code.

**Example Output:** A bottleneck analysis, profiling code to identify the exact issue, optimization recommendations with expected impact, and a benchmarking approach.

---

### DT-03: Code Review Checklist

```
Review the following code for issues:

```{language}
{paste_code}
```

Context:
- Purpose: {what_the_code_does}
- Criticality: {low | medium | high | critical}
- [PR description: {what_changed_and_why}]

Review for:
1. **Correctness** — Does it do what it's supposed to?
2. **Security** — Injection, XSS, auth bypasses, data leaks?
3. **Performance** — Obvious inefficiencies, N+1 queries, memory leaks?
4. **Readability** — Clear naming, logical structure, appropriate comments?
5. **Edge cases** — What inputs could break this?
6. **Error handling** — Are failures handled gracefully?
7. **Testing** — Is this testable? What tests are needed?

For each issue found:
- Severity: Critical / Major / Minor / Nitpick
- Line reference
- Problem description
- Suggested fix (with code)
```

**Usage Notes:** Flag the criticality level — a critical payment processing function gets a different level of scrutiny than a logging utility. Focus on correctness and security first, then style.

**Example Output:** A structured code review with categorized issues, severity levels, line references, and concrete fix suggestions.

---

### DT-04: Log Analysis

```
Analyze these logs to identify the issue:

```
{paste_logs}
```

Context:
- Service: {service_name}
- Time of incident: {timestamp}
- Expected behavior: {what_should_happen}
- Actual behavior: {what_happened}

Provide:
1. Timeline of events leading to the issue
2. Root cause identification
3. Key log entries that indicate the problem (quote them)
4. What additional logs would help (if current logs are insufficient)
5. Remediation steps
6. Monitoring alert to catch this earlier next time
```

**Usage Notes:** Include timestamps and log levels. If logs are voluminous, filter to the relevant timeframe (5 minutes before/after the incident). Include logs from multiple services if the issue spans services.

**Example Output:** A chronological incident analysis, root cause identification with supporting log evidence, remediation steps, and a monitoring alert definition.

---

### DT-05: Dependency Conflict Resolution

```
Help me resolve this dependency conflict:

Error:
```
{paste_dependency_error}
```

Package manager: {npm | pip | maven | cargo | etc.}
Project type: {description}

Current dependencies:
```
{paste_package_json_or_requirements_or_pom}
```

[Lock file excerpt (relevant section):
```
{paste_relevant_lock_file_section}
```]

Provide:
1. What's conflicting and why
2. Resolution strategy (upgrade, downgrade, alias, or replace)
3. Exact commands to fix it
4. How to verify nothing broke
5. How to prevent this in the future (pinning strategy, etc.)
```

**Usage Notes:** Include the full error output — dependency resolvers usually explain the conflict. Paste the relevant section of your dependency file. Mention if you have constraints that prevent upgrading certain packages.

**Example Output:** A clear explanation of the conflict, step-by-step resolution commands, a verification checklist, and a dependency management strategy.

---

### DT-06: Environment / Configuration Debug

```
Help me debug this environment/configuration issue:

Symptom: {what_is_not_working}
Expected: {what_should_happen}
Environment: {OS, runtime, platform}

Configuration:
```
{paste_config_file_or_env_vars}
```

What I've tried:
1. {attempt_1} — Result: {result_1}
2. {attempt_2} — Result: {result_2}

[Error output:
```
{paste_error}
```]

Provide:
1. Diagnosis: what's misconfigured and why
2. Step-by-step fix
3. Verification command to confirm it works
4. Common gotchas for this setup
5. A checklist I can use for similar issues in the future
```

**Usage Notes:** Include the EXACT configuration (with sensitive values redacted). Mention what you've already tried — this prevents the model from suggesting things you've done. Environment issues are often subtle (wrong path, missing env var, permission issue).

**Example Output:** A diagnosis pointing to the specific misconfiguration, fix commands, a verification step, and a reusable environment debugging checklist.

---

### DT-07: Memory Leak Investigation

```
Help me investigate a potential memory leak:

Symptom: {memory_growth_description}
<!-- e.g., "Memory grows from 200MB to 2GB over 24 hours" -->

Application: {language, framework, type}
Runtime: {runtime_details}

Suspected area:
```{language}
{paste_code_you_suspect}
```

[Current memory metrics:
- Heap size: {value}
- GC frequency: {value}
- Object count growth: {value}]

Provide:
1. Common memory leak patterns in {language} to check for
2. Profiling code to identify the leak
3. Analysis of the suspected code
4. Fix recommendations
5. Memory monitoring setup for production
```

**Usage Notes:** Memory leaks are notoriously hard to debug. Provide growth rate over time, not just a snapshot. Mention if the growth is linear (constant leak) or accelerating (compounding leak).

**Example Output:** A systematic investigation plan, profiling code, analysis of common leak patterns in your language, fix suggestions, and a production monitoring setup.

---

### DT-08: Build / Compilation Error Fix

```
Help me fix this build error:

Error output:
```
{paste_full_build_error}
```

Build tool: {tool_and_version}
<!-- webpack, vite, cargo, gcc, tsc, gradle, etc. -->

Project info:
- Language: {language}
- Framework: {framework}
- Recent changes: {what_changed}

[Build configuration:
```
{paste_build_config}
```]

[Package versions:
```
{paste_relevant_versions}
```]

Provide:
1. What the error means
2. Root cause
3. Fix (with exact code/config changes)
4. Verification command
5. Why this happened (for understanding)
```

**Usage Notes:** Include the FULL build output — often the actual error is buried in the middle, not at the end. Mention what changed recently. Include your build configuration file (tsconfig, webpack.config, Cargo.toml, etc.)

**Example Output:** Clear explanation of the build error, the exact changes needed to fix it, and an explanation of why it happened.

---

### DT-09: Network / API Troubleshooting

```
Help me troubleshoot this network/API issue:

Symptom: {what_is_failing}
<!-- e.g., "API returns 503 intermittently", "Connection timeouts to database" -->

Setup:
- Client: {client_description}
- Server/service: {server_description}
- Network: {cloud_provider, VPC, firewall, etc.}

Error details:
```
{paste_error_or_response}
```

[Request that fails:
```
{paste_curl_or_request_details}
```]

What I've verified:
- [ ] DNS resolution works
- [ ] Port is open and listening
- [ ] TLS certificate is valid
- [ ] Firewall rules allow traffic
- [ ] Service is running
- [ ] Request format is correct

Provide:
1. Systematic diagnostic steps (in order)
2. Commands to run at each step
3. Most likely root cause based on the symptoms
4. Fix or workaround
5. Monitoring to prevent recurrence
```

**Usage Notes:** Network issues have many layers — start from the bottom (DNS, connectivity) and work up (TLS, HTTP, application). Include the exact error and request. Check the "What I've verified" boxes before asking — this focuses the diagnosis.

**Example Output:** An ordered diagnostic procedure with commands for each step, the most likely root cause, a fix, and monitoring recommendations.

---

### DT-10: Race Condition / Concurrency Bug

```
Help me identify and fix a potential race condition:

Symptom: {intermittent_behavior_description}
<!-- e.g., "Works 90% of the time, fails under load" -->

Code:
```{language}
{paste_concurrent_code}
```

Concurrency model: {threads | async | processes | goroutines}
Shared resources: {what_is_accessed_concurrently}

Questions:
1. Is there a race condition here? Where?
2. What's the worst-case outcome?
3. How to fix it?
4. How to test for it?

Provide:
1. Analysis of the race condition
2. Execution timeline showing the problematic interleaving
3. Fix with appropriate synchronization
4. Test that would catch this
5. General principles to prevent similar issues
```

**Usage Notes:** Race conditions are intermittent by nature — describe the pattern (fails under load, fails every Nth request, etc.). Identify all shared mutable state. Drawing the execution timeline is key to understanding the bug.

**Example Output:** An execution timeline showing the race condition, a fix using appropriate synchronization primitives, a stress test to verify the fix, and concurrency best practices.

---

### DT-11: Database Query Optimization

```
Help me optimize this slow database query:

Query:
```sql
{paste_slow_query}
```

Execution time: {current_time}
Target time: {desired_time}

Table info:
- {table_name}: {row_count} rows
  - Columns: {key_columns}
  - Indexes: {existing_indexes}
[- {table_2}: {details}]

[EXPLAIN output:
```
{paste_explain_output}
```]

Database: {engine_and_version}

Provide:
1. Analysis of why it's slow
2. Optimized query
3. Index recommendations
4. EXPLAIN comparison (before vs. expected after)
5. Any schema changes that would help long-term
```

**Usage Notes:** ALWAYS include the EXPLAIN output — it shows how the database actually executes the query. Include row counts for all tables involved. Mention your database engine and version as optimization strategies differ.

**Example Output:** A query analysis, optimized version, index CREATE statements, expected EXPLAIN improvement, and long-term schema recommendations.

---

## Miscellaneous & Advanced

### MA-01: Architecture Decision Record (ADR)

```
Write an Architecture Decision Record for: {decision_title}

Context:
- {background_context}
- Current state: {current_architecture}
- Trigger: {what_prompted_this_decision}

Options considered:
1. {option_1}: {brief_description}
2. {option_2}: {brief_description}
[3. {option_3}: {brief_description}]

Evaluation criteria:
- {criterion_1} (weight: {high|medium|low})
- {criterion_2} (weight: {high|medium|low})
- {criterion_3} (weight: {high|medium|low})

Decision: {chosen_option}

Provide:
1. ADR in standard format (Title, Status, Context, Decision, Consequences)
2. Decision matrix comparing all options
3. Migration plan if switching from current state
4. Risks and mitigation strategies
```

**Usage Notes:** ADRs are living documents. Use this for any significant technical decision that future team members will ask "why was this done?" Include the rejected options and reasons — this context is invaluable.

**Example Output:** A complete ADR document with context, decision rationale, pros/cons matrix, consequences, and a migration plan.

---

### MA-02: System Design Outline

```
Design a system for {purpose}.

Requirements:
- Functional: {what_it_does}
- Scale: {users, requests/sec, data volume}
- Latency: {response_time_requirements}
- Availability: {uptime_target}
- [Budget: {constraints}]

Constraints:
- {constraint_1}
- {constraint_2}
[- {constraint_3}]

Provide:
1. High-level architecture diagram (ASCII)
2. Component breakdown with responsibilities
3. Data model (key entities and relationships)
4. API design (key endpoints)
5. Technology stack recommendations with justification
6. Scaling strategy
7. Failure modes and mitigation
8. Cost estimation
```

**Usage Notes:** Start with the requirements, not the solution. Specify the scale explicitly — a system for 100 users is fundamentally different from one for 10M users. Include constraints (budget, existing tech stack, team skills).

**Example Output:** An ASCII architecture diagram, component descriptions, data model, API design, tech stack with rationale, and a scaling plan.

---

### MA-03: Code Refactoring Plan

```
Help me refactor {code_description}.

Current code:
```{language}
{paste_current_code}
```

Problems with current code:
1. {problem_1}
2. {problem_2}
3. {problem_3}

Goals:
- {readability | performance | testability | maintainability}
- Preserve existing behavior (no functional changes)
- [Prepare for: {future_feature}]

Constraints:
- Can't change: {what_must_stay_the_same}
- [Time budget: {hours_available}]
- [Must maintain backward compatibility]

Provide:
1. Refactoring strategy (which pattern/technique to use)
2. Step-by-step plan (ordered to minimize risk)
3. Each step's code change
4. Tests to verify behavior is preserved
5. Estimated effort per step
```

**Usage Notes:** Refactoring should be done in small, testable steps. Always have tests before refactoring. Specify what must NOT change (APIs, interfaces, behavior) — this prevents scope creep.

**Example Output:** An ordered refactoring plan with before/after code for each step, tests to run at each stage, and a risk assessment.

---

### MA-04: Security Audit Prompt

```
Perform a security audit of the following code:

```{language}
{paste_code}
```

Application type: {web_app | API | mobile_backend | CLI_tool}
Security requirements: {compliance_standards}
<!-- e.g., OWASP Top 10, SOC2, HIPAA, PCI-DSS -->

Check for:
1. Injection vulnerabilities (SQL, XSS, command injection)
2. Authentication/authorization flaws
3. Data exposure risks (PII, secrets, tokens in logs)
4. Input validation gaps
5. Cryptographic weaknesses
6. Dependency vulnerabilities
7. Configuration security

For each finding:
- Severity: Critical / High / Medium / Low
- OWASP category (if applicable)
- Vulnerable code (quote it)
- Attack scenario
- Fix (with code)
```

**Usage Notes:** Include all code that handles user input, authentication, or sensitive data. Specify compliance requirements for targeted recommendations. Run this on every PR that touches auth, payment, or user data.

**Example Output:** A prioritized list of security findings with severity, attack scenarios, vulnerable code excerpts, and concrete fixes.

---

### MA-05: Migration Guide

```
Write a migration guide from {source} to {target}.

Current setup: {current_details}
Target setup: {target_details}
Scope: {what_is_being_migrated}

Constraints:
- Downtime tolerance: {zero | minutes | hours}
- Data size: {volume}
- [Dependencies on current system: {list}]
- [Must maintain backward compatibility during migration: {yes/no}]

Provide:
1. Pre-migration checklist
2. Step-by-step migration procedure
3. Data migration strategy (and scripts if applicable)
4. Rollback plan for each step
5. Verification tests for each step
6. Post-migration validation checklist
7. Timeline estimate
```

**Usage Notes:** Always have a rollback plan. For zero-downtime migrations, include the dual-write/gradual cutover strategy. Test the migration on a copy of production data before doing it for real.

**Example Output:** A detailed migration guide with pre-checks, ordered steps, rollback procedures, data migration scripts, and post-migration validation.

---

### MA-06: Prompt Chaining Workflow

```
Design a prompt chain for {complex_task}.

Task breakdown:
1. {subtask_1} → Output needed: {output_1}
2. {subtask_2} → Needs: {output_1} → Output: {output_2}
3. {subtask_3} → Needs: {output_2} → Output: {output_3}
[4. {subtask_4} → Needs: {output_1, output_3} → Final output]

For each step, provide:
1. The prompt to use
2. Expected input format
3. Expected output format
4. Validation check before passing to next step
5. Fallback if this step fails

Requirements:
- Total chain should complete in < {N} LLM calls
- Each step's output must be parseable by the next step
- [Model: {specify_per_step_if_different}]
```

**Usage Notes:** Prompt chains are powerful for complex tasks that a single prompt can't handle well. Keep each step focused on one subtask. Include validation between steps to prevent error propagation.

**Example Output:** A complete prompt chain specification with prompts, input/output schemas, validation logic, and error handling for each step.

---

### MA-07: Technical Specification (RFC)

```
Write a technical specification for {feature_or_system}.

## Overview
Problem: {problem_statement}
Proposed solution: {high_level_approach}
Author: {name}
Status: Draft

## Requirements
### Must have:
- {requirement_1}
- {requirement_2}

### Nice to have:
- {requirement_3}
- {requirement_4}

### Out of scope:
- {exclusion_1}

## Design Details
{describe_key_components_and_their_interactions}

## Provide:
1. Complete RFC document with standard sections
2. API contracts (if applicable)
3. Data model changes
4. Sequence diagrams (ASCII)
5. Risks and open questions
6. Implementation timeline with milestones
7. Success metrics
```

**Usage Notes:** RFCs should be written before implementation, not during. Include "Out of scope" to prevent scope creep. Open questions are good — they invite review feedback on the areas you're least certain about.

**Example Output:** A complete technical specification with all standard RFC sections, diagrams, API contracts, and an implementation timeline.

---

### MA-08: Incident Postmortem

```
Write a postmortem for the following incident:

Incident: {title}
Severity: {S1-S4}
Duration: {start_time} to {end_time}
Impact: {users_affected, revenue_lost, services_degraded}

Timeline:
- {time}: {event}
- {time}: {event}
- {time}: {event}
[Continue...]

Root cause: {description}
Contributing factors: {list}

Provide a postmortem document with:
1. Executive summary (3 sentences)
2. Impact assessment (quantified)
3. Timeline (with detection, response, and resolution phases)
4. Root cause analysis (5 Whys)
5. What went well
6. What went poorly
7. Action items (with owners and deadlines)
8. Lessons learned
```

**Usage Notes:** Blameless postmortems are more effective. Focus on systemic causes, not individual mistakes. Every action item should have an owner and deadline, or it won't get done.

**Example Output:** A complete blameless postmortem with quantified impact, 5-Whys analysis, categorized action items, and systemic lessons learned.

---

### MA-09: API Documentation

```
Generate API documentation for {api_name}.

Base URL: {base_url}
Authentication: {auth_method}
Rate limits: {limits}

Endpoints:
1. {method} {path} — {description}
   - Request: {body/params}
   - Response: {response_schema}
   - Errors: {error_cases}

2. {method} {path} — {description}
   - Request: {body/params}
   - Response: {response_schema}
   - Errors: {error_cases}

[Continue for all endpoints...]

For each endpoint, provide:
1. Description and use case
2. Request example (curl + language-specific)
3. Response example (success + error)
4. Parameter descriptions with types and validation
5. Rate limit and pagination details

Format: {OpenAPI/Swagger | Markdown | HTML}
```

**Usage Notes:** Include real-looking example data, not placeholder values. Document error responses as thoroughly as success responses — developers spend more time debugging errors. Include curl examples for quick testing.

**Example Output:** Complete API documentation with endpoint descriptions, request/response examples in multiple formats, error catalogs, and authentication guides.

---

### MA-10: Learning Roadmap

```
Create a learning roadmap for {skill_or_domain}.

Current level: {beginner | intermediate | advanced}
Goal: {what_I_want_to_be_able_to_do}
Time available: {hours_per_week} for {duration}
Learning style: {reading | video | hands-on | mixed}

Provide:
1. Phase-by-phase curriculum
2. Specific resources for each phase (courses, books, tutorials)
3. Practice projects for each phase (increasing difficulty)
4. Milestones to measure progress
5. Common pitfalls to avoid at each stage
6. Estimated time per phase

Requirements:
- Prioritize practical over theoretical
- Include both free and paid resources
- [Focus area: {specific_subtopic}]
- [Skip: {topics_I_already_know}]
```

**Usage Notes:** Be honest about your current level. A realistic time commitment gets better recommendations than an aspirational one. Include your goal (build X, get hired as Y, pass certification Z) for focused recommendations.

**Example Output:** A phased learning plan with weekly schedules, curated resources, hands-on projects, progress milestones, and common mistakes to avoid.

---

## Appendix: Prompt Engineering Quick Reference

### The CRAFT Framework

When writing your own prompts, use CRAFT:

- **C**ontext — Background info the model needs
- **R**ole — Who should the model act as?
- **A**ction — What specifically should it do?
- **F**ormat — How should the output look?
- **T**one — What style of communication?

### Common Prompt Mistakes

| Mistake | Example | Fix |
|---------|---------|-----|
| Too vague | "Write some code" | "Write a Python function that validates email addresses using regex" |
| No format | "Analyze this data" | "Analyze this data and provide: 1) Summary stats 2) Top 3 insights 3) Visualization recommendations" |
| No constraints | "Write a blog post" | "Write a 1000-word blog post for developer audience in casual tone" |
| Missing context | "Fix this bug" | "Fix this TypeError in my React component (paste code + error)" |
| Too many asks | "Build a full app" | Break into: "Design the schema" → "Write the API" → "Build the UI" |

### Prompt Chaining Cheat Sheet

```
Task → [Decompose] → Sub-task 1 → [Validate] → Sub-task 2 → [Validate] → Final Output
```

Chain when:
- A single prompt gives mediocre results
- You need structured output from unstructured input
- The task has distinct phases (research → analyze → write)

### Temperature Guide

| Temperature | Best For |
|-------------|----------|
| 0.0 - 0.3 | Code generation, factual answers, structured output |
| 0.4 - 0.7 | Writing, analysis, general tasks |
| 0.8 - 1.0 | Creative writing, brainstorming, exploration |

---

*Built by SURVIVE. Works with any LLM. Made to ship.*