mcpField
F
feedsmith

feedsmith

github.com/dobroslavradosavljevicDevelopment339 installsUpdated 2d ago
Repository

About feedsmith

A developer skill for using Feedsmith v3+ to parse and generate RSS, Atom, RDF, JSON Feed, and OPML. It emphasizes typed, structure-preserving APIs and documents version-specific behavior and migration issues.

Key features

  1. 01Parse RSS, Atom, RDF, JSON Feed, and OPML
  2. 02Generate supported feed formats and OPML
  3. 03Typed, format-specific structures
  4. 04Feed format detection guidance
  5. 05v2-to-v3 migration guidance

Use cases

  1. 01Parsing feeds from known formats
  2. 02Handling mixed or unknown feed sources
  3. 03Generating JSON Feed, RSS, Atom, or OPML
  4. 04Migrating a project from Feedsmith v2

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/dobroslavradosavljevic/skills --skill feedsmith

After installing, type/feedsmithin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

agents/
openai.yaml
references/
formats-namespaces.md
generating.md
migration-v2-to-v3.md
parsing.md
source-map.md

Details

From the project README

Feedsmith

Use this skill for Feedsmith v3+ (feedsmith): parse and generate RSS, Atom, RDF, JSON Feed, and OPML with structure-preserving, typed APIs. Docs: feedsmith.dev. Snapshot 3.0.1 (2026-10-01).

Workflow

  1. Inspect the local surface:
    • Installed feedsmith version (bun pm ls feedsmith / bun info feedsmith). This skill targets 3.x; latest is 3.0.1 (ESM build now ships .mjs files; no API changes from 3.0.0).
    • Parse vs generate vs OPML vs detect-only usage.
    • Dates: raw strings vs parseDateFn / Date on generate.
    • v2 leftovers: feedsmith/types, { lenient: true }, flat Atom strings, string RSS persons, singular dc.* fields, Rss/Atom/Json/Rdf type namespaces.
  2. Prefer dedicated parsers when format is known; use parseFeed only for unknown/mixed sources.
  3. Refresh docs when tags drift. Start from source-map.md.
  4. Route deeper detail:
  5. Prefer bun / bunx in command examples.

Core Judgment

  • Preserve structure — do not invent a “universal flattened feed” layer; read format-specific fields and namespaces (feed.itunes, item.dc, …).
  • Dates are strings by default on parse. Use parseDateFn to convert; errors from that fn are not swallowed.
  • Generate is lenient by default (all fields optional). Use { strict: true } for compile-time spec-required fields + Date dates.
  • Atom text/content are objects: title?.value, content?.value (not bare strings).
  • RSS persons are objects: { email?, name?, link? } — not "a@b (Name)" strings. link is parse-only.
  • Types from main entry: RssFeed, AtomFeed, JsonFeed, RdfFeed, Opml, AnyFeed. No feedsmith/types.
  • RDF generate is not available (generateRdfFeed is planned). JSON Feed / RSS / Atom / OPML generate yes. generateJsonFeed returns an object, not a string.
  • Catch DetectError | MalformedError | ParseError | GenerateError — not only generic Error.
  • Known format → dedicated parser (faster, more reliable than detect heuristics).

Verification

Prefer repository-owned commands. Cover the relevant subset:

  • bun pm ls feedsmith / bun info feedsmith — confirm 3.x.
  • Round-trip: parse fixture → assert key fields → generate → re-parse smoke.
  • Typecheck Atom .value / RSS Person / dc.creators (plural) / itunes.duration as number after upgrades.
  • Strict generate: missing required fields should fail at compile time with { strict: true }.
  • Error-path tests for bad XML / wrong format using dedicated error classes.

Report which checks ran, which did not, and version/tag assumptions that remain.

Comments

Markdown supported