Skip to content
Back to skills

Wiki Migration

ASecurity

Use when a wiki page's schema_version is behind the registry's current version for its page type. Owns the minimal schema registry (schemas.json) and a thin verify/apply primitive for running one migration directory against one page. Invoked by /ren:update, not directly by the friend.

  • 2 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 2, 2026
ai-agents

Security analysis

A100/100

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

Scanned September 20, 2026

npx -y skills add hazarsozer/ren-os --skill wiki-migration --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Wiki Migration?

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

Security grade badge for Wiki Migration
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/hazarsozer-wiki-migration/badge)](https://www.skillsdirectory.com/skills/hazarsozer-wiki-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: wiki-migration
description: |
  Use when a wiki page's schema_version is behind the registry's current
  version for its page type. Owns the minimal schema registry
  (schemas.json) and a thin verify/apply primitive for running one
  migration directory against one page. Invoked by /ren:update, not
  directly by the friend.
version: 0.8.8
license: MIT
type: skill
execution_tier: deterministic
schema_version: 1
framework_version: "0.8.8"

contract:
  required_outputs:
    - "run_migration() returns the migrate.sh subprocess's exit code + stdout/stderr, never raising"
    - "verify_page() returns (passed, failures) against a verify.json's assertions"
  budgets:
    turns: 5
    files_written: 0
    duration_seconds: 30
  permissions:
    read:
      - "skills/wiki-migration/schemas.json"
      - "migrations/**"
      - "~/.renos/wiki/**"
    write: []
    execute:
      - "migrations/*/migrate.sh"
  completion_conditions:
    - "load_registry() returns the page_types dict without raising, even if schemas.json is malformed"
  output_paths: []

tags: [migration, schema, registry, verify]
related_skills: [update, doctor]
references_required: []
references_on_demand: []
---

# wiki-migration

The minimal registry + runner `/ren:update` (and `/ren:doctor`'s schema-version check) drive migrations through. Per spec §7.1, donor's heavy chain-computer + registry-template + JSON-schema-validated verify-page.sh machinery is **pre-excluded** for 0.2 — this is deliberately thin.

## `schemas.json`

Enumerates only the page types actually stamped by something in this repo: `identity`, `l2-map` (both still at their initial schema, no migrations yet), and `routine-spec` (schema 3, migrated via `routine-spec-1-to-2` then `routine-spec-2-to-3`). Not a speculative full taxonomy — add an entry only when a page type gets a real migration.

## The env-mapping shim (load-bearing)

`migrations/routine-spec-1-to-2/` was **carried verbatim** from donor and expects `SF_WIKI_ROOT`/`SF_SNAPSHOT_DIR`. `migrations/routine-spec-2-to-3/` was written fresh for this repo and expects `REN_WIKI_ROOT`/`REN_SNAPSHOT_DIR`. `run_migration()` sets **both** pairs of env vars to the same values on every invocation, so the same thin runner drives either migration directory without needing to know in advance which naming convention its `migrate.sh` reads. This is documented here rather than fixed at the source, because "carry verbatim" for 1-to-2 was an explicit instruction (Task 6.3) — the shim is the seam, not a bug to clean up.

## Behavior

1. `load_registry()` reads `schemas.json`.
2. `migration_chain(page_type, from_version)` returns the ordered subset of that page type's migration directories still needed to reach `current`.
3. For each directory in the chain: `run_migration(migration_dir, page_path, wiki_root, snapshot_dir)` invokes its `migrate.sh` (idempotent, in-place — see each migration's own README for what it changes).
4. `verify_page(verify_json_path, page_path)` checks the migrated page's frontmatter against that migration's `verify.json` assertions (`yaml.valid`/`yaml.equals`/`yaml.present`/`yaml.in`; `snapshot.body-identical` is not implemented here — callers that need it compare bodies directly, which both migration test suites already do).

## What this skill does NOT do

- Compute a full dependency-ordered migration chain across ALL page types with cross-references (donor's chain-computer). This is a flat per-page-type list.
- Validate `verify.json` files against a JSON Schema. `verify_page()` is a small, direct predicate interpreter for the four predicate kinds actually used by the two migrations in this repo.
- Decide WHEN to migrate. `/ren:update` (this skill's only caller) owns the snapshot-before/diff-approval/apply flow around these primitives.

## References

- `migrations/routine-spec-1-to-2/`, `migrations/routine-spec-2-to-3/` — the two migration directories this skill can run
- `skills/update/` — the only intended caller of `run_migration`/`verify_page`
- `skills/doctor/` — reads `load_registry()`/`migration_chain()` for its schema-version check

Files in this skill

  • SKILL.md4 KB
  • lib/__init__.py7.5 KB
  • schemas.json1.8 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…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.