Development Workflow
develop is our main branch. All PRs target develop, and deployments are
triggered from there.
Branch Strategy
| Branch | Purpose |
|---|---|
develop | Main integration branch - all PRs merge here |
feature/[description] | New features |
fix/[description] | Bug fixes |
chore/[description] | Maintenance, refactoring, docs |
Deployment Branches (Auto-triggered)
These branches trigger deployments when pushed to:
| Branch | Deploys To |
|---|---|
vercel-prod | Frontend production (Vercel) |
vercel-staging | Frontend staging (Vercel) |
ecs-prod-backend | Backend production (AWS ECS) |
ecs-staging-backend | Backend staging (AWS ECS) |
admin-prod | Admin app production |
admin-staging | Admin app staging |
Local Development
Pre-commit Hooks
Husky runs automatically on commit:
- Biome lint and format on staged files
- TypeScript type checking on affected packages
Commands
# Start development servers
./start-dev.sh --apps frontend,backend --packages db,api
# Run all checks locally
pnpm lint && pnpm typecheck && pnpm test
# Run specific test file
pnpm vite:test --run path/to/test.spec.tsOpening a Pull Request
When your feature or fix is ready, use the /open-pr Claude command to create a well-structured pull request.
# In Claude Code, type:
/open-prThe command automatically:
- Analyzes the diff between your branch and
develop - Identifies affected packages and the type of changes
- Generates a comprehensive PR description (summary, rationale, technical details, testing instructions, impact analysis)
- Creates the PR via GitHub CLI (
gh pr create)
PR Title Conventions
PR titles follow the conventional commits format:
| Prefix | Use Case |
|---|---|
feat | New feature |
fix | Bug fix |
refactor | Code refactoring (no functional changes) |
perf | Performance improvements |
test | Test additions or fixes |
docs | Documentation changes |
chore | Maintenance tasks |
style | Code style changes |
Examples:
fix(frontend): resolve issue with user preferences not savingfeat(api): add AI-powered search functionalityrefactor(db): optimize inventory query performance
Changeset Reminder
Before or after opening your PR, generate a changeset with the /write-changeset command. This creates a versioning entry in .changeset/ describing what changed and the appropriate version bump (patch, minor, or major).
/write-changesetPull Request Checks
When you open a PR against develop, GitHub Actions runs these checks automatically:
Build
Builds all affected packages using Turborepo’s --affected flag.
Lint
Runs Biome linter on affected packages.
pnpm turbo run lint --affectedTypecheck
TypeScript type checking on affected packages.
pnpm turbo run typecheck --affectedTest
Runs Vitest unit tests on affected packages.
pnpm turbo run test --affectedDependency Check
Validates package dependencies (non-blocking).
pnpm depcheck && pnpm check:packagesTranslation Validation
Validates JSON syntax and completeness of translation files when i18n files change.
Code Review Workflow
After your PR is created, CodeRabbit (our automated code review bot) will analyze it and post review comments. Here’s the full review cycle:
Wait for CodeRabbit Review
After opening the PR, wait for CodeRabbit to finish its automated review. It will post inline comments on your code with suggestions, potential bugs, and style recommendations. You’ll see its review appear as comments on the PR.
Triage with /pr-review-analysis
Run the analysis command in Claude Code to triage all review comments at once:
/pr-review-analysis 2159This fetches all unresolved review comments (bot and human) and produces a review-analysis.md file at the repo root. For each comment, it assigns a verdict:
| Verdict | Meaning |
|---|---|
| VALID | Feedback is correct — includes a resolution plan |
| PARTIALLY VALID | Has merit but the suggestion is incomplete or there’s a better approach |
| CONDITIONAL | Valid only under certain conditions |
| INVALID | Wrong, inapplicable, or conflicts with project conventions — includes a pre-composed reply |
The analysis also checks if any comments have already been addressed by subsequent commits and marks them as resolved.
Review the Analysis
Open review-analysis.md and review the verdicts. You can:
- Change a verdict (e.g., from INVALID to VALID if you agree with the reviewer)
- Edit the pre-composed replies for INVALID items
- Adjust resolution plans for VALID items
- Remove entries you don’t want addressed
This step is your opportunity to apply human judgment before the automation acts.
Resolve with /pr-review-resolve
Run the resolve command to act on your reviewed analysis:
/pr-review-resolveIt works through three phases:
- Phase 1 — Dismiss invalid comments: Posts your pre-composed replies and resolves the threads on GitHub
- Phase 2 — Implement valid fixes: Makes code changes based on the resolution plans, then runs typecheck
- Phase 3 — Resolve threads: Resolves all remaining threads (already-resolved items + newly fixed items)
You’ll be asked which phases to run and to review all code changes before committing.
Push and Iterate
After fixes are committed and pushed, check if new review comments appear. If they do, run /pr-review-analysis again. Repeat until all comments are addressed and the PR is ready to merge.
The /resolve-pr-comments command is an older, single-step version of this workflow. Prefer the two-step /pr-review-analysis + /pr-review-resolve pipeline — it gives you the chance to review and edit verdicts before acting.
Claude-Assisted Development
We use Claude Code extensively throughout our development workflow. Claude commands (invoked by typing /command-name in Claude Code) automate repetitive tasks and enforce project conventions.
Key Workflows
Feature ideation pipeline:
/refine-idea → /create-prd → /create-planTakes a feature from rough idea to a structured implementation plan with specs saved in specs/{feature-name}/.
PR review pipeline:
/open-pr → wait for review → /pr-review-analysis → /pr-review-resolveCreates the PR, triages review comments, and resolves them — all from Claude Code.
Parallel development:
/worktree {feature-name} → work in separate directory → /worktree-cleanup {feature-name}Spin up isolated git worktrees for parallel Claude Code sessions on different features.
See the full Claude Commands Reference for all available commands.
Deployment
Manual Deployment
Use the deploy script to deploy any branch to staging or production:
# Deploy develop branch to production
./scripts/deploy.sh prod develop
# Deploy develop branch to staging
./scripts/deploy.sh staging develop
# Deploy a feature branch to staging for testing
./scripts/deploy.sh staging feature/my-featureThe script handles:
- Frontend deployment (pushes to
vercel-prodorvercel-staging) - Backend deployment (pushes to
ecs-prod-backendorecs-staging-backend) - Admin deployment (pushes to
admin-prodoradmin-staging) - Trigger.dev tasks deployment
Automatic Deployments
| Trigger | Action |
|---|---|
Push to develop | Deploys Trigger.dev tasks to staging |
Push to develop | Creates/updates Release PR via Changesets |
Push to ecs-* branches | Builds Docker image, pushes to ECR, deploys to ECS |
Push to vercel-* branches | Vercel automatically deploys |
Versioning with Changesets
We use Changesets for versioning:
-
Add a changeset when making notable changes (use
/write-changesetin Claude Code or manually):pnpm changeset -
Changesets bot creates a “Release” PR that:
- Bumps versions in package.json files
- Updates CHANGELOG.md files
- Creates git tags on merge
-
Git tags trigger deployment workflows for the tagged packages.
Infrastructure
| Service | Platform | Trigger |
|---|---|---|
Frontend (@repo/frontend) | Vercel | Push to vercel-* branches |
Backend (@repo/backend) | AWS ECS | Push to ecs-* branches |
Admin (@repo/admin) | Cloudflare Pages | Push to admin-* branches |
Tasks (@repo/tasks) | Trigger.dev | Push to develop or manual |
| Mobile | EAS Build | Manual workflow dispatch |