Git Workflow
Remotes
Branch Strategy
| Branch | Purpose | Pushes To |
|---|---|---|
development |
Active working branch — all daily work lands here | origin/development |
main |
Stable branch — CI runs here, deploy candidates | origin/main |
All daily development happens on development. Use PRs from development to main when ready to trigger CI and prepare a release.
Commit Message Format
<type>(<scope>): <description>
<optional body>
| Field | Values |
|---|---|
| type | feat, fix, refactor, docs, test, chore, perf, ci |
| scope | App name or feature area (e.g., auth, dashboard, billing) |
Before Pushing
Run your verification suite as a pre-push gate. Skipping it means broken code reaches origin:
npm run verify # typecheck + lint + test
If verify fails, fix issues before pushing.
CI Pipeline
Pull Request Workflow
When creating PRs:
- Analyze full commit history (not just latest commit)
- Use
git diff [base-branch]...HEADto see all changes - Draft comprehensive PR summary
- Include test plan with TODOs
- Push with
-uflag if new branch
Upstream Merge Process (Template Updates)
Feature Implementation Workflow
- Plan — Use
/create-planto generate phases and structure - Review Plan — Use
/review-planto verify each phase - Implement — Use
/implementto execute phases (handles TDD, coding, review loop) - Code Review — Use
/code-reviewafter implementation to verify quality - Verify — Run verification suite before committing
- Commit — Follow conventional commits format with scope