AI Prompts Library

You are a technical writer who creates in-depth, developer-focused blog posts. Write a complete blog post on the specified topic.

**Topic:** [BLOG_POST_TOPIC]
**Target Reader:** [Junior dev / Mid-level dev / Senior dev / Tech lead / Non-technical stakeholder]
**Word Count:** [1500-3000 words]
**Tone:** [Tutorial / Opinion piece / Deep dive / Comparison / Case study]
**Key Takeaway:** [WHAT SHOULD THE READER LEARN]

**Blog Post Structure:**

1. **Title** (3 options):
   - SEO-friendly, specific, and compelling
   - Include a number, "how to", or power word when appropriate
   - Under 60 characters for search engine display

2. **Introduction** (150-200 words):
   - Start with a relatable problem or scenario (no generic intros)
   - State what the reader will learn
   - Establish credibility (why should they trust this content)
   - Preview the structure

3. **Body Sections** (use H2/H3 hierarchy):
   - Each section covers one key concept
   - Include code examples that are complete and runnable
   - Add inline comments explaining non-obvious code
   - Use diagrams described in text where visual explanation helps
   - Include performance benchmarks or comparisons with data
   - Address common mistakes and how to avoid them

4. **Practical Example:**
   - A real-world scenario applying the concepts
   - Step-by-step implementation
   - Complete, copy-pasteable code
   - Expected output

5. **Conclusion:**
   - Summarize key points (not a repeat of the intro)
   - Next steps for the reader
   - Links to related resources or further reading

**Quality Requirements:**
- No filler sentences or generic statements
- Every paragraph must add specific, actionable value
- Code examples must be tested and complete
- Use transition sentences between sections
- Include alt text suggestions for any images/diagrams

**Output**: The complete blog post in Markdown format with frontmatter (title, date, tags, description).

You are a documentation standards expert. Create a comprehensive documentation style guide for the described organization or project.

**Organization/Project:** [NAME]
**Documentation Type:** [API docs / User guides / Internal wikis / Developer docs / All]
**Audience:** [Developers / End users / Mixed]
**Existing Style Preferences:** [Any specific preferences, or 'none']

**Generate a style guide covering:**

1. **Voice and Tone:**
   - Active vs. passive voice rules (with examples)
   - Second person ("you") vs. third person usage
   - Level of formality
   - When to use humor (if ever)
   - Handling of uncertainty ("might" vs. "will")

2. **Structure and Formatting:**
   - Document template (standard sections every doc should have)
   - Heading hierarchy rules (capitalization, depth limits)
   - Paragraph length guidelines
   - List formatting (bullet vs. numbered, when to use each)
   - Table usage guidelines
   - Code block formatting (language tags, line limits, highlighting)

3. **Language Rules:**
   - Preferred terminology (glossary of approved terms)
   - Words to avoid ("simply", "just", "easy", "obviously")
   - Abbreviation and acronym policy (define on first use)
   - Capitalization rules for product names, features, UI elements
   - Date, time, and number formatting
   - Inclusive language guidelines

4. **Code Documentation:**
   - Inline comment standards
   - Function/method documentation format (JSDoc, docstring, etc.)
   - README template
   - API reference format
   - Code example requirements (complete, runnable, with output)

5. **Visual Elements:**
   - Screenshot guidelines (when to include, annotation style)
   - Diagram standards (tools, colors, style)
   - Callout/admonition types (Note, Warning, Tip, Caution)

6. **Review Process:**
   - Documentation review checklist
   - Peer review requirements
   - Freshness/update schedule

**Output**: A complete style guide document that can be shared with all contributors.

You are a developer relations writer who creates clear, developer-friendly API changelogs. Write a changelog entry based on the described changes.

**API Name:** [API_NAME]
**Version:** [FROM_VERSION -> TO_VERSION]
**Release Date:** [DATE]
**Changes:** [DESCRIBE ALL CHANGES - new endpoints, modified behavior, deprecations, bug fixes]

**Changelog Format:**

1. **Header:**
   - Version number and date
   - Release type badge: Major (breaking) / Minor (features) / Patch (fixes)
   - One-sentence summary of the most important change

2. **Breaking Changes** (if any):
   - Use a prominent warning callout
   - Describe exactly what changed and what breaks
   - Provide migration code examples (before/after)
   - Include a migration deadline if applicable
   - Link to migration guide

3. **New Features:**
   - New endpoints with method, path, and brief description
   - New query parameters or request fields
   - New response fields
   - Include minimal working code examples
   - Link to full documentation

4. **Improvements:**
   - Performance improvements with metrics
   - Enhanced error messages
   - Expanded validation rules
   - New SDK support

5. **Bug Fixes:**
   - Brief description of what was wrong
   - What the correct behavior is now
   - Reference issue numbers if applicable

6. **Deprecations:**
   - What is deprecated and when it will be removed
   - Replacement/alternative to use instead
   - Code example showing the migration

7. **Known Issues:**
   - Any outstanding issues in this release
   - Workarounds if available

**Writing Rules:**
- Use present tense ("adds" not "added")
- Be specific ("response time reduced from 500ms to 120ms" not "improved performance")
- Always include code examples for breaking changes
- Use semantic versioning terminology correctly

**Output**: Changelog entry in Markdown format, ready to publish.

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 technical documentation specialist creating comprehensive, user-friendly documentation.

Project: [PROJECT NAME]
Audience: [TARGET USER LEVEL: Beginner/Intermediate/Advanced]
Technology Stack: [TECHNOLOGIES]

Create documentation that includes:

**1. Overview Section**
- Purpose and goals
- Key features
- Prerequisites
- Architecture diagram (describe in detail)

**2. Getting Started**
- Installation steps (OS-specific if needed)
- Initial configuration
- First-time setup
- Quick start example

**3. Core Concepts**
- Fundamental principles
- Terminology glossary
- Common patterns
- Best practices

**4. API Reference** (if applicable)
- Endpoint descriptions
- Parameters and types
- Request/response examples
- Error codes

**5. Advanced Topics**
- Performance optimization
- Troubleshooting guide
- FAQ section
- Migration guides

**6. Code Examples**
- Common use cases (with code)
- Integration examples
- Testing examples

Format: Use clear headings, code blocks, callouts for warnings/tips, and maintain consistent terminology.