@c0x12c/ai-toolkit 1.15.0

package/commands/spartan/teardown.md

@@ -0,0 +1,161 @@
+---
+name: spartan:teardown
+description: Deep competitor analysis — pricing, features, strengths, weaknesses, and where they leave gaps
+argument-hint: "[competitor name or URL]"
+---
+
+# Competitor Teardown: {{ args[0] | default: "competitor" }}
+
+You are running a deep competitor analysis. Be brutally honest — don't downplay their strengths or inflate their weaknesses. The goal is to understand them clearly so we can find real gaps.
+
+If the user gives a URL, use web search to find real data about the company. If they give just a name, search for it.
+
+**Use web search** to find pricing pages, G2/Capterra reviews, traffic data, and social media mentions. Real data beats guessing.
+
+---
+
+## Section 1: Overview
+
+Write one paragraph: What do they do? Who do they serve? When were they founded? How big are they?
+
+Keep it factual. No opinions yet.
+
+---
+
+## Section 2: Pricing
+
+| Plan | Price | Key Features |
+|---|---|---|
+| Free / Trial | | |
+| Starter / Basic | | |
+| Pro / Growth | | |
+| Enterprise | | |
+
+Note: Do they have a free tier? Free trial length? Annual vs monthly pricing difference?
+What's the cheapest way to get started?
+
+---
+
+## Section 3: Feature Breakdown
+
+| Feature | Have It? | How Good? (1-5) | Notes |
+|---|---|---|---|
+| [core feature 1] | Yes/No | | |
+| [core feature 2] | Yes/No | | |
+| [core feature 3] | Yes/No | | |
+| ... | | | |
+
+List 10-15 features that matter for this market. Score quality honestly.
+
+---
+
+## Section 4: What They Do Well (Top 3)
+
+List their top 3 strengths. For each one:
+- What is it?
+- Evidence (user reviews, market position, product quality)
+- How hard would it be to match this?
+
+Don't skip this. If they're winning, there's a reason.
+
+---
+
+## Section 5: What They Do Poorly (Top 3)
+
+List their top 3 weaknesses. For each one:
+- What is it?
+- Evidence (user complaints, missing features, bad UX)
+- Is this a real gap or just nitpicking?
+
+Only list real problems. "Their logo is ugly" doesn't count.
+
+---
+
+## Section 6: User Reviews
+
+Search G2, Capterra, Reddit, Twitter/X, Product Hunt for real user feedback.
+
+**What users love:**
+- [quote or paraphrase + source]
+- [quote or paraphrase + source]
+- [quote or paraphrase + source]
+
+**What users hate:**
+- [quote or paraphrase + source]
+- [quote or paraphrase + source]
+- [quote or paraphrase + source]
+
+**Common themes:** What shows up over and over in reviews?
+
+---
+
+## Section 7: Traffic & Traction
+
+| Metric | Value | Source |
+|---|---|---|
+| Monthly visitors (estimate) | | SimilarWeb / search |
+| Growth trend | Growing / Flat / Declining | |
+| Team size (estimate) | | LinkedIn / Crunchbase |
+| Total funding | | Crunchbase |
+| Last funding round | | |
+| Notable customers | | |
+
+If data isn't available, say so. Don't make up numbers.
+
+---
+
+## Section 8: How They Get Users
+
+Check which channels they use:
+
+| Channel | Active? | Evidence |
+|---|---|---|
+| SEO / Content marketing | | Blog posts? Ranking for key terms? |
+| Paid ads (Google/Meta) | | Found ads? Sponsorships? |
+| Social media | | Active accounts? Engagement? |
+| Community / Forums | | Discord? Slack? Reddit presence? |
+| Partnerships / Integrations | | App stores? Partner pages? |
+| Word of mouth / Referrals | | Referral program? Organic mentions? |
+| Product Hunt / Launch sites | | Past launches? |
+
+What's their main growth channel? Where do most users come from?
+
+---
+
+## Section 9: Positioning
+
+- **How they describe themselves:** [their tagline / hero text]
+- **Target persona:** Who are they really building for?
+- **Positioning:** Are they the cheap option? The premium option? The easy option? The powerful option?
+- **Brand voice:** Corporate / Casual / Technical / Friendly?
+
+---
+
+## Section 10: Our Opportunity
+
+This is the "so what?" section. Based on everything above:
+
+**Gaps they leave open:**
+- [gap 1 — who's underserved?]
+- [gap 2 — what feature is missing or weak?]
+- [gap 3 — what segment do they ignore?]
+
+**What we'd do differently:**
+- [difference 1]
+- [difference 2]
+- [difference 3]
+
+---
+
+## So What?
+
+Write one paragraph: What does this teardown mean for our strategy? Where should we compete, and where should we avoid competing?
+
+Be specific. "We should differentiate" is useless. Say HOW and WHERE.
+
+---
+
+**Next steps:**
+- Want to analyze another competitor? Run `/spartan:teardown [name]` again
+- Ready to compare multiple competitors side by side? Ask me to build a comparison matrix
+- Want to validate your positioning? Run `/spartan:validate` with your idea

package/commands/spartan/testcontainer.md

@@ -0,0 +1,97 @@
+---
+name: spartan:testcontainer
+description: Set up integration testing infrastructure for a Kotlin Micronaut service using @MicronautTest and Testcontainers
+argument-hint: "[postgres | kafka | redis | all]"
+---
+
+Set up integration testing in this Kotlin Micronaut project.
+
+**Reference:** `/testing-strategies` skill and `rules/backend-micronaut/API_DESIGN.md` (testing section)
+
+## Requested containers: {{ args[0] | default: "postgres" }}
+
+### 1. Add Dependencies (build.gradle.kts)
+
+```kotlin
+testImplementation("org.testcontainers:testcontainers:1.19.3")
+testImplementation("org.testcontainers:junit-jupiter:1.19.3")
+testImplementation("org.testcontainers:postgresql:1.19.3")
+testImplementation("io.micronaut.test:micronaut-test-junit5")
+```
+
+### 2. Create Base Test Configuration
+
+Create `src/test/kotlin/.../AbstractControllerTest.kt`:
+
+```kotlin
+@MicronautTest(environments = ["test"], transactional = false)
+@TestInstance(TestInstance.Lifecycle.PER_CLASS)
+abstract class AbstractControllerTest {
+
+    @Inject
+    lateinit var embeddedServer: EmbeddedServer
+
+    @BeforeAll
+    open fun beforeAll() {
+        // Setup test clients from embeddedServer.url
+    }
+
+    companion object {
+        @Container
+        @JvmStatic
+        val postgres = PostgreSQLContainer("postgres:16-alpine")
+            .withDatabaseName("testdb")
+            .withUsername("test")
+            .withPassword("test")
+
+        @DynamicPropertySource
+        @JvmStatic
+        fun overrideProperties(registry: DynamicPropertyRegistry) {
+            registry.add("datasources.default.url", postgres::getJdbcUrl)
+            registry.add("datasources.default.username", postgres::getUsername)
+            registry.add("datasources.default.password", postgres::getPassword)
+        }
+    }
+}
+```
+
+### 3. Create Example Integration Test
+
+```kotlin
+class EmployeeControllerTest : AbstractControllerTest() {
+
+    private lateinit var employeeClient: EmployeeClient
+
+    @BeforeAll
+    override fun beforeAll() {
+        super.beforeAll()
+        val url = embeddedServer.url.toString()
+        employeeClient = EmployeeClient(url)
+    }
+
+    @Test
+    fun `create employee returns success`() {
+        val request = CreateEmployeeRequest(name = "Test User", email = "test@example.com")
+        val response = employeeClient.create(request)
+        assertNotNull(response.id)
+        assertEquals("Test User", response.name)
+    }
+}
+```
+
+### 4. Application config for test profile
+
+Create `src/test/resources/application-test.yml`:
+```yaml
+datasources:
+  default:
+    # Overridden by Testcontainers DynamicPropertySource
+    dialect: POSTGRES
+flyway:
+  datasources:
+    default:
+      enabled: true
+      locations: classpath:db/migration
+```
+
+After setup, verify all tests pass with: `./gradlew test`

package/commands/spartan/tf-cost.md

@@ -0,0 +1,123 @@
+---
+name: spartan:tf-cost
+description: Cost estimation guidance — sizing recommendations, common patterns, optimization tips
+argument-hint: "[optional: resource-type]"
+preamble-tier: 2
+---
+@rules/infrastructure/STRUCTURE.md
+@rules/infrastructure/MODULES.md
+
+# Terraform Cost Estimation: {{ args[0] | default: "infrastructure review" }}
+
+Review infrastructure costs and provide sizing recommendations.
+
+## Step 1: Identify Resources
+
+```bash
+# List all resource types in the current config
+grep -r "^resource " *.tf modules/ 2>/dev/null | awk '{print $2}' | sort | uniq -c | sort -rn
+```
+
+## Step 2: Common Cost Patterns
+
+### RDS (PostgreSQL/Aurora)
+
+| Environment | Instance | Storage | Multi-AZ | Est. Monthly |
+|-------------|----------|---------|----------|-------------|
+| dev | `db.t3.micro` | 20 GB gp3 | No | ~$15 |
+| staging | `db.t3.small` | 50 GB gp3 | No | ~$30 |
+| prod | `db.r6g.large` | 100 GB gp3 | Yes | ~$400 |
+
+**Optimization:**
+- Use `db.t3.*` for dev/staging — burstable is fine for low traffic
+- Enable storage autoscaling with a max limit
+- Aurora Serverless v2 for variable workloads (0.5-128 ACU)
+
+### ElastiCache (Redis)
+
+| Environment | Instance | Replicas | Est. Monthly |
+|-------------|----------|----------|-------------|
+| dev | `cache.t3.micro` | 0 | ~$12 |
+| staging | `cache.t3.small` | 0 | ~$25 |
+| prod | `cache.r6g.large` | 1 | ~$300 |
+
+### NAT Gateway
+
+> **Cost trap:** NAT gateways charge per hour AND per GB processed.
+
+| Setup | Est. Monthly |
+|-------|-------------|
+| 1 NAT per AZ (3 AZs) | ~$100 + data |
+| 1 shared NAT | ~$33 + data |
+| NAT instance (t3.micro) | ~$8 |
+
+**Optimization:**
+- Dev: use a single NAT or NAT instance
+- Prod: one NAT per AZ for high availability
+- Route S3/DynamoDB through VPC endpoints (free) instead of NAT
+
+### ECS Fargate
+
+| Size | vCPU | Memory | Est. Monthly (24/7) |
+|------|------|--------|-------------------|
+| Micro | 0.25 | 0.5 GB | ~$9 |
+| Small | 0.5 | 1 GB | ~$18 |
+| Medium | 1 | 2 GB | ~$36 |
+| Large | 2 | 4 GB | ~$73 |
+
+**Optimization:**
+- Use Fargate Spot for dev/staging (up to 70% savings)
+- Right-size: check CloudWatch CPU/memory utilization
+- Scale to zero in dev after hours
+
+### EKS Node Groups
+
+| Environment | Instance | Nodes | Est. Monthly |
+|-------------|----------|-------|-------------|
+| dev | `t3.medium` | 2 | ~$60 + $75 (control plane) |
+| prod | `m6i.xlarge` | 3-6 | ~$300-600 + $75 |
+
+**Note:** EKS control plane is $75/month regardless of size.
+
+## Step 3: Dev vs Prod Sizing
+
+| Resource | Dev | Prod | Savings |
+|----------|-----|------|---------|
+| RDS | t3.micro, no Multi-AZ | r6g.large, Multi-AZ | 95% |
+| Redis | t3.micro, no replica | r6g.large, 1 replica | 95% |
+| NAT | 1 shared or NAT instance | 1 per AZ | 70% |
+| Fargate | Spot, min replicas | On-demand, auto-scale | 60% |
+| EKS | Spot nodes, smaller | On-demand, right-sized | 50% |
+
+## Step 4: Cost Optimization Tips
+
+1. **VPC Endpoints** — S3 and DynamoDB gateway endpoints are free. Saves NAT data costs.
+2. **Reserved Instances** — 1-year no-upfront saves ~30% on RDS/ElastiCache in prod.
+3. **Scheduled scaling** — Scale down dev/staging outside business hours.
+4. **S3 lifecycle rules** — Move old objects to Glacier or Intelligent-Tiering.
+5. **Right-size** — Review CloudWatch metrics monthly. Downsize over-provisioned resources.
+6. **Clean up** — Delete unused EBS snapshots, old AMIs, unattached EIPs.
+
+## Step 5: Estimate for Current Config
+
+Review the Terraform config and produce:
+
+```
+## Cost Estimate: {env}
+
+| Resource | Type | Size | Est. Monthly |
+|----------|------|------|-------------|
+| RDS | PostgreSQL | db.t3.small | $30 |
+| ... | ... | ... | ... |
+
+**Total estimated:** $X/month
+**Potential savings:** $Y/month with [recommendations]
+```
+
+## Rules
+
+- These are estimates — use AWS Pricing Calculator for exact numbers
+- Always compare dev vs prod sizing — dev should be minimal
+- Flag NAT gateway costs explicitly — they surprise teams
+- Recommend VPC endpoints before adding NAT gateways for AWS service traffic
+- Cost reviews should happen before deploying new infrastructure, not after

package/commands/spartan/tf-deploy.md

@@ -0,0 +1,116 @@
+---
+name: spartan:tf-deploy
+description: Deployment checklist — pre-deploy verification, apply, post-deploy health checks
+argument-hint: "[environment]"
+preamble-tier: 3
+---
+@rules/infrastructure/STATE_AND_BACKEND.md
+
+# Terraform Deploy: {{ args[0] | default: "target environment" }}
+
+Deploy Terraform changes with a full pre/post checklist.
+
+## Pre-Deploy Checklist
+
+### 1. Verify Branch
+
+```bash
+git branch --show-current
+git status --short
+```
+
+- [ ] On the correct branch (not `main` for direct apply)
+- [ ] No uncommitted changes to `.tf` files
+- [ ] PR approved (for staging/prod)
+
+### 2. Run Plan
+
+```bash
+terraform plan \
+  -var-file=../../envs/{{ args[0] | default: "dev" }}.tfvars \
+  -out=tfplan \
+  -detailed-exitcode
+```
+
+- [ ] Plan reviewed and understood
+- [ ] No unexpected destroys or replacements
+- [ ] Resource count matches expectations
+
+### 3. Review Changes
+
+Summarize what will change:
+
+| Action | Resource | Detail |
+|--------|----------|--------|
+| create | `aws_...` | New resource |
+| update | `aws_...` | What's changing |
+| replace | `aws_...` | WHY it's being replaced |
+
+### 4. Check State Locks
+
+```bash
+# Verify no one else is running terraform
+terraform plan -lock=true 2>&1 | grep -i "lock"
+```
+
+If state is locked, identify who holds the lock before proceeding.
+
+## Deploy
+
+### 5. Apply
+
+```bash
+terraform apply tfplan
+```
+
+- Monitor output for errors
+- If apply fails mid-way, DO NOT re-plan — the state has partially updated
+- On partial failure: fix the issue, then run `terraform plan` again to see remaining changes
+
+### 6. Verify Apply Output
+
+- [ ] All resources show `Creation complete` or `Modifications complete`
+- [ ] No errors in output
+- [ ] Apply completed with `Apply complete! Resources: X added, Y changed, Z destroyed.`
+
+## Post-Deploy
+
+### 7. Verify Resources
+
+```bash
+# Check key resources exist and are healthy
+aws ecs describe-services --cluster {project}-{env} --services {service} 2>/dev/null
+aws rds describe-db-instances --db-instance-identifier {project}-{env}-{service} 2>/dev/null
+```
+
+- [ ] Service is running / database is available
+- [ ] Security groups are correctly attached
+- [ ] DNS records resolve (if applicable)
+
+### 8. Health Check
+
+- [ ] Application health endpoint returns 200
+- [ ] Logs show successful startup (no crash loops)
+- [ ] Metrics pipeline receiving data
+
+### 9. Notify
+
+Post deployment summary:
+
+```
+## Deploy Complete: {service} → {{ args[0] | default: "dev" }}
+
+- **Resources:** X added, Y changed, Z destroyed
+- **Commit:** [hash]
+- **Health:** [passing / issues]
+- **Rollback plan:** [revert commit and re-apply / restore from state backup]
+```
+
+## Rules
+
+- Never apply without reviewing the plan first
+- Never apply directly to prod without approval
+- Always use saved plan file (`tfplan`) — never `terraform apply` without `-out`
+- If apply fails partially, do NOT run `terraform destroy` — fix forward
+- Keep the terminal open during apply — interrupted applies can corrupt state
+- For prod deployments, have a rollback plan documented before applying

package/commands/spartan/tf-drift.md

@@ -0,0 +1,100 @@
+---
+name: spartan:tf-drift
+description: Detect and categorize infrastructure drift — benign vs concerning changes
+argument-hint: "[environment]"
+preamble-tier: 2
+---
+@rules/infrastructure/STATE_AND_BACKEND.md
+
+# Terraform Drift Detection: {{ args[0] | default: "target environment" }}
+
+Detect and analyze differences between Terraform state and actual infrastructure.
+
+## Step 1: Initialize
+
+```bash
+terraform init -backend-config=../../envs/{{ args[0] | default: "dev" }}.tfbackend
+```
+
+## Step 2: Refresh and Plan
+
+```bash
+terraform plan \
+  -var-file=../../envs/{{ args[0] | default: "dev" }}.tfvars \
+  -refresh-only \
+  -detailed-exitcode
+```
+
+Exit code `2` means drift was detected.
+
+For a full view including config vs state:
+
+```bash
+terraform plan \
+  -var-file=../../envs/{{ args[0] | default: "dev" }}.tfvars \
+  -detailed-exitcode
+```
+
+## Step 3: Analyze Drift
+
+For each drifted resource, determine the cause:
+
+| Category | Examples | Action |
+|----------|----------|--------|
+| **Benign** | Auto-scaling changed instance count, AWS updated default SSL policy, tags added by AWS | Ignore or update config |
+| **Expected** | Manual hotfix applied, console change during incident | Adopt into config or revert |
+| **Concerning** | Security group rules changed, IAM policy modified, encryption disabled | Investigate immediately |
+| **Critical** | Resources deleted outside Terraform, access controls weakened | Escalate and remediate |
+
+## Step 4: Categorize Findings
+
+```
+## Drift Report: {{ args[0] | default: "dev" }}
+
+### Benign (no action needed)
+- `aws_autoscaling_group.this` — desired_count changed by auto-scaler
+
+### Expected (adopt or revert)
+- `aws_security_group_rule.hotfix` — added during incident on [date]
+  → Recommendation: adopt into config
+
+### Concerning (investigate)
+- `aws_iam_policy.service_role` — permissions widened
+  → Recommendation: review who changed this and why
+
+### Critical (immediate action)
+- [none found / list items]
+```
+
+## Step 5: Remediate
+
+For each category:
+
+- **Benign** — Update Terraform config to match reality, or add `lifecycle { ignore_changes }`:
+  ```hcl
+  lifecycle {
+    ignore_changes = [desired_count]
+  }
+  ```
+
+- **Expected** — Either update config to match (adopt) or run `terraform apply` to revert to config.
+
+- **Concerning** — Investigate through CloudTrail, then decide: adopt or revert.
+
+- **Critical** — Revert immediately with `terraform apply`, then investigate.
+
+## Step 6: Apply Corrections
+
+```bash
+terraform plan -var-file=../../envs/{env}.tfvars -out=tfplan
+# Review the plan
+terraform apply tfplan
+```
+
+## Rules
+
+- Run drift detection on a schedule — weekly for prod, bi-weekly for other envs
+- Never auto-apply drift corrections without human review
+- Use CloudTrail to identify who made out-of-band changes
+- Add `ignore_changes` only for attributes that legitimately change outside Terraform (e.g., auto-scaling counts)
+- Document all adopted drift in commit messages explaining why the manual change was made

package/commands/spartan/tf-import.md

@@ -0,0 +1,107 @@
+---
+name: spartan:tf-import
+description: Import existing AWS resources into Terraform state with config generation
+argument-hint: "[resource-type resource-id]"
+preamble-tier: 3
+---
+@rules/infrastructure/STRUCTURE.md
+@rules/infrastructure/NAMING.md
+
+# Terraform Import: {{ args[0] | default: "existing resource" }}
+
+Import an existing resource into Terraform management.
+
+## Step 1: Identify the Resource
+
+Parse the user's input to determine:
+- **Resource type** — AWS resource type (e.g., `aws_s3_bucket`, `aws_rds_instance`)
+- **Resource ID** — The identifier used by AWS (ARN, name, or ID)
+
+If not provided, ask:
+
+> **What resource are you importing?**
+>
+> Examples:
+> - `aws_s3_bucket my-bucket-name`
+> - `aws_db_instance my-rds-instance`
+> - `aws_security_group sg-0123456789abcdef`
+> - `aws_iam_role my-role-name`
+
+## Step 2: Write Terraform Config
+
+Before importing, write the resource block that matches the existing resource.
+
+```bash
+# Describe the resource to get current config
+aws s3api get-bucket-versioning --bucket {bucket-name} 2>/dev/null
+aws rds describe-db-instances --db-instance-identifier {instance-id} 2>/dev/null
+aws ec2 describe-security-groups --group-ids {sg-id} 2>/dev/null
+aws iam get-role --role-name {role-name} 2>/dev/null
+```
+
+Write a resource block that matches the existing state as closely as possible:
+
+```hcl
+resource "aws_resource_type" "this" {
+  # Match existing configuration exactly
+  # to minimize drift on first plan
+}
+```
+
+## Step 3: Run Import
+
+```bash
+terraform import aws_resource_type.this {resource-id}
+```
+
+### Common Import Patterns
+
+| Resource | Import ID Format |
+|----------|-----------------|
+| `aws_s3_bucket` | Bucket name |
+| `aws_db_instance` | DB instance identifier |
+| `aws_security_group` | Security group ID (`sg-xxx`) |
+| `aws_iam_role` | Role name |
+| `aws_ecs_service` | `{cluster}/{service}` |
+| `aws_lb` | ALB ARN |
+| `aws_route53_record` | `{zone_id}_{name}_{type}` |
+| `aws_ecr_repository` | Repository name |
+
+## Step 4: Verify State
+
+```bash
+terraform state show aws_resource_type.this
+```
+
+Confirm the state contains the expected attributes.
+
+## Step 5: Plan to Check Drift
+
+```bash
+terraform plan -var-file=../../envs/{env}.tfvars
+```
+
+Review the plan output:
+- **No changes** — config matches reality. Done.
+- **In-place updates** — config differs from reality. Update your `.tf` to match, or accept the change.
+- **Replace** — a force-new attribute differs. Update your `.tf` to match exactly.
+
+Iterate: adjust the resource block until `terraform plan` shows no changes.
+
+## Step 6: Commit
+
+Once plan shows no changes:
+
+```bash
+git add -A
+git commit -m "feat(infra): import {resource-type} into terraform state"
+```
+
+## Rules
+
+- Always write the resource config BEFORE running import
+- After import, run plan immediately — never leave imported resources with drift
+- Iterate until plan shows zero changes
+- Import one resource at a time — don't batch
+- For resources with dependencies, import in dependency order (VPC → subnet → security group → instance)
+- Never import resources managed by another Terraform workspace