AI Prompts Library

Write a changelog entry from this diff. Write for someone deciding whether this release affects them, not for someone who already knows the codebase.

Rules:
- Group under Added, Changed, Fixed, Removed, Security. Omit empty groups.
- Lead each entry with the user-visible effect, then the mechanism. Never the reverse.
- For every fix, say what was broken and who it affected. A fix with no symptom is not a changelog entry.
- Name files and functions only when a reader would need them to act.
- Flag anything requiring migration or config changes with a bold BREAKING marker.
- Use plain hyphens, never em dashes.
- No marketing language. No 'we are excited to'.

If the diff contains a change whose user-visible effect you cannot determine, list it under a Needs Description heading rather than inventing one.

Diff:
[PASTE]

Generate a comprehensive article outline for the topic: "[TOPIC]".

Target keyword: [PRIMARY KEYWORD]
Secondary keywords: [LIST 2-3]
Target audience: [READER PERSONA]
Word count: [WORD COUNT]
Intent: [INFORMATIONAL / COMMERCIAL / TRANSACTIONAL]

Produce:
1. SEO-optimized H1
2. Meta description (under 160 chars, includes primary keyword)
3. H2/H3 structure with keyword distribution
4. Featured-snippet-targeted Q&A section (for AEO - answer engine optimization)
5. Recommended internal links (anchor + URL placeholder)
6. Recommended external authoritative sources to cite
7. Schema.org type to use (Article / FAQPage / HowTo)

The outline should be detailed enough that a writer can produce the article in one sitting.

Below is a draft article. Suggest internal links to add.

For each suggestion, provide:
1. The exact phrase in the article to link from (3-7 words, naturally fitting anchor text)
2. The URL/page to link to (assume my site has pages at the URLs I'll provide)
3. Why this link helps SEO (topical authority, user journey, etc.)

My site has these key pages: [LIST URLS WITH ONE-LINE DESCRIPTIONS]

Draft article:
[PASTE ARTICLE]

Return 5-8 strong link recommendations. Skip weak ones - quality over quantity.

Rewrite the title tag and meta description for this page:

Page URL: [URL]
Current title: [CURRENT]
Current meta description: [CURRENT]
Primary target keyword: [KEYWORD]
User intent: [INFORMATIONAL / TRANSACTIONAL]
Page content summary: [3 SENTENCES]

Produce 5 alternatives for each. Constraints:
- Title: 50-60 chars, primary keyword in first 30 chars
- Meta description: 140-160 chars, includes value prop and CTA verb
- Both must accurately represent the page (no clickbait)
- Each variant has a different angle (benefit, urgency, social proof, etc.)

Rank the variants 1-5 by predicted CTR.

Help me build a topic cluster around the pillar topic: "[PILLAR TOPIC]".

Produce:
1. The pillar page outline (definitive, comprehensive)
2. 8-12 cluster posts that link to and from the pillar - each one drilling into a specific subtopic
3. The internal linking structure (which posts link to which)
4. Suggested URL structure (slug pattern)
5. Priority order for publishing (highest-impact first)

For each cluster post, give: title, target keyword, search intent, 1-sentence summary.

Focus on posts that can rank individually AND build authority for the pillar.

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 product communication specialist. Generate user-friendly release notes from the provided list of changes.

**Product:** [PRODUCT_NAME]
**Version:** [VERSION]
**Release Date:** [DATE]
**Audience:** [End users / Developers / Both]
**Raw Changes:** [PASTE GIT LOG, JIRA TICKETS, OR BULLET LIST OF CHANGES]

**Release Notes Structure:**

1. **Summary** (2-3 sentences):
   - Highlight the most impactful change
   - Set context for why this release matters
   - Build excitement without overselling

2. **What is New** (user-facing features):
   - Feature name as heading
   - 2-3 sentence description focused on user benefit (not implementation)
   - Screenshot/GIF description suggestion
   - How to access/try the feature

3. **Improvements** (enhancements to existing features):
   - Before vs. after comparison
   - Quantify improvements when possible ("30% faster", "50% less memory")

4. **Bug Fixes:**
   - Group by severity or area
   - Write in past tense ("Fixed an issue where...")
   - No technical jargon for end-user release notes
   - Include issue/ticket reference numbers

5. **Known Issues:**
   - Honest disclosure of known limitations
   - Workarounds where available
   - Expected fix timeline

**Writing Guidelines:**
- Transform technical descriptions into user benefits
- Example: "Implemented Redis caching layer" becomes "Dashboard now loads 3x faster"
- Use consistent formatting (bullet points for lists, bold for feature names)
- Keep individual items to 1-3 sentences
- Avoid: "minor bug fixes", "various improvements", "stability enhancements" (be specific)
- Include links to detailed documentation for complex features

**Output Formats:**
1. Full release notes (for blog/documentation)
2. Short version (for in-app notification, max 280 characters)
3. Email version (for customer communication)
4. Internal version (more technical detail for support team)

You are an executive communications consultant. Write a concise, impactful executive summary for the described report or proposal.

**Document Type:** [Project Proposal / Quarterly Report / Research Report / Business Case / Post-Mortem / Strategy Document]
**Full Content:** [PASTE THE FULL DOCUMENT OR KEY POINTS]
**Audience:** [C-suite / Board / Investors / Department heads / External stakeholders]
**Desired Length:** [1 page / 2 pages / 500 words / 1000 words]
**Decision Required:** [What action or decision should the reader take after reading?]

**Executive Summary Structure:**

1. **Opening Statement** (1-2 sentences):
   - State the purpose and recommendation upfront
   - Use the pyramid principle: conclusion first, then supporting evidence

2. **Context** (2-3 sentences):
   - Why this matters now (market change, problem, opportunity)
   - Scope and timeline

3. **Key Findings/Recommendations** (bullet points):
   - 3-5 critical insights, each with supporting data
   - Quantify everything possible (dollar amounts, percentages, timeframes)
   - Bold the key metric or takeaway in each point

4. **Financial Impact** (if applicable):
   - Cost, revenue, ROI, or resource requirements
   - Comparison to alternatives or status quo

5. **Risks and Mitigations:**
   - Top 2-3 risks
   - Proposed mitigation for each

6. **Recommended Next Steps:**
   - Specific actions with owners and deadlines
   - Decision points requiring approval

**Writing Rules:**
- No jargon unless the audience expects it
- Every sentence must earn its place (no filler)
- Use data and specifics, not vague qualifiers
- Active voice, present tense for recommendations
- Lead with impact, follow with methodology
- The reader should be able to make a decision based on the summary alone

**Output**: The executive summary plus a 3-bullet "elevator pitch" version for verbal communication.

You are an experienced product owner and agile coach. Write comprehensive user stories with acceptance criteria for the described feature.

**Feature:** [DESCRIBE THE FEATURE]
**Product:** [PRODUCT_NAME]
**Sprint Goal:** [WHAT THIS SPRINT AIMS TO ACHIEVE]
**Users/Personas:** [WHO WILL USE THIS FEATURE]

**For each user story, provide:**

1. **Story Format:**
   As a [specific user role],
   I want to [action/capability],
   So that [business value/benefit].

2. **Acceptance Criteria** (Given/When/Then format):
   - Given [precondition]
   - When [action]
   - Then [expected result]
   - Write 3-7 acceptance criteria per story covering happy path and edge cases

3. **Story Metadata:**
   - Priority: Must-have / Should-have / Could-have / Won't-have (MoSCoW)
   - Story Points: Estimate using Fibonacci (1, 2, 3, 5, 8, 13)
   - Dependencies: Other stories this depends on
   - Labels: Frontend / Backend / Full-stack / Design / Infrastructure

4. **Technical Notes:**
   - Implementation hints (not prescriptive, but helpful context)
   - API endpoints needed
   - Database changes required
   - Third-party integrations

5. **Definition of Done:**
   - Code complete with tests
   - Code review approved
   - QA tested on staging
   - Documentation updated
   - Accessibility verified
   - Performance acceptable

**Story Splitting Guidance:**
- If a story is > 8 points, split it using these techniques:
  - By workflow step
  - By data variation
  - By business rule
  - By interface (API first, then UI)
  - By operation (CRUD: create first, then read, update, delete)

**Output**: A complete set of user stories for the feature, organized by priority, with a story map showing the user journey.

You are an executive assistant who creates clear, actionable meeting summaries. Transform the provided meeting notes or transcript into a structured summary.

**Meeting Details:**
- Meeting Title: [TITLE]
- Date: [DATE]
- Duration: [LENGTH]
- Attendees: [LIST OF PARTICIPANTS]
- Meeting Type: [Stand-up / Sprint planning / Strategy / 1:1 / All-hands / Client meeting]

**Raw Notes/Transcript:**
[PASTE NOTES OR TRANSCRIPT HERE]

**Generate this structured summary:**

1. **TL;DR** (2-3 sentences):
   - The single most important outcome or decision
   - Key context for anyone who missed the meeting

2. **Decisions Made:**
   - List each decision with who made it
   - Include any conditions or constraints
   - Note any dissenting opinions

3. **Action Items** (table format):
   | Action | Owner | Deadline | Priority |
   - Each action must be specific and measurable
   - Include a clear deadline (even if estimated)
   - Assign a single owner (not a team)

4. **Discussion Topics:**
   - Summarize each major topic discussed
   - Note differing viewpoints on contentious topics
   - Include relevant data or metrics mentioned
   - Flag items that need follow-up

5. **Parking Lot:**
   - Topics raised but deferred for later
   - Questions that need answers before next meeting

6. **Next Steps:**
   - When is the follow-up meeting?
   - What needs to be prepared before then?
   - Who needs to be informed about decisions?

**Summary Rules:**
- Use present tense for decisions, future tense for actions
- Name specific people, not "the team" or "someone"
- Quantify wherever possible
- Flag blockers and risks prominently
- Keep the entire summary under 1 page

**Output**: The structured summary plus a 3-line Slack/email message version for quick team notification.