Upgrade Your Project

RED upgrades are handled by /red-update. This is not a blind dependency upgrade. The skill reads your current RED version, fetches release metadata through create-red-app, builds a migration plan, asks for confirmation, then applies changes carefully.

Prerequisites

.red-version exists and reflects the RED base version your project started from.
.red-license exists and is git-ignored.
Your working tree is reviewable before starting the migration.

If .red-version is missing and you do not know the base version, stop and recover that information first. Guessing the migration base can corrupt a customized project.

Run the Skill

/red-update

How It Works

1. Read Current State

The skill reads .red-version, .red-license, verifies .red-license is ignored, and inspects the repo state before planning changes.

2. Fetch Releases

It runs:

bunx create-red-app versions

The CLI reads .red-license automatically. If the license is invalid, the migration stops.

3. Choose Target Version

You choose whether to upgrade to the latest release or a specific release. If there are multiple releases between your current version and the target, the skill applies them sequentially.

4. Build the Migration Plan

For each version step, the skill runs:

bunx create-red-app info <version>

It reads the changelog, migration markdown, and structured migration manifest, then explains what will change before touching files.

5. Download Release Archives

For each step, the skill runs:

bunx create-red-app download <version>

The archive is extracted outside your working copy. The skill compares three versions of files when needed:

old — the file from your current RED base release.
new — the file from the target RED release.
current — your customized file.

6. Apply Safely

Manifest-driven changes are applied first:

Add files only if missing.
Remove files only if unmodified.
Replace files only if unmodified.
Apply dependency and config updates.

For customized files, the skill computes the upstream intent from old -> new, then applies the smallest correct change to current. It preserves buyer code unless the migration explicitly requires a change. If the merge is ambiguous, it pauses and asks.

7. Verify

Verification runs before .red-version is updated:

bun install
bun run lint
bun run typecheck
bun run test

If Convex is configured and backend code changed, the skill also runs:

bunx convex dev --once

If UI behavior changed, verify the app in the browser before considering the migration complete.

8. Update Version and Summarize

Only after verification passes, the skill updates .red-version to the new target release and summarizes:

Versions applied.
Files changed automatically.
Files merged with judgment.
Manual follow-up items.

Safety Rules

Never blindly replace buyer-modified files.
Never update .red-version before verification passes.
Prefer minimal diffs over full-file replacement.
Stop and ask when migration instructions conflict with buyer code.

When To Upgrade

Upgrade when:

A security fix affects your project.
A RED release includes a feature you want.
You need to move to a supported base version before doing larger custom work.

For normal product development, stay focused on your domain code, agents, tools, and task nodes. Use /red-update when you intentionally want upstream RED changes.