Agent Integration and Extension

Documentation for BrandBuilder 3.0.1. Official release and exact skill asset.

Agents consume BrandBuilder through explicit local authority. They must distinguish authoring a brand system, implementing a delivered contract, and auditing existing output before changing files.

Installation and recovery

For repository development, use the checked-in skill/ source and its declared dependencies. For a generated consumer kit, begin with enforcement/consumer-contract.json. If BrandBuilder is unavailable, verify the SHA-256 recorded under recovery, extract the exact delivered .skill archive into the declared empty directory, and use its templates. Do not fetch an unspecified latest release.

Agent entry points

SKILL.md describes operating modes and authoritative references. AGENTS.md provides the synchronized ambient form for compatible hosts. A generated kit adds a merge-safe governed block under enforcement/AGENTS.md; human instructions outside its markers remain intact. The machine contract outranks screenshots, legacy stylesheets, and inferred local values.

In Implementation mode, read the consumer contract and IMPLEMENTATION.md, use exact local paths, and run the declared verification commands. In Audit mode, report drift with evidence and do not mutate output unless remediation is requested. In Author mode, change governed sources and templates, then regenerate. Never patch a generated kit to conceal a generator defect.

Capability gaps

When a consumer requirement is reusable but missing from the shared contracts, copy and complete the local capability-gap record. Include a reproducible need, the missing semantic concept, and evidence. Submission upstream requires explicit human authorization. Until adoption, the local record does not modify shared authority.

After an authorized upstream change, update the owning brand system, recipe, or adapter with tests. Bump the correct independent version, regenerate, verify compatibility, publish, and let consumers adopt that exact version deliberately. For WordPress, the generated theme files are rebuildable defaults while posts, navigation, and saved Site Editor styles/templates remain client-owned database state. Inspect wordpress/README.md before an update and preserve a pinned ZIP, checksum, and database backup for rollback.

Extension checklist

1. Identify the authoritative source and the generated outputs it controls.
2. Add failing tests for schema, behavior, negative paths, and cross-surface drift.
3. Make the smallest source or template change that satisfies the contract.
4. Run the owning focused verifier before the complete repository gate.
5. Record version and migration impact without expanding identity authority.
6. Keep generated dist/, site exports, archives, PDFs, and raster output out of source control.

Extensions may add governed shared capability. They may not redraw approved marks, infer affiliation, lower accessibility gates, or create a permanent parallel design system.

Choose a source for the task

The References library carries stable source IDs and offline explanations. For an accessibility obligation, start with the local contract and WCAG 2.1. For a web control, use the pinned adapter plus React labels or the applicable ARIA pattern. For native egui, use its pinned test API and record what the host platform bridge actually exposes. For WordPress, use the pinned adapter and theme starter with native theme structure and Global Styles precedence. Android entries guide host work without claiming a generated Compose adapter. If a source changes edition or moves URL, retain the local ID's meaning and review the citation before changing generated instructions.