بنقرة واحدة
helm-standards
Standards for Helm charts in SDD projects, including settings-driven patterns.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Standards for Helm charts in SDD projects, including settings-driven patterns.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Orchestrates SDD project initialization — version detection, environment verification, scaffolding, and git setup.
Manage project settings in sdd/sdd-settings.yaml including component settings that drive scaffolding.
Single gateway for all core↔tech-pack interactions. Reads manifests, resolves paths, loads skills/agents, routes commands.
Manage tasks and plans using the .tasks/ directory.
Standards for authoring SDD plugin agents — frontmatter, self-containment, skill references, and no-user-interaction rules.
Standards for authoring SDD plugin commands — frontmatter, user interaction, skill/agent invocation, CLI integration, and output formatting.
| name | helm-standards |
| description | Standards for Helm charts in SDD projects, including settings-driven patterns. |
Standards for Helm charts in SDD projects. Charts are generated based on component settings from sdd/sdd-settings.yaml.
Use the following skills for reference:
techpack-settings — Authoritative source for helm component settings schema, validation rules, and the chart-per-deployment patternEach deployment configuration gets its own helm chart. A single server can have multiple helm charts (e.g., one for API mode with ingress, one for worker mode without). Delegate to the techpack-settings skill for the complete helm settings schema — it returns deploys (server reference), deploy_type (server/webapp), deploy_modes (array of mode strings like [api, worker]), ingress (boolean), and assets (static file configuration). These settings determine which templates are included in each chart.
Helm charts live at components/helm_charts/<name>/:
components/helm_charts/
├── main-server-api/ # API deployment
│ ├── Chart.yaml
│ ├── values.yaml
│ └── templates/
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ ├── configmap.yaml
│ └── servicemonitor.yaml
├── main-server-worker/ # Worker deployment (no ingress)
│ ├── Chart.yaml
│ ├── values.yaml
│ └── templates/
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── configmap.yaml
│ └── servicemonitor.yaml
├── admin-dashboard/ # Webapp deployment
│ ├── Chart.yaml
│ ├── values.yaml
│ └── templates/
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ └── configmap.yaml
└── umbrella/ # Optional: installs all charts
├── Chart.yaml
└── values.yaml
| File | Purpose |
|---|---|
values.yaml | Default values (development-safe) |
values-{env}.yaml | Environment overrides (local, staging, production) |
Every Helm chart must define these values:
# Infrastructure settings (NOT application config)
nodeEnv: development # NODE_ENV for libraries (Express caching, etc.)
# Application config (from config component)
config: {} # Merged config from components/config/envs/{env}/
replicaCount: 1
nodeEnv: development
image:
repository: main-server
tag: latest
pullPolicy: IfNotPresent
service:
type: ClusterIP
port: 3000
observability:
metrics:
enabled: true
port: 9090
serviceMonitor:
enabled: false
interval: 30s
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 100m
memory: 128Mi
config: {}
nodeEnv: development
image:
repository: main-server
tag: latest
pullPolicy: IfNotPresent
# Each mode gets independent scaling
api:
enabled: true
replicaCount: 2
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 100m
memory: 128Mi
worker:
enabled: true
replicaCount: 5
resources:
limits:
cpu: 1000m
memory: 1Gi
requests:
cpu: 200m
memory: 256Mi
service:
type: ClusterIP
port: 3000
observability:
metrics:
enabled: true
port: 9090
serviceMonitor:
enabled: false
interval: 30s
config: {}
replicaCount: 1
nodeEnv: development
image:
repository: nginx
tag: alpine
pullPolicy: IfNotPresent
assets:
type: bundled # bundled | entrypoint
path: /usr/share/nginx/html
service:
type: ClusterIP
port: 80
ingress:
enabled: true
className: nginx
hosts:
- host: app.example.com
paths:
- path: /
pathType: Prefix
config: {} # Injected into HTML at deploy time
All server charts include observability by default:
# templates/servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: {{ include "common.fullname" . }}
spec:
selector:
matchLabels:
{{- include "common.selectorLabels" . | nindent 6 }}
endpoints:
- port: metrics
interval: {{ .Values.observability.metrics.serviceMonitor.interval }}
path: /metrics
All servers expose metrics on port 9090:
/metrics - Prometheus format metrics/health/live - Liveness probe/health/ready - Readiness probeApplications output JSON logs to stdout. The cluster's log collector (Victoria Logs) picks them up automatically.
Note: Cluster-level observability infrastructure is set up separately (see task #47).
Config is mounted via ConfigMap at /app/config/config.yaml:
# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ include "common.fullname" . }}-config
data:
config.yaml: |
{{- toYaml .Values.config | nindent 4 }}
Config is injected into HTML at deploy time:
export const startApp = (config: AppConfig) => { ... }startApp(__SDD_CONFIG__)__SDD_CONFIG__ with JSON from ConfigMap# Generate config for production environment
<plugin-root>/fullstack-typescript/system/system-run.sh config generate --env production --component main-server \
--output helm-values-config.yaml
# Deploy with config
helm install my-release ./components/helm_charts/main-server-api \
-f values-production.yaml \
--set-file config=helm-values-config.yaml
| Var | Source | Purpose |
|---|---|---|
NODE_ENV | .Values.nodeEnv | Library behavior (Express caching, etc.) |
SDD_CONFIG_PATH | Static /app/config/config.yaml | Path to mounted config |
SDD_SERVER_MODE | Set per deployment | For hybrid: which mode (api, worker, cron) |
Config contains secret names, not values. Applications use K8s secretKeyRef to load the actual values:
# values-production.yaml
config:
database:
host: db.production.internal
passwordSecret: "my-db-credentials" # K8s Secret name
# templates/deployment.yaml - Using secretKeyRef
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: {{ .Values.config.database.passwordSecret }}
key: password
/sdd I want to validate my config in CI/CDThis skill defines no input parameters or structured output.
config-standards — Delegate to this for config naming and structure conventions. Defines the config schema patterns that Helm values.yaml must align with.