amplicode/spring-skills/spring-security-configuration

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

Spring Security Configuration

Generates a @Configuration @EnableWebSecurity class with a filterChain() method, DSL chains for authentication and authorization, beans, dependencies, and properties in application.properties.

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–3 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

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 "Authentication type?" -> user answers "jwt" -> this IS the choice, don't show options
• Question "Client ID?" -> user answers "my-app" -> this IS the value, don't re-ask
• 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: Group closely related questions into a single AskUserQuestion call (up to 4 questions per call) when they:

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

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 (authentication type) 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, existing security configurations, 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. authentication type, authorization rules).

Hierarchy of decisions:

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

Examples: language and Boot version from get_project_summary; existing dependencies from list_module_dependencies; packageName from existing @Configuration classes; className = SecurityConfiguration; appPrefix from existing @Value annotations.

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

Format: `` Will create SecurityConfiguration with JWT (spring-boot-starter-oauth2-resource-server found in dependencies). Alternatives: Form Login, OIDC, LDAP, Custom. OK? `` The user can answer "ok" / "yes" / silence → accept; or name an alternative → switch.

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

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.

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

This applies to: authentication type (when no deps hint at it), authorization rules, variant-specific settings.

How to ask — prefer AskUserQuestion

When a question must be asked, prefer the `AskUserQuestion` tool 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. 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. "Auth Type", "CSRF", "Headers").

When AskUserQuestion is not the right tool:

• Free-form input with no enumerable set of options (e.g. URL, client ID,

DN, patterns) — ask in plain text.

• The "single confirmation line" from principle 2 — that is a plain

yes/no, not an enumerated choice.

NEVER ask the user for credentials of any kind (client secret, manager password, API key, token, etc.) — not via AskUserQuestion, not in plain text, not in any form. Secret values must not enter the conversation. For every credential field, the skill emits an env-var placeholder (${OAUTH_*_CLIENT_SECRET}, ${LDAP_MANAGER_PASSWORD}, ${AUTHSERVER_*_CLIENT_SECRET}) into application.properties and reports the placeholder name to the user after generation — see the per-variant references and _properties/*/properties.md "secret handling" sections.

The question lists in Steps 2–3 and in reference files 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–3. Do NOT ask "Authentication type?" if the user wrote "configure JWT" — JWT is the answer. Do NOT ask language if the user wrote "in Kotlin".

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 context (automatic, no questions)

Call Spring MCP tools (in parallel where possible).

If multi-module project (multiple modules in get_project_summary): Ask which module to use. Then re-call module-specific MCP tools with that module.

If existingConfigs is not empty:

• Warn user: "Project already has security configuration(s): {list}. Create an additional one?"
• If user confirms — suggest a {className} that does not collide with existing names
• If user declines — STOP

Determine appPrefix: scan existing @Value annotations in the project for a common custom prefix (e.g. @Value("${myapp.something}") → appPrefix = myapp). If none found, default to app.

Step 2 -- Authentication type

Ask:

Authentication type?
1. Form Login (HTTP Session) -- form login with session
2. JWT (OAuth2 Resource Server) -- stateless JWT
3. OAuth2/OIDC Login -- login via external provider (Keycloak, Google, GitHub...)
4. Authorization Server -- own authorization server (Spring Boot >= 3.1)
5. LDAP -- LDAP authentication
6. Custom -- empty filterChain, only common DSL blocks

Map answer to reference file:

• 1 -> references/http-session.md
• 2 -> references/jwt.md
• 3 -> references/oidc.md
• 4 -> references/authorization-server.md (requires bootMajor >= 3.1 — if lower, warn user and ask to choose another type)
• 5 -> references/ldap.md
• 6 -> references/custom.md

Step 3 -- Variant-specific questions (inline)

Read the mapped reference file and follow its questions flow. Only asked if user did NOT say "all defaults".

Each reference file specifies:

• Which fragments to include
• Which beans to generate
• Which dependencies to add
• Which properties to write
• Variant-specific questions

Step 4 -- Generate code

1. Read skeleton from examples/_skeletons/{lang}.md where {lang} = java or kotlin (from Step 1)

1. Create the configuration class file using the skeleton, substituting {packageName} and {className}