Adding an implement provider

A feature is content per provider, deliberately written independently rather than templated from a shared skeleton.

features/<feature-id>/
  manifest.json                     { id, name, description, category, providers }
  providers/<technology-id>/
    plan.md                         the step-by-step implementation plan
    checklist.md                    what to verify before shipping
    prompts/*.md                    ready to hand to an AI assistant
    scaffold/**                     mirrored into the project's source layout

The point is that providers differ

Follow an existing sibling as a structural reference — not as a template to fill in blanks on. Two providers must produce genuinely different content, grounded in that technology's actual APIs and gotchas. Its own cursor-rule.mdc and setup.md are the best source for those.

Say what you don't know

If you are not confident about a specific SDK detail, say so in the content and point at the current official docs rather than asserting something you are unsure of.

Rules for scaffold files

→Paths must land inside a folder the technology's own folders.json already declares, and never a path that technology's templates/ could also write to.

→They should be skeletons — a TODO and a pointer back to plan.md, not a full implementation.

→manifest.json's category names which wizard category's answer selects the provider. providers is validated against the real module registry at load time.

Before opening a PR

# generate a project with that provider selected, then inside it:
npm install && npx tsc --noEmit && npx eslint .

This is exactly how three real bugs — two bad relative import paths and a listener-reference mismatch — were caught while building the first three features. None of them would have been found by the test suite alone.

Adding a technology

Adding an archetype

On this page

The point is that providers differ Rules for scaffold files Before opening a PR

Source: CONTRIBUTING.md §Adding a provider