Shipping GitHub and Vercel Changes
Default branch model
Respect the repository's actual policy. When it uses dev and main, feature/fix branches target dev; release promotion goes from dev to main.
Workflow
- Inspect current branch, remote,
git status, and existing PRs before writing. - Never mix unrelated dirty work into the task.
- Create a descriptive branch for feature/fix work when currently on the default branch.
- Commit narrowly with messages that describe the delivered behavior.
- Run relevant gates before claiming readiness: diff check, lint, typecheck, tests, production build.
- Inspect runtime/UI when the change is visual or interactive.
- Reuse an existing matching PR rather than opening duplicates.
- Include summary, verification performed, screenshots when useful, known limitations, and migration/env implications in the PR.
- Do not merge unless the user or repository workflow authorizes it.
- After merge, verify deployment status and runtime configuration when the task includes release delivery.
Vercel specifics
- Distinguish Preview from Production configuration.
- Ensure required environment variables exist in the correct environments.
- Never paste secrets into source or PR body.
- Treat successful deployment as necessary but not sufficient; verify the deployed route when release correctness matters.