vc:update
This Claude Code skill synchronizes a project with the latest agent harness improvements from the vibecode-pro-max-kit repository. Use it when a new harness version is available, periodically to check for updates, or after initial project setup to ensure the latest features and fixes are installed. The skill performs a dry-run comparison, displays a summary of changes, waits for user confirmation, then applies the updates while preserving local customizations.
git clone --depth 1 https://github.com/withkynam/vibecode-pro-max-kit /tmp/vc-update && cp -r /tmp/vc-update/.claude/skills/vc-update ~/.claude/skills/vc-updateSKILL.md
# vc-update
Pull the latest agent harness improvements from the remote vibecode-pro-max-kit repository into the current project.
## When to Use
- After being told a new harness version is available
- Periodically to check for updates
- After bootstrapping a project with `vc-setup` and wanting the latest improvements
## Workflow
Follow these steps exactly. Do NOT skip the dry-run or confirmation step.
### Step 1: Check Worktree Status
Run `git status --porcelain` in the project root.
- If output is non-empty: **warn** the user that they have uncommitted changes and suggest `git stash` or committing first. **Do not block** -- continue after warning.
- If output is empty: proceed silently.
### Step 2: Read Current Version
Read the file `.vc-version` in the project root.
- If it exists: store its contents as `currentVersion` (a semver string like `2.0.4`).
- If it does not exist: set `currentVersion` to `"0.0.0"` (treat as first update).
### Step 3: Clone Remote Repository
```bash
TMPDIR="/tmp/vc-update-$(date +%s)"
git clone --depth 1 https://github.com/withkynam/vibecode-pro-max-kit.git "$TMPDIR"
```
If the clone fails (network error, auth error, repo not found):
- Print the error message.
- Clean up the temp directory if it was partially created.
- **Stop.** Do not proceed.
### Step 4: Resolve Remote Manifest
Run the resolver script from the cloned repo:
```bash
node "$TMPDIR/resolve-manifest.mjs" --root "$TMPDIR" --json
```
Parse the JSON output to extract:
- `files` (string[]) -- resolved managed file paths
- `merge` (string[]) -- files where user customizations are preserved (not overwritten)
- `copyIfMissing` (string[]) -- files only installed if they don't already exist locally
- `strip` (string[]) -- files needing content stripping (informational)
- `symlinks` (object) -- symlink path -> target mappings
Extract the remote version from the manifest:
```bash
node -e "console.log(JSON.parse(require('fs').readFileSync('$TMPDIR/vc-manifest.json','utf8')).version)"
```
**Legacy fallback:** If `resolve-manifest.mjs` does not exist in the remote (very old kit version), fall back to reading `vc-manifest.json` directly and using the old `managed`/`managedDirs`/`seedsDir` fields for file resolution.
### Step 5: Compare Versions
Compare the remote manifest `version` against `currentVersion`.
- If they are equal: report **"Already up to date (vX.Y.Z)"** and clean up `$TMPDIR`. **Stop.**
- If remote is newer (or currentVersion is `0.0.0`): continue to diff.
### Step 6: Read Local Snapshot and Compute Diff
**Read `.vc-installed-files`** from the project root (if it exists). This file contains one file path per line -- the list of files installed by the last update.
**If `.vc-installed-files` does NOT exist** (first update with new system):
1. Build a synthetic snapshot by scanning the user project for files that exist AND match the remote `files` list.
2. Also check for legacy `deletions` from the v2.0.4 era -- the resolver embeds these as `legacyDeletions` in legacy mode. For any path in the legacy deletions list that still exists locally, mark it for deletion.
3. Write this synthetic snapshot to `.vc-installed-files` for future updates.
**Compute the diff** using three lists: remote `files`, local snapshot, and local filesystem:
- **Additions:** Files in remote `files` but NOT in local snapshot (new files to install).
- **Removals:** Files in local snapshot but NOT in remote `files` (files removed from kit -- should be deleted locally).
- **Modifications:** Files in both lists -- compare content via `diff` between `$TMPDIR/{path}` and `{projectRoot}/{path}`.
- If identical: **unchanged**.
- If different: **modified** (note line count changes).
- **Merge files:** Files in the `merge` list (e.g. `.claude/settings.json`) that have local changes. Preserve local version entirely, show diff, flag for manual review.
- **Copy-if-missing files:** Files in the `copyIfMissing` list that already exist locally. Show the diff but note they will NOT be overwritten.
### Step 7: Check Symlinks
For each entry in the `symlinks` object (key = symlink path, value = target):
- If the symlink exists and points to the correct target: mark as **ok**.
- If the symlink is missing or points to a different target: mark as **will fix**.
- If a real directory exists at the symlink path (not a symlink): mark as **will replace dir with symlink**.
### Step 8: Print Dry-Run Summary
Print a summary with all collected results. Format:
```
vc-update dry run: v{currentVersion} -> v{remoteVersion}
FILES:
[modified] .claude/agents/vc-execute-agent.md (+12 -3)
[new] .claude/hooks/lib/new-util.cjs
[removed] .claude/skills/deprecated-skill/SKILL.md
[unchanged] .claude/agents/vc-debugger.md
...
MERGE (preserved, manual review needed):
[differs] .claude/settings.json (+2 -1)
COPY-IF-MISSING (skipped, already present):
(none)
SYMLINKS:
[ok] .agents/skills -> ../.claude/skills
[will fix] .codex/hooks -> ../.claude/hooks
Summary: 5 modified, 2 new, 1 removal, 1 merge skipped, 45 unchanged
```
### Step 9: Wait for Confirmation
**STOP HERE.** Tell the user:
> "This is a dry-run summary. Type **apply** to proceed with the update, or **abort** to cancel. The temp clone will be cleaned up either way."
Do NOT proceed until the user explicitly says "apply" (or a clear affirmative like "yes", "go", "do it").
If the user aborts:
- Remove `$TMPDIR`.
- Print "Update cancelled. No changes made."
- **Stop.**
### Step 10: Apply Changes
On user confirmation, apply in this order:
1. **Additions and modifications**: For each file in the remote `files` list:
- Skip if file is in `merge` list AND exists locally (preserve user version).
- Skip if file is in `copyIfMissing` list AND exists locally (preserve user version).
- Otherwise: `mkdir -p` the parent directory, copy from `$TMPDIR/{path}` to `{projectRoot}/{path}`.
2. **Removals**: For each file in the local sComprehensive code review with scout-based edge case detection. Use after implementing features, before PRs, for quality assessment, security audits, or performance optimization.
Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Focuses on recently modified code unless instructed otherwise.
Use this agent when you need to investigate issues, analyze system behavior, diagnose performance problems, examine database structures, collect and analyze logs from servers or CI/CD pipelines, run tests for debugging purposes, or optimize system performance. This includes troubleshooting errors, identifying bottlenecks, analyzing failed deployments, investigating test failures, and creating diagnostic reports. Examples:\n\n<example>\nContext: The user needs to investigate why an API endpoint is returning 500 errors.\nuser: "The /api/users endpoint is throwing 500 errors"\nassistant: "I''ll use the debugger agent to investigate this issue"\n<commentary>\nSince this involves investigating an issue, use the Task tool to launch the debugger agent.\n</commentary>\n</example>\n\n<example>\nContext: The user wants to analyze why the CI/CD pipeline is failing.\nuser: "The GitHub Actions workflow keeps failing on the test step"\nassistant: "Let me use the debugger agent to analyze the CI/CD pipeline logs and identify the issue"\n<commentary>\nThis requires analyzing CI/CD logs and test failures, so use the debugger agent.\n</commentary>\n</example>\n\n<example>\nContext: The user notices performance degradation in the application.\nuser: "The application response times have increased by 300% since yesterday"\nassistant: "I''ll launch the debugger agent to analyze system behavior and identify performance bottlenecks"\n<commentary>\nPerformance analysis and bottleneck identification requires the debugger agent.\n</commentary>\n</example>
EXECUTE MODE - Implementing EXACTLY what was planned. Full tool access. Can only be invoked after explicit user confirmation. Use after plan is approved.
FAST MODE - Execute compressed RIPER-5 workflow (RESEARCH + INNOVATE + PLAN) in one session, then pause for EXECUTE confirmation. Use when you want quick end-to-end solution.
Stage, commit, and push code changes with conventional commits. Use when user says "commit", "push", or finishes a feature/fix.
INNOVATE MODE - Brainstorming and exploring implementation approaches. Discusses possibilities without making decisions. Use after research is complete.
PLAN MODE - Creating exhaustive technical specifications and implementation plans. Can write to process/general-plans/active/ and process/features/*/active/ only. Use after approach is decided.