sdtk-ops-kit 0.2.0

package/assets/toolkit/toolkit/skills/ops-ci-cd/SKILL.md

@@ -0,0 +1,88 @@
+<!-- Based on agency-agents by AgentLand Contributors (MIT License, 2025). Adapted for SDTK-OPS. -->
+---
+name: ops-ci-cd
+description: CI/CD pipeline design and management. Use when setting up or modifying build, test, and deployment pipelines -- covers pipeline stages, branch strategies, artifact management, and secret handling.
+---
+
+# Ops CI CD
+
+## Overview
+
+A pipeline should make the safe path the default path. It must build the artifact, test it, scan it, promote it, and leave an auditable trail of what ran and what was deployed.
+
+## Standard Pipeline Flow
+
+Use this default flow:
+
+```text
+commit
+  -> build
+  -> unit test
+  -> lint and SAST
+  -> integration test
+  -> security scan
+  -> build artifact
+  -> deploy staging
+  -> smoke test
+  -> deploy production
+  -> health check
+```
+
+Do not collapse build, scan, and deploy into one opaque job.
+
+## Branch And Promotion Strategy
+
+Prefer:
+- trunk-based development with short-lived branches
+- automatic promotion to staging after required checks pass
+- manual or policy-gated promotion to production
+- immutable artifact promotion instead of rebuilding per environment
+
+## Pipeline Config Patterns
+
+Keep pipeline definitions:
+- small enough to review
+- explicit about dependencies between jobs
+- strict about required checks
+- separate from infrastructure design details that belong in `ops-infra-plan`
+
+Use `./references/pipeline-examples.md` for GitHub Actions and GitLab CI examples.
+
+## <HARD-GATE>
+
+NEVER:
+- hardcode secrets in pipeline files
+- pass long-lived cloud credentials through plain environment variables when OIDC or equivalent short-lived auth is available
+- skip secret rotation or access auditing
+
+ALWAYS:
+- use platform secret stores
+- scope credentials to the minimum required permissions
+- rotate and review access on a defined schedule
+
+## Artifact Management
+
+Pipeline outputs should be:
+- versioned with semver and git SHA
+- immutable once published
+- stored with retention rules
+- traceable from deployment record back to commit and build
+
+## Pipeline Optimization
+
+Optimize only after correctness:
+- cache dependencies and build layers
+- parallelize independent jobs
+- use matrix builds only when they produce clear value
+- skip unaffected jobs based on changed files when dependency rules are reliable
+
+## Common Mistakes
+
+| Mistake | Why it fails |
+|---------|--------------|
+| Secrets committed in YAML | Rotation and audit control are lost immediately |
+| No staging environment | Production becomes the first integration test |
+| Manual deploy steps outside pipeline | Audit trail and repeatability disappear |
+| Skip security scanning to save time | Vulnerabilities ship by default |
+| No build cache or job parallelism | Pipeline slows down until teams bypass it |
+

package/assets/toolkit/toolkit/skills/ops-ci-cd/references/pipeline-examples.md

@@ -0,0 +1,113 @@
+<!-- Based on agency-agents by AgentLand Contributors (MIT License, 2025). Adapted for SDTK-OPS. -->
+
+# Pipeline Examples
+
+## GitHub Actions
+
+```yaml
+name: Production Deployment
+
+on:
+  push:
+    branches: [main]
+
+jobs:
+  security-scan:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Run dependency and image scan
+        run: ./scripts/security-scan.sh
+
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install dependencies
+        run: ./scripts/install.sh
+      - name: Run tests
+        run: ./scripts/test.sh
+
+  build:
+    runs-on: ubuntu-latest
+    needs: [security-scan, test]
+    steps:
+      - uses: actions/checkout@v4
+      - name: Build artifact
+        run: ./scripts/build.sh
+      - name: Publish image
+        run: ./scripts/publish-image.sh
+
+  deploy:
+    runs-on: ubuntu-latest
+    needs: [build]
+    environment: production
+    permissions:
+      id-token: write
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+      - name: Blue-Green deploy
+        run: |
+          kubectl set image deployment/app app=registry.example.com/app:${{ github.sha }}
+          kubectl rollout status deployment/app
+          kubectl patch service app-service -p '{"spec":{"selector":{"version":"green"}}}'
+      - name: Health check
+        run: curl -fsS https://app.example.com/health
+```
+
+## GitLab CI
+
+```yaml
+stages:
+  - build
+  - test
+  - security
+  - deploy_staging
+  - smoke
+  - deploy_prod
+
+variables:
+  IMAGE_TAG: "$CI_COMMIT_SHORT_SHA"
+
+build:
+  stage: build
+  script:
+    - ./scripts/build.sh
+    - ./scripts/publish-image.sh "$IMAGE_TAG"
+
+test:
+  stage: test
+  script:
+    - ./scripts/test.sh
+
+security_scan:
+  stage: security
+  script:
+    - ./scripts/security-scan.sh
+
+deploy_staging:
+  stage: deploy_staging
+  script:
+    - ./scripts/deploy.sh staging "$IMAGE_TAG"
+
+smoke_test:
+  stage: smoke
+  script:
+    - ./scripts/smoke-test.sh staging
+
+deploy_prod:
+  stage: deploy_prod
+  when: manual
+  script:
+    - ./scripts/deploy.sh production "$IMAGE_TAG"
+    - ./scripts/health-check.sh production
+```
+
+## Pattern Notes
+
+- keep security scanning before production deploy
+- promote the same artifact between environments
+- prefer platform identity federation over static cloud keys
+- keep deployment commands explicit enough to review and replay
+

package/assets/toolkit/toolkit/skills/ops-compliance/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: ops-compliance
+description: Compliance and audit readiness. Use when setting up compliance scanning, audit logging, or preparing evidence for regulatory audits -- covers policy-as-code patterns and evidence collection.
+---
+
+# Ops Compliance
+
+## Overview
+
+Compliance automation should make controls testable and evidence easy to retrieve. SDTK-OPS covers the tooling and operational patterns that support compliance work. It does not replace legal interpretation, certification strategy, or third-party auditor management.
+
+## The Iron Law
+
+```
+NO AUDIT READINESS WITHOUT IMMUTABLE LOGS AND AUTOMATED EVIDENCE COLLECTION
+```
+
+## When to Use
+
+Use for:
+- audit logging design
+- evidence collection workflows
+- policy-as-code adoption
+- compliance scanning in CI/CD
+- audit readiness reviews before external assessment
+
+## Regulatory Framework Awareness
+
+| Framework | Focus Area | Key Operational Requirements |
+|-----------|------------|------------------------------|
+| SOC 2 | trust services criteria | access control, change management, logging, availability evidence |
+| GDPR | personal data handling | data access controls, deletion workflows, audit trail, breach evidence |
+| HIPAA | protected health information | access auditing, retention, encryption, incident evidence |
+| PCI-DSS | payment card data security | segmentation, access control, logging, vulnerability management |
+
+These are awareness anchors only. They are not legal or certification guidance.
+
+## Audit Logging Requirements
+
+Every audit trail should answer:
+- **WHO**
+  - which identity performed the action
+- **WHAT**
+  - what action or change happened
+- **WHEN**
+  - timestamp in a consistent standard
+- **WHERE**
+  - account, region, environment, or system boundary
+- **WHETHER**
+  - outcome, such as allowed, denied, success, or failure
+
+## Implementation Patterns
+
+Use a layered pattern:
+- cloud-provider audit logs for infrastructure and identity changes
+- application audit logs in structured JSON for user and system events
+- immutable or write-once log storage for retention-sensitive records
+- restricted access to log management and export paths
+
+## <HARD-GATE>
+
+Do not claim audit readiness until all are true:
+- audit logs are immutable or strongly tamper-resistant
+- retention is at least 1 year or stricter if the policy requires it
+- tamper monitoring exists for critical logs
+- access to log management is restricted and reviewable
+
+## Policy As Code
+
+Policy should be executable:
+- define guardrails as code
+- run them in CI/CD
+- fail deployment when policies are violated
+
+Awareness tools include:
+- OPA and Rego
+- cloud-native policy engines
+- IaC scanners such as Checkov or tfsec
+
+## Evidence Collection Automation
+
+| Control Area | Evidence Type | Collection Method | Frequency |
+|--------------|---------------|-------------------|-----------|
+| Access review | privileged access report | scheduled export from IAM source | monthly |
+| Change management | deployment and approval log | CI/CD pipeline export | per release |
+| Backup control | restore drill report | runbook output and stored artifact | quarterly |
+| Logging control | retention and tamper status | scripted control check | monthly |
+| Vulnerability management | scan summary and remediation status | scanner export | weekly |
+
+## Common Mistakes
+
+| Mistake | Why it fails |
+|---------|--------------|
+| Manual evidence collection | Audit prep becomes a scramble and gaps are hidden |
+| Treat compliance as a yearly project | Controls drift the rest of the year |
+| Keep policy only in documents | Violations continue because nothing enforces them |
+| Store audit logs with normal mutable application data | Tampering and accidental deletion become easier |
+
+## Execution Handoff
+
+After compliance controls are defined:
+- implement logging and retention changes through `ops-infra-plan`
+- route CI/CD policy enforcement through `ops-ci-cd`
+- validate collected evidence with `ops-verify`
+

package/assets/toolkit/toolkit/skills/ops-container/SKILL.md

@@ -0,0 +1,95 @@
+<!-- Based on agency-agents by AgentLand Contributors (MIT License, 2025). Adapted for SDTK-OPS. -->
+---
+name: ops-container
+description: Container operations. Use when building Docker images, writing Dockerfiles, creating Kubernetes manifests, or managing container lifecycle -- covers best practices, security scanning, and orchestration patterns.
+---
+
+# Ops Container
+
+## Overview
+
+Container workflows fail when image build, runtime security, and orchestration design are treated as separate concerns. Build lean images, run them with explicit security posture, and define manifests that expose health and resource boundaries.
+
+## When to Use
+
+Use for:
+- Dockerfile authoring or review
+- image build and tagging strategy
+- Kubernetes deployment manifest design
+- local multi-service orchestration
+- container registry policy updates
+
+## Dockerfile Best Practices
+
+Use these defaults:
+- multi-stage builds to separate build tools from runtime image
+- specific base image tags, never floating `latest`
+- minimal runtime packages
+- `.dockerignore` to exclude git metadata, secrets, and local caches
+- deterministic dependency install steps for repeatable builds
+
+## Security Defaults
+
+Container security starts in the image:
+- run as non-root user
+- pin base images to explicit versions
+- scan images before push
+- keep secrets out of the image and build args
+- remove unused packages and shells where possible
+
+## <HARD-GATE>
+
+Do not publish or deploy the image unless all are true:
+- multi-stage build is used where build tooling is separate from runtime
+- container runs as non-root unless a reviewed exception exists
+- vulnerability scan passes with no CRITICAL or HIGH findings
+- base image tag is specific and reviewable
+
+## Kubernetes Patterns
+
+For production-oriented workloads, define:
+- Deployment with explicit resource requests and limits
+- readiness, liveness, and startup probes
+- rolling update settings that limit simultaneous disruption
+- PodDisruptionBudget for critical workloads
+- Service type matched to actual exposure need
+- ConfigMap and Secret references instead of baked config
+
+Use `./references/k8s-manifest-patterns.md` for concrete manifest examples.
+
+## Health Probes
+
+| Probe | Purpose | Failure Action |
+|-------|---------|----------------|
+| Liveness | Detect deadlocked or unrecoverable process | restart container |
+| Readiness | Control whether traffic reaches the pod | remove pod from service endpoints |
+| Startup | Protect slow boot from early liveness failure | delay other probe enforcement until startup completes |
+
+## Docker Compose Pattern
+
+For local or small deployments:
+- define each service explicitly
+- isolate shared environment variables in files or secret stores
+- declare volumes and networks on purpose
+- use health checks so service startup order is evidence-based, not timing-based
+
+Do not treat Docker Compose defaults as production architecture.
+
+## Container Registry Discipline
+
+Use a tagging and retention policy:
+- tag images with semver and git SHA
+- enable scan-on-push where the registry supports it
+- expire unneeded intermediate tags
+- keep a clear mapping from deployed revision to immutable image digest
+
+## Common Mistakes
+
+| Mistake | Why it fails |
+|---------|--------------|
+| Use `latest` everywhere | Rollback and provenance become guesswork |
+| Run as root by default | One container escape becomes much worse |
+| Bake secrets into Dockerfile or image | Rotation and access control break immediately |
+| Skip resource limits | Noisy neighbors and eviction behavior become unpredictable |
+| Omit probes | Broken containers look healthy until users discover them |
+

package/assets/toolkit/toolkit/skills/ops-container/references/k8s-manifest-patterns.md

@@ -0,0 +1,116 @@
+<!-- Based on agency-agents by AgentLand Contributors (MIT License, 2025). Adapted for SDTK-OPS. -->
+
+# Kubernetes Manifest Patterns
+
+## Deployment
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: app-api
+spec:
+  replicas: 3
+  strategy:
+    type: RollingUpdate
+    rollingUpdate:
+      maxUnavailable: 1
+      maxSurge: 1
+  selector:
+    matchLabels:
+      app: app-api
+  template:
+    metadata:
+      labels:
+        app: app-api
+    spec:
+      containers:
+        - name: api
+          image: registry.example.com/app-api:1.2.3-abcd123
+          ports:
+            - containerPort: 8080
+          resources:
+            requests:
+              cpu: "250m"
+              memory: "256Mi"
+            limits:
+              cpu: "500m"
+              memory: "512Mi"
+          readinessProbe:
+            httpGet:
+              path: /health/ready
+              port: 8080
+            initialDelaySeconds: 5
+            periodSeconds: 10
+          livenessProbe:
+            httpGet:
+              path: /health/live
+              port: 8080
+            initialDelaySeconds: 15
+            periodSeconds: 20
+          startupProbe:
+            httpGet:
+              path: /health/startup
+              port: 8080
+            failureThreshold: 30
+            periodSeconds: 5
+          envFrom:
+            - configMapRef:
+                name: app-api-config
+            - secretRef:
+                name: app-api-secrets
+          securityContext:
+            runAsNonRoot: true
+            allowPrivilegeEscalation: false
+```
+
+## Service
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: app-api
+spec:
+  type: ClusterIP
+  selector:
+    app: app-api
+  ports:
+    - name: http
+      port: 80
+      targetPort: 8080
+```
+
+## ConfigMap
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: app-api-config
+data:
+  APP_ENV: production
+  LOG_LEVEL: info
+  FEATURE_FLAG_X: "false"
+```
+
+## PodDisruptionBudget
+
+```yaml
+apiVersion: policy/v1
+kind: PodDisruptionBudget
+metadata:
+  name: app-api
+spec:
+  minAvailable: 2
+  selector:
+    matchLabels:
+      app: app-api
+```
+
+## Pattern Notes
+
+- keep resource limits and probes in the first deployable version
+- route config and secrets through references, not inline literals
+- match `maxUnavailable` and `minAvailable` so rollout and maintenance rules do not fight each other
+

package/assets/toolkit/toolkit/skills/ops-cost/SKILL.md

@@ -0,0 +1,88 @@
+<!-- Based on agency-agents by AgentLand Contributors (MIT License, 2025). Adapted for SDTK-OPS. -->
+---
+name: ops-cost
+description: Cloud cost analysis and optimization. Use when reviewing infrastructure costs, right-sizing resources, or implementing cost reduction strategies -- covers cost allocation, tagging, reserved capacity, and budget alerts.
+---
+
+# Ops Cost
+
+## Overview
+
+Cost optimization is not a one-time cleanup. It is an operating loop: make spend visible, find waste, right-size safely, buy commitments with evidence, and review the result every month.
+
+## Five-Step Framework
+
+1. **Visibility**
+   - tag all resources by owner, environment, service, and cost center
+2. **Identify Waste**
+   - find unused, idle, or obviously oversized resources
+3. **Right-Size**
+   - adjust resources based on measured utilization
+4. **Reserved Capacity**
+   - buy longer commitments only after usage patterns are stable
+5. **Continuous Optimization**
+   - review, clean up, and compare month over month
+
+## Waste Types
+
+| Waste Type | Detection Rule | Typical Response |
+|------------|----------------|------------------|
+| Unused resources | CPU below 5% for 14 or more days | delete or stop |
+| Over-provisioned resources | CPU or memory below 30% average | downsize after validation |
+| Unattached storage | no active attachment or mount | delete after review |
+| Old snapshots | beyond retention with no restore purpose | expire automatically |
+| Idle load balancers | no meaningful traffic or backend use | consolidate or remove |
+
+## Right-Sizing
+
+Use a 30-day utilization window before changing production sizing:
+- review CPU, memory, storage, and throughput
+- recommend smaller instance families or lower replica counts where safe
+- validate with load testing or staged rollout before changing production
+
+Route structural changes through `ops-infra-plan` and rollout changes through `ops-deploy`.
+
+## Purchase Types
+
+| Purchase Type | Savings | Commitment | Risk |
+|---------------|---------|------------|------|
+| On-demand | baseline | none | low |
+| Spot or preemptible | 60% to 90% | none | high interruption risk |
+| 1-year reserved | medium | 1 year | medium |
+| 3-year reserved | high | 3 years | higher lock-in risk |
+| Savings plan or equivalent | medium to high | usage commitment | medium |
+
+## <HARD-GATE>
+
+Do not call cost management operationally sound until all are true:
+- all production resources are tagged
+- monthly cost review is documented
+- unused resource cleanup runs at least monthly
+- budget alerts are configured per account or environment
+
+## Cost Report Template
+
+Use a recurring report with:
+- spending by service
+- month-over-month comparison
+- optimization opportunities
+- reserved-capacity recommendations
+- action items with owners and due dates
+
+## Common Mistakes
+
+| Mistake | Why it fails |
+|---------|--------------|
+| No tagging strategy | Costs cannot be assigned or optimized correctly |
+| Buy reserved capacity without usage data | Long-term commitment locks in the wrong shape |
+| Ignore data transfer costs | Network spend grows outside compute reviews |
+| Run one audit and stop | Waste returns as systems change |
+| Optimize cost without performance validation | Reliability drops and rollback follows |
+
+## Execution Handoff
+
+After a cost review:
+- send architecture changes to `ops-infra-plan`
+- deploy right-sizing changes with `ops-deploy`
+- confirm savings and service health with `ops-verify`
+