Skip to main content

Agent Layer is open source and contributions are welcome. If you're unsure where to start, open an issue with a clear problem statement and a small reproduction.

Where to start​

What makes a great PR​

  • Scope is small and focused
  • Behavior changes are covered by tests
  • Docs are updated when user-facing behavior changes
  • Upgrade-related behavior or guidance updates include corresponding changes to /docs/upgrades
  • Commit messages explain the intent (not just the mechanics)

Local workflow​

The repo is set up so generated outputs stay repeatable and CI tooling stays aligned. For most changes:

./scripts/setup.sh
make dev

Run from: repo root

make dev is the fast formatting and lint loop. Use make test as the global test gate, make coverage for diagnostic coverage reporting, and run make ci before you open a PR. Hosted CI also runs make ci.

Template and sync changes​

If you change anything under internal/templates/ (or sync behavior), validate the seeded output by running init and sync against a scratch repo:

mkdir -p tmp/dev-repo
cd tmp/dev-repo
go run ../../cmd/al init
go run ../../cmd/al sync

Run from: repo root

This catches unintended changes in generated outputs before CI does.

Documentation​

The website content lives under:

  • site/docs/ (documentation pages)
  • site/pages/ (marketing and utility pages like Install, FAQ, Security)

Documentation-only PRs are welcome. If you're changing copy and structure only, you usually do not need any Go tooling beyond opening a PR.

For public authoring guidance, use the Best Practices hub, including Skill Design, CLI Skill Design, and Instruction Design.

Design principles​

  • Keep repo-local configuration explicit
  • Avoid introducing hidden defaults
  • Fail fast when required inputs are missing
  • Keep generated outputs repeatable from the same inputs
tip

If you improve the docs, include a before/after example. It helps reviewers validate impact quickly.