Standalone Plugin Repository

Prompt-first procedure: Describe the outcome you want in your agent conversation. The agent should select and load the appropriate AIWG assets, explain material changes, request any needed approval, and report verification evidence. Exact commands and flags appear only in the CLI reference.

Use this workflow when a team or community repository owns an AIWG marketplace wrapper independently of the AIWG source tree.

Scaffold

Use AIWG to complete this documented outcome: Scaffold
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

The wrapper lives at `.aiwg/plugins/team-tools/`. Its `manifest.json` declares `type: plugin` and points to a byte-preserved addon, extension, or framework under `pluginConfig.payloadPath`. Complete the payload manifest before packaging.

Validate and package

Use AIWG to complete this documented outcome: Validate and package
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

An explicit source is also supported, but it must resolve inside the current repository:

Use AIWG to complete this documented outcome: An explicit source is also supported, but it must resolve inside the current repository
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

The packager applies the canonical bundle schema recursively to the wrapper and payload, then validates wrapper identity, payload type/path agreement, symlink containment, provider selection, and output collisions. It emits deterministic `.tar.gz` archives with provider-native metadata. Payload bytes are not rewritten.

Install smoke

Before publication, exercise the same Git-native install path consumers use. Choose project-local or global state explicitly; both update their associated package registry and marketplace/Fortemi indices.

Use AIWG to complete this documented outcome: Before publication, exercise the same Git-native install path consumers use. Choose project-local or global state explicitly; both update their associated package registry and marketplace/Fortemi indices.
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

See Git-Native Package Exchange for publisher signatures, trust policy, catalogs, portable export/import, mirrors, recovery, and key rotation.

The provider-native archive smoke remains useful as a second packaging gate:

Extract each archive into a disposable repository before publication:

fixture="$(mktemp -d)"
mkdir -p "$fixture/claude/.git" "$fixture/claude/.claude/plugins"
tar -xzf dist/plugins/team-tools-1.0.0-claude.tar.gz -C "$fixture/claude/.claude/plugins"
test -f "$fixture/claude/.claude/plugins/team-tools/.claude-plugin/plugin.json"

mkdir -p "$fixture/codex/.git" "$fixture/codex/.codex/plugins"
tar -xzf dist/plugins/team-tools-1.0.0-codex.tar.gz -C "$fixture/codex/.codex/plugins"
test -f "$fixture/codex/.codex/plugins/team-tools/.codex-plugin/plugin.json"
test -f "$fixture/codex/.codex/plugins/team-tools/marketplace.json"

Then use the provider's local plugin installation surface from that fixture. The integration suite installs into these provider-native repository paths, validates both manifests with the canonical loader, and compares payload bytes.

Repository and release policy

• Keep wrapper and payload manifests at the same intentional release version.
• Record the original payload repository and commit in release notes.
• Include a license selected by the repository owner; AIWG does not choose one.
• Tag releases with the repository's declared version and attach both provider

archives plus checksums.

• Configure GitHub/Gitea or other remotes explicitly; the packager never pushes

or publishes.

• Provider marketplace submission and review remain provider-owned steps.

Use the agent’s capability search or steward when returning to this workflow.