create-inox-app 0.1.0

package/dist/templates/claude-config/kustomize/.claude/settings.json

@@ -0,0 +1,42 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(ls:*)",
+      "Bash(cat:*)",
+      "Bash(grep:*)",
+      "Bash(rg:*)",
+      "Bash(cp:*)",
+      "Bash(find:*)",
+      "Bash(pwd:*)",
+      "Bash(echo:*)",
+      "Bash(whoami:*)",
+      "Bash(source:*)",
+      "Bash(sed:*)",
+      "Bash(head:*)",
+      "Bash(tail:*)",
+      "Bash(mkdir:*)",
+      "Bash(mv:*)",
+      "Bash(touch:*)",
+      "Bash(cd:*)",
+      "Bash(tree:*)",
+      "Bash(type:*)",
+      "Bash(which:*)",
+      "Bash(git:*)",
+      "Bash(bun:*)",
+      "Bash(npm:*)"
+    ],
+    "deny": [
+      "Bash(git push:*)",
+      "Bash(git pull:*)",
+      "Bash(git fetch:*)",
+      "Bash(git reset:*)",
+      "Bash(git clean:*)",
+      "Bash(git checkout .:*)",
+      "Bash(git rebase:*)",
+      "Bash(git stash:*)",
+      "Bash(npm publish:*)",
+      "Bash(bun publish:*)",
+      "Bash(git branch -D:*)"
+    ]
+  }
+}

package/dist/templates/claude-config/kustomize/.claude/skills/git-commit/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: git-commit
+description: 'Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping'
+license: MIT
+allowed-tools: Bash
+---
+
+# Git Commit with Conventional Commits
+
+## Overview
+
+Create standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.
+
+## Conventional Commit Format
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+## Commit Types
+
+| Type       | Purpose                        |
+| ---------- | ------------------------------ |
+| `feat`     | New feature                    |
+| `fix`      | Bug fix                        |
+| `docs`     | Documentation only             |
+| `style`    | Formatting/style (no logic)    |
+| `refactor` | Code refactor (no feature/fix) |
+| `perf`     | Performance improvement        |
+| `test`     | Add/update tests               |
+| `build`    | Build system/dependencies      |
+| `ci`       | CI/config changes              |
+| `chore`    | Maintenance/misc               |
+| `revert`   | Revert commit                  |
+
+## Breaking Changes
+
+```
+# Exclamation mark after type/scope
+feat!: remove deprecated endpoint
+
+# BREAKING CHANGE footer
+feat: allow config to extend other configs
+
+BREAKING CHANGE: `extends` key behavior changed
+```
+
+## Workflow
+
+### 1. Analyze Diff
+
+```bash
+# If files are staged, use staged diff
+git diff --staged
+
+# If nothing staged, use working tree diff
+git diff
+
+# Also check status
+git status --porcelain
+```
+
+### 2. Stage Files (if needed)
+
+If nothing is staged or you want to group changes differently:
+
+```bash
+# Stage specific files
+git add path/to/file1 path/to/file2
+
+# Stage by pattern
+git add *.test.*
+git add src/components/*
+
+# Interactive staging
+git add -p
+```
+
+**Never commit secrets** (.env, credentials.json, private keys).
+
+### 3. Generate Commit Message
+
+Analyze the diff to determine:
+
+- **Type**: What kind of change is this?
+- **Scope**: What area/module is affected?
+- **Description**: One-line summary of what changed (present tense, imperative mood, <72 chars)
+
+### 4. Execute Commit
+
+```bash
+# Single line
+git commit -m "<type>[scope]: <description>"
+
+# Multi-line with body/footer
+git commit -m "$(cat <<'EOF'
+<type>[scope]: <description>
+
+<optional body>
+
+<optional footer>
+EOF
+)"
+```
+
+## Best Practices
+
+- One logical change per commit
+- Present tense: "add" not "added"
+- Imperative mood: "fix bug" not "fixes bug"
+- Reference issues: `Closes #123`, `Refs #456`
+- Keep description under 72 characters
+
+## Git Safety Protocol
+
+- NEVER update git config
+- NEVER run destructive commands (--force, hard reset) without explicit request
+- NEVER skip hooks (--no-verify) unless user asks
+- NEVER force push to main/master
+- If commit fails due to hooks, fix and create NEW commit (don't amend)

package/dist/templates/claude-config/kustomize/.claude/skills/k8s-manifest-generator/SKILL.md

@@ -0,0 +1,534 @@
+---
+name: k8s-manifest-generator
+description: Create production-ready Kubernetes manifests for Deployments, Services, ConfigMaps, and Secrets following best practices and security standards. Use when generating Kubernetes YAML manifests, creating K8s resources, or implementing production-grade Kubernetes configurations.
+---
+
+# Kubernetes Manifest Generator
+
+Step-by-step guidance for creating production-ready Kubernetes manifests including Deployments, Services, ConfigMaps, Secrets, and PersistentVolumeClaims.
+
+## Purpose
+
+This skill provides comprehensive guidance for generating well-structured, secure, and production-ready Kubernetes manifests following cloud-native best practices and Kubernetes conventions.
+
+## When to Use This Skill
+
+Use this skill when you need to:
+
+- Create new Kubernetes Deployment manifests
+- Define Service resources for network connectivity
+- Generate ConfigMap and Secret resources for configuration management
+- Create PersistentVolumeClaim manifests for stateful workloads
+- Follow Kubernetes best practices and naming conventions
+- Implement resource limits, health checks, and security contexts
+- Design manifests for multi-environment deployments
+
+## Step-by-Step Workflow
+
+### 1. Gather Requirements
+
+**Understand the workload:**
+
+- Application type (stateless/stateful)
+- Container image and version
+- Environment variables and configuration needs
+- Storage requirements
+- Network exposure requirements (internal/external)
+- Resource requirements (CPU, memory)
+- Scaling requirements
+- Health check endpoints
+
+**Questions to ask:**
+
+- What is the application name and purpose?
+- What container image and tag will be used?
+- Does the application need persistent storage?
+- What ports does the application expose?
+- Are there any secrets or configuration files needed?
+- What are the CPU and memory requirements?
+- Does the application need to be exposed externally?
+
+### 2. Create Deployment Manifest
+
+**Follow this structure:**
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: <app-name>
+  namespace: <namespace>
+  labels:
+    app: <app-name>
+    version: <version>
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: <app-name>
+  template:
+    metadata:
+      labels:
+        app: <app-name>
+        version: <version>
+    spec:
+      containers:
+        - name: <container-name>
+          image: <image>:<tag>
+          ports:
+            - containerPort: <port>
+              name: http
+          resources:
+            requests:
+              memory: "256Mi"
+              cpu: "250m"
+            limits:
+              memory: "512Mi"
+              cpu: "500m"
+          livenessProbe:
+            httpGet:
+              path: /health
+              port: http
+            initialDelaySeconds: 30
+            periodSeconds: 10
+          readinessProbe:
+            httpGet:
+              path: /ready
+              port: http
+            initialDelaySeconds: 5
+            periodSeconds: 5
+          env:
+            - name: ENV_VAR
+              value: "value"
+          envFrom:
+            - configMapRef:
+                name: <app-name>-config
+            - secretRef:
+                name: <app-name>-secret
+```
+
+**Best practices to apply:**
+
+- Always set resource requests and limits
+- Implement both liveness and readiness probes
+- Use specific image tags (never `:latest`)
+- Apply security context for non-root users
+- Use labels for organization and selection
+- Set appropriate replica count based on availability needs
+
+**Reference:** See `references/deployment-spec.md` for detailed deployment options
+
+### 3. Create Service Manifest
+
+**Choose the appropriate Service type:**
+
+**ClusterIP (internal only):**
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: <app-name>
+  namespace: <namespace>
+  labels:
+    app: <app-name>
+spec:
+  type: ClusterIP
+  selector:
+    app: <app-name>
+  ports:
+    - name: http
+      port: 80
+      targetPort: 8080
+      protocol: TCP
+```
+
+**LoadBalancer (external access):**
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: <app-name>
+  namespace: <namespace>
+  labels:
+    app: <app-name>
+  annotations:
+    service.beta.kubernetes.io/aws-load-balancer-type: nlb
+spec:
+  type: LoadBalancer
+  selector:
+    app: <app-name>
+  ports:
+    - name: http
+      port: 80
+      targetPort: 8080
+      protocol: TCP
+```
+
+**Reference:** See `references/service-spec.md` for service types and networking
+
+### 4. Create ConfigMap
+
+**For application configuration:**
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: <app-name>-config
+  namespace: <namespace>
+data:
+  APP_MODE: production
+  LOG_LEVEL: info
+  DATABASE_HOST: db.example.com
+  # For config files
+  app.properties: |
+    server.port=8080
+    server.host=0.0.0.0
+    logging.level=INFO
+```
+
+**Best practices:**
+
+- Use ConfigMaps for non-sensitive data only
+- Organize related configuration together
+- Use meaningful names for keys
+- Consider using one ConfigMap per component
+- Version ConfigMaps when making changes
+
+**Reference:** See `assets/configmap-template.yaml` for examples
+
+### 5. Create Secret
+
+**For sensitive data:**
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: <app-name>-secret
+  namespace: <namespace>
+type: Opaque
+stringData:
+  DATABASE_PASSWORD: "changeme"
+  API_KEY: "secret-api-key"
+  # For certificate files
+  tls.crt: |
+    -----BEGIN CERTIFICATE-----
+    ...
+    -----END CERTIFICATE-----
+  tls.key: |
+    -----BEGIN PRIVATE KEY-----
+    ...
+    -----END PRIVATE KEY-----
+```
+
+**Security considerations:**
+
+- Never commit secrets to Git in plain text
+- Use Sealed Secrets, External Secrets Operator, or Vault
+- Rotate secrets regularly
+- Use RBAC to limit secret access
+- Consider using Secret type: `kubernetes.io/tls` for TLS secrets
+
+### 6. Create PersistentVolumeClaim (if needed)
+
+**For stateful applications:**
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: <app-name>-data
+  namespace: <namespace>
+spec:
+  accessModes:
+    - ReadWriteOnce
+  storageClassName: gp3
+  resources:
+    requests:
+      storage: 10Gi
+```
+
+**Mount in Deployment:**
+
+```yaml
+spec:
+  template:
+    spec:
+      containers:
+        - name: app
+          volumeMounts:
+            - name: data
+              mountPath: /var/lib/app
+      volumes:
+        - name: data
+          persistentVolumeClaim:
+            claimName: <app-name>-data
+```
+
+**Storage considerations:**
+
+- Choose appropriate StorageClass for performance needs
+- Use ReadWriteOnce for single-pod access
+- Use ReadWriteMany for multi-pod shared storage
+- Consider backup strategies
+- Set appropriate retention policies
+
+### 7. Apply Security Best Practices
+
+**Add security context to Deployment:**
+
+```yaml
+spec:
+  template:
+    spec:
+      securityContext:
+        runAsNonRoot: true
+        runAsUser: 1000
+        fsGroup: 1000
+        seccompProfile:
+          type: RuntimeDefault
+      containers:
+        - name: app
+          securityContext:
+            allowPrivilegeEscalation: false
+            readOnlyRootFilesystem: true
+            capabilities:
+              drop:
+                - ALL
+```
+
+**Security checklist:**
+
+- [ ] Run as non-root user
+- [ ] Drop all capabilities
+- [ ] Use read-only root filesystem
+- [ ] Disable privilege escalation
+- [ ] Set seccomp profile
+- [ ] Use Pod Security Standards
+
+### 8. Add Labels and Annotations
+
+**Standard labels (recommended):**
+
+```yaml
+metadata:
+  labels:
+    app.kubernetes.io/name: <app-name>
+    app.kubernetes.io/instance: <instance-name>
+    app.kubernetes.io/version: "1.0.0"
+    app.kubernetes.io/component: backend
+    app.kubernetes.io/part-of: <system-name>
+    app.kubernetes.io/managed-by: kubectl
+```
+
+**Useful annotations:**
+
+```yaml
+metadata:
+  annotations:
+    description: "Application description"
+    contact: "team@example.com"
+    prometheus.io/scrape: "true"
+    prometheus.io/port: "9090"
+    prometheus.io/path: "/metrics"
+```
+
+### 9. Organize Multi-Resource Manifests
+
+**File organization options:**
+
+**Option 1: Single file with `---` separator**
+
+```yaml
+# app-name.yaml
+---
+apiVersion: v1
+kind: ConfigMap
+...
+---
+apiVersion: v1
+kind: Secret
+...
+---
+apiVersion: apps/v1
+kind: Deployment
+...
+---
+apiVersion: v1
+kind: Service
+...
+```
+
+**Option 2: Separate files**
+
+```
+manifests/
+├── configmap.yaml
+├── secret.yaml
+├── deployment.yaml
+├── service.yaml
+└── pvc.yaml
+```
+
+**Option 3: Kustomize structure**
+
+```
+base/
+├── kustomization.yaml
+├── deployment.yaml
+├── service.yaml
+└── configmap.yaml
+overlays/
+├── dev/
+│   └── kustomization.yaml
+└── prod/
+    └── kustomization.yaml
+```
+
+### 10. Validate and Test
+
+**Validation steps:**
+
+```bash
+# Dry-run validation
+kubectl apply -f manifest.yaml --dry-run=client
+
+# Server-side validation
+kubectl apply -f manifest.yaml --dry-run=server
+
+# Validate with kubeval
+kubeval manifest.yaml
+
+# Validate with kube-score
+kube-score score manifest.yaml
+
+# Check with kube-linter
+kube-linter lint manifest.yaml
+```
+
+**Testing checklist:**
+
+- [ ] Manifest passes dry-run validation
+- [ ] All required fields are present
+- [ ] Resource limits are reasonable
+- [ ] Health checks are configured
+- [ ] Security context is set
+- [ ] Labels follow conventions
+- [ ] Namespace exists or is created
+
+## Common Patterns
+
+### Pattern 1: Simple Stateless Web Application
+
+**Use case:** Standard web API or microservice
+
+**Components needed:**
+
+- Deployment (3 replicas for HA)
+- ClusterIP Service
+- ConfigMap for configuration
+- Secret for API keys
+- HorizontalPodAutoscaler (optional)
+
+**Reference:** See `assets/deployment-template.yaml`
+
+### Pattern 2: Stateful Database Application
+
+**Use case:** Database or persistent storage application
+
+**Components needed:**
+
+- StatefulSet (not Deployment)
+- Headless Service
+- PersistentVolumeClaim template
+- ConfigMap for DB configuration
+- Secret for credentials
+
+### Pattern 3: Background Job or Cron
+
+**Use case:** Scheduled tasks or batch processing
+
+**Components needed:**
+
+- CronJob or Job
+- ConfigMap for job parameters
+- Secret for credentials
+- ServiceAccount with RBAC
+
+### Pattern 4: Multi-Container Pod
+
+**Use case:** Application with sidecar containers
+
+**Components needed:**
+
+- Deployment with multiple containers
+- Shared volumes between containers
+- Init containers for setup
+- Service (if needed)
+
+## Templates
+
+The following templates are available in the `assets/` directory:
+
+- `deployment-template.yaml` - Standard deployment with best practices
+- `service-template.yaml` - Service configurations (ClusterIP, LoadBalancer, NodePort)
+- `configmap-template.yaml` - ConfigMap examples with different data types
+- `secret-template.yaml` - Secret examples (to be generated, not committed)
+- `pvc-template.yaml` - PersistentVolumeClaim templates
+
+## Reference Documentation
+
+- `references/deployment-spec.md` - Detailed Deployment specification
+- `references/service-spec.md` - Service types and networking details
+
+## Best Practices Summary
+
+1. **Always set resource requests and limits** - Prevents resource starvation
+2. **Implement health checks** - Ensures Kubernetes can manage your application
+3. **Use specific image tags** - Avoid unpredictable deployments
+4. **Apply security contexts** - Run as non-root, drop capabilities
+5. **Use ConfigMaps and Secrets** - Separate config from code
+6. **Label everything** - Enables filtering and organization
+7. **Follow naming conventions** - Use standard Kubernetes labels
+8. **Validate before applying** - Use dry-run and validation tools
+9. **Version your manifests** - Keep in Git with version control
+10. **Document with annotations** - Add context for other developers
+
+## Troubleshooting
+
+**Pods not starting:**
+
+- Check image pull errors: `kubectl describe pod <pod-name>`
+- Verify resource availability: `kubectl get nodes`
+- Check events: `kubectl get events --sort-by='.lastTimestamp'`
+
+**Service not accessible:**
+
+- Verify selector matches pod labels: `kubectl get endpoints <service-name>`
+- Check service type and port configuration
+- Test from within cluster: `kubectl run debug --rm -it --image=busybox -- sh`
+
+**ConfigMap/Secret not loading:**
+
+- Verify names match in Deployment
+- Check namespace
+- Ensure resources exist: `kubectl get configmap,secret`
+
+## Next Steps
+
+After creating manifests:
+
+1. Store in Git repository
+2. Set up CI/CD pipeline for deployment
+3. Consider using Helm or Kustomize for templating
+4. Implement GitOps with ArgoCD or Flux
+5. Add monitoring and observability
+
+## Related Skills
+
+- `helm-chart-scaffolding` - For templating and packaging
+- `gitops-workflow` - For automated deployments
+- `k8s-security-policies` - For advanced security configurations