Automated summary

Drives a Kotlin/Spring backend verification loop — the Gradle `verify` task (ktlint + unit tests), plus Testcontainers integration tests when repositories or Flyway migrations changed — and iterates on fixes until green.

Strengths

Ordered step sequence with a clear stop condition (`gradlew verify` exiting 0)
Explicit guardrails against deleting, skipping, or disabling tests just to pass
Runs integration tests only when the diff touches repos, migrations, or `*IT` files, avoiding slow cycles
Includes a `ktlintFormat` step so the style gate does not fail the build at the end
Reinforces the project's fixed test stack (JUnit 5, MockK, kotest-assertions) instead of letting new libraries creep in

Limitations

Tightly coupled to a project-specific Gradle setup (`verify`/`integrationTest` tasks, migration path, `com.epam.brn` package)
Covers only the local pre-PR gate — not CI, Sonar, or deployment
Assumes Docker is running for integration tests and offers no fallback when it is unavailable

When to use it

Use it after editing Kotlin/Spring backend code, or when the user asks to verify or check the build.

When not to use it

Do not use it on a project that lacks this particular Gradle task setup, or to validate frontend or infrastructure changes.

Security analysis

Safe

Quality score86/100

The skill is a purely process-oriented verification routine: it tells the agent to run local Gradle tasks (gradlew verify, ktlintCheck/ktlintFormat, integrationTest) and to fix failing code rather than weakening tests. There is no destructive command, no secret/token handling, no network exfiltration, no obfuscation, and no attempt to override safety or instructions. The only execution surfaces are standard build/test commands (and a local Postgres Testcontainer via Docker for integration tests), which is ordinary, legitimate developer workflow.

No concerns found

How this analysis is made

Examples

Verify after a service change

I just refactored BrnService to use the new ExerciseRepository API. Run the verification loop and fix anything that fails.

Migration touched

I added a Flyway migration that renames a column in the exercise table. Verify the build, and run the integration tests since the schema changed.

Lint gate fails

gradlew verify is failing on ktlint rules. Format the code, re-run the gate, and tell me what you had to change.

name: verify description: Run the backend verification loop after Kotlin/Spring code changes — Kotlin style + unit tests via `gradlew verify`, plus integration tests when repos/migrations changed — and drive fixes until green. Use after editing backend code or when the user asks to verify/check the build.

Verify

Name: Verify Kotlin/Spring backend changes
Author: Skills Guide Bot

The routine for confirming a backend change is correct. Fix the implementation to satisfy the checks; never weaken the checks to fit the implementation.

Steps

Scope the change. Note which files/modules changed. If you touched repositories, Flyway migrations (src/main/resources/db/migration), or any *IT test, mark that integration verification is required.
Fast feedback while iterating (optional). For a quick loop on one area, run the narrowest useful target first, e.g. gradlew test --tests "com.epam.brn.service.SomeServiceTest".
Run the gate. gradlew verify — this is ktlintCheck + unit test, no Docker. Do not treat the task as done until it exits 0.
On failure, find the root cause. Read the actual failure (assertion, compile error, or ktlint rule). Fix the implementation. Only edit a test if the test itself is provably wrong — then state explicitly what you changed and why. Never delete/skip/@Disabled a test just to go green.
Repeat steps 3–4 until gradlew verify passes.
Style. Run gradlew ktlintFormat before finishing; the ktlint gate fails the build otherwise. Re-run gradlew verify if it reformatted anything.
Integration (only if step 1 flagged it). Ensure Docker is running, then gradlew integrationTest. These use a Postgres Testcontainer and are slow — run them once at the end, not on every edit.

Conventions to respect

Test stack is fixed: JUnit 5 + MockK + kotest-assertions. Do not introduce Mockito, AssertJ, Kluent, kotlin.test, or JUnit Assertions (see CLAUDE.md).
gradlew verify is a local pre-PR gate, not a replacement for CI/Sonar.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/verify-kotlin-spring-backend-changes-mvda86uw/download' --output '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md.part' && mv '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md.part' '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code

test -f '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md' && test -s '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/verify' && cp -R '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw' '.claude/skills/verify'

Cursor

test -f '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md' && test -s '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/verify' && cp -R '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw' '.cursor/skills/verify'

Codex

test -f '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md' && test -s '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/verify' && cp -R '.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw' '.agents/skills/verify'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation

openskills install './.skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw'

openskills read 'verify-kotlin-spring-backend-changes-mvda86uw'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/verify-kotlin-spring-backend-changes-mvda86uw/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.