Workspace Migration

Workspace Migration

Use this skill when a user wants an existing workspace adjusted to OpenArc conventions.

Goal

Move an existing repository toward OpenArc structure while preserving working project intent and minimizing churn.

Migration Workflow

1. Inventory the workspace:

• agent guides
• README and docs
• code style docs, formatter config, lint config, tests, and naming conventions
• repo profile and profile-relevant PRD/design/brand materials
• specs, plans, tasks
• assets
• changelog and releases
• CI and GitHub workflows

1. Map existing files to OpenArc targets.
2. Identify missing code style preferences that cannot be inferred from existing config or code.
3. For UI, frontend, desktop, mobile, or component profiles, identify missing design preferences that cannot be inferred from existing design docs, components, CSS, or assets.
4. Classify actions:

• keep as-is
• patch in place
• move or rename
• create missing
• archive duplicate

1. Produce a migration plan before editing.
2. Ask for confirmation before moving or renaming files.
3. Apply small patches first.
4. Validate links, docs, JSON/YAML, tests, and release workflow as applicable.
5. Report all created, modified, moved, and skipped files.

If scripts/openarc.py is available, start with:

python3 plugins/openarc/scripts/openarc.py scan .

Use the scan to seed the migration plan, not to auto-move files.

Profile-Aware Target Structure

AGENT.md or AGENTS.md
README.md
docs/
  PROJECT_BRIEF.md
  CODE_STYLE.md
  TASKS.md
  CHANGELOG_AI.md
  specs/
  plans/
  tasks/
  archive/
  PRD.md        # app/product profile when needed
  DESIGN.md     # UI/frontend/desktop/mobile profile when needed
  BRAND.md      # public brand or identity profile when needed
  assets/       # UI, brand, screenshots, or visual references when needed
    brand/
    icons/
    illustrations/
    screenshots/
    references/

Rules

• Existing files win over templates.
• Preserve inferred code style in docs/CODE_STYLE.md; ask only for preferences the repo cannot reveal.
• Repo profile controls target scope; script, CLI, automation, library, and docs-only repositories do not need design or brand scaffolding by default.
• Do not flatten useful project-specific organization.
• Do not move files only for aesthetics.
• Do not delete legacy docs unless the user explicitly confirms deletion.
• Prefer aliases, index links, or patching when moving would break references.
• Use templates/MIGRATION.template.md for persistent migration plans.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Yipxiyi
• Source: Yipxiyi/OpenArc
• License: MIT
• Homepage: https://github.com/Yipxiyi/OpenArc

Install and usage instructions live in the source repository linked above.