Contributing

Thanks for contributing to LoopForge.

Development workflow

Start changes from a feature branch.
Keep Classic/Portable workflow templates generic; do not introduce organisation-, repository-, or cloud-specific information there. Product tools under tools/ (such as tools/tcmcp) may target a public cloud product, but must not include private domains, real resource IDs, or credentials.
Do not commit credentials, local permission configurations, or production data.
First indicate whether a change belongs to Classic, Portable, or shared behaviour contracts. Portable only modifies skills/; Classic .cursor/.claude files are not edited directly — run build-classic-hosts.py --write.
When modifying shared workflow contracts, describe the impact on both editions separately; do not copy runtime files between them.
Run bash scripts/validate.sh, bash scripts/smoke-install.sh and bash scripts/e2e.sh before submitting, plus bash scripts/test-observability.sh when you change agent-observability. The E2E suite drives the installed workflow with a fake host Agent and recorded stage outputs, so it needs no API key; see tests/e2e/README.md.

Describe the problem the change solves and the applicable runtime.
List behaviour changes, compatibility impact, and verification results.
When adding third-party content, include source, licence, and modification notes.
Do not put internal deployment or operational capabilities into Classic/Portable templates; keep unpublished ops in a private extension. Optional public tools belong in tools/, not in host workflow packs.

Commit messages should follow Conventional Commits, e.g. feat: add workflow checkpoint validation.