meteor-community-packages

Meteor community packages

Use Meteor's community package pages as a curated discovery catalog. A listing does not make a package part of Meteor core, transfer its maintenance to the Meteor organization, or guarantee compatibility with every Meteor 3 release. Select a package only after checking its ownership, current release, supported Meteor range, and changes to application behavior.

This skill owns package discovery, comparison, first adoption, and the package-specific integration documented in Meteor core. It does not replace the core skill for methods, publications, Mongo, accounts, security, testing, builds, or deployment.

Decision flow

1. Define the missing capability and the behavior that must remain unchanged. Distinguish a new adoption from a package that stopped resolving during a Meteor upgrade. Route the latter to migrate-to-meteor-3.
2. Inspect .meteor/release, .meteor/packages, .meteor/versions, package.json, and the npm lockfile. Package APIs follow the resolved package version, not only the Meteor release.
3. Read references/package-catalog.md when the request matches the documented catalog or a promoted package. Open only the selected package's local guide and read its baseline, selection rules, and required checks before responding. Then consult its linked upstream repository for APIs or versions beyond Meteor's maintained guidance.
4. Classify the candidate correctly:
   • A docs-listed community package keeps its named maintainer and independent release lifecycle.
   • A package under Meteor Community is community-maintained, not Meteor core.
   • A promoted core package, such as roles in Meteor 3.1+, uses the core package name and Meteor documentation.
5. Compare behavior, not feature labels. Identify monkey patches, changed query or removal semantics, client persistence, replay, external endpoints, database topology requirements, and production runtime effects.
6. Verify the Meteor floor from official documentation and the package version from its registry or repository. If the docs do not state a floor, say so and inspect the current release instead of inferring support.
7. Install through the package's documented ecosystem. Use meteor add for an Atmosphere package and meteor npm install for an npm package. Do not invent a version constraint. After installation, confirm the resolved version in .meteor/versions or the npm lockfile.
8. Apply every relevant required check from the selected package guide. Do not stop after asking for a project path. If files are unavailable, state the exact version, security, behavior, and test checks as required next steps. For an option not covered there, verify the resolved version against the upstream repository instead of extrapolating from another release.
9. Add the smallest representative integration and test its package-specific behavior plus the underlying Meteor invariants. Use the owning core skill for authorization, validation, publication selectors, indexes, transaction design, build output, or deployment architecture.