dia-migration
starsforks
How to install dia-migration?
pssah4/digital-innovation-agents/dia-migration
$npx -y skills add pssah4/digital-innovation-agents --skill dia-migrationConvenience wrapper for existing DIA users upgrading between DIA versions (e.g. v1 -> v2 -> v3). Runs the migration scripts under tools/migration/ in sequence: detect state, strip status duplicates, rename IDs (FEATURE-NNNN -> FEAT-EE-FF, EPIC-NNN -> EPIC-NN), flatten analysis/
SKILL.md
| 1 | # DIA Migration |
| 2 | |
| 3 | Convenience wrapper that brings an **existing DIA repo** to current |
| 4 | conventions. Not a brownfield onboarding skill -- for that, use |
| 5 | `/reverse-engineering`, which contains the same migration mechanics |
| 6 | plus a full code-walk for missing artefacts. |
| 7 | |
| 8 | Designed for two starting states: |
| 9 | |
| 10 | - **DIA v1 -> current**: artefacts use the old patterns |
| 11 | (FEATURE-NNNN, ADR-NNN, status in frontmatter, fixes under context/, |
| 12 | archive/ folders, 20_bugs.md, numeric-prefixed context files). |
| 13 | - **Older V-Model variant -> current**: same DIA layout idea but |
| 14 | inconsistent prefixes or per-cycle handoffs. |
| 15 | |
| 16 | For **brownfield without V-Model artefacts** (code exists, no |
| 17 | `_devprocess/` directory): the answer is `/reverse-engineering`. |
| 18 | That skill detects pre-existing partial artefacts, runs the same |
| 19 | migration scripts as Phase -1.5, then walks the code to produce |
| 20 | the missing artefacts. Do not start with `/dia-migration` for |
| 21 | brownfield -- you would only get the migration step without the |
| 22 | artefact-bootstrap from code. |
| 23 | |
| 24 | The skill is **idempotent**. Running it on an already-current repo |
| 25 | performs the consistency check and exits without changes. |
| 26 | |
| 27 | ## MANDATORY Pre-Phase 0: Branch check (cross-cutting operation) |
| 28 | |
| 29 | Migration is a cross-cutting maintenance operation, not a V-Model |
| 30 | phase. It does not target a backlog item; it touches many artefacts |
| 31 | across the repo. Therefore migration runs on a dedicated branch and |
| 32 | does not set V-Model phase tags. |
| 33 | |
| 34 | Branch convention: `chore/dia-migration-<YYYY-MM-DD>`. |
| 35 | |
| 36 | Check at start (full rules: |
| 37 | `skills/project-conventions/references/team-workflow.md`): |
| 38 | |
| 39 | 1. If on `main` / `master` / `dev`: refuse, AskUserQuestion to |
| 40 | create `chore/dia-migration-<YYYY-MM-DD>` and switch. |
| 41 | 2. If on the expected migration branch (or any other `chore/*` / |
| 42 | `feature/*` branch the user explicitly confirms): silent continue. |
| 43 | 3. If on a different branch: AskUserQuestion to switch to the |
| 44 | migration branch (recommended) or stay (only when consciously |
| 45 | bundling migration with other work, which is discouraged). |
| 46 | |
| 47 | GitHub integration: migration does NOT create a per-item issue or |
| 48 | draft PR. The migration commits go in as a single chore PR |
| 49 | (`chore/dia-migration-<date>` -> `dev`). The user opens that PR |
| 50 | manually after Phase 7 completes. |
| 51 | |
| 52 | Phase tags: migration does NOT set V-Model phase tags |
| 53 | (`<id>/ba-done` etc. are reserved for backlog items). It does |
| 54 | write progress markers via per-phase commits with the message |
| 55 | prefix `chore(dia-migration): phase <N> -- <summary>` so the |
| 56 | history is reviewable. |
| 57 | |
| 58 | State stored in `.git/dia-active-skill` so subsequent invocations |
| 59 | of the migration loop stay silent if everything matches. |
| 60 | |
| 61 | ## Shared tooling |
| 62 | |
| 63 | This skill orchestrates the scripts under `tools/migration/` in the |
| 64 | DIA repo: |
| 65 | |
| 66 | | Script | Phase | Purpose | |
| 67 | |---------------------------------|-------|----------------------------------------------------------| |
| 68 | | `tools/migration/detect_state.py` | 0 | Inventory the repo, classify v1/v2/mixed. | |
| 69 | | `tools/migration/strip_frontmatter_status.py` | 2a | Remove `status:` / `phase:` from YAML frontmatter. | |
| 70 | | `tools/migration/strip_body_status.py` | 2b | Remove body-level `**Status:**` / `> **Status**:` lines. | |
| 71 | | `tools/migration/migrate_naming.py` | 3 | Rename ID schemas (FEATURE-NNNN -> FEAT-EE-FF, etc.). | |
| 72 | | `tools/migration/flatten_analysis.py` | 4 | Flatten analysis/ to BA / EXPLORE / RESEARCH / AUDIT. | |
| 73 | | `tools/migration/build_backlog.py` | 5 | Regenerate BACKLOG.md from artefact scan. | |
| 74 | | `tools/migration/migrate_skill_names.py` | 6 | Rewrite `/business-analyse` -> `/business-analysis`, |
| 75 | `/v-model-workflow` -> `/dia-guide`. | |
| 76 | | `tools/migration/migrate_status_vocabulary.py` | 5b | Rewrite BACKLOG status values to the GitHub-aligned vocabulary. | |
| 77 | |
| 78 | `/reverse-engineering` reuses the same scripts under Phase -1.5. |
| 79 | Both skills share the canonical implementation; this one wraps it |
| 80 | with a phase-by-phase confirmation loop, |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
