shmakk 1.1.0 → 1.2.0

package/skills/dev-scaffolding-oracle-to-postgres-migration-test-project.md

@@ -0,0 +1,55 @@
+---
+name: scaffolding-oracle-to-postgres-migration-test-project
+description: 'Scaffolds an xUnit integration test project for validating Oracle-to-PostgreSQL database migration behavior in .NET solutions. Creates the test project, transaction-rollback base class, and seed data manager. Use when setting up test infrastructure before writing migration integration tests, or when a test project is needed for Oracle-to-PostgreSQL validation.'
+category: dev
+---
+
+# Scaffolding an Integration Test Project for Oracle-to-PostgreSQL Migration
+
+Creates a compilable, empty xUnit test project with transaction management and seed data infrastructure for a single target project. Run once per project before writing tests.
+
+## Workflow
+
+```
+Progress:
+- [ ] Step 1: Inspect the target project
+- [ ] Step 2: Create the xUnit test project
+- [ ] Step 3: Implement transaction-rollback base class
+- [ ] Step 4: Implement seed data manager
+- [ ] Step 5: Verify the project compiles
+```
+
+**Step 1: Inspect the target project**
+
+Read the target project's `.csproj` to determine the .NET version and existing package references. Match these versions exactly — do not upgrade.
+
+**Step 2: Create the xUnit test project**
+
+- Target the same .NET version as the application under test.
+- Add NuGet packages for Oracle database connectivity and xUnit.
+- Add a project reference to the target project only — no other application projects.
+- Add an `appsettings.json` configured for Oracle database connectivity.
+
+**Step 3: Implement transaction-rollback base class**
+
+- Create a base test class that opens a transaction before each test and rolls it back after.
+- Catch and handle all exceptions to guarantee rollback.
+- Make the pattern inheritable by all downstream test classes.
+
+**Step 4: Implement seed data manager**
+
+- Create a global seed manager for loading test data within the transaction scope.
+- Do not commit seed data — transactions roll back after each test.
+- Do not use `TRUNCATE TABLE` — preserve existing database data.
+- Reuse existing seed files if available.
+- Establish a naming convention for seed file location that downstream test creation will follow.
+
+**Step 5: Verify the project compiles**
+
+Build the test project and confirm it compiles with zero errors before finishing.
+
+## Key Constraints
+
+- Oracle is the golden behavior source — scaffold for Oracle first.
+- Keep to existing .NET and C# versions; do not introduce newer language or runtime features.
+- Output is an empty test project with infrastructure only — no test cases.

package/skills/dev-spring-boot-testing.md

@@ -0,0 +1,190 @@
+---
+name: spring-boot-testing
+description: Expert Spring Boot 4 testing specialist that selects the best Spring Boot testing techniques for your situation with Junit 6 and AssertJ.
+category: dev
+---
+
+# Spring Boot Testing
+
+This skill provides expert guide for testing Spring Boot 4 applications with modern patterns and best practices.
+
+## Core Principles
+
+1. **Test Pyramid**: Unit (fast) > Slice (focused) > Integration (complete)
+2. **Right Tool**: Use the narrowest slice that gives you confidence
+3. **AssertJ Style**: Fluent, readable assertions over verbose matchers
+4. **Modern APIs**: Prefer MockMvcTester and RestTestClient over legacy alternatives
+
+## Which Test Slice?
+
+| Scenario | Annotation | Reference |
+|----------|------------|-----------|
+| Controller + HTTP semantics | `@WebMvcTest` | [references/webmvctest.md](references/webmvctest.md) |
+| Repository + JPA queries | `@DataJpaTest` | [references/datajpatest.md](references/datajpatest.md) |
+| REST client + external APIs | `@RestClientTest` | [references/restclienttest.md](references/restclienttest.md) |
+| JSON (de)serialization | `@JsonTest` | [references/test-slices-overview.md](references/test-slices-overview.md) |
+| Full application | `@SpringBootTest` | [references/test-slices-overview.md](references/test-slices-overview.md) |
+
+## Test Slices Reference
+
+- [references/test-slices-overview.md](references/test-slices-overview.md) - Decision matrix and comparison
+- [references/webmvctest.md](references/webmvctest.md) - Web layer with MockMvc
+- [references/datajpatest.md](references/datajpatest.md) - Data layer with Testcontainers
+- [references/restclienttest.md](references/restclienttest.md) - REST client testing
+
+## Testing Tools Reference
+
+- [references/mockmvc-tester.md](references/mockmvc-tester.md) - AssertJ-style MockMvc (3.2+)
+- [references/mockmvc-classic.md](references/mockmvc-classic.md) - Traditional MockMvc (pre-3.2)
+- [references/resttestclient.md](references/resttestclient.md) - Spring Boot 4+ REST client
+- [references/mockitobean.md](references/mockitobean.md) - Mocking dependencies
+
+## Assertion Libraries
+
+- [references/assertj-basics.md](references/assertj-basics.md) - Scalars, strings, booleans, dates
+- [references/assertj-collections.md](references/assertj-collections.md) - Lists, Sets, Maps, arrays
+
+## Testcontainers
+
+- [references/testcontainers-jdbc.md](references/testcontainers-jdbc.md) - PostgreSQL, MySQL, etc.
+
+## Test Data Generation
+
+- [references/instancio.md](references/instancio.md) - Generate complex test objects (3+ properties)
+
+## Performance & Migration
+
+- [references/context-caching.md](references/context-caching.md) - Speed up test suites
+- [references/sb4-migration.md](references/sb4-migration.md) - Spring Boot 4.0 changes
+
+## Quick Decision Tree
+
+```
+Testing a controller endpoint?
+  Yes → @WebMvcTest with MockMvcTester
+
+Testing repository queries?
+  Yes → @DataJpaTest with Testcontainers (real DB)
+
+Testing business logic in service?
+  Yes → Plain JUnit + Mockito (no Spring context)
+
+Testing external API client?
+  Yes → @RestClientTest with MockRestServiceServer
+
+Testing JSON mapping?
+  Yes → @JsonTest
+
+Need full integration test?
+  Yes → @SpringBootTest with minimal context config
+```
+
+## Spring Boot 4 Highlights
+
+- **RestTestClient**: Modern alternative to TestRestTemplate
+- **@MockitoBean**: Replaces @MockBean (deprecated)
+- **MockMvcTester**: AssertJ-style assertions for web tests
+- **Modular starters**: Technology-specific test starters
+- **Context pausing**: Automatic pausing of cached contexts (Spring Framework 7)
+
+## Testing Best Practices
+
+### Code Complexity Assessment
+
+When a method or class is too complex to test effectively:
+
+1. **Analyze complexity** - If you need more than 5-7 test cases to cover a single method, it's likely too complex
+2. **Recommend refactoring** - Suggest breaking the code into smaller, focused functions
+3. **User decision** - If the user agrees to refactor, help identify extraction points
+4. **Proceed if needed** - If the user decides to continue with the complex code, implement tests despite the difficulty
+
+**Example of refactoring recommendation:**
+```java
+// Before: Complex method hard to test
+public Order processOrder(OrderRequest request) {
+  // Validation, discount calculation, payment, inventory, notification...
+  // 50+ lines of mixed concerns
+}
+
+// After: Refactored into testable units
+public Order processOrder(OrderRequest request) {
+  validateOrder(request);
+  var order = createOrder(request);
+  applyDiscount(order);
+  processPayment(order);
+  updateInventory(order);
+  sendNotification(order);
+  return order;
+}
+```
+
+### Avoid Code Redundancy
+
+Create helper methods for commonly used objects and mock setup to enhance readability and maintainability.
+
+### Test Organization with @DisplayName
+
+Use descriptive display names to clarify test intent:
+
+```java
+@Test
+@DisplayName("Should calculate discount for VIP customer")
+void shouldCalculateDiscountForVip() { }
+
+@Test
+@DisplayName("Should reject order when customer has insufficient credit")
+void shouldRejectOrderForInsufficientCredit() { }
+```
+
+### Test Coverage Order
+
+Always structure tests in this order:
+
+1. **Main scenario** - The happy path, most common use case
+2. **Other paths** - Alternative valid scenarios, edge cases
+3. **Exceptions/Errors** - Invalid inputs, error conditions, failure modes
+
+### Test Production Scenarios
+
+Write tests with real production scenarios in mind. This makes tests more relatable and helps understand code behavior in actual production cases.
+
+### Test Coverage Goals
+
+Aim for 80% code coverage as a practical balance between quality and effort. Higher coverage is beneficial but not the only goal.
+
+Use Jacoco maven plugin for coverage reporting and tracking.
+
+
+**Coverage Rules:**
+- 80+% coverage minimum
+- Focus on meaningful assertions, not just execution
+
+**What to Prioritize:**
+1. Business-critical paths (payment processing, order validation)
+2. Complex algorithms (pricing, discount calculations)
+3. Error handling (exceptions, edge cases)
+4. Integration points (external APIs, databases)
+
+## Dependencies (Spring Boot 4)
+
+```xml
+<dependency>
+  <groupId>org.springframework.boot</groupId>
+  <artifactId>spring-boot-starter-test</artifactId>
+  <scope>test</scope>
+</dependency>
+
+<!-- For WebMvc tests -->
+<dependency>
+  <groupId>org.springframework.boot</groupId>
+  <artifactId>spring-boot-starter-webmvc-test</artifactId>
+  <scope>test</scope>
+</dependency>
+
+<!-- For Testcontainers -->
+<dependency>
+  <groupId>org.springframework.boot</groupId>
+  <artifactId>spring-boot-testcontainers</artifactId>
+  <scope>test</scope>
+</dependency>
+```

package/skills/dev-sync-upstream.md

@@ -0,0 +1,32 @@
+---
+name: sync-upstream
+description: Update a stale session branch by rebasing onto the latest origin. Use when the upstream has moved significantly and the session needs to catch up, resolving conflicts by preserving upstream changes and adapting session work to fit.
+category: dev
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Update Branch
+
+Rebase the current session branch onto the latest upstream so the work stays grounded in origin.
+
+## Workflow
+
+1. If there are uncommitted changes, use the `/commit` skill to commit them first.
+2. Fetch the latest upstream and rebase onto it:
+   ```
+   git fetch origin
+   git rebase origin/main
+   ```
+   Use the appropriate base branch if it is not `main`.
+
+## Conflict Resolution
+
+When conflicts arise, **upstream always wins**:
+
+- **Never alter upstream logic, APIs, or patterns** to accommodate session changes.
+- **Adapt session work** to fit the new upstream — rename, restructure, or rewrite as needed while preserving the session's goals.
+- After resolving each conflict, `git add` the files and `git rebase --continue`.
+
+## Validation
+
+After the rebase completes, verify the result still compiles and meets the session's objectives. If session changes no longer make sense against the updated upstream, explain what changed and propose a revised approach.

package/skills/dev-sync.md

@@ -0,0 +1,74 @@
+---
+name: sync
+description: Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.
+category: dev
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Sync Changes
+
+Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.
+
+## Guidelines
+
+- **Never force-push** (`--force`, `--force-with-lease`) without explicit user approval.
+- **Never skip pre-push hooks** (do not use `--no-verify`).
+- **Never rewrite or drop commits** during rebase without asking the user.
+- When in doubt about conflict resolution — ask the user.
+
+## Workflow
+
+1. Check for uncommitted changes first. If there are uncommitted changes, use the `/commit` skill to commit them before continuing.
+2. Check whether the current session branch has an upstream branch.
+3. If the current session branch has an upstream branch:
+   3.1. Fetch the upstream remote first so tracking refs are up to date.
+      ```
+      git fetch <upstream-remote>
+      ```
+   3.2. Check ahead/behind counts. If the branch is already in sync (0 ahead, 0 behind), stop and report that no sync is needed.
+      ```
+      git rev-list --left-right --count HEAD...@{u}
+      ```
+   3.3. If behind, rebase onto the upstream tracking branch.
+      ```
+      git rebase @{u}
+      ```
+   3.4. If there are merge conflicts, resolve them by preserving the intent of both sides. Stage the resolved files and continue the rebase.
+      ```
+      git add <resolved-files>
+      git rebase --continue
+      ```
+      If conflict resolution is unclear, ask the user how to proceed. If the user wants to stop the rebase, abort it:
+      ```
+      git rebase --abort
+      ```
+   3.5. If the branch has local commits (ahead > 0), push them to the remote after a successful rebase.
+      ```
+      git push
+      ```
+      If the push is rejected because the rebase rewrote history, explain the situation to the user and ask for approval before force-pushing.
+4. If the current session branch does not have an upstream branch:
+   4.1. Determine the remote to publish to.
+      - If there is only one remote, use it.
+      - If there are multiple remotes, use the #tool:vscode/askQuestions tool to ask which remote to use.
+   4.2. Publish the current branch and set upstream in one step.
+      ```
+      git push -u <remote> HEAD
+      ```
+
+## Validation
+
+After the workflow completes, validate the result with explicit checks:
+
+1. Verify the working tree is clean:
+   ```
+   git status --porcelain
+   ```
+2. Verify sync state (ahead/behind counts are both 0):
+   ```
+   git rev-list --left-right --count HEAD...@{u}
+   ```
+3. If the branch was newly published, verify the upstream branch is configured:
+   ```
+   git rev-parse --abbrev-ref --symbolic-full-name @{u}
+   ```

package/skills/dev-tdd-workflow.md

@@ -0,0 +1,23 @@
+---
+name: tdd-workflow
+description: TDD London School workflow -- mock-first, outside-in test development
+argument-hint: "<module-path>"
+allowed-tools: Bash(npx * npm *) mcp__claude-flow__hooks_pre-task mcp__claude-flow__hooks_post-task Read Write Edit
+category: dev
+---
+Follow the TDD London School (mock-first) approach:
+
+1. **Write the failing test first** -- define expected behavior with mocked dependencies
+2. **Run the test** -- confirm it fails for the right reason
+3. **Implement minimal code** -- make the test pass with the simplest solution
+4. **Refactor** -- clean up while keeping tests green
+5. **Repeat** -- add the next behavior
+
+Before starting: `mcp__claude-flow__hooks_pre-task({ description: "TDD: FEATURE_NAME" })`
+After completing: `mcp__claude-flow__hooks_post-task({ taskId: "tdd-FEATURE", success: true, storeResults: true })`
+
+Principles:
+- Mock external dependencies at boundaries
+- Test behavior, not implementation
+- One assertion per test when possible
+- Descriptive names: `should [behavior] when [condition]`

package/skills/dev-terraform-azurerm-set-diff-analyzer.md

@@ -0,0 +1,49 @@
+---
+name: terraform-azurerm-set-diff-analyzer
+description: Analyze Terraform plan JSON output for AzureRM Provider to distinguish between false-positive diffs (order-only changes in Set-type attributes) and actual resource changes. Use when reviewing terraform plan output for Azure resources like Application Gateway, Load Balancer, Firewall, Front Door, NSG, and other resources with Set-type attributes that cause spurious diffs due to internal ordering changes.
+license: MIT
+category: dev
+---
+
+# Terraform AzureRM Set Diff Analyzer
+
+A skill to identify "false-positive diffs" in Terraform plans caused by AzureRM Provider's Set-type attributes and distinguish them from actual changes.
+
+## When to Use
+
+- `terraform plan` shows many changes, but you only added/removed a single element
+- Application Gateway, Load Balancer, NSG, etc. show "all elements changed"
+- You want to automatically filter false-positive diffs in CI/CD
+
+## Background
+
+Terraform's Set type compares by position rather than by key, so when adding or removing elements, all elements appear as "changed". This is a general Terraform issue, but it's particularly noticeable with AzureRM resources that heavily use Set-type attributes like Application Gateway, Load Balancer, and NSG.
+
+These "false-positive diffs" don't actually affect the resources, but they make reviewing terraform plan output difficult.
+
+## Prerequisites
+
+- Python 3.8+
+
+If Python is unavailable, install via your package manager (e.g., `apt install python3`, `brew install python3`) or from [python.org](https://www.python.org/downloads/).
+
+## Basic Usage
+
+```bash
+# 1. Generate plan JSON output
+terraform plan -out=plan.tfplan
+terraform show -json plan.tfplan > plan.json
+
+# 2. Analyze
+python scripts/analyze_plan.py plan.json
+```
+
+## Troubleshooting
+
+- **`python: command not found`**: Use `python3` instead, or install Python
+- **`ModuleNotFoundError`**: Script uses only standard library; ensure Python 3.8+
+
+## Detailed Documentation
+
+- [scripts/README.md](scripts/README.md) - All options, output formats, exit codes, CI/CD examples
+- [references/azurerm_set_attributes.md](references/azurerm_set_attributes.md) - Supported resources and attributes