Bring Your Own Coding Agent: Itential Builder Skills Now Run in Claude Code, Codex, Copilot & Cursor

When we put Builder Skills in the Anthropic Marketplace, the first question from almost every team was some version of the same thing: does it work in Copilot? Then Cursor. Then Codex.

That question says a lot about how engineering teams actually work. Nobody standardized on one coding agent. The network architect lives in Claude Code. The platform team is licensed on GitHub Copilot. Someone on the automation team switched to Cursor last quarter and is not going back. Asking all of them to change tools so they can follow the same delivery process is a non-starter.

So we stopped asking. As of version 2.0, Builder Skills runs in five harnesses: Claude Code, Codex CLI, GitHub Copilot CLI, GitHub Copilot in VS Code, and Cursor. Same repo. Same 17 skills. Same six-stage lifecycle. Same artifacts at the end.

Standardize the delivery model, not the editor. The harness is where the engineer types. The skills are where the Itential knowledge lives.

This post covers how that works under the hood, how to install it in each harness, what changed in the lifecycle, and the handful of differences worth knowing before you start.

What’s Changed

• Cross-harness support
  Five supported harnesses from a single repository, built on the open Agent Skills convention.
• A sixth stage
  Test is now its own stage, owned by a new qa-agent that also owns As-Built.
• 17 skills
  Eight delivery skills and nine platform skills, including new ones for documentation, JSON Forms, and Itential Gateway 4 to Gateway 5 migration readiness.
• Customization layers
  Every skill now has org, team, and dev override folders that survive plugin updates.

How One Repo Serves Five Harnesses

Every skill follows the open Agent Skills convention: a folder containing a SKILL.md file, which opens with YAML frontmatter holding a name and a description. Every harness we support reads that format.

That description isn’t documentation for humans. It’s the routing signal. When an engineer types “the build is done, let’s test it,” the harness matches the request against skill descriptions and loads the right one. That’s why you can call a skill by name or just describe what you need. We run trigger evaluations against the highest-conflict skills, 20 queries each (10 that should trigger the skill and 10 that shouldn’t), to keep that routing accurate as descriptions evolve.

There is one copy of every skill, in the repo’s skills/ folder. Each harness installs from it through its own small manifest:

We didn’t want copies of every skill drifting apart, so there are no per-harness copies. And every skill is self-contained: the templates, reference projects, spec library, and platform rules it uses are bundled into its own folder, so it works the same in every harness.

AGENTS.md Is What Makes It Portable

The skills carry the domain knowledge. AGENTS.md carries the discipline. It’s bundled into every skill, so the rules travel with the skill into every harness, and it holds the rules that keep an agent from improvising against a live platform:

• A skill router that is a hard gate.
  Before the agent authors a workflow, template, or project payload, it loads the matching skill. Not as a suggestion. As a precondition.
• A pre-flight checklist before every create or save call.
  Check the helper library for a worked example, confirm the exact task name in tasks.json, pull the task schema, and never invent an endpoint, field name, or enum value.
• A repeat-failure circuit breaker.
  The same class of schema error twice in a row means stop, read the actual schema, and ask. No third guess from memory.
• Platform rules learned from live builds.
  Task IDs are hex-only. Adapter tasks need error transitions or jobs hang. Importing over an existing project ID is a destructive full replace, not a merge.

None of that is specific to Claude, or Copilot, or Cursor. It’s specific to the Itential Platform. That’s exactly why it ports.

Install It in Your Harness

Prerequisites are the same everywhere: Itential Platform 6.x for every skill, and Itential Gateway 5 only if you use the iag skill. Pick your harness below. Each path ends in the same place.

Claude Code

Restart Claude Code after install.

1. Check it worked: /plugin lists itential-builder, or type /itential-builder: to see the skills.
2. Run a skill: /itential-builder:spec-agent
3. Update: automatic, or /plugin update itential-builder@itential-builder and restart.

Note the namespace. Claude Code scopes plugin skills under the plugin name, which is why it’s /itential-builder:spec-agent here and /spec-agent in most other harnesses.

Codex CLI

1. Check it worked: in Codex, type /skills. The skills are listed as itential-builder:<skill>.
2. Run a skill: $itential-builder:spec-agent
3. Update:

Codex registers the repo through its own manifest at .agents/plugins/marketplace.json and invokes skills with $, not /.

GitHub Copilot CLI

1. Check it worked: copilot skill list
2. Run a skill: /spec-agent
3. Update: run the same install command with –force.

gh skill needs a recent GitHub CLI. If the subcommand isn’t recognized, upgrade gh first.

GitHub Copilot in VS Code

Open the Command Palette (⇧⌘P on Mac, Ctrl+Shift+P on Windows), run Chat: Install Plugin From Source, and enter itential/builder-skills. Or install from a clone:

Then run Chat: Install Plugin From Source and enter the clone’s path as a file:/// URI (for example, file:///Users/you/builder-skills).

1. Check it worked: in Copilot Chat, type /, or open Configure Skills.
2. Run a skill: /spec-agent
3. Update: VS Code checks for plugin updates every 24 hours when extension auto-update is on. To update now, run Extensions: Check for Extension Updates. If you installed from a clone, git pull.

Cursor

1. Check it worked: in chat, type /.
2. Run a skill: /spec-agent
3. Update: rerun the install command with –force. From a clone, git pull first, then rerun with –force.

At a glance

Natural language works in all five. Describe the task and the harness routes to the right skill.

Your First Delivery, in Any Harness

After install, setup is identical regardless of harness. Create a working folder with a .env holding your platform credentials:

On a local or dev platform, use AUTH_METHOD=password with USERNAME and PASSWORD instead of the client ID and secret. Then start a delivery with spec-agent, using your harness’s invocation from the table above.

Authentication happens once. The first skill that needs the platform, usually explore or solution-arch-agent at feasibility, authenticates and writes the token to .auth.json. Every skill after that reuses it, and on a 401 or 403 it re-authenticates silently from .env instead of stopping to ask. OAuth tokens go in a bearer header. Local /login tokens go in a query parameter. Never commit either file.

Each use case gets its own workspace, and everything the agents know about the delivery lives there:

The workspace is plain files. That’s what makes the harness interchangeable, even mid-delivery.

Because state lives in files and not in a chat session, a delivery can change hands. use-case-memory.md carries a Stage field, and every skill updates it before handing off. When a session resumes, the skill checks that field against the artifacts that actually exist. If they disagree, the files win. One engineer can take a use case from requirements through an approved solution-design.md in Claude Code, and a teammate can pick up the build in Cursor from exactly that point.

Six Stages, Four Agents

Every delivery follows the same path. Each stage produces a named artifact, and nothing moves forward without the engineer’s sign-off.

Why Test Got Its Own Stage

In the original five-stage model, builder-agent built the assets, tested them, and wrote the as-built record. It worked. But it put the same agent in charge of building something and certifying it. We wouldn’t accept that from a human team, so we stopped accepting it from agents.

qa-agent now owns verification, and it works like this:

• Plans from the approved criteria.
  It drafts test-plan.md from the acceptance criteria in customer-spec.md and the criteria-to-test mapping in solution-design.md. Every acceptance criterion gets exactly one test-plan entry.
• Asks for real test data.
  Acceptance tests run real jobs with real side effects: pushing config to a device, opening a ServiceNow ticket, allocating an IP. The agent asks which targets are safe and never invents a device name, ticket number, or IP block.
• Waits for approval.
  Nothing runs live until the engineer approves the plan. Same gate discipline as spec, feasibility, and design.
• Runs static checks first.
  They’re cheap. POST /workflow_engine/workflows/validate (Platform 6.5.2 and later) catches non-hex task IDs, missing required fields, wrong adapter app values, and dangling references. Local jq checks cover what the endpoint doesn’t, like missing error transitions and invalid evaluation operators. It checks warnings, not just isValid.
• Runs acceptance cases against the delivered build.
  Real jobs through Operations Manager, with results checked in each task’s own output, not just the job status.
• Hands failures back.
  On a failed case, it reports the evidence and returns the work to builder-agent. It never edits a workflow itself.
• Writes the record last.
  Once tests pass, it produces as-built.md, backed by the test evidence.

“It works” is a claim. test-report.md is evidence.

Customize Without Forking

Multi-harness teams hit the next problem fast. Everyone wants the skills to follow their conventions: naming standards, security policy, the sandbox they test against. Editing SKILL.md is the wrong answer. Those files are Itential-owned and get overwritten on the next update.

Instead, every skill has a custom/ folder with three layers, read automatically before the skill acts: