UAIX.org and Agent Skills Integration Report

Full report

On this page

Executive summary

This report focuses strictly on UAIX.org and Agent Skills. It does not analyze or rely on AUiX, which is unrelated to UAIX.org. UAIX currently positions UAI-1 as the public, portable exchange and evidence layer for AI-to-AI work, with published schemas, a registry, examples, a validator, an API surface, an Adoption Kit, a Conformance Pack, AI Memory, Project Handoff, implementation tracks, and a public roadmap. The live catalog currently identifies UAI-1 as the current release, with uai_version 1.0, release date 2026-04-22, and counts of 6 schemas, 6 registry entries, 6 examples, 2 transport bindings, 5 trust channels, 4 conformance levels, and 11 error codes.

The strongest integration model is layered, not overlapping. Agent Skills should supply the reusable operating procedure: discovery, activation, instructions, bundled scripts, references, and evaluations. UAIX / UAI-1 should supply the portable record, the validator-backed evidence, the support-boundary language, and the handoff artifacts that survive beyond one agent session or runtime. UAIX itself explicitly says it is the public evidence and handoff layer, not the runtime, and its roadmap warns not to describe UAIX as an agent runtime, scheduler, SDK, CLI, official adapter set, or certification body.

That positioning is also consistent with Agent Skills. The Agent Skills format defines a skill as a folder containing SKILL.md plus optional scripts/, references/, and assets/; agents discover only names and descriptions first, activate by loading the full SKILL.md, and then read scripts or references only as needed. Client guidance also recommends scanning cross-client paths such as .agents/skills/, activating skills model-first or via a dedicated tool, preserving active skill content during context compaction, and gating project-level skills behind trust checks when a repository may be untrusted.

The most rigorous recommendation is therefore for UAIX.org to publish a reference UAIX Agent Skill bundle that teaches skills-compatible agents how to: discover the current UAIX surface from the live catalog and discovery routes; resolve the correct UAI-1 profile, schema, registry entry, example, and field registry; create a candidate UAI-1 packet; validate it via the public validator route; package the result into an Adoption Kit–style first-proof packet or a Conformance Pack–style release packet; and then promote only reviewed facts into AI Memory and Project Handoff. That recommendation is not speculative hand-waving: UAIX’s own roadmap already names “SKILL.md folders” as part of the capability-package sidecar space it wants to evaluate as optional UAI evidence mappings, while explicitly stating that such work is not current package-profile support, authorization, adapter support, SDK support, CLI support, certification, endorsement, or a conformance claim.

The integration should therefore be marketed with a short, accurate sentence:

Agent Skills package UAIX procedures; UAI-1 records UAIX evidence.

That sentence matches the authoritative boundaries on both sites and avoids the two main failure modes: first, confusing UAIX with a runtime; second, confusing a passing validator result with certification or blanket ecosystem support. UAIX repeatedly states that a validator result is evidence for the reviewed packet and named scope, not a certification surface or broad support claim.

Source basis and analytical fit

The authoritative UAIX pages relevant to this integration are the UAI-1 specification, Schemas, Registry, Examples, Validator, API Reference, Adoption Kit, Conformance Pack, AI Memory, Project Handoff, Implementations, Roadmap, and the Agentic Harness guide. The API Reference is especially important, because UAIX says implementers should start from the live catalog and discovery routes and use the live OpenAPI export and starter requests instead of reverse-engineering the site or relying on stale notes.

From the UAI-1 specification and supporting records, the current published UAI-1 profile family is:

UAIX also makes the envelope model explicit. The field registry says the stable root order is uai_version, profile, message_id, source, target, conversation, delivery, trust, body, provenance, integrity, and extensions; the schema page explains that the envelope keeps identity, workflow state, trust posture, auditability, provenance, integrity, and extension metadata explicit across profiles.

The public machine surface is unusually mature for a standards site. The API Reference enumerates discovery GET routes for catalog, discovery, schemas, registry, field registry, examples, transport bindings, trust channels, error registry, conformance levels, roadmap, OpenAPI, adoption kit, and conformance pack; it also identifies execution POST routes for validation and mock exchange. The same page gives starter call patterns in curl, PowerShell, Python, and TypeScript, including a Python flow that fetches the adoption kit, catalog, example packet, validator result, and mock exchange response without depending on a published SDK.

UAIX’s implementation and roadmap material strongly constrain how the integration should be worded. The current public implementation scope is intentionally narrow: the published implementation tracks are WordPress Publication Track and .NET Bridge Track. UAIX treats only a named implementation-track record plus release-trail entry as a public support claim; validated packets and release-ready packets are necessary evidence, but not the same thing as public support. The roadmap further says UAIX is not an agent runtime, scheduler, tool bus, hosted memory platform, official adapter set, SDK, CLI, or certification program today.

Agent Skills fit cleanly into that boundary because they are a procedure format, not a runtime claim. The skills specification requires YAML frontmatter and Markdown body in SKILL.md; name and description are required, license, compatibility, metadata, and allowed-tools are optional; and the description should say both what the skill does and when to use it. The description field is capped at 1024 characters, the name at 64 characters, and the skill directory can optionally contain scripts/, references/, and assets/.

The conceptual responsibility split is therefore straightforward:

That split is not merely elegant. It is directly aligned with the most conservative reading of both standards, which matters because the roadmap explicitly warns against widening support language before the relevant public evidence exists.

Data flow and reference architecture

The concrete integration should follow a discover → activate → resolve → validate → package → hand off pattern. The first three steps come from Agent Skills’ discovery and progressive-disclosure model; the latter three come from UAIX’s proof path, validator, Adoption Kit, Conformance Pack, AI Memory, and Project Handoff guidance. Agent Skills says discover names and descriptions first, activate the full skill only on demand, and load bundled resources only as needed. UAIX says the proof path is profile → schema/example/registry → validator result → implementation or handoff record, and both the Adoption Kit and the Conformance Pack repeat that same order.

The reference sequence below is the cleanest end-to-end architecture for a UAIX Agent Skill.

sequenceDiagram
    autonumber
    participant User
    participant Runtime as Skills-compatible runtime
    participant Skill as UAIX Agent Skill
    participant UAIX as UAIX public routes
    participant Memory as AI Memory / Project Handoff

    User->>Runtime: Ask for UAIX/UAI-1 work
    Runtime->>Runtime: Discover .agents/skills and load name+description
    Runtime->>Skill: Activate SKILL.md
    Skill->>UAIX: GET /wp-json/uaix/v1/catalog
    Skill->>UAIX: GET /wp-json/uaix/v1/discovery
    Skill->>UAIX: GET schema/registry/example for selected profile
    Skill->>Runtime: Assemble candidate UAI-1 message
    Skill->>UAIX: POST /wp-json/uaix/v1/validate
    UAIX-->>Skill: uai.conformance.result.v1 or validation result
    opt first-proof or response inspection
        Skill->>UAIX: GET /wp-json/uaix/v1/adoption-kit
        Skill->>UAIX: POST /wp-json/uaix/v1/mock-exchange
    end
    opt broader release evidence
        Skill->>UAIX: GET /wp-json/uaix/v1/conformance-pack
    end
    Skill->>Memory: Write reviewed facts only
    Memory-->>Runtime: Updated AGENTS.md / readme.human / .uai / AI Memory

A second way to see the same flow is as a data-contract ladder:

The most important control is what does not leave the harness. UAIX’s harness guide says planning, tool calls, retries, approvals, traces, hidden prompts, and raw logs belong in the harness or cold memory; only reviewed, redacted, validator-ready evidence, eval summaries, adoption signals, and project-memory handoff material should survive as public or durable records. AI Memory and Project Handoff make the same point in a file-based form: agents should read front-door files first, load only the needed files, and treat old chat, LLM wiki material, dropped files, and generated summaries as background until reviewed and promoted.

Proposed UAIX Agent Skill bundle

The cleanest bundle is a project-installable reference skill rooted at .agents/skills/uaix-uai-1/, because .agents/skills/ is the cross-client convention most Agent Skills clients are encouraged to scan. That path also makes it easy for UAIX users to add the bundle to a repo without implying that UAIX itself is a runtime or package manager.

.agents/
  skills/
    uaix-uai-1/
      SKILL.md
      LICENSE.txt
      references/
        uaix-overview.md
        uaix-routes.md
        uai-profiles.md
        support-boundaries.md
        ai-memory-and-handoff.md
      scripts/
        fetch_catalog.py
        validate_uai.py
        package_first_proof.py
      assets/
        starter-message.template.json
        validate-request.template.json
        mock-exchange-request.template.json
      evals/
        evals.json
        trigger-queries.json

The frontmatter below follows the Agent Skills requirements for name, description, optional license, optional compatibility, and optional metadata. The description is intentionally explicit so that a model sees both what the skill does and when to use it; that matches the Agent Skills triggering guidance.

---
name: uaix-uai-1
description: Use this skill when the user asks about UAIX.org, UAI-1, UAIX validator-backed AI-to-AI records, the UAIX Adoption Kit, the UAIX Conformance Pack, AI Memory, or Project Handoff. Resolve the live UAIX catalog and discovery routes, select the correct UAI-1 profile, assemble a candidate message, validate it, package first-proof or release evidence, and write back only reviewed facts. Do not use this skill for AUiX.
license: See LICENSE.txt
compatibility: Requires a skills-compatible runtime, network access to uaix.org public routes, and either Python 3.11+ or an equivalent HTTP-capable environment.
metadata:
  canonical_site: uaix.org
  standard_family: UAI
  current_release: UAI-1
  preferred_install_path: .agents/skills/uaix-uai-1
  public_citation_routes:
    - /en-us/specification/uai-1/
    - /en-us/tools/validator/
    - /en-us/tools/api-reference/
    - /en-us/tools/adoption-kit/
    - /en-us/tools/conformance-pack/
    - /en-us/ai-memory/
    - /en-us/specification/project-handoff/
---

The skill body should be concise. Agent Skills recommends keeping the main SKILL.md compact and moving detail into references/. In practice, the body should tell the model to: discover the live UAIX routes from catalog/discovery first; do not rely on cached route notes; resolve the profile against Registry, Schemas, Examples, and Field Registry; validate before claiming support; use Adoption Kit for first-proof onboarding; use Conformance Pack for broader release evidence; write only reviewed facts into AI Memory and Project Handoff; and never market UAIX as a runtime, SDK, CLI, certification program, or official adapter set.

The scripts should follow Agent Skills’ script guidance: be non-interactive, accept input by flags or stdin, and prefer structured output such as JSON.

# scripts/fetch_catalog.py
# Pseudocode: resolve live UAIX machine surface before route-specific work.

import json
import urllib.request

CATALOG_URL = "https://uaix.org/wp-json/uaix/v1/catalog"
DISCOVERY_URL = "https://uaix.org/wp-json/uaix/v1/discovery"

def get_json(url: str) -> dict:
    with urllib.request.urlopen(url) as resp:
        return json.load(resp)

def main():
    catalog = get_json(CATALOG_URL)
    discovery = get_json(DISCOVERY_URL)
    output = {
        "catalog_release": catalog.get("current_release"),
        "uai_version": catalog.get("uai_version"),
        "release_date": catalog.get("release_date"),
        "routes": catalog.get("routes", {}),
        "well_known": catalog.get("well_known", {}),
        "discovery": discovery,
    }
    print(json.dumps(output, indent=2))

if __name__ == "__main__":
    main()

That script shape directly follows UAIX’s API Reference and starter snippets, which tell implementers to start from catalog and discovery and then move into route-specific work.

# scripts/validate_uai.py
# Pseudocode: validate a candidate packet and return a structured result.

import json
import sys
import urllib.request

VALIDATE_URL = "https://uaix.org/wp-json/uaix/v1/validate"

def main(path_to_message_json: str):
    with open(path_to_message_json, "r", encoding="utf-8") as f:
        message = json.load(f)

    payload = {
        "message": message,
        "format": "result"
    }

    req = urllib.request.Request(
        VALIDATE_URL,
        data=json.dumps(payload).encode("utf-8"),
        headers={"Content-Type": "application/json"},
        method="POST",
    )

    with urllib.request.urlopen(req) as resp:
        result = json.load(resp)

    print(json.dumps(result, indent=2))

if __name__ == "__main__":
    main(sys.argv[1])

That validation posture matches both the API Reference and the Validator page: the validate route is a public JSON POST surface for checking candidate messages, and a passing result should be preserved together with the exact checked packet and the artifact URLs used during review.

# scripts/package_first_proof.py
# Pseudocode: assemble a minimal reusable proof packet from UAIX public sources.

import json
import urllib.request
from pathlib import Path

ADOPTION_KIT_URL = "https://uaix.org/wp-json/uaix/v1/adoption-kit"
CONFORMANCE_PACK_URL = "https://uaix.org/wp-json/uaix/v1/conformance-pack"

def get_json(url: str) -> dict:
    with urllib.request.urlopen(url) as resp:
        return json.load(resp)

def main(output_dir: str, mode: str = "first-proof"):
    out = Path(output_dir)
    out.mkdir(parents=True, exist_ok=True)

    adoption = get_json(ADOPTION_KIT_URL)
    with open(out / "uai-adoption-kit.json", "w", encoding="utf-8") as f:
        json.dump(adoption, f, indent=2)

    if mode == "release":
        conformance = get_json(CONFORMANCE_PACK_URL)
        with open(out / "uai-conformance-pack.json", "w", encoding="utf-8") as f:
            json.dump(conformance, f, indent=2)

    manifest = {
        "mode": mode,
        "required_companions": [
            "starter-message.json",
            "validate-request.json",
            "uai-conformance-record.json",
            "implementation-evidence-checklist.json"
        ],
        "rule": "Keep checked packet, validator result, route URLs, implementation scope, and non-claim boundary together."
    }

    with open(out / "proof-manifest.json", "w", encoding="utf-8") as f:
        json.dump(manifest, f, indent=2)

if __name__ == "__main__":
    main("out")

That packaging logic reflects the official first-proof and release-packet guidance. The Adoption Kit is the shortest onboarding packet and currently ships starter message, validation request, mock exchange request, conformance record, implementation evidence checklist, conformance fixture pack, and bridge evidence pack metadata. The Conformance Pack is the broader machine-readable release packet for launch review and support claims.

The message templates below are not alternate standards; they are concise synthesis templates derived from the official schemas, registry records, and example fixtures for the six published profiles.

Generic envelope skeleton:

{
  "uai_version": "1.0",
  "profile": "<profile-id>",
  "message_id": "<stable-message-id>",
  "source": {
    "type": "<agent|service|message|public-record>",
    "id": "<sender-id>",
    "label": "<sender-label>",
    "uri": "<sender-uri>",
    "did": "<sender-did-or-empty>",
    "role": "<sender-role>",
    "implementation": "<implementation-id>"
  },
  "target": {
    "type": "<target-type>",
    "id": "<target-id>",
    "label": "<target-label>",
    "uri": "<target-uri>",
    "did": "<target-did-or-empty>",
    "role": "<target-role>",
    "implementation": "<target-implementation>"
  },
  "conversation": {
    "conversation_id": "<conversation-id>",
    "turn_id": "<turn-id>",
    "parent_message_id": "<optional-parent>",
    "traceparent": "<optional-traceparent>",
    "sequence": 1
  },
  "delivery": {
    "mode": "<sync|async|event>",
    "priority": "<routine|interactive>",
    "expires_at": "<ISO-8601>",
    "reply_requested": true,
    "ack_required": false,
    "task_ref": "<optional-task-ref>"
  },
  "trust": {
    "channel": "<credentialed|signed-envelope|...>",
    "auth_scheme": "<jws|did+vc|...>",
    "principal": "<principal>",
    "credential_ref": "<optional-credential-ref>",
    "signature_ref": "<optional-signature-ref>",
    "replay_window_id": "<optional-replay-window-id>"
  },
  "body": {},
  "provenance": {
    "trace_id": "<trace-id>",
    "parent_trace_id": "<optional-parent-trace>",
    "issued_at": "<ISO-8601>",
    "log_ref": "<optional-log-ref>",
    "agent_id": "<agent-id>",
    "model_id": "<model-id>",
    "confidence": 0.99,
    "lineage": []
  },
  "integrity": {
    "version": 2,
    "algorithm": "sha256",
    "canonicalization": "jcs",
    "checksum": "<sha256:...>"
  },
  "extensions": []
}

Common body templates:

// uai.intent.request.v1
{
  "intent": "resolve-profile",
  "subject": "uai.task.status.v1",
  "requested_profile": "uai.task.status.v1",
  "parameters": {
    "include_schema": true,
    "include_example": true,
    "include_field_registry": true
  },
  "constraints": [
    "public-record-only",
    "trace-linked",
    "validator-ready"
  ],
  "response_profile": "uai.intent.response.v1"
}

// uai.intent.response.v1
{
  "status": "accepted",
  "subject": "uai.task.status.v1",
  "request_message_id": "<message-id-of-request>",
  "result": {
    "task_id": "<task-id>",
    "status_profile": "uai.task.status.v1",
    "status_url": "https://uaix.org/wp-json/uaix/v1/examples/uai.task.status.v1",
    "field_registry_url": "https://uaix.org/wp-json/uaix/v1/field-registry"
  },
  "notices": [
    "async-task-started",
    "follow-status-profile"
  ],
  "task_ref": "<task-id>"
}

// uai.task.status.v1
{
  "task_id": "<task-id>",
  "state": "working",
  "subject": "uai.task.status.v1",
  "progress": 60,
  "status_message": "Field registry resolved and schema packet assembled; release evidence is being prepared.",
  "result_profile": "uai.intent.response.v1",
  "result_ref": "https://uaix.org/wp-json/uaix/v1/examples/uai.intent.response.v1",
  "blocking_reasons": [],
  "updated_fields": [
    "body.progress",
    "body.status_message",
    "body.result_ref"
  ]
}

// uai.error.v1
{
  "type": "https://uaix.org/problems/unknown-profile",
  "title": "Unknown public profile",
  "detail": "The declared profile is not present in the published UAI-1 registry.",
  "status": 404,
  "code": "unknown_profile",
  "retryable": false,
  "instance": "https://uaix.org/errors/<message-id>",
  "errors": [
    {
      "path": "$.profile",
      "code": "unknown_profile",
      "message": "Use a published UAI-1 profile from the registry."
    }
  ],
  "next_step": "Resolve the current registry entry before retrying validation."
}

// uai.conformance.result.v1
{
  "status": "pass",
  "checked_profile": "uai.intent.request.v1",
  "issues": [],
  "summary": {
    "error_count": 0,
    "warning_count": 0,
    "checked_at": "<ISO-8601>"
  },
  "artifacts": {
    "catalog_url": "https://uaix.org/wp-json/uaix/v1/catalog",
    "schema_url": "https://uaix.org/wp-json/uaix/v1/schemas/uai.intent.request.v1",
    "registry_url": "https://uaix.org/wp-json/uaix/v1/registry/uai.intent.request.v1",
    "example_url": "https://uaix.org/wp-json/uaix/v1/examples/uai.intent.request.v1",
    "field_registry_url": "https://uaix.org/wp-json/uaix/v1/field-registry",
    "transport_bindings_url": "https://uaix.org/wp-json/uaix/v1/transport-bindings",
    "trust_channels_url": "https://uaix.org/wp-json/uaix/v1/trust-channels",
    "conformance_levels_url": "https://uaix.org/wp-json/uaix/v1/conformance-levels",
    "error_registry_url": "https://uaix.org/wp-json/uaix/v1/error-registry",
    "validate_url": "https://uaix.org/wp-json/uaix/v1/validate"
  },
  "target_message_ref": "<checked-message-id>"
}

UAIX.org copy, rollout plan, and evaluation

The best UAIX.org integration page would be a human-citation route such as /en-us/integrations/agent-skills/, because UAIX’s API Reference distinguishes between machine routes and human citation routes, and says public claims should cite human pages when prose, boundaries, and next steps matter.

Recommended page copy:

# Using Agent Skills with UAIX

Agent Skills package reusable agent procedures.
UAI-1 records the portable public evidence.

Use the UAIX Agent Skill when a skills-compatible agent needs to work with UAIX.org, UAI-1 records, validator-backed exchange evidence, the Adoption Kit, the Conformance Pack, AI Memory, or Project Handoff.

## What Agent Skills do
Agent Skills help compatible agents discover, activate, and follow reusable procedures through a SKILL.md file plus optional scripts, references, and assets.

## What UAIX does
UAIX publishes the UAI-1 public exchange contract, schemas, registry, examples, validator, machine-readable API routes, first-proof Adoption Kit, reusable Conformance Pack, AI Memory bundles, and Project Handoff guidance.

## How they work together
A skills-compatible agent can:
1. discover the UAIX Agent Skill,
2. activate it for UAIX/UAI-1 tasks,
3. resolve the live UAIX catalog and discovery routes,
4. create a candidate UAI-1 packet,
5. validate it,
6. package first-proof or release evidence,
7. write back only reviewed facts into AI Memory or Project Handoff.

## What not to claim
Using the UAIX Agent Skill does not make UAIX an agent runtime, certification authority, SDK, CLI, or official adapter provider.
A passing validator result is evidence for the reviewed packet and named scope, not blanket ecosystem support.

## Start here
Read the UAI-1 specification, open the Validator, inspect the API Reference, fetch the Adoption Kit, and use the Conformance Pack when release evidence needs to travel.

That copy is faithful to the current UAIX posture because it keeps the integration procedural and evidence-oriented. It does not turn UAIX into a runtime claim, and it reflects the official support boundaries around validator evidence, public implementation lanes, and non-runtime positioning.

Recommended short support-claim language:

UAIX publishes a reference Agent Skill bundle for skills-compatible agents. The bundle helps agents create, validate, package, and hand off UAI-1 evidence using UAIX’s public specification, validator, API routes, Adoption Kit, Conformance Pack, AI Memory, and Project Handoff. It does not make UAIX an agent runtime, SDK, CLI, certification program, or official adapter set.

That sentence is intentionally narrow because UAIX’s roadmap says broader capability-package sidecars and mapping annexes remain research-track evidence-mapping ideas until public fixtures, ownership, and release evidence exist.

A phased implementation plan should follow the same evidence ladder UAIX already uses:

This rollout order mirrors both UAIX’s evidence-promotion gates and Agent Skills’ advice to ground a skill in real artifacts, ship a first version, and refine it through structured evaluation.

A timeline visualization can stay equally conservative:

gantt
    title UAIX Agent Skill rollout
    dateFormat  YYYY-MM-DD
    section Foundation
    Integration page and bundle skeleton     :a1, 2026-05-07, 7d
    section Skill release
    SKILL.md, references, scripts            :a2, after a1, 10d
    section Proof automation
    Validator and first-proof packaging      :a3, after a2, 10d
    section Handoff
    AI Memory and Project Handoff mapping    :a4, after a3, 7d
    section Evaluation
    Evals and trigger tests                  :a5, after a4, 10d
    section Release evidence
    Public release note and optional kit ref :a6, after a5, 7d

The evaluation format should follow Agent Skills’ evals/evals.json pattern. Agent Skills recommends each test case include a realistic prompt, an expected output, and optional files, and stresses comparing “with skill” vs “without skill” performance.

{
  "skill_name": "uaix-uai-1",
  "evals": [
    {
      "id": "uaix-not-auix",
      "prompt": "Create a report on UAIX.org and Agent Skills integration. Do not confuse UAIX with AUiX.",
      "expected_output": "Explains UAIX.org as Universal Artificial Intelligence Exchange / UAI-1, stays strictly scoped to UAIX.org, and explicitly avoids AUiX."
    },
    {
      "id": "resolve-live-routes",
      "prompt": "Resolve the current UAIX catalog and discovery routes, then list the validator, adoption-kit, and conformance-pack endpoints.",
      "expected_output": "Starts from catalog/discovery rather than guessing routes, and names the validate, adoption-kit, and conformance-pack endpoints."
    },
    {
      "id": "validate-request-profile",
      "prompt": "Use the official UAIX request profile to assemble a validator-ready UAI-1 message and prepare a validate request.",
      "expected_output": "Creates a request packet using uai.intent.request.v1 and a validate wrapper suitable for POST /wp-json/uaix/v1/validate."
    },
    {
      "id": "first-proof-packet",
      "prompt": "Package a first-proof UAIX evidence packet from the Adoption Kit, validator result, and mock-exchange request.",
      "expected_output": "Produces a minimal packet containing starter message, validation request, conformance result, and mock-exchange request, with supporting route references."
    },
    {
      "id": "handoff-writeback",
      "prompt": "Write back only the accepted facts from a validated UAIX run into Project Handoff and AI Memory.",
      "expected_output": "Updates AGENTS.md/readme.human/.uai or AI Memory guidance with accepted facts, checks run, blockers, and next actions, while excluding raw traces and unsupported claims."
    }
  ]
}

A companion trigger test file is equally important because the integration is vulnerable to accidental activation on the wrong term:

[
  { "query": "Help me integrate UAIX.org with Agent Skills", "should_trigger": true },
  { "query": "Create a validator-backed UAI-1 packet", "should_trigger": true },
  { "query": "Package a UAIX conformance record for handoff", "should_trigger": true },
  { "query": "Tell me about AUiX funding", "should_trigger": false },
  { "query": "General MCP runtime design", "should_trigger": false },
  { "query": "Build a CLI for my local scripts", "should_trigger": false }
]

Risks, controls, assumptions, and conclusion

The main risks are not technical difficulty. They are scope confusion, support overclaiming, repository trust issues, and evidence contamination.

The principal assumptions behind this report are modest and explicit. The target agent runtimes are unspecified, so the design assumes only a skills-compatible runtime that can scan .agents/skills/, read files, and make HTTP requests. That is consistent with Agent Skills, which does not mandate one client product or one discovery path and notes that supported script languages depend on the runtime. Programming language choice is therefore left open, although UAIX’s own starter snippets make Python, shell, PowerShell, and TypeScript practical first choices. Hosting constraints are also unspecified, so the recommended bundle is a plain folder/ZIP distribution rather than a hosted marketplace integration. License choice is similarly open because Agent Skills makes it optional.

There are also a few limitations. I did not rely on unpublished internals of the UAIX JSON bundles where the site’s human pages already expose the authoritative onboarding and proof workflow. The exact JSON field shapes of the full Adoption Kit and full Conformance Pack are therefore represented here through the human-documented manifest and packet descriptions rather than exhaustive reverse-engineering of every top-level key. That is appropriate, because UAIX itself says the human citation pages are the routes to cite when prose boundaries and next steps matter, while machine routes are the automation surface.

The final recommendation is clear: UAIX.org should publish a reference Agent Skill bundle, not claim an Agent Skills runtime. The bundle should teach skills-compatible agents how to resolve the live UAIX surface, assemble and validate UAI-1 packets, package first-proof and release evidence, and write only reviewed facts into AI Memory and Project Handoff. That is the integration model that is maximally useful, minimally overstated, and most faithful to the current official record of both UAIX.org and Agent Skills.