$npx -y skills add Amplicode/spring-skills --skill spring-planningCreate structured implementation plan in docs/plans/
| 1 | # Preflight: Spring MCP |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | - **If at least one Amplicode tool is available** — MCP is connected. Proceed with the skill below. |
| 6 | - **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. |
| 7 | - 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."* |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | # Implementation Plan Creation |
| 12 | |
| 13 | create an implementation plan in `docs/plans/yyyymmdd-<task-name>.md` with interactive context gathering. |
| 14 | |
| 15 | ## step 0: parse intent and gather context |
| 16 | |
| 17 | before asking questions, understand what the user is working on: |
| 18 | |
| 19 | 1. **parse user's command arguments** to identify intent: |
| 20 | - "add feature Z" / "implement W" → feature development |
| 21 | - "fix bug" / "debug issue" → bug fix plan |
| 22 | - "refactor X" / "improve Y" → refactoring plan |
| 23 | - "migrate to Z" / "upgrade W" → migration plan |
| 24 | - generic request → explore current work |
| 25 | |
| 26 | 2. **gather relevant context quickly** — use direct spring-explore skill, NOT an Explore agent. keep discovery under 30 seconds: |
| 27 | |
| 28 | **CRITICAL: do NOT launch an Explore agent. the goal is a quick scan, not exhaustive analysis. if more context is needed, ask the user in step 1.** |
| 29 | |
| 30 | ## step 1: present context and ask focused questions |
| 31 | |
| 32 | show the discovered context, then ask questions **one at a time** using the AskUserQuestion tool: |
| 33 | |
| 34 | "based on your request, i found: [context summary]" |
| 35 | |
| 36 | **ask questions one at a time (do not overwhelm with multiple questions):** |
| 37 | |
| 38 | 1. **plan purpose**: use AskUserQuestion - "what is the main goal?" |
| 39 | - provide multiple choice with suggested answer based on discovered intent |
| 40 | - wait for response before next question |
| 41 | |
| 42 | 2. **scope**: use AskUserQuestion - "which components/files are involved?" |
| 43 | - provide multiple choice with suggested discovered files/areas |
| 44 | - wait for response before next question |
| 45 | |
| 46 | 3. **constraints**: use AskUserQuestion - "any specific requirements or limitations?" |
| 47 | - can be open-ended if constraints vary widely |
| 48 | - wait for response before next question |
| 49 | |
| 50 | 4. **testing approach**: use AskUserQuestion - "do you prefer TDD, regular approach or no tests?" |
| 51 | - options: "TDD (tests first)" and "Regular (code first, then tests)" and "None (no tests)" |
| 52 | - store preference for reference during implementation |
| 53 | - wait for response before next question |
| 54 | |
| 55 | 5. **plan title**: use AskUserQuestion - "short descriptive title?" |
| 56 | - provide suggested name based on intent |
| 57 | |
| 58 | after all questions answered, synthesize responses into plan context. |
| 59 | |
| 60 | ## step 1.5: explore approaches |
| 61 | |
| 62 | once the problem is understood, propose implementation approaches: |
| 63 | |
| 64 | 1. **propose 2-3 different approaches** with trade-offs for each |
| 65 | 2. **lead with recommended option** and explain reasoning |
| 66 | 3. **present conversationally** - not a formal document yet |
| 67 | |
| 68 | example format: |
| 69 | ``` |
| 70 | i see three approaches: |
| 71 | |
| 72 | **Option A: [name]** (recommended) |
| 73 | - how it works: ... |
| 74 | - pros: ... |
| 75 | - cons: ... |
| 76 | |
| 77 | **Option B: [name]** |
| 78 | - how it works: ... |
| 79 | - pros: ... |
| 80 | - cons: ... |
| 81 | |
| 82 | which direction appeals to you? |
| 83 | ``` |
| 84 | |
| 85 | use AskUserQuestion tool to let user select preferred approach before creating the plan. |
| 86 | |
| 87 | **skip this step** if: |
| 88 | - the implementation approach is obvious (single clear path) |
| 89 | - user explicitly specified how they want it done |
| 90 | - it's a bug fix with clear solution |
| 91 | |
| 92 | ## step 2: create plan file |
| 93 | |
| 94 | check `docs/plans/` for existing files, then create `docs/plans/yyyymmdd-<task-name>.md` (use current date): |
| 95 | |
| 96 | ### plan structure |
| 97 | |
| 98 | ```markdown |
| 99 | # [Plan Title] |
| 100 | |
| 101 | ## Overview |
| 102 | - clear description of the feature/change being implemented |
| 103 | - problem it solves and key benefits |
| 104 | - how it integrates with existing system |
| 105 | |
| 106 | ## Context (from discovery) |
| 107 | - files/components involved: [list from step 0] |
| 108 | - related patterns found: [patterns discovered] |
| 109 | - dependencies identified: [dependencies] |
| 110 | |
| 111 | ## Development Approach |
| 112 | - **testing approach**: [TDD / Regular - from user preference in planning] |
| 113 | - complete each task fully before moving to |