CtrlK
BlogDocsLog inGet started
Tessl Logo

dia-migration

Convenience 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/, regenerate BACKLOG.md, update skill-name references, run `/consistency-check` mode A. Idempotent. Use this skill when the user already has DIA artefacts and wants to upgrade to current conventions without the full reverse-engineering walk. Triggers: "migrate to DIA v2", "migrate v1", "upgrade DIA", "convert backlog", "restructure backlog", "FEATURE to FEAT". For BROWNFIELD projects (no `_devprocess/` yet, only code), use `/reverse-engineering` instead -- it absorbs the same migration mechanics for any pre-existing partial artefacts and additionally walks the code to fill the gaps.

67

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

62%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a thorough and well-structured migration workflow with excellent sequencing, validation checkpoints, and rollback procedures. However, it suffers significantly from verbosity — repeating information across sections (e.g., legacy mini-BA handling described three times), including a redundant tools table, and explaining context that Claude doesn't need. The content would benefit greatly from being split into a concise overview SKILL.md with detailed phase references in separate files.

Suggestions

Deduplicate repeated content: the tools table appears twice, the mini-BA migration is described in Phases 1, 3, and 4, and the brownfield vs migration distinction is explained three times. Consolidate each to a single authoritative location.

Move the detailed rename mapping tables (Phase 3, Phase 4, Phase 5b) into a separate MIGRATION-REFERENCE.md file and reference it from the main skill, keeping only a summary in SKILL.md.

Remove the Keywords section entirely — it serves no purpose for Claude's execution and wastes tokens.

Trim explanatory prose that restates what the scripts do (e.g., 'The script does two passes: first the file renames, then a global text replacement') — Claude can read the script summaries from the tools table.

DimensionReasoningScore

Conciseness

The skill is extremely verbose at ~450+ lines. It over-explains many details that Claude could infer (e.g., what brownfield means, repeated explanations of when to use /reverse-engineering vs this skill, the tools table appearing twice, extensive rename mapping tables). The Keywords section at the end is pure padding. Many sections repeat information already stated earlier (e.g., the legacy mini-BA move is described in Phase 1, Phase 3, and Phase 4).

2 / 5

Actionability

The skill provides concrete script paths, exact CLI commands, specific file patterns, and detailed rename mappings. Each phase has clear executable steps with named scripts. However, the scripts themselves are external and not shown — the skill assumes they exist and work correctly. The bash commands in Phase 8 are copy-paste ready, and the commit message format is specific.

4 / 5

Workflow Clarity

The workflow is exceptionally well-sequenced across 8+ phases with explicit validation checkpoints. The pre-flight branch check is a gate, each phase commits independently for rollback, Phase 7 runs a consistency check, and there are clear failure/rollback procedures. User confirmation is required at multiple points (Phase 0 plan, Phase 3 rename plan, Phase 5 backlog overwrite). The feedback loop of detect-fix-revalidate is present.

5 / 5

Progressive Disclosure

The skill references external files (team-workflow.md, templates, other skills) but inlines an enormous amount of detail that could be split into separate reference files — the rename mapping tables, the analysis flattening rules, and the status vocabulary mapping could all be in referenced documents. No bundle files are provided, so we can't verify references exist. The content is structured with clear headers but is monolithic in practice.

3 / 5

Total

14

/

20

Passed

Description

100%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is an excellent skill description that comprehensively covers what the skill does with specific concrete actions, when to use it with explicit trigger phrases, and how it differs from related skills. It uses proper third-person voice throughout and provides enough detail for Claude to confidently select or reject this skill from a large pool. The boundary guidance distinguishing it from /reverse-engineering is a notable strength.

DimensionReasoningScore

Specificity

The description lists multiple specific concrete actions: detect state, strip status duplicates, rename IDs (with format examples), flatten analysis/, regenerate BACKLOG.md, update skill-name references, and run consistency-check mode A. This is comprehensive coverage of what the skill does.

5 / 5

Completeness

Clearly answers 'what' (runs migration scripts in sequence with specific steps listed) and 'when' (explicit 'Use this skill when...' clause plus enumerated trigger phrases). Also includes a boundary condition distinguishing it from /reverse-engineering for brownfield projects.

5 / 5

Trigger Term Quality

Includes explicit trigger phrases ('migrate to DIA v2', 'migrate v1', 'upgrade DIA', 'convert backlog', 'restructure backlog', 'FEATURE to FEAT') that cover natural user language and synonyms. Also includes contextual terms like 'DIA artefacts', 'upgrade', and version references.

5 / 5

Distinctiveness Conflict Risk

Highly distinctive with a clear niche (DIA version migration). Explicitly differentiates itself from the /reverse-engineering skill for brownfield projects, minimizing conflict risk. The specific ID format examples (FEATURE-NNNN -> FEAT-EE-FF) and tool paths further narrow its scope.

5 / 5

Total

20

/

20

Passed

Validation

90%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (561 lines); consider splitting into references/ and linking

Warning

Total

10

/

11

Passed

Repository
salemaziel/digital-innovation-agents
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.