shmakk 1.1.0 → 1.2.0

package/skills/general-import-infrastructure-as-code.md

@@ -0,0 +1,368 @@
+---
+name: import-infrastructure-as-code
+description: 'Import existing Azure resources into Terraform using Azure CLI discovery and Azure Verified Modules (AVM). Use when asked to reverse-engineer live Azure infrastructure, generate Infrastructure as Code from existing subscriptions/resource groups/resource IDs, map dependencies, derive exact import addresses from downloaded module source, prevent configuration drift, and produce AVM-based Terraform files ready for validation and planning across any Azure resource type.'
+category: general
+---
+
+# Import Infrastructure as Code (Azure -> Terraform with AVM)
+
+Convert existing Azure infrastructure into maintainable Terraform code using discovery data and Azure Verified Modules.
+
+## When to Use This Skill
+
+Use this skill when the user asks to:
+
+- Import existing Azure resources into Terraform
+- Generate IaC from live Azure environments
+- Handle any Azure resource type supported by AVM (and document justified non-AVM fallbacks)
+- Recreate infrastructure from a subscription or resource group
+- Map dependencies between discovered Azure resources
+- Use AVM modules instead of handwritten `azurerm_*` resources
+
+## Prerequisites
+
+- Azure CLI installed and authenticated (`az login`)
+- Access to the target subscription or resource group
+- Terraform CLI installed
+- Network access to Terraform Registry and AVM index sources
+
+## Inputs
+
+| Parameter | Required | Default | Description |
+|---|---|---|---|
+| `subscription-id` | No | Active CLI context | Azure subscription used for subscription-scope discovery and context setting |
+| `resource-group-name` | No | None | Azure resource group used for resource-group-scope discovery |
+| `resource-id` | No | None | One or more Azure ARM resource IDs used for specific-resource-scope discovery |
+
+At least one of `subscription-id`, `resource-group-name`, or `resource-id` is required.
+
+## Step-by-Step Workflows
+
+### 1) Collect Required Scope (Mandatory)
+
+Request one of these scopes before running discovery commands:
+
+- Subscription scope: `<subscription-id>`
+- Resource group scope: `<resource-group-name>`
+- Specific resources scope: one or more `<resource-id>` values
+
+Scope handling rules:
+
+- Treat Azure ARM resource IDs (for example `/subscriptions/.../providers/...`) as cloud resource identifiers, not local file system paths.
+- Use resource IDs only with Azure CLI `--ids` arguments (for example `az resource show --ids <resource-id>`).
+- Never pass resource IDs to file-reading commands (`cat`, `ls`, `read_file`, glob searches) unless the user explicitly says they are local file paths.
+- If the user already provided one valid scope, do not ask for additional scope inputs unless required by a failing command.
+- Do not ask follow-up questions that can be answered from already-provided scope values.
+
+If scope is missing, ask for it explicitly and stop.
+
+### 2) Authenticate and Set Context
+
+Run only the commands required for the selected scope.
+
+For subscription scope:
+
+```bash
+az login
+az account set --subscription <subscription-id>
+az account show --query "{subscriptionId:id, name:name, tenantId:tenantId}" -o json
+```
+
+Expected output: JSON object with `subscriptionId`, `name`, and `tenantId`.
+
+For resource group or specific resource scope, `az login` is still required but `az account set` is optional if the active context is already correct.
+
+When using specific resource scope, prefer direct `--ids`-based commands first and avoid extra discovery prompts for subscription or resource group unless needed for a concrete command.
+
+### 3) Run Discovery Commands
+
+Discover resources using the selected scopes. Ensure to fetch all necessary information for accurate Terraform generation.
+
+```bash
+# Subscription scope
+az resource list --subscription <subscription-id> -o json
+
+# Resource group scope
+az resource list --resource-group <resource-group-name> -o json
+
+# Specific resource scope
+az resource show --ids <resource-id-1> <resource-id-2> ... -o json
+```
+
+Expected output: JSON object or array containing Azure resource metadata (`id`, `type`, `name`, `location`, `tags`, `properties`).
+
+### 4) Resolve Dependencies Before Code Generation
+
+Parse exported JSON and map:
+
+- Parent-child relationships (for example: NIC -> Subnet -> VNet)
+- Cross-resource references in `properties`
+- Ordering for Terraform creation
+
+IMPORTANT: Generate the following documentation and save it to a docs folder in the root of the project.
+- `exported-resources.json` with all discovered resources and their metadata, including dependencies and references.
+- `EXPORTED-ARCHITECTURE.MD` file with a human-readable architecture overview based on the discovered resources and their relationships.
+
+### 5) Select Azure Verified Modules (Required)
+
+Use the latest AVM version for each resource type.
+
+### Terraform Registry
+
+- Search for "avm" + resource name
+- Filter by "Partner" tag to find official AVM modules
+- Example: Search "avm storage account" → filter by Partner
+
+### Official AVM Index
+
+> **Note:** The following links always point to the latest version of the CSV files on the main branch. As intended, this means the files may change over time. If you require a point-in-time version, consider using a specific release tag in the URL.
+
+- **Terraform Resource Modules**: `https://raw.githubusercontent.com/Azure/Azure-Verified-Modules/refs/heads/main/docs/static/module-indexes/TerraformResourceModules.csv`
+- **Terraform Pattern Modules**: `https://raw.githubusercontent.com/Azure/Azure-Verified-Modules/refs/heads/main/docs/static/module-indexes/TerraformPatternModules.csv`
+- **Terraform Utility Modules**: `https://raw.githubusercontent.com/Azure/Azure-Verified-Modules/refs/heads/main/docs/static/module-indexes/TerraformUtilityModules.csv`
+
+### Individual Module information
+
+Use the `web` tool or another suitable MCP method to get module information if not available locally in the `.terraform` folder.
+
+Use AVM sources:
+
+- Registry: `https://registry.terraform.io/modules/Azure/<module>/azurerm/latest`
+- GitHub: `https://github.com/Azure/terraform-azurerm-avm-res-<service>-<resource>`
+
+Prefer AVM modules over handwritten `azurerm_*` resources when an AVM module exists.
+
+When fetching module information from GitHub repositories, the README.md file in the root of the repository typically contains all detailed information about the module, for example: https://raw.githubusercontent.com/Azure/terraform-azurerm-avm-res-<service>-<resource>/refs/heads/main/README.md
+
+### 5a) Read the Module README Before Writing Any Code (Mandatory)
+
+**This step is not optional.** Before writing a single line of HCL for a module, fetch and
+read the full README for that module. Do not rely on knowledge of the raw `azurerm` provider
+or prior experience with other AVM modules.
+
+For each selected AVM module, fetch its README:
+
+```text
+https://raw.githubusercontent.com/Azure/terraform-azurerm-avm-res-<service>-<resource>/refs/heads/main/README.md
+```
+
+Or if the module is already downloaded after `terraform init`:
+
+```bash
+cat .terraform/modules/<module_key>/README.md
+```
+
+From the README, extract and record **before writing code**:
+
+1. **Required Inputs** — every input the module requires. Any child resource listed here
+	 (NICs, extensions, subnets, public IPs) is managed **inside** the module. Do **not**
+	 create standalone module blocks for those resources.
+2. **Optional Inputs** — the exact Terraform variable names and their declared `type`.
+	 Do not assume they match the raw `azurerm` provider argument names or block shapes.
+3. **Usage examples** — check what resource group identifier is used (`parent_id` vs
+	 `resource_group_name`), how child resources are expressed (inline map vs separate module),
+	 and what syntax each input expects.
+
+#### Apply module rules as patterns, not assumptions
+
+Use the lessons below as examples of the *type* of mismatch that often causes imports to fail.
+Do not assume these exact names apply to every AVM module. Always verify each selected module's
+README and `variables.tf`.
+
+**`avm-res-compute-virtualmachine` (any version)**
+
+- `network_interfaces` is a **Required Input**. NICs are owned by the VM module. Never
+	create standalone `avm-res-network-networkinterface` modules alongside a VM module —
+	define every NIC inline under `network_interfaces`.
+- TrustedLaunch is expressed through the top-level booleans `secure_boot_enabled = true`
+	and `vtpm_enabled = true`. The `security_type` argument exists only under `os_disk` for
+	Confidential VM disk encryption and must not be used for TrustedLaunch.
+- `boot_diagnostics` is a `bool`, not an object. Use `boot_diagnostics = true`; use the
+	separate `boot_diagnostics_storage_account_uri` variable if a storage URI is needed.
+- Extensions are managed inside the module via the `extensions` map. Do not create
+	standalone extension resources.
+
+**`avm-res-network-virtualnetwork` (any version)**
+
+- This module is backed by the AzAPI provider, not `azurerm`. Use `parent_id` (the full
+	resource group resource ID string) to specify the resource group, not `resource_group_name`.
+- Every example in the README shows `parent_id`; none show `resource_group_name`.
+
+Generalized takeaway for all AVM modules:
+
+- Determine child resource ownership from **Required Inputs** before creating sibling modules.
+- Determine accepted variable names and types from **Optional Inputs** and `variables.tf`.
+- Determine identifier style and input shape from README usage examples.
+- Do not infer argument names from raw `azurerm_*` resources.
+
+### 6) Generate Terraform Files
+
+### Before Writing Import Blocks — Inspect Module Source (Mandatory)
+
+After `terraform init` downloads the modules, inspect each module's source files to determine
+the exact Terraform resource addresses before writing any `import {}` blocks. Never write
+import addresses from memory.
+
+#### Step A — Identify the provider and resource label
+
+```bash
+grep "^resource" .terraform/modules/<module_key>/main*.tf
+```
+
+This reveals whether the module uses `azurerm_*` or `azapi_resource` labels. For example,
+`avm-res-network-virtualnetwork` exposes `azapi_resource "vnet"`, not
+`azurerm_virtual_network "this"`.
+
+#### Step B — Identify child modules and nested paths
+
+```bash
+grep "^module" .terraform/modules/<module_key>/main*.tf
+```
+
+If child resources are managed in a sub-module (subnets, extensions, etc.), the import
+address must include every intermediate module label:
+
+```text
+module.<root_module_key>.module.<child_module_key>["<map_key>"].<resource_type>.<label>[<index>]
+```
+
+#### Step C — Check for `count` vs `for_each`
+
+```bash
+grep -n "count\|for_each" .terraform/modules/<module_key>/main*.tf
+```
+
+Any resource using `count` requires an index in the import address. When `count = 1` (e.g.,
+conditional Linux vs Windows selection), the address must end with `[0]`. Resources using
+`for_each` use string keys, not numeric indexes.
+
+#### Known import address patterns (examples from lessons learned)
+
+These are examples only. Use them as templates for reasoning, then derive the exact addresses
+from the downloaded source code for the modules in your current import.
+
+| Resource | Correct import `to` address pattern |
+|---|---|
+| AzAPI-backed VNet | `module.<vnet_key>.azapi_resource.vnet` |
+| Subnet (nested, count-based) | `module.<vnet_key>.module.subnet["<subnet_name>"].azapi_resource.subnet[0]` |
+| Linux VM (count-based) | `module.<vm_key>.azurerm_linux_virtual_machine.this[0]` |
+| VM NIC | `module.<vm_key>.azurerm_network_interface.virtualmachine_network_interfaces["<nic_key>"]` |
+| VM extension (default deploy_sequence=5) | `module.<vm_key>.module.extension["<ext_name>"].azurerm_virtual_machine_extension.this` |
+| VM extension (deploy_sequence=1–4) | `module.<vm_key>.module.extension_<n>["<ext_name>"].azurerm_virtual_machine_extension.this` |
+| NSG-NIC association | `module.<vm_key>.azurerm_network_interface_security_group_association.this["<nic_key>-<nsg_key>"]` |
+
+Produce:
+
+- `providers.tf` with `azurerm` provider and required version constraints
+- `main.tf` with AVM module blocks and explicit dependencies
+- `variables.tf` for environment-specific values
+- `outputs.tf` for key IDs and endpoints
+- `terraform.tfvars.example` with placeholder values
+
+### Diff Live Properties Against Module Defaults (Mandatory)
+
+After writing the initial configuration, compare every non-zero property of each discovered
+live resource against the default value declared in the corresponding AVM module's
+`variables.tf`. Any property where the live value differs from the module default must be
+set explicitly in the Terraform configuration.
+
+Pay particular attention to the following property categories, which are common sources
+of silent configuration drift:
+
+- **Timeout values** (e.g., Public IP `idle_timeout_in_minutes` defaults to `4`; live
+	deployments often use `30`)
+- **Network policy flags** (e.g., subnet `private_endpoint_network_policies` defaults to
+	`"Enabled"`; existing subnets often have `"Disabled"`)
+- **SKU and allocation** (e.g., Public IP `sku`, `allocation_method`)
+- **Availability zones** (e.g., VM zone, Public IP zone)
+- **Redundancy and replication** settings on storage and database resources
+
+Retrieve full live properties with explicit `az` commands, for example:
+
+```bash
+az network public-ip show --ids <resource_id> --query "{idleTimeout:idleTimeoutInMinutes, sku:sku.name, zones:zones}" -o json
+az network vnet subnet show --ids <resource_id> --query "{privateEndpointPolicies:privateEndpointNetworkPolicies, delegation:delegations}" -o json
+```
+
+Do not rely solely on `az resource list` output, which may omit nested or computed properties.
+
+Pin module versions explicitly:
+
+```hcl
+module "example" {
+	source  = "Azure/<module>/azurerm"
+	version = "<latest-compatible-version>"
+}
+```
+
+### 7) Validate Generated Code
+
+Run:
+
+```bash
+terraform init
+terraform fmt -recursive
+terraform validate
+terraform plan
+```
+
+Expected output: no syntax errors, no validation errors, and a plan that matches discovered infrastructure intent.
+
+## Troubleshooting
+
+| Problem | Likely Cause | Action |
+|---|---|---|
+| `az` command fails with authorization errors | Wrong tenant/subscription or missing RBAC role | Re-run `az login`, verify subscription context, confirm required permissions |
+| Discovery output is empty | Incorrect scope or no resources in scope | Re-check scope input and run scoped list/show command again |
+| No AVM module found for a resource type | Resource type not yet covered by AVM | Use native `azurerm_*` resource for that type and document the gap |
+| `terraform validate` fails | Missing variables or unresolved dependencies | Add required variables and explicit dependencies, then re-run validation |
+| Unknown argument or variable not found in module | AVM variable name differs from `azurerm` provider argument name | Read the module README `variables.tf` or Optional Inputs section for the correct name |
+| Import block fails — resource not found at address | Wrong provider label (`azurerm_` vs `azapi_`), missing sub-module path, or missing `[0]` index | Run `grep "^resource" .terraform/modules/<key>/main*.tf` and `grep "^module"` to find exact address |
+| `terraform plan` shows unexpected `~ update` on imported resource | Live value differs from AVM module default | Fetch live property with `az <resource> show`, compare to module default, add explicit value |
+| Child-resource module gives "provider configuration not present" | Child resources declared as standalone modules even though parent module owns them | Check Required Inputs in README, remove incorrect standalone modules, and model child resources using the parent module's documented input structure |
+| Nested child resource import fails with "resource not found" | Missing intermediate module path, wrong map key, or missing index | Inspect module blocks and `count`/`for_each` in source; build full nested import address including all module segments and required key/index |
+| Tool tries to read ARM resource ID as file path or asks repeated scope questions | Resource ID not treated as `--ids` input, or agent did not trust already-provided scope | Treat ARM IDs strictly as cloud identifiers, use `az ... --ids ...`, and stop re-prompting once one valid scope is present |
+
+## Response Contract
+
+When returning results, provide:
+
+1. Scope used (subscription, resource group, or resource IDs)
+2. Discovery files created
+3. Resource types detected
+4. AVM modules selected with versions
+5. Terraform files generated or updated
+6. Validation command results
+7. Open gaps requiring user input (if any)
+
+## Execution Rules for the Agent
+
+- Do not continue if scope is missing.
+- Do not claim successful import without listing discovered files and validation output.
+- Do not skip dependency mapping before generating Terraform.
+- Prefer AVM modules first; justify each non-AVM fallback explicitly.
+- **Read the README for every AVM module before writing code.** Required Inputs identify
+	which child resources the module owns. Optional Inputs document exact variable names and
+	types. Usage examples show provider-specific conventions (`parent_id` vs
+	`resource_group_name`). Skipping the README is the single most common cause of
+	code errors in AVM-based imports.
+- **Never assume NIC, extension, or public IP resources are standalone.** For
+	any AVM module, treat child resources as parent-owned unless the README explicitly indicates
+	a separate module is required. Check Required Inputs before creating sibling modules.
+- **Never write import addresses from memory.** After `terraform init`, grep the downloaded
+	module source to discover the actual provider (`azurerm` vs `azapi`), resource labels,
+	sub-module nesting, and `count` vs `for_each` usage before writing any `import {}` block.
+- **Never treat ARM resource IDs as file paths.** Resource IDs belong in Azure CLI `--ids`
+	arguments and API queries, not file IO tools. Only read local files when a real workspace
+	path is provided.
+- **Minimize prompts when scope is already known.** If subscription, resource group, or
+	specific resource IDs are already provided, proceed with commands directly and only ask a
+	follow-up when a command fails due to missing required context.
+- **Do not declare the import complete until `terraform plan` shows 0 destroys and 0
+	unwanted changes.** Telemetry `+ create` resources are acceptable. Any `~ update` or
+	`- destroy` on real infrastructure resources must be resolved.
+
+## References
+
+- [Azure Verified Modules index (Terraform)](https://github.com/Azure/Azure-Verified-Modules/tree/main/docs/static/module-indexes)
+- [Terraform AVM Registry namespace](https://registry.terraform.io/namespaces/Azure)

package/skills/general-init.md

@@ -0,0 +1,49 @@
+---
+name: init
+description: Generate or update chat customization files for AI coding agents
+argument-hint: Optionally specify a focus area or pattern to document for agents
+disable-model-invocation: true
+category: general
+---
+
+The purpose of this command is to create or update chat customization files
+- the agent instructions file (`.github/copilot-instructions.md` or `AGENTS.md`) to help AI coding agents understand the codebase and be immediately productive
+- skills and custom agents to automate common tasks or enforce conventions in the codebase
+
+The user can optionally call this command with an argument. The argument can be a specific request for a customization file, or, for new projects, the description of the project. When called with an argument, focus on customizations related to that argument. Only create or modify chat customization files. Never start working on a task in the argument.
+
+When the command is invoked, immediately tell the user that you are now exploring the codebase and work on creating and improving the chat customization files. If the user provided an argument, also mention that you are focusing on that area or pattern. Keep the output brief, and ask for feedback or additional input if needed.
+
+Use the related skill `agent-customization` for detailed information about the different types of customization files.
+Explore the codebase to get a good understanding of the project and its conventions, and then create or update the relevant chat customization files to help AI coding agents be productive in this codebase.
+
+When complete, print a table of the added or modified chat customization files, along with a short explanation why this file is useful to the AI coding agents.
+
+## Workflow
+
+1. **Discover existing conventions**
+   Search: `**/{.github/copilot-instructions.md,AGENT.md,AGENTS.md,CLAUDE.md,.cursorrules,.windsurfrules,.clinerules,.cursor/rules/**,.windsurf/rules/**,.clinerules/**,README.md}`
+
+2. **Explore the codebase** via subagent, 1-3 in parallel if needed
+   Find essential knowledge that helps an AI agent be immediately productive:
+   - Build/test commands (agents run these automatically)
+   - Architecture decisions and component boundaries
+   - Project-specific conventions that differ from common practices
+   - Potential pitfalls or common development environment issues
+   - Key files/directories that exemplify patterns
+
+   Also inventory existing documentation (`docs/**/*.md`, `CONTRIBUTING.md`, `ARCHITECTURE.md`, etc.) to identify topics that should be linked, not duplicated.
+
+3. **Generate or merge**
+   - New file: Prefer AGENTS.md over `.github/copilot-instructions.md`. If the user already has one of these files, update it instead of creating a new one.
+   - Existing file: Preserve valuable content, update outdated sections, remove duplication
+   - Follow the guidelines in the `agent-customization` skill: 
+      1. **Link, don't embed** principle. Do not copy existing documentation that exists in the workspace, link to them with a Markdown link instead.
+      2. **Minimal by default**: Only what's relevant and can not be easely discovered by an agent should be included. Link to other documentation for details.
+      3. **Concise and actionable**: Every line should guide behavior
+
+4. **Iterate**
+   - Ask for feedback on unclear or incomplete sections
+   - If the workspace is complex, suggest creating separate instructions files or skills for specific areas (e.g., frontend, backend, tests)
+
+Once finalized, propose related agent-customizations to create next (`/create-(agent|hook|instruction|prompt|skill) …`), explaining the customization and how it would be used in practice.

package/skills/general-java-junit.md

@@ -0,0 +1,64 @@
+---
+name: java-junit
+description: 'Get best practices for JUnit 5 unit testing, including data-driven tests'
+category: general
+---
+
+# JUnit 5+ Best Practices
+
+Your goal is to help me write effective unit tests with JUnit 5, covering both standard and data-driven testing approaches.
+
+## Project Setup
+
+- Use a standard Maven or Gradle project structure.
+- Place test source code in `src/test/java`.
+- Include dependencies for `junit-jupiter-api`, `junit-jupiter-engine`, and `junit-jupiter-params` for parameterized tests.
+- Use build tool commands to run tests: `mvn test` or `gradle test`.
+
+## Test Structure
+
+- Test classes should have a `Test` suffix, e.g., `CalculatorTest` for a `Calculator` class.
+- Use `@Test` for test methods.
+- Follow the Arrange-Act-Assert (AAA) pattern.
+- Name tests using a descriptive convention, like `methodName_should_expectedBehavior_when_scenario`.
+- Use `@BeforeEach` and `@AfterEach` for per-test setup and teardown.
+- Use `@BeforeAll` and `@AfterAll` for per-class setup and teardown (must be static methods).
+- Use `@DisplayName` to provide a human-readable name for test classes and methods.
+
+## Standard Tests
+
+- Keep tests focused on a single behavior.
+- Avoid testing multiple conditions in one test method.
+- Make tests independent and idempotent (can run in any order).
+- Avoid test interdependencies.
+
+## Data-Driven (Parameterized) Tests
+
+- Use `@ParameterizedTest` to mark a method as a parameterized test.
+- Use `@ValueSource` for simple literal values (strings, ints, etc.).
+- Use `@MethodSource` to refer to a factory method that provides test arguments as a `Stream`, `Collection`, etc.
+- Use `@CsvSource` for inline comma-separated values.
+- Use `@CsvFileSource` to use a CSV file from the classpath.
+- Use `@EnumSource` to use enum constants.
+
+## Assertions
+
+- Use the static methods from `org.junit.jupiter.api.Assertions` (e.g., `assertEquals`, `assertTrue`, `assertNotNull`).
+- For more fluent and readable assertions, consider using a library like AssertJ (`assertThat(...).is...`).
+- Use `assertThrows` or `assertDoesNotThrow` to test for exceptions.
+- Group related assertions with `assertAll` to ensure all assertions are checked before the test fails.
+- Use descriptive messages in assertions to provide clarity on failure.
+
+## Mocking and Isolation
+
+- Use a mocking framework like Mockito to create mock objects for dependencies.
+- Use `@Mock` and `@InjectMocks` annotations from Mockito to simplify mock creation and injection.
+- Use interfaces to facilitate mocking.
+
+## Test Organization
+
+- Group tests by feature or component using packages.
+- Use `@Tag` to categorize tests (e.g., `@Tag("fast")`, `@Tag("integration")`).
+- Use `@TestMethodOrder(MethodOrderer.OrderAnnotation.class)` and `@Order` to control test execution order when strictly necessary.
+- Use `@Disabled` to temporarily skip a test method or class, providing a reason.
+- Use `@Nested` to group tests in a nested inner class for better organization and structure.

package/skills/general-java-springboot.md

@@ -0,0 +1,66 @@
+---
+name: java-springboot
+description: 'Get best practices for developing applications with Spring Boot.'
+category: general
+---
+
+# Spring Boot Best Practices
+
+Your goal is to help me write high-quality Spring Boot applications by following established best practices.
+
+## Project Setup & Structure
+
+- **Build Tool:** Use Maven (`pom.xml`) or Gradle (`build.gradle`) for dependency management.
+- **Starters:** Use Spring Boot starters (e.g., `spring-boot-starter-web`, `spring-boot-starter-data-jpa`) to simplify dependency management.
+- **Package Structure:** Organize code by feature/domain (e.g., `com.example.app.order`, `com.example.app.user`) rather than by layer (e.g., `com.example.app.controller`, `com.example.app.service`).
+
+## Dependency Injection & Components
+
+- **Constructor Injection:** Always use constructor-based injection for required dependencies. This makes components easier to test and dependencies explicit.
+- **Immutability:** Declare dependency fields as `private final`.
+- **Component Stereotypes:** Use `@Component`, `@Service`, `@Repository`, and `@Controller`/`@RestController` annotations appropriately to define beans.
+
+## Configuration
+
+- **Externalized Configuration:** Use `application.yml` (or `application.properties`) for configuration. YAML is often preferred for its readability and hierarchical structure.
+- **Type-Safe Properties:** Use `@ConfigurationProperties` to bind configuration to strongly-typed Java objects.
+- **Profiles:** Use Spring Profiles (`application-dev.yml`, `application-prod.yml`) to manage environment-specific configurations.
+- **Secrets Management:** Do not hardcode secrets. Use environment variables, or a dedicated secret management tool like HashiCorp Vault or AWS Secrets Manager.
+
+## Web Layer (Controllers)
+
+- **RESTful APIs:** Design clear and consistent RESTful endpoints.
+- **DTOs (Data Transfer Objects):** Use DTOs to expose and consume data in the API layer. Do not expose JPA entities directly to the client.
+- **Validation:** Use Java Bean Validation (JSR 380) with annotations (`@Valid`, `@NotNull`, `@Size`) on DTOs to validate request payloads.
+- **Error Handling:** Implement a global exception handler using `@ControllerAdvice` and `@ExceptionHandler` to provide consistent error responses.
+
+## Service Layer
+
+- **Business Logic:** Encapsulate all business logic within `@Service` classes.
+- **Statelessness:** Services should be stateless.
+- **Transaction Management:** Use `@Transactional` on service methods to manage database transactions declaratively. Apply it at the most granular level necessary.
+
+## Data Layer (Repositories)
+
+- **Spring Data JPA:** Use Spring Data JPA repositories by extending `JpaRepository` or `CrudRepository` for standard database operations.
+- **Custom Queries:** For complex queries, use `@Query` or the JPA Criteria API.
+- **Projections:** Use DTO projections to fetch only the necessary data from the database.
+
+## Logging
+
+- **SLF4J:** Use the SLF4J API for logging.
+- **Logger Declaration:** `private static final Logger logger = LoggerFactory.getLogger(MyClass.class);`
+- **Parameterized Logging:** Use parameterized messages (`logger.info("Processing user {}...", userId);`) instead of string concatenation to improve performance.
+
+## Testing
+
+- **Unit Tests:** Write unit tests for services and components using JUnit 5 and a mocking framework like Mockito.
+- **Integration Tests:** Use `@SpringBootTest` for integration tests that load the Spring application context.
+- **Test Slices:** Use test slice annotations like `@WebMvcTest` (for controllers) or `@DataJpaTest` (for repositories) to test specific parts of the application in isolation.
+- **Testcontainers:** Consider using Testcontainers for reliable integration tests with real databases, message brokers, etc.
+
+## Security
+
+- **Spring Security:** Use Spring Security for authentication and authorization.
+- **Password Encoding:** Always encode passwords using a strong hashing algorithm like BCrypt.
+- **Input Sanitization:** Prevent SQL injection by using Spring Data JPA or parameterized queries. Prevent Cross-Site Scripting (XSS) by properly encoding output.

package/skills/general-javascript-typescript-jest.md

@@ -0,0 +1,45 @@
+---
+name: javascript-typescript-jest
+description: 'Best practices for writing JavaScript/TypeScript tests using Jest, including mocking strategies, test structure, and common patterns.'
+category: general
+---
+
+### Test Structure
+- Name test files with `.test.ts` or `.test.js` suffix
+- Place test files next to the code they test or in a dedicated `__tests__` directory
+- Use descriptive test names that explain the expected behavior
+- Use nested describe blocks to organize related tests
+- Follow the pattern: `describe('Component/Function/Class', () => { it('should do something', () => {}) })`
+
+### Effective Mocking
+- Mock external dependencies (APIs, databases, etc.) to isolate your tests
+- Use `jest.mock()` for module-level mocks
+- Use `jest.spyOn()` for specific function mocks
+- Use `mockImplementation()` or `mockReturnValue()` to define mock behavior
+- Reset mocks between tests with `jest.resetAllMocks()` in `afterEach`
+
+### Testing Async Code
+- Always return promises or use async/await syntax in tests
+- Use `resolves`/`rejects` matchers for promises
+- Set appropriate timeouts for slow tests with `jest.setTimeout()`
+
+### Snapshot Testing
+- Use snapshot tests for UI components or complex objects that change infrequently
+- Keep snapshots small and focused
+- Review snapshot changes carefully before committing
+
+### Testing React Components
+- Use React Testing Library over Enzyme for testing components
+- Test user behavior and component accessibility
+- Query elements by accessibility roles, labels, or text content
+- Use `userEvent` over `fireEvent` for more realistic user interactions
+
+## Common Jest Matchers
+- Basic: `expect(value).toBe(expected)`, `expect(value).toEqual(expected)`
+- Truthiness: `expect(value).toBeTruthy()`, `expect(value).toBeFalsy()`
+- Numbers: `expect(value).toBeGreaterThan(3)`, `expect(value).toBeLessThanOrEqual(3)`
+- Strings: `expect(value).toMatch(/pattern/)`, `expect(value).toContain('substring')`
+- Arrays: `expect(array).toContain(item)`, `expect(array).toHaveLength(3)`
+- Objects: `expect(object).toHaveProperty('key', value)`
+- Exceptions: `expect(fn).toThrow()`, `expect(fn).toThrow(Error)`
+- Mock functions: `expect(mockFn).toHaveBeenCalled()`, `expect(mockFn).toHaveBeenCalledWith(arg1, arg2)`

package/skills/general-kotlin-springboot.md

@@ -0,0 +1,71 @@
+---
+name: kotlin-springboot
+description: 'Get best practices for developing applications with Spring Boot and Kotlin.'
+category: general
+---
+
+# Spring Boot with Kotlin Best Practices
+
+Your goal is to help me write high-quality, idiomatic Spring Boot applications using Kotlin.
+
+## Project Setup & Structure
+
+- **Build Tool:** Use Maven (`pom.xml`) or Gradle (`build.gradle`) with the Kotlin plugins (`kotlin-maven-plugin` or `org.jetbrains.kotlin.jvm`).
+- **Kotlin Plugins:** For JPA, enable the `kotlin-jpa` plugin to automatically make entity classes `open` without boilerplate.
+- **Starters:** Use Spring Boot starters (e.g., `spring-boot-starter-web`, `spring-boot-starter-data-jpa`) as usual.
+- **Package Structure:** Organize code by feature/domain (e.g., `com.example.app.order`, `com.example.app.user`) rather than by layer.
+
+## Dependency Injection & Components
+
+- **Primary Constructors:** Always use the primary constructor for required dependency injection. It's the most idiomatic and concise approach in Kotlin.
+- **Immutability:** Declare dependencies as `private val` in the primary constructor. Prefer `val` over `var` everywhere to promote immutability.
+- **Component Stereotypes:** Use `@Service`, `@Repository`, and `@RestController` annotations just as you would in Java.
+
+## Configuration
+
+- **Externalized Configuration:** Use `application.yml` for its readability and hierarchical structure.
+- **Type-Safe Properties:** Use `@ConfigurationProperties` with `data class` to create immutable, type-safe configuration objects.
+- **Profiles:** Use Spring Profiles (`application-dev.yml`, `application-prod.yml`) to manage environment-specific configurations.
+- **Secrets Management:** Never hardcode secrets. Use environment variables or a dedicated secret management tool like HashiCorp Vault or AWS Secrets Manager.
+
+## Web Layer (Controllers)
+
+- **RESTful APIs:** Design clear and consistent RESTful endpoints.
+- **Data Classes for DTOs:** Use Kotlin `data class` for all DTOs. This provides `equals()`, `hashCode()`, `toString()`, and `copy()` for free and promotes immutability.
+- **Validation:** Use Java Bean Validation (JSR 380) with annotations (`@Valid`, `@NotNull`, `@Size`) on your DTO data classes.
+- **Error Handling:** Implement a global exception handler using `@ControllerAdvice` and `@ExceptionHandler` for consistent error responses.
+
+## Service Layer
+
+- **Business Logic:** Encapsulate business logic within `@Service` classes.
+- **Statelessness:** Services should be stateless.
+- **Transaction Management:** Use `@Transactional` on service methods. In Kotlin, this can be applied to class or function level.
+
+## Data Layer (Repositories)
+
+- **JPA Entities:** Define entities as classes. Remember they must be `open`. It's highly recommended to use the `kotlin-jpa` compiler plugin to handle this automatically.
+- **Null Safety:** Leverage Kotlin's null-safety (`?`) to clearly define which entity fields are optional or required at the type level.
+- **Spring Data JPA:** Use Spring Data JPA repositories by extending `JpaRepository` or `CrudRepository`.
+- **Coroutines:** For reactive applications, leverage Spring Boot's support for Kotlin Coroutines in the data layer.
+
+## Logging
+
+- **Companion Object Logger:** The idiomatic way to declare a logger is in a companion object.
+  ```kotlin
+  companion object {
+      private val logger = LoggerFactory.getLogger(MyClass::class.java)
+  }
+  ```
+- **Parameterized Logging:** Use parameterized messages (`logger.info("Processing user {}...", userId)`) for performance and clarity.
+
+## Testing
+
+- **JUnit 5:** JUnit 5 is the default and works seamlessly with Kotlin.
+- **Idiomatic Testing Libraries:** For more fluent and idiomatic tests, consider using **Kotest** for assertions and **MockK** for mocking. They are designed for Kotlin and offer a more expressive syntax.
+- **Test Slices:** Use test slice annotations like `@WebMvcTest` or `@DataJpaTest` to test specific parts of the application.
+- **Testcontainers:** Use Testcontainers for reliable integration tests with real databases, message brokers, etc.
+
+## Coroutines & Asynchronous Programming
+
+- **`suspend` functions:** For non-blocking asynchronous code, use `suspend` functions in your controllers and services. Spring Boot has excellent support for coroutines.
+- **Structured Concurrency:** Use `coroutineScope` or `supervisorScope` to manage the lifecycle of coroutines.