Git-native distributions and customization
Agent Workflows is designed to support both a trusted upstream and a healthy ecosystem of customized distributions. In that target model, teams may consume reviewed Upstream Releases unchanged, maintain long-lived forks with explicit provenance and patch histories, and contribute portable improvements back upstream.
“AI reduces the cost of divergence without hiding divergence.”
Customization is encouraged. The responsibility is to keep ownership, provenance, validation, and release claims visible at the layer where each change belongs.
Choose the narrowest customization layer
- Configure the Consumer Repo.Put repository-specific commands, CI, trust, branch, and release policy in the Consumer Repo’s Agent Workflow Configuration Seam.
- Separate personal workflows.Put unrelated personal workflows in separate personal skills or plugins. They are not part of the shared Source Pack.
- Fork shared behavior deliberately.Fork Agent Workflows when changing shared Source Pack behavior, curating features, or maintaining organization-wide defaults.
- Contribute portable improvements upstream.When a change is generally useful, prepare it for the shared project instead of leaving every Derived Distribution to rediscover it.
- Track temporary downstream fixes.Keep each temporary patch explicit until upstream accepts it or an Upstream Release supersedes it.
Forks are first-class distributions.
A maintained fork is not accidental drift. It is a Derived Distribution with its own release boundary and an accountable relationship to the Source Pack. Each Derived Distribution should carry:
- an exact Upstream Release and commit as its baseline;
- its own immutable release identity;
- an explicit downstream patch ledger;
- validation and synchronization evidence;
- a path for contributing improvements upstream; and
- release claims that remain distinct from upstream’s claims.
AI-assisted synchronization
AI can lower the maintenance cost of an honest fork. It can compare Upstream Releases, classify relevant changes, detect semantic conflicts, adapt local patches, identify patches that upstream has superseded, prepare synchronization pull requests, and extract portable contributions.
Humans still approve stable release promotion at the exact candidate commit. AI review is advisory; it is not human release approval.
Two update modes
Adopt a complete Upstream Release
The safer default. Rebase the Derived Distribution on one coherent upstream boundary, reconcile its patch ledger, validate the candidate, and promote an exact downstream commit.
Selectively backport specific changes
Useful for urgent fixes. The Derived Distribution owns the resulting compatibility claim, its validation evidence, and the later reconciliation with a complete Upstream Release.
Why this matters
- Safe, exact, rollback-capable upgrades.
- Freedom to customize without concealing divergence.
- Long-lived forks that remain synchronizable.
- Well-defined upstream and derived releases.
- Easier contribution back to the shared project.
- A visible ecosystem of maintained distributions as evidence of adoption and credibility.
Repository references
The current repository documents the Source Pack vocabulary, Agent Workflow Configuration Seam, development-channel installation, and release trust boundary. The formal distribution-and-forks guide, Derived Distribution protocol, and architecture decision will be linked here after they are merged into the Source Pack repository.