Grace Migrate

What it does

When your agent uses it

• Development work in your project

Example prompts

• “/grace-migrate”

Workflow steps

9 steps, taken from the first numbered list in SKILL.md.

1. 1Detect legacy docs and current .grace state. If .grace already exists, stop and ask whether migration should merge, replace, or abort.
2. 2Inventory legacy source paths and create or verify a restorable backup. Record source coverage and backup evidence in the report.
3. 3Map legacy requirements, technology, graph, verification, and operational content into the GRACE 4 layout. List ambiguities and…
4. 4Produce references/migration-report-template.xml, review references/migration-checklist.md, and ask for explicit approval before writing…
5. 5Write .grace, then run grace lint --path --assertions current and grace status --path --json. Require status projectKind grace4 with no…
6. 6If validation is not successful or generated coverage is incomplete, retain all legacy sources and stop.
7. 7Detect git availability and worktree membership. If git is available for the project, record git status --porcelain --untracked-files=all…
8. 8Present an exact cleanup proposal containing only inventoried legacy paths. Ask for a separate explicit cleanup approval. For a dirty…
9. 9Archive or delete only the approved paths, record each result, and leave the backup intact. Do not use broad globs, hidden shell cleanup…

What it can do on your machine

Read from SKILL.md and the folder at commit 70f5ec4. It shows what the files ask for, not the result of running them.

• Tool permissions

  Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

  From allowed-tools in the SKILL.md frontmatter.

• Runs code

  Shell commands in SKILL.md call:

  • git

  From the folder's file list and the shell code blocks in SKILL.md.

• Network

  No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

  From URLs in SKILL.md, links to its own repository left out.

• Credentials

  Names no API keys, tokens, secrets or passwords.

  From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Grace Migrate loads about 706 tokens when it runs, and up to ~1.8k if it reads all its reference files. Until then it costs about 32 tokens; SKILL.md has 346 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it

~32

When it runs · the whole SKILL.md, loaded when a task matches

~706

With references · SKILL.md plus every file in references/, read only if the agent opens them

~1.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from osovv/grace-marketplace at commit 70f5ec4, republished under its MIT licence (© osovv). 346 words, ~706 tokens.

name

grace-migrate

description

Agent-applied GRACE 3 to GRACE 4 migration workflow. CLI validates the result but does not convert or delete files.

<skill>
<migration_safety>
Migration is copy-and-validate, not destructive conversion. Before writing `.grace`, inventory every legacy source, record a restorable backup path outside the proposed cleanup set, present the migration report, and wait for explicit write approval. Never create retroactive `C-*` bundles.
</migration_safety>

<workflow>
1. Detect legacy docs and current `.grace` state. If `.grace` already exists, stop and ask whether migration should merge, replace, or abort.
2. Inventory legacy source paths and create or verify a restorable backup. Record source coverage and backup evidence in the report.
3. Map legacy requirements, technology, graph, verification, and operational content into the GRACE 4 layout. List ambiguities and unsupported structures rather than guessing.
4. Produce `references/migration-report-template.xml`, review `references/migration-checklist.md`, and ask for explicit approval before writing `.grace`.
5. Write `.grace`, then run `grace lint --path <project-root> --assertions current` and `grace status --path <project-root> --json`. Require status `projectKind` `grace4` with no integrity errors, and record commands, exit states, and findings.
6. If validation is not successful or generated coverage is incomplete, retain all legacy sources and stop.
7. Detect git availability and worktree membership. If git is available for the project, record `git status --porcelain --untracked-files=all` before cleanup.
8. Present an exact cleanup proposal containing only inventoried legacy paths. Ask for a separate explicit cleanup approval. For a dirty worktree or non-git project, require another explicit acknowledgement naming that risk.
9. Archive or delete only the approved paths, record each result, and leave the backup intact. Do not use broad globs, hidden shell cleanup, or unreviewed recursive deletion.
</workflow>

© osovv, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (references) in skills/grace/grace-migrate of osovv/grace-marketplace.

• SKILL.md
• agents/openai.yaml
• references/migration-checklist.md
• references/migration-report-template.xml

Open the folder on GitHubat commit 70f5ec4