Skip to content
Back to skills

Blueprint Migration

BSecurity

Versioned migration procedures for blueprint format upgrades (v1.x to v3.3). Use when blueprint-upgrade needs version-specific logic, content hashing, or rollback.

  • 58 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added February 8, 2026
toolsbash

Security analysis

B85/100
  • highPerforms destructive filesystem operations

Pro scans all 4 files and shows the line behind each finding

Scanned September 3, 2026

npx -y skills add laurigates/claude-plugins --skill blueprint-migration --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Blueprint Migration?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Blueprint Migration
[![Security: B — Skills Directory](https://www.skillsdirectory.com/api/skills/laurigates-blueprint-migration/badge)](https://www.skillsdirectory.com/skills/laurigates-blueprint-migration)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: blueprint-migration
description: Versioned migration procedures for blueprint format upgrades (v1.x to v3.3). Use when blueprint-upgrade needs version-specific logic, content hashing, or rollback.
user-invocable: false
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion, TodoWrite
created: 2025-12-22
modified: 2026-05-09
reviewed: 2026-04-25
---

# Blueprint Migration

Expert skill for migrating blueprint structures between format versions. This skill is triggered by `/blueprint:upgrade` and handles version-specific migration logic.

## When to Use This Skill

| Use this skill when... | Use blueprint-upgrade instead when... |
|---|---|
| You need version-specific migration logic (v3.0→v3.1, v3.2→v3.3, etc.) | You're invoking the user-facing upgrade workflow with prompts |
| You need content hashing to detect manual modifications during migration | You want the high-level "upgrade my blueprint" entry point |
| You're implementing a new migration step between format versions | Use blueprint-init instead when the project has no manifest yet |

## Core Expertise

- Reading and parsing the blueprint manifest (`docs/blueprint/manifest.json` in v3.0+, or legacy `.claude/blueprints/.manifest.json` in v1.x/v2.x) for current version
- Determining appropriate migration path based on version comparison
- Executing versioned migration steps with user confirmation
- Content hashing for detecting manual modifications
- Safe file moves with rollback capability

## Canonical Manifest Filename

- **v3.0+**: `docs/blueprint/manifest.json` (canonical, no dot prefix — produced by `/blueprint:init`). Some repos carry a legacy `docs/blueprint/.manifest.json` from earlier v3.0 migrations; upgrade tooling tolerates both via the `$MANIFEST` variable resolved in `/blueprint:upgrade` Step 2.
- **v1.x/v2.x (historical)**: `.claude/blueprints/.manifest.json` — references to this path in v1/v2 migration documents are historical and must not be renamed.

## Migration Workflow

```
1. Read current manifest version
2. Compare with target version (latest: 3.3.0)
3. Load migration document for version range
4. Execute migration steps sequentially
5. Confirm each destructive operation
6. Update manifest to target version
7. Report migration summary
```

## Available Migrations

| From | To | Document |
|------|-----|----------|
| 1.0.x | 1.1.x | `migrations/v1.0-to-v1.1.md` |
| 1.x.x | 2.0.0 | `migrations/v1.x-to-v2.0.md` |
| 2.x.x | 3.0.0 | `migrations/v2.x-to-v3.0.md` |
| 3.0.x | 3.1.0 | `migrations/v3.0-to-v3.1.md` |
| 3.1.x | 3.2.0 | inline in `blueprint-upgrade` (step 3a) |
| 3.2.x | 3.3.0 | `migrations/v3.2-to-v3.3.md` |

## Version Detection

```bash
# Resolve manifest path — canonical first, then tolerated variants
if [[ -f docs/blueprint/manifest.json ]]; then
  MANIFEST=docs/blueprint/manifest.json
elif [[ -f docs/blueprint/.manifest.json ]]; then
  MANIFEST=docs/blueprint/.manifest.json
elif [[ -f .claude/blueprints/.manifest.json ]]; then
  MANIFEST=.claude/blueprints/.manifest.json
fi

jq -r '.format_version // "1.0.0"' "$MANIFEST"

# Detect v1.0 (no format_version field — legacy v1.x/v2.x location only)
if [[ -f .claude/blueprints/.manifest.json ]] && \
   ! jq -e '.format_version' .claude/blueprints/.manifest.json > /dev/null 2>&1; then
  echo "v1.0.0"
fi
```

## Content Hashing

For detecting modifications to generated content:

```bash
# Generate SHA256 hash of file content
sha256sum path/to/file | cut -d' ' -f1

# Compare with stored hash in manifest (use $MANIFEST from Version Detection above)
jq -r '.generated.skills["skill-name"].content_hash' "$MANIFEST"
```

## Migration Execution Pattern

When executing migrations:

1. **Announce step** - Explain what will happen
2. **Check prerequisites** - Verify source exists, target doesn't
3. **Confirm with user** - Use AskUserQuestion for destructive operations
4. **Execute** - Perform the migration step
5. **Verify** - Check operation succeeded
6. **Update manifest** - Track completion in manifest

## Error Handling

If migration fails:
- Stop immediately (fail-fast)
- Report which step failed and why
- Preserve original files (don't delete until confirmed)
- Provide manual recovery instructions

## Quick Reference

| Operation | Command |
|-----------|---------|
| Check version | `jq -r '.format_version' "$MANIFEST"` (resolve `$MANIFEST` first; see Version Detection) |
| Hash file | `sha256sum file \| cut -d' ' -f1` |
| Safe move | `cp -r source target && rm -rf source` |
| Check empty dir | `[ -z "$(ls -A dir)" ]` |

Files in this skill

  • migrations/v1.0-to-v1.1.md1.9 KB
  • migrations/v1.x-to-v2.0.md6 KB
  • migrations/v2.x-to-v3.0.md12.1 KB
  • skill.md2.9 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…