amplicode/spring-skills/crud-rest-controller

Preflight: Spring MCP

This skill is part of the Spring Agent Toolkit and is designed to work with the Spring MCP server (provided by the Amplicode IntelliJ plugin). Before doing anything else, check your tool list for any Spring MCP tool — they are exposed under the amplicode MCP server (e.g. get_project_summary, list_module_dependencies, get_entity_details); harnesses that flatten MCP tools into the tool list use the mcp__amplicode__ prefix on the same names.

• 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."

CRUD REST Controller

Generates a @RestController class with standard CRUD endpoints for an entity, using a Spring Data repository, optional DTO mapping, pagination, filtering, and patch support.

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–4 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.

Defaults

The options below are grouped by topic. language and bootVersion are auto-detected; all other options are resolved via the Decision-making principle (derive from context → confirm → ask).

Block 1 — Entity & repository

Block 2 — DTO mode

Block 3 — Controller naming & paths

Block 4 — Pagination & filtering

Auto-detected (no questions)

Smart defaults: If user says "use defaults", "all defaults", "default settings", or similar -- skip ALL questions where "Always ask?" = NO. Only ask mandatory questions.

Smart answer recognition: When user provides a value instead of choosing from a numbered list, accept it directly. Examples:

• Question "Which entity?" --> user answers "Product" --> this IS the entity, don't re-ask
• Question "Repository?" --> user answers "ProductRepository" --> this IS the choice
• If user provides multiple answers in one message --> accept all, skip answered questions
• NEVER ask a question that the user already answered (even implicitly)

Batch questions: When multiple questions must be asked (i.e. cannot be resolved by principles 1–2 of the Decision-making principle), group them into a single AskUserQuestion call (up to 4 questions per call) when they:

• Belong to the same logical section
• Don't depend on each other's answers

Rules:

• 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) is always asked ALONE
• Prefer AskUserQuestion for choices; fall back to plain text lists only if the tool is unavailable

Decision-making principle — context first, then ask

Before asking the user any question, attempt to derive the answer from the context already gathered: project summary, module dependencies, entity details, existing files in the package, prior turns of this conversation, and the user's original prompt. Only ask when the context yields no clear default or when the choice is genuinely user-specific (e.g. which entity, which repository).

Hierarchy of decisions:

1. Context is unambiguous → decide silently, do NOT ask.

Examples: language and JDK from get_project_summary; repository when there is exactly one for the entity; controller package from existing controllers; basePath from existing endpoints; Jackson version from list_module_dependencies; pagination type when project already uses one consistently.

1. Context gives a strong signal → state the decision + alternatives in one line, let the user override or stay silent.

Format: `` Will create ProductController at /rest/products with Page pagination, no DTO. Alternatives: use DTO, Window pagination, custom paths. 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.

1. Context yields no clear default → ask with `AskUserQuestion` (preferred) or its analogue, with the recommended option first.

When AskUserQuestion is available, use it with the recommended option marked (Recommended) and placed first. If no interactive choice tool is available, fall back to a plain text list. Never ask iteratively ("which entity?" → user picks → "repository?" → …) when one batched call would do.

1. Context is fully empty for a critical input → ask plainly.

This applies to: which entity (when not mentioned), the user's intent itself.

How to ask — prefer AskUserQuestion

When a question must be asked, prefer the `AskUserQuestion` tool (or its analogue) over writing a numbered list in the response body. Fall back to plain text only if no interactive choice tool is available.

Rules for AskUserQuestion calls in this skill:

• 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.

• header is a 12-char chip label (e.g. "Entity", "DTO mode", "Paths").
• Each option has a description explaining what the choice means.

When AskUserQuestion is not the right tool:

• Free-form input where there is no enumerable set of options

(e.g. arbitrary class name, arbitrary path) — 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.

The screen-driven question lists in Steps 2–4 below are a fallback for case 4. They are NOT a script to execute top-to-bottom. If a question's answer is already determined by principles 1–3, skip the question.

Step 0 -- Conversation context first (REQUIRED, no tool calls)

Before any MCP call, before any question, re-read the user's prompt and the prior turns of this conversation and extract whatever is already stated. This step costs nothing and prevents the most common failure mode of this skill — asking the user something they already said.

Build a mental checklist of inputs and tick off everything the user has already provided, explicitly or implicitly:

For every input that is explicitly or strongly implicitly answered: mark it as decided and skip the corresponding question in Steps 2–4. Do NOT ask "which entity?" if the user wrote "create CRUD controller for Product" — Product is the answer. Do NOT ask "which repository?" if there is exactly one repository for the entity.

For every input that is not answered: defer to the Decision-making principle above — try to derive it from project context first (Step 1), and only then ask.

Step 0 is mental, not a tool call. Do not announce it to the user. Do not write "Step 0 done". Just internalize what the user already said before proceeding to Step 1.

Step 1 -- Gather minimal project context (automatic, no questions)

Call only the MCP tools whose result is actually consumed by a later step. Do not pre-fetch "in case we need it" — every variable here must have a concrete downstream user.

That is the entire Step 1. Do NOT fetch:

• 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.

• list_entity_repositories — depends on knowing the entity, which

happens in Step 2. Defer to Step 3 as a lazy fallback.

• get_entity_details — depends on knowing the entity. Defer to Step 2.
• list_entity_dtos / list_entity_mappers — depend on knowing the

entity AND the DTO decision. Defer to Step 4.