RSS and Atom Feed Generation Prompt Template

This prompt is designed for content syndication developers and platform engineers who need to generate valid RSS 2.0 or Atom 1.0 feeds from source material that may be structured (database records, API responses) or unstructured (blog posts, release notes, meeting summaries). The core job-to-be-done is transforming a collection of content items into a standards-compliant XML feed that passes validation against the W3C Feed Validator and renders correctly in common feed readers. The ideal user is someone who already understands the difference between RSS and Atom, knows their target consumer requirements, and needs a reliable, schema-first generation path rather than a tutorial on syndication formats.

Use this prompt when you have a batch of content items with at least a title, publication date, and unique identifier for each entry. The prompt works best when you provide a clear [OUTPUT_SCHEMA] that specifies the feed format (RSS 2.0 or Atom 1.0), required channel metadata (title, link, description, language), and per-item fields (title, link, guid/id, pubDate/updated, description/summary). Include [CONSTRAINTS] for date format requirements (RFC 822 for RSS, RFC 3339 for Atom), GUID permanence rules, enclosure MIME type validation, and any feed reader compatibility targets. The prompt template includes placeholders for [EXAMPLES] of correct feed entries, which is critical for teaching the model the exact XML structure, namespace declarations, and escaping behavior you expect.

Do not use this prompt when you need real-time feed generation from streaming data, when feed items require complex digital signatures or encryption, or when the source content contains untrusted HTML that must be sanitized before inclusion in description elements. This prompt is also insufficient for generating podcast-specific RSS extensions (iTunes namespace, Google Play namespace) without explicit examples in the [EXAMPLES] block. For high-risk syndication pipelines where feed validity directly impacts content distribution revenue, always pair this prompt with a post-generation validation harness that runs the output through a feed validator, checks for broken links, and verifies date ordering before publishing. Human review is required when feeds include legal disclaimers, copyright assertions, or content that must comply with platform-specific terms of service.

This prompt template is designed to produce a complete, standards-compliant RSS 2.0 or Atom 1.0 feed document. It accepts a list of content items, feed-level metadata, and a target format specification. The template enforces strict XML structure, correct date formatting (RFC 822 for RSS, RFC 3339 for Atom), proper GUID handling, and valid enclosure elements. Use this as the core instruction block in your feed generation pipeline, replacing the square-bracket placeholders with your application's data before sending the request to the model.

textCopy
You are a precise XML feed generator. Your task is to produce a single, complete, and valid [FEED_FORMAT] feed document based on the provided inputs. The output must be nothing but the XML document itself, starting with the XML declaration and the root feed element.

# INPUT DATA

## Feed Metadata
- Title: [FEED_TITLE]
- Link: [FEED_LINK]
- Description: [FEED_DESCRIPTION]
- Language: [FEED_LANGUAGE]
- Last Build Date (for RSS): [LAST_BUILD_DATE]
- Updated Date (for Atom): [UPDATED_DATE]
- Generator: [GENERATOR_STRING]

## Content Items
[ITEMS_ARRAY]

# OUTPUT CONSTRAINTS
1. **Format**: Generate a valid [FEED_FORMAT] document. If RSS 2.0, use `<rss version="2.0">` as the root. If Atom 1.0, use `<feed xmlns="http://www.w3.org/2005/Atom">` as the root.
2. **Dates**: For RSS, all dates must be in RFC 822 format (e.g., `Mon, 01 Jan 2024 12:00:00 GMT`). For Atom, all dates must be in RFC 3339 format (e.g., `2024-01-01T12:00:00Z`).
3. **GUIDs**: For RSS, each `<guid>` must have an `isPermaLink` attribute set to `true` or `false`. If the GUID is a URL, use `true`; otherwise, use `false` and ensure the value is a unique string.
4. **Enclosures**: For any item with an enclosure, include a valid `<enclosure>` element with `url`, `length`, and `type` attributes. The `length` must be a positive integer representing bytes.
5. **Escaping**: Properly escape all XML special characters (`&`, `<`, `>`, `"`, `'`) in text content. Use CDATA sections only when explicitly requested for a specific field.
6. **Encoding**: The XML declaration must specify `encoding="UTF-8"`.
7. **Completeness**: Include all provided items. Do not truncate or summarize the feed content.
8. **Output Only**: Do not include any explanatory text, markdown fences, or conversational preamble. The response must start with `<?xml` and end with the closing root tag.

# EXAMPLES
[FEW_SHOT_EXAMPLES]

# RISK LEVEL
[RISK_LEVEL]

Adaptation Guidance: The [ITEMS_ARRAY] placeholder should be replaced with a serialized representation of your content items, each containing fields like title, link, description, pubDate, guid, and optional enclosure details. The [FEW_SHOT_EXAMPLES] placeholder is critical for format adherence; provide at least one complete, valid feed example matching your target format. For high-stakes publishing pipelines, set [RISK_LEVEL] to HIGH and ensure downstream validation with a feed validator like the W3C Feed Validation Service before distribution. If your items contain HTML in the description field, add an explicit instruction to wrap that content in a CDATA section to prevent parser errors.

Integrating an LLM-based feed generator into a production system requires treating the prompt as a deterministic function with strict input validation, output verification, and a clear retry/fallback path. The prompt template expects structured inputs—a list of articles with titles, URLs, dates, and optional content—and produces a complete XML document. Before calling the model, your application layer must sanitize all user-provided text fields to prevent prompt injection, validate that required fields (title, link, pubDate/updated) are present and non-null, and format all datetime objects into the RFC 822 (RSS) or RFC 3339 (Atom) strings the prompt demands. Missing or malformed dates are the most common cause of feed validator failures, so pre-formatting them in code rather than relying on the model to interpret arbitrary date strings is essential.

The model call itself should be wrapped in a harness that enforces a strict output contract. Configure your API request with response_format set to a JSON Schema object containing a single feed_xml string property, or use a constrained text completion with stop sequences that prevent the model from generating explanatory text before or after the XML declaration. On receiving the response, run a multi-stage validation pipeline: first, parse the string with a strict XML parser (reject on any parse error); second, validate against the RSS 2.0 or Atom 1.0 schema using a library like feedparser or a dedicated XML Schema validator; third, check feed-reader compatibility rules such as GUID uniqueness, enclosure URL accessibility, and the presence of at least one <title> and <link> element in the channel/feed header. If any stage fails, log the raw output and the specific validation error, then retry once with the same prompt plus the validation error message appended as a correction instruction. If the retry also fails, fall back to a template-based feed generator built in application code—never ship a broken feed to subscribers.

For high-volume or user-facing systems, add observability hooks around every generation call. Log the input article count, the model used, the token consumption, the validation pass/fail status, and the latency of each pipeline stage. Set up alerts on validation failure rate spikes, which often indicate prompt drift or upstream data quality issues. If your feed includes user-generated content, implement a human review queue for first-time publishers or content flagged by automated safety classifiers before the feed XML is cached and served. Finally, cache successfully generated feeds at the HTTP level with ETag and Last-Modified headers based on the newest article's publication date, and regenerate only when new articles are added—this keeps costs predictable and response times fast while ensuring subscribers always receive valid, standards-compliant XML.