Skip to Content
Development Workflow

Development Workflow

develop is our main branch. All PRs target develop, and deployments are triggered from there.

Branch Strategy

BranchPurpose
developMain 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:

BranchDeploys To
vercel-prodFrontend production (Vercel)
vercel-stagingFrontend staging (Vercel)
ecs-prod-backendBackend production (AWS ECS)
ecs-staging-backendBackend staging (AWS ECS)
admin-prodAdmin app production
admin-stagingAdmin 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.ts

Opening 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-pr

The command automatically:

  1. Analyzes the diff between your branch and develop
  2. Identifies affected packages and the type of changes
  3. Generates a comprehensive PR description (summary, rationale, technical details, testing instructions, impact analysis)
  4. Creates the PR via GitHub CLI (gh pr create)

PR Title Conventions

PR titles follow the conventional commits format:

PrefixUse Case
featNew feature
fixBug fix
refactorCode refactoring (no functional changes)
perfPerformance improvements
testTest additions or fixes
docsDocumentation changes
choreMaintenance tasks
styleCode style changes

Examples:

  • fix(frontend): resolve issue with user preferences not saving
  • feat(api): add AI-powered search functionality
  • refactor(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-changeset

Pull 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 --affected

Typecheck

TypeScript type checking on affected packages.

pnpm turbo run typecheck --affected

Test

Runs Vitest unit tests on affected packages.

pnpm turbo run test --affected

Dependency Check

Validates package dependencies (non-blocking).

pnpm depcheck && pnpm check:packages

Translation 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 2159

This 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:

VerdictMeaning
VALIDFeedback is correct — includes a resolution plan
PARTIALLY VALIDHas merit but the suggestion is incomplete or there’s a better approach
CONDITIONALValid only under certain conditions
INVALIDWrong, 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-resolve

It works through three phases:

  1. Phase 1 — Dismiss invalid comments: Posts your pre-composed replies and resolves the threads on GitHub
  2. Phase 2 — Implement valid fixes: Makes code changes based on the resolution plans, then runs typecheck
  3. 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-plan

Takes 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-resolve

Creates 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-feature

The script handles:

  1. Frontend deployment (pushes to vercel-prod or vercel-staging)
  2. Backend deployment (pushes to ecs-prod-backend or ecs-staging-backend)
  3. Admin deployment (pushes to admin-prod or admin-staging)
  4. Trigger.dev tasks deployment

Automatic Deployments

TriggerAction
Push to developDeploys Trigger.dev tasks to staging
Push to developCreates/updates Release PR via Changesets
Push to ecs-* branchesBuilds Docker image, pushes to ECR, deploys to ECS
Push to vercel-* branchesVercel automatically deploys

Versioning with Changesets

We use Changesets  for versioning:

  1. Add a changeset when making notable changes (use /write-changeset in Claude Code or manually):

    pnpm changeset
  2. Changesets bot creates a “Release” PR that:

    • Bumps versions in package.json files
    • Updates CHANGELOG.md files
    • Creates git tags on merge
  3. Git tags trigger deployment workflows for the tagged packages.

Infrastructure

ServicePlatformTrigger
Frontend (@repo/frontend)VercelPush to vercel-* branches
Backend (@repo/backend)AWS ECSPush to ecs-* branches
Admin (@repo/admin)Cloudflare PagesPush to admin-* branches
Tasks (@repo/tasks)Trigger.devPush to develop or manual
MobileEAS BuildManual workflow dispatch
Last updated on