Add Automatic Support to Your Repository

Your team has built a set of AI agent resources — skills that encode your deployment workflow, MCP server configs for your internal tools, coding rules that keep PRs consistent. Today those live in a wiki, a Slack thread, or someone's dotfiles. With Remote Sources, you can publish them from a git repository and let anyone install them with a single click.

What are Remote Sources?

Remote Sources let Automatic load resources directly from a git repository. You add a manifest file called automatic.json to your repo, and Automatic handles the rest — cloning, unpacking, tracking provenance, and keeping everything up to date.

The resources you can publish:

• Skills — reusable agent instructions (deployment runbooks, code review checklists, framework guides)
• MCP Servers — tool configurations that connect agents to databases, APIs, and services
• Rules — coding standards and conventions agents should follow
• Templates — project scaffolds for new repos
• Commands — custom agent commands
• Agents — agent definitions with specific roles
• Collections — curated bundles that appear in the Automatic Marketplace

Getting started: the manifest

If you have Automatic installed, the fastest way to get started is to ask your agent to create a Remote Source manifest. Automatic can scaffold a complete automatic.json based on your repository — detecting existing skills, MCP servers, and rules automatically.

You can also create the manifest by hand. At minimum, you need a name, version, and description:

{
  "$schema": "https://tryautomatic.app/schemas/automatic.json",
  "name": "my-team-toolkit",
  "version": "1.0.0",
  "description": "AI agent resources for our team"
}

The $schema field gives you autocomplete and validation in VS Code and other editors that support JSON Schema.

From there, add whichever resource sections you need. Every section is optional — a source can provide just skills, just rules, or any combination.

Adding skills

Skills are the most common resource type. Each skill is a directory containing a SKILL.md file (the main instructions) and optional companion files like scripts, templates, or reference docs.

You can define skills inline or point to a skill.json spec file:

{
  "skills": {
    "entries": [
      {
        "name": "our-deploy-skill",
        "path": "./skills/deploy",
        "description": "Production deployment automation",
        "tags": ["devops", "deployment"]
      }
    ]
  }
}

If your repo already has a skill.json at root (the standard skill registry format), you can reference it instead:

{
  "skills": {
    "skill_json": "./skill.json"
  }
}

Both approaches work together — use skill_json for compatibility with the broader skill ecosystem, and entries for skills specific to your manifest.

Bonus: If your repo has a skill.json but no automatic.json, Automatic treats it as a skills-only source automatically. No manifest authoring required.

Adding MCP servers, rules, and more

MCP servers, rules, templates, commands, and agents all use the same simple format:

{
  "mcp_servers": [
    {
      "name": "internal-db",
      "path": "./mcp-servers/internal-db.json",
      "description": "Connect to our internal database"
    }
  ],
  "rules": [
    {
      "name": "code-style",
      "path": "./rules/code-style.md",
      "description": "Team coding standards"
    }
  ]
}

Each entry needs a name, a path (relative to the manifest), and a description. Automatic handles installing each resource to the right location.

Controlling which agents get what

Not every agent needs every resource. The agent_overrides section lets you fine-tune which resources are enabled for Claude, Cursor, Codex, or any other supported agent:

{
  "agent_overrides": {
    "_defaults": {
      "skills": ["our-deploy-skill"],
      "rules": ["code-style"]
    },
    "cursor": {
      "exclude_skills": ["our-deploy-skill"]
    },
    "claude": {
      "include_rules": ["claude-specific-hints"]
    }
  }
}

The _defaults key sets the baseline for all agents. Per-agent keys add includes or excludes on top. The effective set is always defaults + includes - excludes.

One-click install with deep links

Once your manifest is ready, you can give users a one-click install link:

automatic://install?repo=your-org/your-repo

When someone clicks this link, Automatic opens, fetches your manifest, and shows a confirmation dialog before installing anything. No manual cloning, no copy-pasting configs.

Pin to a specific version:

automatic://install?repo=your-org/your-repo&ref=v2.0.0

For monorepos where the manifest lives in a subdirectory:

automatic://install?repo=your-org/your-repo&dir=packages/ai-config

Add an install badge to your README

Drop this into your README to give users a clear install path:

[![Install in Automatic](https://tryautomatic.app/badges/install.svg)](automatic://install?repo=your-org/your-repo)

Or use HTML for websites and landing pages:

<a href="automatic://install?repo=your-org/your-repo">
  <img src="https://tryautomatic.app/badges/install.svg"
       alt="Install in Automatic" height="32">
</a>

Version pinning

By default, sources track the main branch — when you push updates, users get them on their next sync. You can also configure tag or commit pinning for stricter version control:

{
  "pinning": {
    "strategy": "tag",
    "ref": "v2.0.0"
  }
}

Three strategies are available:

Strategy	Behavior
branch	Tracks a branch. Updates pull the latest. This is the default.
tag	Pins to a git tag. Only changes when the user updates the pin.
commit	Pins to a specific SHA. Maximum reproducibility.

Updates and conflict resolution

When a source is updated, Automatic diffs the manifest against the previous install. New resources are added, changed resources are overwritten, and removed resources are cleaned up. Provenance tracking ensures every installed resource maps back to its source, so nothing gets orphaned.

If two sources try to provide a resource with the same name, Automatic surfaces the conflict before installing and lets the user choose how to resolve it.

Putting it all together

Here is a complete example for a team that wants to share deployment skills, a database MCP server, and coding standards:

{
  "$schema": "https://tryautomatic.app/schemas/automatic.json",
  "name": "acme-ai-toolkit",
  "version": "1.0.0",
  "description": "AI agent resources for the Acme engineering team",
  "author": { "name": "Acme Corp" },
  "license": "MIT",

  "skills": {
    "entries": [
      {
        "name": "acme-deploy",
        "path": "./skills/deploy",
        "description": "Deploy to Acme staging and production",
        "tags": ["devops"]
      }
    ]
  },

  "mcp_servers": [
    {
      "name": "acme-db",
      "path": "./mcp-servers/acme-db.json",
      "description": "Acme database MCP server"
    }
  ],

  "rules": [
    {
      "name": "acme-code-style",
      "path": "./rules/code-style.md",
      "description": "Acme coding standards"
    }
  ],

  "agent_overrides": {
    "_defaults": {
      "skills": ["acme-deploy"],
      "mcp_servers": ["acme-db"],
      "rules": ["acme-code-style"]
    }
  }
}

Commit this to your repo, share the install link, and your entire team has a consistent AI agent setup in seconds.

Example and reference

We've published a working example repository you can fork or use as a starting point. It includes a complete automatic.json with skills, MCP servers, rules, and agent overrides.

For the full specification — including collections, monorepo support, and conflict resolution — see the Remote Sources documentation.

Remote Sources turn your repository into the single source of truth for how AI agents work with your codebase. No more scattered configs, no more onboarding friction — just push to git and everyone stays in sync.