Project-Local Customization

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.

Project-local customization lets a team add its own AIWG rules, skills, agents, frameworks, and provider selectors inside the project repo. Use it when one project needs local workflow guidance without forking AIWG or publishing a shared package.

Status: Shipped in 2026.5.x. The `.aiwg/{extensions,addons,frameworks}/<name>/` content layout

superseded the original single-directory `.aiwg/.project/` proposal (#750 → epic #1033).

`.aiwg/plugins/<name>/` remains supported for marketplace delivery wrappers.

Canonical docs

The authoritative documentation now lives under `docs/customization/`:

Doc	What it covers
Quickstart	Author your first project-local bundle
Lifecycle reference	Discovery, deploy, conflict resolution, doctor, remove, promote, activity log
Project quickrefs	Always-visible project orientation, precedence, generation, and provider deployment
Type disambiguation	Which bundle type to author
Customization README	Path A (project-local) / Path B (fork) / Path C (corpus)
Troubleshooting	Common failures and fixes
From-fork migration	Move existing fork-based customizations to project-local

Quick orientation

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

The load-bearing invariant: a project-local bundle uses the same layout as its upstream form, so the agent-owned promote operation can perform a hash-verified copy without a format migration (ADR #1038).