amplicode

get_project_summary

list_module_dependencies

get_entity_details

mcp__amplicode__

• If at least one Amplicode tool is available — MCP is connected. Proceed with the skill below.
• If none are available — stop and invoke the

  amplicode-install

  skill (bundled with the Spring Agent Toolkit). It installs the Amplicode plugin and walks the user through the «Настроить Spring Agent» welcome-screen button + MCP-client restart. After it completes, the MCP tools become available — resume this skill.
• If

  amplicode-install

  is not registered in your skill list, tell the user (in their language): "This skill needs the Amplicode IntelliJ plugin and its MCP server. Install it from https://amplicode.ru/marketplace into IntelliJ IDEA Ultimate/Community or GigaIDE, open any project, click «Настроить Spring Agent» on the Amplicode welcome screen, then restart your MCP client."

CRITICAL: Code ONLY from examples/ files. If no matching example -- STOP and ask user. CRITICAL: For questions with a fixed set of choices, prefer

AskUserQuestion

> its analogue > plain text list. Plain numbered text lists are the last resort when no interactive tool is available. CRITICAL: Read the conversation context BEFORE running Step 1. Half the questions in Steps 2–7 may already be answered by the user's prompt and prior turns. Re-asking what was already said is the #1 reason this skill feels slow. Step 7 (mapper) is automatic when conversion is needed. If from context it is clear that the DTO will be used in code that converts entities to/from DTOs (controller, service, endpoint replacement, etc.), the skill MUST delegate to

mapper-creator

— never write manual mapping code inline. The

mapper-creator

skill decides the implementation (MapStruct, Custom, adding dependencies) — this skill just delegates.

{EntityName}Dto

get_project_summary

id

references/sub-dto.md

Set<Integer> specialtyIds

references/sub-dto.md

.editorconfig

• Question "Which entity?" -> user answers "Order" -> this IS the entity, don't re-ask
• Question "Variant?" -> user answers "record" -> this IS Java record, don't show options
• If user provides multiple answers in one message -> accept all, skip answered questions
• NEVER ask a question that the user already answered (even implicitly)

AskUserQuestion

• Belong to the same logical section (e.g. both are Java method generation settings)
• Don't depend on each other's answers
• Have obvious defaults that the user can skip

• Maximum 3-4 questions per

  AskUserQuestion

  call
• Mark the recommended option with

  (Recommended)

  and place it first
• Never batch questions from DIFFERENT decision branches
• The primary branching question (entity selection, variant) is always asked ALONE
• Prefer

  AskUserQuestion

  for choices; fall back to plain text lists only if the tool is unavailable

1. Context is unambiguous → decide silently, do NOT ask. Examples: language and JDK from

   get_project_summary

   ; Lombok / Jackson / Hibernate Validator from

   list_module_dependencies

   ; package from the entity FQN; className from

   {Entity}Dto

   ; back-reference

   @ManyToOne

   filtering; auto-selection of sub-entity scalars; record vs. plain class when JDK ≥ 16 and no Lombok and the user did not request otherwise. Exception: subDtoType is NEVER decided silently — it always requires at minimum principle 2 (one-line confirmation), unless the USER explicitly stated the shape in their own message (not in ARGUMENTS).
2. Context gives a strong signal → state the decision + alternatives in one line, let the user override or stay silent. Format:

   Will create `ScheduleTemplateDto` as a Java record with nested `SlotDto` (record).
   Alternatives: plain class, Lombok, separate file for SlotDto. OK?

   The user can answer "ok" / "yes" / silence → accept; or name an alternative → switch. This is not the same as the numbered question format — it is a single confirmation line.
3. Context yields no clear default → ask with

   AskUserQuestion

   (preferred) or its analogue, with the recommended option first. When

   AskUserQuestion

   is available, use it with

   preview

   fields so the user sees the concrete code shape for each option. Mark the recommended option with

   (Recommended)

   in its label and place it first. If no interactive choice tool is available, fall back to a plain text list. Never ask iteratively ("which variant?" → user picks → "which fields?" → …) when one batched call would do.
4. Context is fully empty for a critical input → ask plainly. This applies to: which entity, which fields (when not "all"), the user's intent itself.

AskUserQuestion

AskUserQuestion

• Each call may contain up to 4 questions that are independent of each other (the tool will render them together). Use this to batch related decisions in one round-trip.
• Each question has 2–4 options. The tool auto-adds an "Other" choice for free-form input — never include it manually.
• Mark the recommended option by putting it first with

  (Recommended)

  appended to the label.
• Use

  multiSelect: true

  for "which fields to include" or "which validators to add" — anything where multiple answers are valid.

• header

  is a 12-char chip label (e.g. "Variant", "Sub-DTO", "Fields").
• Each option has a

  description

  explaining what the choice means or its consequence (one short sentence).

AskUserQuestion

• Free-form input where there is no enumerable set of options (e.g. arbitrary class name, arbitrary field rename) — ask in plain text.
• The "single confirmation line" form from principle 2 — that is a plain question with an obvious yes/no, not an enumerated choice.

get_project_summary

language

jdkVersion

moduleName

canUseRecords = jdkVersion >= 16

list_module_dependencies

list_module_dependencies(moduleName)

presentDeps

• springBootVersion

  /

  bootMajor

  — no branching depends on it

• buildFile

  — DTO generation does not edit the build file (no dependencies to add); a DTO needs only language constructs

• mainPackage

  — the DTO's package is derived from the entity's FQN, not from the project root

• list_application_properties_files

  /

  propsFile

  — DTO writes nothing to

  application.properties

• list_all_domain_entities

  — needed only if the user did not name an entity in their prompt. Defer to Step 2 as a lazy fallback.

• get_entity_details

  /

  list_entity_dtos

  — depend on knowing the entity, which happens in Step 2. Defer to Step 2.

presentDeps

get_project_summary

• hasLombok

  =

  presentDeps

  contains

  lombok

• hasJackson

  =

  presentDeps

  contains

  jackson-databind

  or

  jackson-core

• hasValidation

  =

  presentDeps

  contains

  hibernate-validator

  or

  jakarta.validation-api

  or

  spring-boot-starter-validation

• canUseRecords

  =

  language == JAVA

  AND

  jdkVersion >= 16

get_project_summary

list_module_dependencies

• The user explicitly said "choose fields" / "ask about fields" / "fine-tune settings", OR
• The entity has many fields and the purpose signal is ambiguous AND the user did not say "use defaults".

AskUserQuestion

multiSelect: true

{Entity}Dto

references/sub-dto.md

references/kotlin.md

hasLombok = true

references/java-lombok.md

canUseRecords = true

hasLombok = false

references/java-record.md

canUseRecords = false

hasLombok = false

references/java-plain.md

hasLombok = true

canUseRecords = true

references/java-plain.md

references/java-record.md

hasLombok = true

references/java-lombok.md

• plain →

  references/java-plain.md

• record →

  references/java-record.md

• Lombok →

  references/java-lombok.md

1. Determine target path:

   src/main/{java|kotlin}/{packagePath}/{className}.{java|kt}

2. Follow the Generation Order from the selected reference file.
3. For each step:
   If skeleton (new file):
   • Read the skeleton

     .md

     from

     examples/_skeletons/

   • Apply variable substitutions
   • Use Write tool to create the file
   If fragment:
   • Read the fragment

     .md

     from

     examples/_fragments/

   • Read the Insert Point to know WHERE to insert
   • Use Edit tool to insert code at the specified point
   • Apply variable substitutions
4. Variable substitution rules:

   • {packageName}

     -> from entity package or user choice

   • {className}

     -> from user or default

     {EntityName}Dto

   • Field-level variables -> from entity details
   • NEVER substitute anything not listed in Variables
   • NEVER add imports, methods, or code not in the example
   • FQN handling (CRITICAL): examples contain FQNs (e.g.

     java.util.Objects

     ,

     java.util.List

     ,

     jakarta.validation.constraints.NotNull

     ). When writing the final file, you MUST:
     1. Replace every FQN in the body of the class with its short name (e.g.

        java.util.Objects.hash(...)

        ->

        Objects.hash(...)

        ,

        java.util.List<Integer>

        ->

        List<Integer>

        ,

        @jakarta.validation.constraints.NotNull

        ->

        @NotNull

        ).
     2. Collect every FQN you shortened and emit a corresponding

        import

        line right after the

        package

        statement, sorted, no duplicates.
     3. Types from

        java.lang

        (

        String

        ,

        Integer

        ,

        Object

        , ...) must NOT be imported and must appear as short names.
     4. Classes from the same package as the DTO must NOT be imported.
     5. Javadoc

        {@link ...}

        references — UNIFORM: Generate short name + import in

        {@link …}

        for every shape: top-level Java class, top-level Java record, nested static class, nested record, and separate-file sub-DTO (NEW_CLASS). There is no asymmetry. Always shorten the entity reference and always add the corresponding

        import

        line (unless the entity is in the same package).
     6. Group imports in two blocks separated by ONE blank line:
        • Block 1 — all third-party / project imports together:

          jakarta.*

          ,

          com.fasterxml.*

          ,

          org.springframework.*

          ,

          org.hibernate.*

          , project packages, etc. (alphabetical inside the block).
        • (blank line)
        • Block 2 —

          java.*

          and

          javax.*

          (alphabetical). Do NOT split block 1 into per-package sub-blocks. The final file must contain short names in the body (including every Javadoc

          {@link …}

          ) and a clean, grouped import block at the top.
5. For sub-DTOs (subDtoType=NEW_CLASS): create a separate file by repeating Steps 6.1-6.4 recursively for the sub-entity.
6. For nested classes (subDtoType=NEW_NESTED_CLASS): add inner class to the parent DTO file, then fill it following the same fragment rules.
7. Nested in a record parent — MANDATORY: when the parent DTO is a Java record, every

   NEW_NESTED_CLASS

   association MUST be emitted as a nested

   public record

   inside the parent record's body. The skill MUST NOT silently fall back to

   NEW_CLASS

   (separate file) just because the record-form fragment looks shorter. The full procedure is in

   references/java-record.md

   Step 6 and

   examples/_fragments/nested-class/java/nested-class.md

   ("Java record" variant). If those instructions seem ambiguous to you, that is a bug in the skill — fix the docs, do NOT work around it by changing the

   subDtoType

   .

1. .editorconfig

   at the project root (or any parent of the target file's directory). For Java files, look up the

   [*.java]

   or

   [*]

   section and read

   indent_style

   (

   tab

   or

   space

   ) and

   indent_size

   /

   tab_width

   .
2. Sample existing Java files in the same package (or the nearest ancestor package that contains Java files). Detect whether the leading whitespace on indented lines uses

   \t

   or spaces, and how many.
3. Default to 4-space if neither source is conclusive. (Tabs are also acceptable as a default if the developer explicitly prefers them, but the skill must never silently assume one over the other.)

• Field rename (

  fieldNameOverride

  ): the DTO field name can differ from the entity attribute name. Mapper generation still maps it from the original attribute.
• Add validations (

  extraValidations

  ): the user can add jakarta / hibernate-validator constraints on top of the ones inherited from the entity. The list of allowed constraints depends on the field type — see

  references/validation.md

  .
• Remove inherited validations (

  removedValidations

  ): the user can drop any constraint that came from the entity field.
• Edit annotation parameters (

  message

  ,

  min

  ,

  max

  ,

  regexp

  , …): all parameters of every constraint are editable.

• The code comes from an examples/ file (cite which one)
• Only declared variables were substituted
• No framework API calls were added "from knowledge"
• Import list matches the example exactly
• Method signatures match the example exactly
• No comments or convenience methods were added
• FQNs from examples are shortened in the body AND corresponding

  import

  lines were added after

  package

• Every Javadoc shape — top-level class, top-level record, nested static class, nested record, separate-file sub-DTO — uses short name

  {@link Pet}

  AND adds a matching

  import

  (unless the entity is in the same package). Uniform rule, no asymmetry.
• If a sub-DTO name (separate file or nested) would collide with an existing class in the target package, auto-suffix with a number (e.g.

  PetDto1

  ). The skill must do the same — call

  list_existing_classes(package)

  before generating, and append

  1

  ,

  2

  , … until the name is free.
• When generating a Java record, the inner class for any

  NEW_NESTED_CLASS

  association is also a record (not a static class). All component validators are inlined onto the record component parameters (e.g.

  @NotBlank String firstName

  ), not on separate field declarations.
• When

  isJavaRecord = true

  , the skill MUST NOT emit

  equals()

  ,

  hashCode()

  ,

  toString()

  , mutable setters, or fluent setters — records auto-generate these and these options should not be available for record DTOs.
• Class-level Javadoc is multi-line (

  /**\n * DTO for {@link …}\n */

  ), never collapsed to one line.
• Getters and setters are multi-line (signature line, indented body, closing brace), never one-liners.
• In

  mutable=true && fluentSetters=false

  mode, getters and setters are interleaved (

  getX, setX, getY, setY, …

  ), not grouped.
• In

  mutable=true

  mode, both the no-args constructor and the all-args constructor are emitted.
• The skill does NOT offer "Only ID" as a separate option — this option does not exist (neither for ToOne nor for ToMany). The "association id only" effect is produced by Flat with only the sub-entity

  id

  checked, and the skill must implement it that way.
• For collection associations (

  List<X>

  ,

  Set<X>

  ), Flat is offered and produces composite plural fields (

  Set<Integer> specialtyIds

  ,

  List<Integer> petIds

  ), provided the skill auto-checks the sub-entity scalars.
• Back-reference

  @ManyToOne

  fields are filtered out of the attribute list (e.g.

  Pet.owner

  is not offered when creating

  PetDto

  ).
• Imports are grouped with a blank line between

  jakarta.*

  /

  com.*

  /

  org.*

  /

  java.*

  blocks.
• Indentation matches the project's detected style (

  .editorconfig

  first, then sampling existing files in the same package, then 4-space default). Never hardcode tabs or spaces. Apply uniformly across every fragment in the file.
• @JsonIgnoreProperties is NOT added for Kotlin (Java-only feature)
• Validation annotations use

  @field:

  prefix in Kotlin
• Java types are converted to Kotlin types for Kotlin DTOs