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; test locally with pnpm dev:<app-name>.
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, 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 Test

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; local dev and build verified
• Committed with conventional prefix; pushed; PR opened to main
• You: CI passed; preview 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