How ACX Pluginization Solves Multi‑Agent Harness Asset Management Challenges

Commercial clients of the Harness platform face a systemic governance problem: dozens of product lines, multiple agents (Claude Code, Codex, etc.), and many Mac devices cause Rules, Skills, Hooks, MCP configurations and prompt‑template assets to be scattered, leading to configuration drift, rule conflicts and hidden technical debt.

Key Terminology

NAD : abbreviation for Native Ad client.

ACX : the name of the AI Coding Extension repository; ACX assets and commercial client Harness assets are equivalent in this context.

Challenges

Multi‑product line & multi‑end : Android, iOS, HarmonyOS, SDKs, each with its own code, logging, billing and component conventions.

Mixed global and platform‑specific specifications : common code standards coexist with Android Activity, iOS page or HarmonyOS capability specs.

Business knowledge & engineering process : product shapes, ad styles, MRD interpretation, test instructions together with Git/CR/release pipelines.

Frequent rule updates : daily or high‑frequency sync required.

Varying applicability : some rules are global, others apply only to specific files, platforms or skills.

Multi‑Agent Coexistence

Claude Code and Codex interpret assets differently:

Claude Code uses CLAUDE.md and .claude/rules/*.md as model‑behaviour context, and .claude/skills/<skill>/SKILL.md as on‑demand capability packages.

Codex reads AGENTS.md as the instruction entry point, and ~/.codex/rules/*.rules as command‑execution policies (Starlark scripts).

These differences mean that ACX must keep separate representations for each host while ensuring a single source of truth.

Local Deployment Requirements

Low‑cost initialization for new machines, agents or profiles.

Idempotent execution: daily auto‑sync must not duplicate configurations.

Migration protection: existing user rules/skills must not be overwritten unintentionally.

Compatibility with multiple host semantics.

Diagnosable and recoverable failures (dirty repo, manifest errors, registration failures, symlink issues).

Evolution of the ACX Deployment Scheme

Stage 1 – Single‑Agent File Synchronization

Initial approach copied files directly into ~/.claude and ~/.claude/skills using sparse‑checkout and cp -rf. Advantages: simple, quick validation, per‑platform selection, significant speed gain with sparse checkout. Problems: only works for Claude, not Codex; users must manually select platforms; copy‑and‑conflict handling becomes costly as assets grow; recovery after partial failures is unstable.

Stage 2 – Scripted Installation & Dynamic Asset Sync

A Bash script install.sh replaced ad‑hoc copying. The script performs a sparse clone, scans rules/*/ and skills/*/, flattens root‑level rules, detects skill name clashes, supports auto‑install, auto‑update and local‑debug flags, and runs automatically on the first daily session. Benefits: deterministic single‑step install, easy addition of new directories, self‑update, gray‑scale control. Remaining issues: still copies assets to user directories, resulting in two copies ( ~/.acx and ~/.claude), and rule/skill loading semantics remain host‑specific.

Stage 3 – Central ~/.acx with Symlinks

Both Claude and Codex now point to a shared ~/.acx directory via symlinks:

~/.claude/skills   --symlink--> ~/.acx/skills
~/.claude/rules    --symlink--> ~/.acx/rules
~/.codex/skills    --symlink--> ~/.acx/skills
~/.codex/AGENTS.md --bridge--> ~/.acx/rules

Advantages: one local copy for all agents, reduced token pollution (sub‑directory rules are excluded by default), unified plugin registration. Drawbacks: still a directory‑based solution, ambiguous boundaries between ACX assets and user‑added assets, and symlinks do not convey plugin identity, version or enable‑state.

Stage 4 – Full ACX Repository Pluginization

The repository itself becomes a native plugin source. Two manifest files are added: .claude-plugin/plugin.json for Claude Code. .codex-plugin/plugin.json for Codex.

Hosts discover the plugin via their marketplace/settings, treating ACX as a single plugin named acx. The local nad‑acx‑init skill now only updates the repository and registers the plugin; it no longer copies files.

Core Benefits After Pluginization

ACX repository is the unique source of truth; local copies are eliminated.

Both Claude and Codex load assets through their native plugin mechanisms, preserving host‑specific semantics.

Clear separation between team‑owned Harness assets and personal user assets.

Loading shifts from directory reuse to plugin‑based discovery, reducing context pollution.

Daily auto‑update now upgrades the plugin source instead of copying files.

Future extensions (new agents, new rule categories) are added by updating the plugin manifest rather than expanding global directories.

Constraints & Best Practices

The plugin source must point to a complete ACX repository; temporary sparse clones are not allowed.

Manifest schemas must match the real validation logic of Claude Code and Codex. nad‑acx‑init only manages ACX‑related configuration and never overwrites user‑defined hooks, permissions, sandbox or environment settings.

Codex keeps the plugin registration immutable during daily auto‑updates to avoid interactive prompts.

Three‑Layer Governance Model

Behavior‑spec layer : CLAUDE.md, AGENTS.md, .claude/rules/*.md, ACX Markdown rules – define how the model thinks and generates code.

Capability‑execution layer : SKILL.md, scripts, references, assets – encapsulate repeatable processes as callable abilities.

Host‑integration layer : plugin manifests, marketplace entries, settings, permissions, hooks – inform the host about asset source, enable‑state, loading boundaries and update paths.

The nad‑acx‑init skill registers the first two layers into the third.

Automation Details

nad‑acx‑auto‑daily‑init

rule triggers nad‑acx‑init on the first session each day, keeping local rules, skills and plugins up‑to‑date. nad‑acx‑report‑active‑rules‑skills rule forces agents to report which rules and skills were actually applied after a task, giving visibility into effectiveness.

Progressive loading: root‑level rules are always loaded; sub‑directory rules/skills are loaded only when their description matches the current context, avoiding token pollution.

Five‑dimension matching (platform, product line, scenario, request type, delivery stage) tags each rule/skill, enabling precise, on‑demand loading during development.

Conclusion

The core of commercial client Harness asset management is not merely copying files but establishing a complete lifecycle—creation, review, release, distribution, update and deprecation—governed by a unified ACX repository. By evolving from single‑file sync to full pluginization, the system achieves deterministic deployment, clear ownership, host‑native loading, and scalable daily synchronization, laying a solid foundation for future AI‑agent engineering.