mcpbeat Sign in

Review Groovy Migration Skill for Claude

> Post-migration quality review. Checks Java test files produced by migrate-groovy-to-java against the shared quality rules. Use after migration, or on any branch with recently migrated .java test files. Produces structured FINDING blocks grouped by severity, then offers to auto-fix BLOCKERs and WARNINGs.

1k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
727
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/DataDog/dd-trace-java --skill review-groovy-migration

What it tells the agent to use

found in the instruction text
Grep reads your files

The instruction itself

6 sections, as written by the author

Review migrated Java test files against the quality rules.

Step 1 — Load rules

Read .claude/skills/migrate-groovy-to-java/QUALITY_RULES.md in full before proceeding.

Step 2 — Identify target files

If the user specified files or a module path, use those. Otherwise, find files added on the current branch:

MERGE_BASE=$(git merge-base HEAD origin/master 2>/dev/null || git merge-base HEAD master)
git diff "$MERGE_BASE" --name-only --diff-filter=A | grep 'src/test/java.*\.java$'

If no files are found, fall back to modified test files:

git diff "$MERGE_BASE" --name-only | grep 'src/test/java.*\.java$'

Step 3 — Run grep-based detection

For each rule with a grep Detection pattern, run it over the target files. Use the patterns from the rules file. The patterns below assume GNU/ugrep-compatible regex (\b, \.); alternation uses grep -E "...|..." so it also works under BSD grep — adapt if your grep differs.

# RULE-C01  (also fires on RULE-C02 lines — see dedup note below)
grep -rn "assertTrue(.*instanceof" <files>

# RULE-C02  (more specific than C01)
grep -rEn "assertTrue\(.*== *null.*instanceof|assertTrue\(.*instanceof.*== *null" <files>

# RULE-F01  (BLOCKER, but verify context — see note below)
# Run as three separate greps: word boundaries (\b) combined with | alternation
# misbehave under some grep builds, so do not merge these into one alternation.
grep -rEn "\bint\b.*[Ss]ampling[Pp]riority" <files>
grep -rEn "\bint\b.*\bpriority\b" <files>
grep -rEn "\bint\b.*\bmechanism\b" <files>

# RULE-A02
grep -rn '@WithConfig(key = "' <files>

# RULE-B01
grep -rn "new LinkedHashMap<>()" <files>

# RULE-C04
grep -rn "\.getTags()\.get(" <files>

# RULE-C05  (BLOCKER, but verify context — see note below)
# A matcher is only legitimate for genuinely non-deterministic values; otherwise it
# silently relaxes an assertion the Groovy original pinned. Cross-check the Groovy source.
grep -rEn "any\(\)|anyInt\(\)|anyLong\(\)|anyString\(\)|anyByte\(\)|anyBoolean\(\)|atLeastOnce\(\)" <files>

# RULE-D01
grep -rn "mock(.*Map.*\.class)" <files>

# RULE-G01
grep -rn "/\* [a-z]" <files>

# RULE-G02
grep -rEn "\(\) -> [a-zA-Z]+\.[a-zA-Z]+\(\)" <files>

# RULE-G05  (verify context — only when close() is the finally's sole statement and there
# is no surrounding logic requiring an explicit close; read the block before flagging)
grep -rEn "\} finally \{" <files>

# RULE-H01
grep -rEn "'18446744073709551[0-9]+'" <files>

# RULE-J02
grep -rEn "CarrierVisitor|forEachKeyValue" <files>

Read the full content of any file that has at least one hit, to understand the context.

Step 4 — Structural detection (LLM-based)

For rules without grep patterns (RULE-A01, RULE-B02, RULE-B03, RULE-C03, RULE-E01, RULE-E02, RULE-E03, RULE-G04, RULE-H02, RULE-I01, RULE-I02), read all target files and identify violations based on the Before/After examples in the rules.

Step 5 — Emit structured findings

For each issue found, emit one finding block:

FINDING
  file:     <absolute path>
  line:     <line number, or range start-end>
  rule:     <RULE-XNN>
  severity: <BLOCKER|WARNING|STYLE>
  excerpt:  <the offending code, single line>
  fix:      <the corrected code, single line or brief description>

Group all findings by severity: BLOCKERs first, then WARNINGs, then STYLEs.

At the end, print a one-line summary:

Summary: N blocker(s), M warning(s), K style issue(s) across F file(s).

If no issues are found:

No findings. All rules pass.

Step 6 — Offer to fix

After the summary, ask: "Fix all BLOCKERs and WARNINGs automatically? (yes / no / select rules)"

If the user agrees:

  • Apply each fix. For each file changed, run ./gradlew spotlessApply on its module after editing.
  • Re-run the grep checks to confirm the findings are resolved.
  • Report which findings were fixed and which (if any) require manual attention.

Other skills for the same job

different authors, same section of the catalogue
Finishing A Development Branch
by ZhanlinCui
×7

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

1k tokens
Github Release Management
by ComeOnOliver
×3

Comprehensive GitHub release orchestration with AI swarm coordination for automated versioning, testing, deployment, and rollback management

10k tokens
Migrate To Shoehorn
by mxyhi
×2

Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

965 tokens
Bun Development
by ComeOnOliver
×2

Modern JavaScript/TypeScript development with Bun runtime. Covers package management, bundling, testing, and migration from Node.js. Use when working with Bun, optimizing JS/TS development speed, or migrating from Node.js to Bun.

8k tokens
Framework Migration Deps Upgrade
by ComeOnOliver
×2

You are a dependency management expert specializing in safe, incremental upgrades of project dependencies. Plan and execute dependency updates with minimal risk, proper testing, and clear migration pa

8k tokens
Debugging Strategies
by ComeOnOliver
×2

Master systematic debugging techniques, profiling tools, and root cause analysis to efficiently track down bugs across any codebase or technology stack. Use when investigating bugs, performance issues, or unexpected behavior.

6k tokens
Backend Dev Guidelines
by ComeOnOliver
×2

Opinionated backend development standards for Node.js + Express + TypeScript microservices. Covers layered architecture, BaseController pattern, dependency injection, Prisma repositories, Zod validation, unifiedConfig, Sentry error tracking, async safety, and testing discipline.

36k tokens
Javascript Typescript Jest
by github
vendor ×1

Best practices for writing JavaScript/TypeScript tests using Jest, including mocking strategies, test structure, and common patterns.

558 tokens

How to use it

Copy the folder

Take datadog/review-groovy-migration from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.