agentleFS
Sign inStart free
VinkyDevVinkyDev/vibestart/.agents/skills/add-integration/SKILL.md

add-integration

Skill289 starsChanged 29 days agoMITView on GitHub

Add or replace a stack choice in the generator. Use when adding an integration, a capability, or a new option for a kind (a database, ORM, framework, runtime, deployment), or when renaming one.

7 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Shape: Write down the kind, provides, requires (with alternatives), and whether it is auxiliary.

    line 8
  2. Very specific:

    Tracer bullet: Create packages/integrations/src/<id>.ts with defineIntegration, register it in kind position in registry.ts, and add its …

    line 9
  3. Very specific:

    Snapshots: Run vp test -u, then read the diff of src/__snapshots__/ and schema.json.

    line 12
  4. Very specific:

    Finish: Run the self-review skill, then vp run ready.

    line 15

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

An integration reaches every layer that names its choices: the registry, templates, other integrations, the goldens, the Studio, and the docs. Read docs/architecture.md "Model", "Resolver", and "Contributions" first, and the vocabulary in GLOSSARY.md. git show --stat 451fa8bc (MongoDB and Mongoose) is the reference change.

  1. Shape. Write down the kind, provides, requires (with alternatives), and whether it is auxiliary. List the legal stacks it opens and the ones it closes. Done when each new capability has a one-line description you will add to capabilities in packages/integrations/src/registry.ts.
  2. Tracer bullet. Create packages/integrations/src/<id>.ts with defineIntegration, register it in kind position in registry.ts, and add its packages to src/catalog.ts. Start from the smallest sibling of the same kind (sqlite.ts for a database). Done when vp test packages/integrations/src/registry.test.ts passes.
  3. Contributions. Contribute through the slots other owners define (packageJson, serverEnv, dockerRuntime, lintOverrides, readmeLayers); a file you return is yours alone. Where another owner's file changes with your choice, branch inside that owner on ctx.has("<id>") or a helper in src/app.ts. Static files go under templates/<id>/<set>/. Done when rg 'ctx.has\("<sibling>"\)' packages/integrations/src shows every place a sibling is named, and each one decides what your id does there.
  4. Goldens. The goldens together use every integration (src/golden.test.ts). Swap the new choice into the golden whose product it fits in src/goldens.ts, adjust that test's expected setup commands, and run vp run stacks goldens. Give the stack label a segment in src/stack-label.ts when two stacks would otherwise share a name. Done when vp test packages/integrations/src/golden.test.ts passes.
  5. Snapshots. Run vp test -u, then read the diff of src/__snapshots__/ and schema.json. It is what every generated project receives. Done when each changed hunk is one you meant.
  6. Services. A database or server that tests need gets a URL in src/stacks.ts (STACKS_*_URL), a branch in src/env-files.ts (MaterializeEnvOptions and the scheme list in localValue), and a CI service in .github/workflows/ci.yml on Linux and Windows.
  7. Studio and docs. In apps/web: messages/en.json and zh.json (desc_<id>, fit_<id>, any cap_* and note_any_*), src/lib/i18n.ts, src/lib/roles.ts, src/assets/tech/<id>.svg, src/components/docs/tech-icons.ts, src/components/docs/viz/stack-map.tsx, and the topology in src/components/topology/ when the choice runs as a process. Then the stack/*.mdx page in both languages, README.md, README.zh.md, apps/cli/README.md, and the --<kind> choices message in apps/cli/src/command.test.ts. Done when vp test apps/web/src/lib/i18n.test.ts passes.
  8. Finish. Run the self-review skill, then vp run ready. CI verifies the stacks the change reaches; a red verify job names the stack and ends with its log. Done when vp run ready passes and the PR body says which legal stacks were added or removed.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free