Code Integration

When multiple people contribute to a project built through synthesis coding, integration is fundamentally different from a standard open source merge workflow. This skill defines how it works.

Binding rules

1. Adopt and adapt by default; never blind-merge. Branch fresh from current main, bring changes in selectively, and fix issues before they reach main, because the contributor built against a codebase that has since moved. Lighter phases are earned by a contributor's record and lost on a regression.
2. Zero accepted failures. Every test passes and every lint is clean, including failures you did not cause, fixed in the same branch; a suite with known failures cannot tell you whether a change is safe.
3. Every contribution passes Gates 1 to 4 (completeness, security, architecture, project-specific standards) before integration. An undocumented standard is the lead's to document, not the contributor's fault.
4. Never merge another long-lived branch into a PR branch. Put the commit on that branch as a separate operation; only a promotion PR (such as develop to main) carries another branch's work.
5. After every cherry-pick, look for silent reversions and run the full suite. A conflict-free cherry-pick can bring back an old version of a file; never trust the GitHub diff for an old branch.
6. Never force-push main to the staging branch. Check for divergence and merge instead, so contributors' unintegrated work survives.
7. Run the pre-squash PR manifest check before every squash merge, and write no changelog entry for a feature you have not found in the code on the target branch.
8. Guard every deliberate upgrade of a critical config value (effort level, token budget, model, retries) with a test that explains why the value matters.
9. Ground every technical reply in code. Separate what you observed from what you conclude, and say "I don't know" when you don't.
10. Credit contributors with Co-authored-by trailers that match the integration intensity, because contribution graphs feed careers.
11. Fix first, talk later when the fix is quick and delay is risky.
12. Production deploys always require explicit human approval.