Review and Deploy

• Time required: 30–60 minutes 

• What this does: Code review, PR creation, CI/CD setup, and deployment. 

• When to use: When a phase or feature is complete and verified.

• What you will have after this: A merged PR, passing CI/CD, and a deployed, verified release.

Step 1: Run automated code review

Before creating a PR, run the multi-agent code review. On your feature branch:

/code-review

This launches 5 parallel review agents that analyse your changes from different angles. Only high-confidence issues (80+ score) are reported. Fix any issues found.

If code-review flagged specific areas of concern, use the pr-review-toolkit agents to investigate deeper, ask Claude to:

Please review the error handling, test coverage for edges cases and if the code comments accurate in for all concerns you have found

If the review finds no high-confidence issues, it will tell you. This is a good sign but does not replace the human review in Step 5. When you are ready to post the review as a PR comment (after creating the PR in Step 2):

/code-review --comment

This posts the findings directly to the GitHub PR for the human reviewer to see.

Step 2: Create a Pull Request

PROMPT: Create PR Create a pull request from this branch to main. The PR description should include: 

1. **Summary:** One paragraph describing what this PR does
2. **Changes:** Bullet list of key changes
3. **Acceptance criteria verified:** List the AC numbers that were verified (copy from the checklist)
4. **Testing:** What tests were run and their results (pass count, coverage %)
5. **Screenshots:** (note: add these manually if applicable)
6. **How to test manually:** Step-by-step instructions for a reviewer to verify this works Use `gh pr create` or guide me through creating it on GitHub.

If you do not have the GitHub CLI (gh) installed:

brew install gh
gh auth login

Step 3: Set up CI/CD with Claude Code GitHub Action (one-time per repo)

If this is the first PR for this project, set up the Claude Code GitHub Action for automated review.

PROMPT: Setup CI/CD Create the following GitHub Actions workflows: 1. **Claude Code PR Review** at .github/workflows/claude-review.yml: - Uses: anthropics/claude-code-action@v1 - Triggers on: pull_request (opened, synchronize) - Claude reviews the PR and posts comments - Include the ANTHROPIC_API_KEY secret reference 2. **Test Suite** at .github/workflows/test.yml: - Triggers on: pull_request and push to main - Sets up the project (install dependencies) - Runs the full test suite - Reports coverage - Fails the PR if tests fail or coverage drops below 80% 3. **Linting** at .github/workflows/lint.yml: - Triggers on: pull_request - Runs linting (ESLint, Prettier, or equivalent for our stack) - Fails the PR if there are lint errors Show me each file before creating them. I need to approve the workflows.

Important: You need to add the ANTHROPIC_API_KEY secret to your GitHub repo:

1. Go to your repo on GitHub

2. Settings → Secrets and variables → Actions

3. Click "New repository secret"

4. Name: ANTHROPIC_API_KEY

5. Value: Your Anthropic API key

6. Click "Add secret"

Step 4: Security hardening for CI/CD

Tell Claude:

Update the GitHub Actions workflows with these security measures: 1. Pin all action versions by SHA (not just tag)
2. Add explicit permissions (contents: read, pull-requests: write)
3. Restrict allowed_tools in the Claude review action to only what is needed
4. Add a timeout to prevent runaway jobs (30 minutes max)

Step 5: Human code review

Even with Claude's automated review, a human must review the PR.

For the reviewer:

1. Read the PR description

2. Check that all listed acceptance criteria are actually tested

3. Look at the diff — does it make sense?

4. Run the app locally and verify it works as described

5. Check for security issues (secrets, injection, auth gaps)

6. Approve or request changes

Tip: If you are reviewing a PR and want Claude's help understanding specific feedback, the GitHub MCP server lets Claude read PR comments directly: "Read the review comments on PR #\[number\] and summarise the requested changes."

Step 6: Merge

Once the PR is approved by a human AND all CI checks pass:

1. Merge via GitHub (use "Squash and merge" for a clean history)

2. Delete the feature branch after merge

3. Pull main locally:

git checkout main
git pull

Step 7: Deploy (project-specific)

Deployment depends on your hosting choice (from the ADRs). Here is the general pattern:

PROMPT: Create Deployment Guide Based on our architecture (ADR for hosting/deployment), create a deployment guide at /docs/deployment.md that includes: 1. **Environment setup:** What environment variables are needed?
2. **Build command:** How to create the production build
3. **Deploy command:** How to deploy to [our chosen platform]
4. **Verify deployment:** How to confirm the deployment succeeded
5. **Rollback procedure:** How to revert to the previous version if something breaks
6. **Environment management:** How to manage dev/staging/prod environments Include the exact commands for each step.

Step 8: Post-deployment verification

After deploying:

1. Open the deployed URL in Chrome

2. Run through the acceptance criteria for this release

3. Check for console errors

4. Verify all user flows work end-to-end

5. If you set up the Playwright MCP during testing (Part 8, Step 4), you can use it here too

Secrets Management for Non-Local Environments

The .env pattern works for local development. For staging and production, you need a secrets management approach appropriate to your hosting platform:

• Vercel/Netlify/Railway: Use the platform's environment variables UI

• AWS: Use AWS Secrets Manager or SSM Parameter Store

• Google Cloud: Use Secret Manager

• Azure: Use Key Vault

• Self-hosted: Use HashiCorp Vault or sealed secrets

Whichever you choose, create an ADR documenting the decision: /project:create-adr

The deployment guide (created above) should reference how secrets are loaded in each environment. Never store production credentials in .env files, environment variable UIs, or anywhere that is committed to version control.

Checkpoint

After deployment:

• PR merged to main

• CI/CD passing

• Deployed to target environment

• Post-deployment verification complete

• All acceptance criteria for this release verified on production

For ongoing project maintenance, see Ongoing Operations.