Minor Changes

Step-by-step workflow for small features, bug fixes, and quick updates using the /new-minor-feature skill.

Overview

For single features, bug fixes, and quick updates that fit in one session, you can use the /new-minor-feature skill with Claude. It guides you through plan mode, implementation, build verification, and opening a PR. You handle review and merge in GitHub.

Use this workflow when:

• Adding a single feature or fixing a bug
• Doing UI tweaks or content updates
• The work fits in one session and does not need architectural decisions

If your task spans multiple days or needs structured planning, use Phase Development instead.

The /new-minor-feature Skill

The /new-minor-feature skill walks you through the full minor-changes flow: plan from main, implement with Claude, verify the build, then commit and open a PR. Claude does not review or merge — you do that in GitHub after CI passes and you have tested the preview.

How to Use It

In Claude, type:

/new-minor-feature

Then describe what you want to do (e.g. add a feature, fix a bug, update docs) and which app you are working on. Claude will use plan mode to analyze the request and the monorepo guidelines (CLAUDE.md), create a feature branch from main, and then implement with you step by step.

What You'll Do

1. Start the session — Tell Claude the app name and what you want to do. Use plan mode so Claude creates a feature branch from main.
2. Implement — Work with Claude to make the changes.
3. Verify build — Ask Claude to run the build before committing (required; CI will fail otherwise).
4. Commit and open PR — Ask Claude to commit your changes and create a Pull Request to main. Claude returns the PR URL.
5. Review and merge (you) — Wait for CI to pass, review the PR, test the preview URL posted in the PR comment, then merge in GitHub. Claude does not review or merge.

What the Skill Does

Behind the scenes, /new-minor-feature follows these steps with you:

Step 1: Plan and Branch

Step 2: Implement and Verify Build

You don't run the app locally. Behaviour testing happens on the PR preview URL after push (see Step 4).

Step 3: Commit and Open PR

Commit Message Format

Step 4 & 5: Your Part — Review and Merge

After the PR is open:

1. CI — Linting, type checking, and build run automatically. Wait for all checks to pass (green).
2. Review — Review the PR description and diff; edit the PR if needed. Claude does not review or approve; you do.
3. Preview — A preview deploy runs (staging + Neon DB branch). A PR comment contains the Preview URL. Test your changes on that URL.
4. Merge — In GitHub, merge the PR to main after approval and green checks. Claude does not merge; you do. After merge, changes deploy to production automatically.

Summary Checklist

• Plan mode used; feature branch created from main
• Changes implemented; pnpm build:<app-name> passes locally
• Committed with conventional prefix; pushed; PR opened to main
• You: CI passed; preview URL tested; PR merged in GitHub

Manual Fallback

If you prefer to run the workflow without the skill:

# Switch to main and pull latest
git checkout main
git pull origin main
git checkout -b feature/your-feature-name

# After making changes: run build
pnpm build:your-app-name

# Stage, commit, push, create PR
git add .
git commit -m "feat: add new feature description"
git push -u origin feature/your-feature-name
gh pr create --base main --fill

Then wait for CI, review, test the preview, and merge the PR in GitHub.

Quiz

Common Mistakes to Avoid

• ❌ Committing directly to main
• ❌ Skipping local build verification
• ❌ Not pulling latest changes before creating branch
• ❌ Using unclear commit messages