Bring your own agent skills — InfraDots now speaks the Agent Plugins standard

Reviewer guidance solved one half of teaching an agent your team's standards: the one-liners. "Tag production with a cost-center." "Use for_each, not count." Short rules, authored in the product, remembered forever.

But plenty of what a team knows doesn't fit on one line. The checklist you run through before touching prod networking. The step-by-step for adopting an internal module. The three exceptions to your IAM boundary policy and the reasoning behind each. That's a document, not a rule — and it already lives somewhere in a repo, reviewed like code.

Now you can hand it to the agent.

What's new

InfraDots is a conformant client for Agent Plugins 1.0.0, the open, vendor-neutral format for packaging agent skills. A plugin is just a directory in a git repository:

tf-standards/
├── plugin.json
└── skills/
    ├── prod-networking/
    │   ├── SKILL.md
    │   └── references/runbook.md
    └── module-adoption/
        └── SKILL.md

plugin.json names the package. Each SKILL.md carries a name, a description of when to use it, and the instructions themselves. Point InfraDots at the repository and every valid skill inside becomes available to your review and implement agents.

It doesn't flood the agent's context

A fifty-skill library would be useless if every review had to read all fifty. It doesn't. Skills load in stages:

1. Every run sees each skill's name and one-line description — about a sentence apiece.
2. When the agent judges a skill relevant to the change in front of it, it opens the full instructions.
3. If those instructions point at a reference file, it reads that too.

So the cost of installing a large library is the index, and you only pay for the skills a given change actually needs. That's why the description field matters more than it looks — it's what the agent uses to decide.

Why an open standard, and not our own format

• Your skills aren't locked to us. Agent Plugins is a shared spec. The same package you install here works in any other conformant client, and a plugin someone already wrote for a different tool works here unchanged.
• They're version-controlled, because they're just files. Skills live in your repo, get reviewed in a pull request, and can be pinned to a tag or a commit SHA. Rolling one back is a git operation.
• Broken parts stay broken in isolation. If one skill has a malformed header, that skill is skipped and reported — the rest of the package still loads. You'll see exactly what was skipped and why.

Skills only — and nothing in a package is ever executed

Two limits, on purpose:

The spec defines two component types, skills and MCP servers, and explicitly allows a client to support only skills. That's what we've done: an mcp.json in your package is ignored, not an error.

And InfraDots reads a plugin, never runs it. If a skill ships a scripts/ directory, those files are text the agent can read like any other reference — they are never executed in our infrastructure.

Skills never override your guardrails

Like reviewer guidance, skills are advisory. They shape what the agent flags, what it lets pass, and the conventions it writes code to. They cannot override InfraDots' destructive-change or security checks, and the agent is explicitly instructed to ignore and report anything in a skill that tries to change its role, disable a check, or send data somewhere.

Worth knowing, since a plugin comes from a repository: whoever can merge to that repository can influence how your agent reviews. Pin source_ref to a tag or a commit SHA if you want a human in the loop on every change.

Guidance or a plugin?

They compose. Most teams will want both.

How to use it

The API is live now; a management screen in the UI is coming next. Install a plugin by pointing at the repository:

curl -X POST https://app.infradots.com/api/agents/$ORG/plugins/ \
  -H "Authorization: Bearer $IDP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "source_repo": "https://github.com/acme/tf-standards",
        "source_ref": "v1.2.0",
        "source_path": ""
      }'

The response tells you what was found — the package name and version, the skill index, and any diagnostics for parts that were skipped. From there:

• GET /api/agents/$ORG/plugins/ — everything installed, with status
• POST /api/agents/$ORG/plugins/$ID/sync/ — re-read the repository after you push new skills or move the ref
• PATCH /api/agents/$ORG/plugins/$ID/ — repoint it, or set enabled: false to park it without uninstalling

Installed skills reach your review and implement agents on their next run. No flag to flip.