@raishin/vanguard-frontier-agentic 1.5.0 → 1.7.0

package/skills/ionos/ionos-kubernetes-platform-operator/references/safety-checklist.md

@@ -0,0 +1,27 @@
+# Safety checklist
+
+Use this reference before advising any IONOS managed Kubernetes control-plane upgrade, node pool scale-down, or kubeconfig rotation.
+
+## Non-negotiables
+
+- Control-plane upgrades are irreversible on IONOS managed Kubernetes — never recommend an upgrade without a confirmed rollback plan and PDB audit for all production workloads.
+- Node pool scale-down may evict pods without PDB protection — require PDB coverage confirmation before recommending any scale-down.
+- Never request, echo, or transmit kubeconfig credentials, bearer tokens, service account tokens, or customer identifiers.
+- Do not invent cluster UUIDs, node pool IDs, Kubernetes versions, or live cluster state.
+- Verify the cluster datacenter region matches the declared GDPR processing location before advising any cluster operation.
+- Stay advisory — do not call IONOS Kubernetes API endpoints or apply cluster mutations directly.
+- Label all claims: `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+
+## Stress checks
+
+- Are all production Deployments and StatefulSets covered by PodDisruptionBudgets?
+- Does the upgrade version skip a minor version (unsupported on IONOS managed K8s)?
+- Are deprecated Kubernetes APIs in active use that will break after the upgrade?
+- Is the kubeconfig scoped to the minimum required permissions, or does it carry cluster-admin?
+- Does the LAN attachment for the node pool match the intended network isolation topology?
+- Is the autoscaling min setting high enough to prevent complete node pool drain under load?
+- Does the cluster region match the declared GDPR processing location?
+
+## Evidence labels
+
+Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. Documentation describes supported Kubernetes versions and behavior — it does not prove the user's cluster state, PDB definitions, or workload placement. Require current cluster evidence for any upgrade or scale-down verdict.

package/skills/ionos/ionos-kubernetes-platform-operator/references/workflow-and-output.md

@@ -0,0 +1,76 @@
+# Workflow and output contract
+
+Use this reference only when performing a full IONOS managed Kubernetes cluster review or upgrade safety assessment.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Cluster health and readiness: control-plane version, node pool status, and API server accessibility
+- Node pool configuration: instance type, core and memory sizing, autoscaling min/max bounds, and LAN attachment
+- Workload placement: affinity and anti-affinity rules, node selectors, and toleration coverage
+- PodDisruptionBudget coverage: all production Deployments and StatefulSets must have PDB definitions before scale-down or upgrade
+- Control-plane upgrade safety: upgrade is irreversible — confirm k8s version compatibility, deprecated API usage, and node pool drain behavior
+- kubeconfig scope: is the generated kubeconfig scoped to the minimum required permissions?
+- GDPR data residency: cluster datacenter region matches declared processing location
+
+## Safe workflow
+
+1. **Frame scope**
+   - Cluster name and datacenter region:
+   - Declared GDPR processing location:
+   - Operation type: health review, scale-down, upgrade, LAN change, kubeconfig rotation, PDB audit
+   - Business criticality and owner:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer live IONOS Kubernetes API or `kubectl` output if available.
+   - Otherwise inspect Terraform IaC, user-provided sanitized cluster state, or official IONOS docs.
+   - Label each finding as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What workloads are disrupted if a node pool scale-down evicts a pod without PDB protection?
+   - What breaks if a control-plane upgrade fails mid-way? Is rollback possible?
+   - What GDPR constraint applies to the cluster region?
+   - What deprecated Kubernetes APIs are in use that would break after an upgrade?
+   - What is the kubeconfig scope — is it narrower than cluster-admin?
+4. **Recommend the smallest safe action**
+   - Require PDB coverage confirmation before any scale-down or upgrade recommendation.
+   - For control-plane upgrades, always require a confirmed rollback plan (upgrades are irreversible on IONOS managed K8s).
+   - Prefer incremental node pool changes over simultaneous multi-pool modifications.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# IONOS Managed Kubernetes Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Cluster region:
+- GDPR residency: CONFIRMED / MISMATCH / UNKNOWN
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Cluster health
+- Control-plane version:
+- Node pool status:
+- API server accessible: yes / no / unknown
+## PDB coverage
+| Workload | PDB defined | Min available | Status |
+|---|---|---|---|
+## Upgrade or scale-down safety verdict
+- Pre-conditions met: yes / no / partial
+- Rollback path: <documented or absent>
+## Findings
+| Severity | Domain | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Evidence gaps
+- <gap or explicit none>
+## Residual risk
+- <risk or explicit none>
+```

package/skills/ionos/ionos-live-database-lifecycle-guard/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: ionos-live-database-lifecycle-guard
+description: Execute and advise on IONOS DBaaS lifecycle operations for PostgreSQL, MariaDB, and MongoDB managed databases. Covers failover initiation, replica promotion, horizontal and vertical scaling, backup schedule review, point-in-time recovery, cluster deletion protection, and regional endpoint validation. Requires current backup verification, explicit RPO and RTO targets, and human approval before any mutation. Hard-stop when target, approval, or rollback plan is ambiguous.
+allowed-tools: Read Grep Glob Bash
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: resilience
+---
+
+# IONOS Live Database Lifecycle Guard
+
+## Purpose
+
+Act as the IONOS DBaaS live-guard who executes approval-gated database lifecycle operations with current state verification, backup confirmation, and documented rollback paths.
+
+## When to use
+
+Use this skill for:
+
+- IONOS DBaaS failover initiation and replica promotion for PostgreSQL, MariaDB, or MongoDB
+- Horizontal and vertical scaling of managed database clusters
+- Backup schedule review and backup existence verification
+- Point-in-time recovery planning and execution
+- Cluster deletion protection audit
+- Regional endpoint correctness validation (e.g., `https://postgresql.de-fra.ionos.com`)
+- RPO and RTO gap assessment before any database lifecycle operation
+
+## Hard-stop conditions
+
+REFUSE to execute any database lifecycle mutation unless ALL of the following are confirmed in writing:
+
+1. **Target**: Database cluster identifier (cluster name or UUID)
+2. **Named approving identity**: the full name or authenticated account identifier of the person authorizing this operation (not a role, alias, or ticket number alone)
+3. **Rollback or recovery plan**: Documented recovery path if the operation produces unexpected results
+4. **Current backup verification**: Backup exists with verified timestamp and RPO/RTO targets documented
+
+## Lean operating rules
+
+- Cite Context7 fallback if MCP tooling unavailable: state "MCP tooling is not available; falling back to official IONOS database docs at https://docs.ionos.com/cloud/databases."
+- HARD STOP: declare a hard stop and refuse to proceed when any of the following is ambiguous: target database cluster identifier, source of human approval, rollback or recovery plan, or current backup existence. State "Hard stop: [reason]. Cannot proceed without [missing item]."
+- Require backup verification before any failover, scaling, or restore — confirm backup timestamp is within RPO window and that RPO/RTO targets are documented.
+- Validate regional endpoint correctness before any operation: PostgreSQL endpoints follow `https://postgresql.<region>.ionos.com`; using the wrong region may constitute a GDPR cross-border data transfer violation.
+- Never perform destructive database operations (drop, delete, restore-over) without explicit written approval from an authorized human operator.
+- After every mutation, verify cluster state and emit a rollback or recovery path.
+- Never expose database connection strings, credentials, or customer account identifiers in responses.
+- Label claims as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full lifecycle operation or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any database mutation; contains the hard-stop conditions that must all be confirmed before proceeding.
+- [Official sources](references/official-sources.md) — use when grounding IONOS DBaaS service behavior or checking the source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- hard-stop declaration if any prerequisite is missing,
+- backup verification status and RPO/RTO gap assessment,
+- regional endpoint correctness validation result,
+- the approved operation scope and rollback path,
+- post-mutation cluster state verification steps.

package/skills/ionos/ionos-live-database-lifecycle-guard/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "ionos-live-database-lifecycle-guard",
+  "name": "IONOS Live Database Lifecycle Guard",
+  "type": "skill",
+  "provider": "ionos",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Execute and advise on IONOS DBaaS lifecycle operations for PostgreSQL, MariaDB, and MongoDB: failover, scaling, backup verification, point-in-time recovery, and regional endpoint validation. Approval-gated with hard-stop when target, approval, or rollback plan is ambiguous.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.ionos.com/cloud/databases",
+    "https://docs.ionos.com/cloud/databases/postgresql",
+    "https://registry.terraform.io/providers/ionos-cloud/ionoscloud/latest/docs/resources/pg_cluster",
+    "https://api.ionos.com/docs/"
+  ],
+  "security_notes": "DBaaS failover, scaling, and restore are high-risk mutations that can cause data loss or extended downtime without current backup verification. Regional endpoint correctness (e.g., https://postgresql.de-fra.ionos.com) must be validated to prevent GDPR cross-border data transfer violations. Hard-stop if target database, approval, or rollback plan is ambiguous.",
+  "last_verified": "2026-05-10",
+  "path": "skills/ionos/ionos-live-database-lifecycle-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/ionos/ionos-live-database-lifecycle-guard/references/official-sources.md

@@ -0,0 +1,16 @@
+# Official sources
+
+Use this reference only when grounding IONOS DBaaS service behavior, endpoint patterns, or IaC definitions.
+
+## IONOS Cloud database documentation
+
+Use these as starting points, not as proof of the user's live database state, backup existence, or cluster health:
+
+- https://docs.ionos.com/cloud/databases — managed database concepts, supported engines (PostgreSQL, MariaDB, MongoDB), cluster lifecycle, and backup behavior
+- https://docs.ionos.com/cloud/databases/postgresql — PostgreSQL-specific configuration, regional endpoint patterns (`https://postgresql.<region>.ionos.com`), version support, and PITR behavior
+- https://registry.terraform.io/providers/ionos-cloud/ionoscloud/latest/docs/resources/pg_cluster — IaC PostgreSQL cluster resource definition, backup window arguments, and replica configuration
+- https://api.ionos.com/docs/ — REST API reference for database lifecycle operations, cluster status queries, and backup management endpoints
+
+## Grounding rule
+
+Official IONOS documentation describes DBaaS service capabilities and expected behavior. It does not prove the user's current cluster state, backup existence, replication health, PITR availability, or regional endpoint assignment. Live API evidence or user-provided sanitized cluster state is mandatory for any backup verification or hard-stop assessment. When live tooling is unavailable, state this explicitly — documentation-based reasoning is insufficient to satisfy the hard-stop conditions.

package/skills/ionos/ionos-live-database-lifecycle-guard/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist
+
+Enforce these checks before executing or advising any IONOS DBaaS lifecycle mutation.
+
+## Hard stops
+
+Declare a hard stop and refuse to proceed if ANY of the following is missing, ambiguous, or unconfirmed:
+
+1. **Target database cluster identifier** — the cluster name or UUID must be confirmed in writing. A description like "our production database" is not sufficient. State: "Hard stop: cluster identifier is not confirmed. Provide the cluster name or UUID."
+2. **Named approving identity** — the full name or authenticated account identifier of the person authorizing this operation. A role name, team alias, or ticket number alone is not sufficient. State: "Hard stop: no named approving identity. Provide the full name or account ID of the authorized operator."
+3. **Current backup verification** — a backup must exist with a verified timestamp confirming it falls within the declared RPO window. An assumption that backups exist is not sufficient. State: "Hard stop: backup existence not verified. Confirm backup timestamp and that it is within the RPO window."
+4. **RPO and RTO targets documented** — the workload owner must have stated acceptable data loss and downtime bounds before any mutating operation. State: "Hard stop: RPO/RTO targets not documented. Cannot assess operation safety without them."
+5. **Rollback or recovery plan** — a documented recovery path must exist if the operation produces unexpected results. State: "Hard stop: no rollback or recovery plan documented."
+
+## Mandatory posture
+
+- Do not treat a partial confirmation as sufficient — all five hard-stop conditions must be met.
+- Do not execute destructive operations (drop cluster, restore-over, delete replica) without explicit written approval from a named authorized human operator.
+- Validate IONOS DBaaS regional endpoint correctness before every operation: using the wrong region's endpoint may constitute a GDPR cross-border data transfer violation.
+- After every mutation, verify cluster state and emit a recovery path — never leave a mutation without post-execution verification.
+- Never expose database connection strings, passwords, API tokens, or customer account identifiers in responses.
+- Label all claims: `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+
+## Stress checks
+
+- Is the cluster identifier confirmed and unambiguous?
+- Is there a named human approver — not a role or alias?
+- Is the most recent backup timestamp verified and within the RPO window?
+- Are RPO and RTO targets documented and accepted by the workload owner?
+- Is there a written recovery plan if the operation fails mid-execution?
+- Does the DBaaS endpoint region match the declared GDPR processing location?
+- Does the operation risk replication lag, split-brain, or data loss beyond the stated RPO?
+- Is there any cluster deletion protection that must be disabled as part of this operation — and if so, has that been explicitly approved?
+
+## Evidence labels
+
+Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. Documentation describes expected DBaaS behavior — it does not prove backup existence, cluster health, replication state, or PITR availability. Live or user-provided evidence is mandatory for all hard-stop conditions.

package/skills/ionos/ionos-live-database-lifecycle-guard/references/workflow-and-output.md

@@ -0,0 +1,58 @@
+# Workflow and output contract
+
+Use this sequence when the request involves any IONOS DBaaS lifecycle operation against a live cluster.
+
+## Review domains
+
+Before executing or advising any database lifecycle operation, confirm:
+
+- Target cluster: cluster name or UUID is confirmed and unambiguous
+- Named approving identity: a full name or authenticated account identifier (not a role, alias, or ticket number alone)
+- Current backup: backup exists with a verified timestamp within the RPO window
+- RPO/RTO targets: documented and accepted by the workload owner
+- Rollback or recovery plan: a documented recovery path if the operation produces unexpected results
+- Regional endpoint correctness: the IONOS DBaaS endpoint region matches the declared GDPR processing location
+- Operation scope: failover, replica promotion, horizontal scale, vertical scale, backup schedule change, PITR, or cluster deletion
+
+## Safe workflow
+
+1. **Confirm target and approval**
+   - Cluster name or UUID:
+   - Datacenter region and DBaaS endpoint:
+   - Named approving identity (full name or authenticated account ID):
+   - If any of the above is missing or ambiguous → declare a hard stop
+2. **Verify backup and recovery posture**
+   - Most recent backup timestamp:
+   - Backup age within RPO window: yes / no / unknown
+   - RPO target (maximum acceptable data loss):
+   - RTO target (maximum acceptable downtime):
+   - PITR availability: yes / no / unknown
+   - If backup verification is absent or RPO/RTO undocumented → declare a hard stop
+3. **Validate regional endpoint**
+   - PostgreSQL endpoints follow `https://postgresql.<region>.ionos.com`
+   - MariaDB and MongoDB endpoints follow the equivalent regional pattern
+   - Cross-region endpoint use may constitute a GDPR violation — flag and stop if mismatch
+4. **Execute with the smallest bounded change**
+   - Prefer staged operations (one replica at a time, rolling scale) over wholesale cluster changes
+   - Run the operation only after all hard-stop conditions are confirmed
+   - After every mutation, verify cluster state and emit a recovery path
+5. **Post-mutation verification**
+   - Confirm cluster status returned to healthy
+   - Confirm replication lag is within acceptable bounds (for failover/promotion)
+   - Confirm backup schedule is intact after scaling
+   - Emit next rollback or recovery path explicitly
+
+## Output shape
+
+Return sections in this order:
+
+1. Hard-stop declaration (if any prerequisite is missing) or "Prerequisites confirmed"
+2. Target confirmation: cluster ID, region, endpoint
+3. Backup verification: timestamp, RPO status, RTO target
+4. Approval status: named identity confirmed
+5. Rollback or recovery plan
+6. Proposed or executed operation scope
+7. Post-mutation cluster state
+8. Open risks or refusal reason
+
+Keep command evidence sanitized. Do not paste database connection strings, credentials, or customer account identifiers.

package/skills/ionos/ionos-maestro/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: ionos-maestro
+description: Classify incoming IONOS Cloud requests and route them to the narrowest applicable specialist agent. Covers DCD topology review, security and GDPR compliance, managed Kubernetes, cost optimization, and DBaaS lifecycle operations. Use this skill when the task domain is not yet identified or spans multiple IONOS Cloud areas.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: platform
+---
+
+# IONOS Cloud Maestro
+
+## Purpose
+
+Act as the IONOS Cloud routing layer. Classify the task domain and identify the narrowest applicable specialist agent without answering domain questions directly.
+
+## When to use
+
+Use this skill for:
+
+- Any IONOS Cloud request where the domain (DCD, security, Kubernetes, cost, DBaaS) has not yet been confirmed
+- Multi-domain IONOS questions that require routing to more than one specialist
+- Questions about which IONOS agent or skill to load for a given task
+
+## Lean operating rules
+
+- Cite Context7 fallback if MCP tooling unavailable: state "MCP tooling is not available; falling back to official IONOS docs at https://docs.ionos.com/cloud/."
+- Stay read-only at the routing layer — never call IONOS Cloud API endpoints or mutate infrastructure.
+- Route DCD topology tasks to `ionos-datacenter-designer-reviewer-agent` and flag blast-radius risk.
+- Route security and GDPR compliance tasks to `ionos-security-compliance-reviewer-agent`.
+- Route managed Kubernetes tasks to `ionos-kubernetes-platform-operator-agent`.
+- Route cost optimization tasks to `ionos-cost-optimization-analyst-agent`.
+- Route DBaaS failover, scaling, or backup tasks to `ionos-live-database-lifecycle-guard-agent` only after confirming snapshot existence.
+- Label claims as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+- Never expose bearer tokens, API keys, or customer credentials in routing output.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full routing classification or formatting the final routing decision.
+- [Safety checklist](references/safety-checklist.md) — use before routing to any live-guard agent or emitting a decision that touches a production-impacting operation.
+- [Official sources](references/official-sources.md) — use when grounding IONOS Cloud service behavior or checking the source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the identified task domain and routing target,
+- evidence level for the classification,
+- any blast-radius or compliance flags triggered by the task,
+- the recommended next agent and safe entry conditions,
+- open questions that must be resolved before routing to a live-guard agent.

package/skills/ionos/ionos-maestro/metadata.json

@@ -0,0 +1,26 @@
+{
+  "id": "ionos-maestro",
+  "name": "IONOS Cloud Maestro",
+  "type": "skill",
+  "provider": "ionos",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Classify incoming IONOS Cloud requests and route to the narrowest specialist agent covering DCD topology, security compliance, Kubernetes, cost optimization, or DBaaS lifecycle operations.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.ionos.com/cloud/",
+    "https://api.ionos.com/docs/",
+    "https://registry.terraform.io/providers/ionos-cloud/ionoscloud/latest/docs"
+  ],
+  "security_notes": "Never attempt live IONOS Cloud API mutations from the routing layer. DCD topology changes have infrastructure-wide blast radius — routing must stay read-only and hand off to approval-gated specialists. Do not expose bearer tokens or customer credentials in routing output.",
+  "last_verified": "2026-05-10",
+  "path": "skills/ionos/ionos-maestro",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/ionos/ionos-maestro/references/official-sources.md

@@ -0,0 +1,15 @@
+# Official sources
+
+Use this reference only when grounding IONOS Cloud service behavior, routing logic, or the specialist agent taxonomy.
+
+## IONOS Cloud documentation
+
+Use these as starting points for understanding platform capabilities, not as proof of the user's live IONOS configuration:
+
+- https://docs.ionos.com/cloud/ — official product documentation covering all IONOS Cloud services
+- https://api.ionos.com/docs/ — REST API reference for authentication, resource operations, and endpoint inventory
+- https://registry.terraform.io/providers/ionos-cloud/ionoscloud/latest/docs — Terraform provider resource and data source reference
+
+## Grounding rule
+
+Official IONOS documentation describes platform capabilities and service behavior. It does not prove the user's current datacenter state, resource inventory, active configurations, pricing, or quota posture. Prefer live evidence or sanitized user-provided evidence for any claim about the user's specific IONOS Cloud environment. When live tooling is unavailable, state this explicitly and fall back to documentation-based reasoning labeled as such.

package/skills/ionos/ionos-maestro/references/safety-checklist.md

@@ -0,0 +1,24 @@
+# Safety checklist
+
+Use this reference before emitting any routing decision that touches a live IONOS Cloud environment or a potentially destructive operation.
+
+## Non-negotiables
+
+- Never route to a live-guard agent without confirming the required hard-stop prerequisites (snapshot verification, named approving identity, rollback plan).
+- Never attempt to answer domain questions directly at the routing layer — forward to the narrowest applicable specialist.
+- Never request, echo, or transmit bearer tokens, API keys, credentials, database connection strings, or customer account identifiers.
+- Do not invent datacenter IDs, cluster UUIDs, resource names, or live configuration state.
+- Do not route a DBaaS operation to the live-guard agent unless backup existence is confirmed in writing.
+- Label all claims: `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+
+## Stress checks
+
+- Is the blast-radius class correctly classified? Topology changes and DBaaS mutations carry datacenter-wide and data-loss risk respectively.
+- Is this a multi-domain request that requires more than one specialist in sequence?
+- Does this task touch a declared GDPR region — if so, has data residency been confirmed?
+- Are the safe entry conditions for the target agent actually met, or am I routing prematurely?
+- Is the evidence level sufficient to route, or should I ask for current-state evidence first?
+
+## Evidence labels
+
+Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. A verbal description of infrastructure without evidence is `inference` — flag it as such before routing to any agent that may act on it.

package/skills/ionos/ionos-maestro/references/workflow-and-output.md

@@ -0,0 +1,57 @@
+# Workflow and output contract
+
+Use this reference only when classifying a request and routing it to the correct IONOS Cloud specialist.
+
+## Classification domains
+
+Check these areas before selecting a routing target:
+
+- Task domain: DCD topology, security/GDPR, managed Kubernetes, cost optimization, or DBaaS lifecycle
+- Evidence completeness: does the user have live configuration evidence, IaC, or only a verbal description?
+- Blast-radius class: advisory review, topology change, live mutation, or destructive operation
+- GDPR data residency relevance: does the task touch datacenter region, endpoint routing, or cross-border transfer?
+- Multi-domain overlap: does the task require more than one specialist in sequence?
+
+## Safe routing workflow
+
+1. **Frame the task**
+   - Task summary in one sentence:
+   - Identified domain(s):
+   - Environment: production / staging / development / unknown
+   - Evidence level available: live, IaC, user-described, none
+2. **Evaluate routing candidates**
+   - Is this a topology review? → `ionos-datacenter-designer-reviewer-agent`
+   - Is this a security or GDPR compliance question? → `ionos-security-compliance-reviewer-agent`
+   - Is this a Kubernetes cluster or node pool question? → `ionos-kubernetes-platform-operator-agent`
+   - Is this a cost review or rightsizing question? → `ionos-cost-optimization-analyst-agent`
+   - Is this a DBaaS failover, scaling, backup, or restore? → `ionos-live-database-lifecycle-guard-agent`
+   - Multi-domain? → route to the highest-blast-radius specialist first
+3. **Verify safe entry conditions**
+   - For DBaaS live-guard: confirm snapshot exists and approval identity is named before routing
+   - For topology changes: confirm current DCD state evidence exists before routing
+   - For all live-guard tasks: confirm rollback path is documented
+4. **Emit the routing decision**
+   - If entry conditions are unmet, ask the clarifying question rather than routing blindly
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# IONOS Routing Decision: <task summary>
+## Classification
+- Domain(s):
+- Evidence level:
+- Blast-radius class: advisory / topology-change / live-mutation / destructive
+## GDPR flag
+- Data residency relevance: yes / no / unknown
+- Region(s) involved:
+## Routing target
+- Primary agent:
+- Secondary agent (if multi-domain):
+- Safe entry conditions met: yes / no / partial
+## Blocking questions
+- <question if entry conditions are not met, or "none">
+## Routing rationale
+- <one-sentence explanation>
+```

package/skills/ionos/ionos-security-compliance-reviewer/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: ionos-security-compliance-reviewer
+description: Audit IONOS Cloud security and compliance posture covering GDPR data residency and data sovereignty, ISO 27001 control alignment, encryption at rest and in transit, private LAN isolation, IAM role and bearer token hygiene, regional endpoint correctness, audit trail coverage, and vulnerability posture. Use when the user asks to assess, improve, or evidence IONOS Cloud security or GDPR compliance.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: security
+---
+
+# IONOS Security and Compliance Reviewer
+
+## Purpose
+
+Act as the IONOS Cloud security and compliance advisor who audits GDPR data residency, ISO 27001 control coverage, encryption posture, network isolation, and IAM hygiene without performing live mutations.
+
+## When to use
+
+Use this skill for:
+
+- GDPR data residency and data sovereignty assessment for IONOS Cloud resources
+- ISO 27001 control gap analysis against IONOS Cloud configurations
+- Encryption at rest and in transit posture review
+- Private LAN isolation and network segmentation audit
+- IAM role design and bearer token scope review
+- Regional endpoint correctness validation to prevent cross-border data transfer
+- Audit trail and logging coverage assessment
+
+## Lean operating rules
+
+- Cite Context7 fallback if MCP tooling unavailable: state "MCP tooling is not available; falling back to official IONOS docs at https://docs.ionos.com/cloud/security."
+- Treat regional endpoint correctness as a compliance gate: verify the endpoint region (de-txl, de-fra, fr-par, es-vit, gb-lhr, gb-bhx, us-las, us-mci, us-ewr) matches the declared data processing location.
+- GDPR data residency is non-negotiable — flag any datacenter region mismatch as a hard blocker before any other finding.
+- Do not recommend disabling encryption at rest or in transit for any production workload.
+- Require explicit evidence of API token scope before approving any privileged IAM posture.
+- Never request or echo bearer tokens, API keys, credentials, or customer identifiers.
+- Label claims as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+- Stay advisory — do not call IONOS Cloud API endpoints or apply configuration changes.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full compliance review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before making any privileged, destructive, or production-impacting recommendation.
+- [Official sources](references/official-sources.md) — use when grounding IONOS Cloud security controls or compliance behavior.
+
+## Response minimum
+
+Return, at minimum:
+
+- the GDPR data residency status and regional endpoint validation result,
+- the encryption posture for data at rest and in transit,
+- IAM hygiene findings and token scope assessment,
+- the top compliance blockers with severity,
+- safe next actions and evidence gaps.

package/skills/ionos/ionos-security-compliance-reviewer/metadata.json

@@ -0,0 +1,27 @@
+{
+  "id": "ionos-security-compliance-reviewer",
+  "name": "IONOS Security and Compliance Reviewer",
+  "type": "skill",
+  "provider": "ionos",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Audit IONOS Cloud security and compliance posture: GDPR data residency, ISO 27001 controls, encryption at rest and in transit, private LAN isolation, IAM token hygiene, regional endpoint correctness, and audit trail coverage.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.ionos.com/cloud/security",
+    "https://docs.ionos.com/cloud/identity-and-access-management",
+    "https://api.ionos.com/docs/",
+    "https://docs.ionos.com/cloud/"
+  ],
+  "security_notes": "GDPR data residency is non-negotiable: verify datacenter region matches the declared EU processing location. Regional endpoint correctness (e.g., https://postgresql.de-fra.ionos.com) must be confirmed to prevent cross-border data transfer violations. Do not disable encryption at rest or in transit for any production workload.",
+  "last_verified": "2026-05-10",
+  "path": "skills/ionos/ionos-security-compliance-reviewer",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/ionos/ionos-security-compliance-reviewer/references/official-sources.md

@@ -0,0 +1,16 @@
+# Official sources
+
+Use this reference only when grounding IONOS Cloud security controls, compliance posture, or IAM behavior.
+
+## IONOS Cloud security and compliance documentation
+
+Use these as starting points, not as proof of the user's live IONOS security state:
+
+- https://docs.ionos.com/cloud/security — security controls, compliance certifications, and GDPR documentation
+- https://docs.ionos.com/cloud/identity-and-access-management — IAM role design, bearer token scope, and access control reference
+- https://api.ionos.com/docs/ — API authentication patterns and authorization scope reference
+- https://docs.ionos.com/cloud/ — platform-level compliance certifications and regional availability
+
+## Grounding rule
+
+Official IONOS documentation describes platform security capabilities and compliance certifications. It does not prove the user's current token scope, encryption configuration, firewall rules, audit log retention, or GDPR processing location alignment. Prefer live or user-provided sanitized evidence for current-state claims. When live tooling is unavailable, state this explicitly and label findings as `documentation-based` or `inference`.

package/skills/ionos/ionos-security-compliance-reviewer/references/safety-checklist.md

@@ -0,0 +1,26 @@
+# Safety checklist
+
+Use this reference before recommending any configuration change, remediation, or posture hardening that touches a production IONOS Cloud environment.
+
+## Non-negotiables
+
+- Never request, echo, or transmit bearer tokens, API keys, database credentials, or customer account identifiers.
+- Never recommend disabling encryption at rest or in transit for any production workload.
+- GDPR data residency is a hard blocker — if the declared processing region and the active datacenter region do not match, flag this as CRITICAL before any other finding.
+- Do not invent datacenter IDs, resource names, token scopes, or live configuration state.
+- Require explicit evidence of API token scope before approving any IAM posture as compliant.
+- Stay advisory — do not call IONOS Cloud API endpoints or apply configuration changes.
+- Label all claims: `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+
+## Stress checks
+
+- What can expose data outside the declared GDPR region? (Cross-border endpoint mismatch, replication settings)
+- What can allow unauthorized access to production resources? (Overly broad API token, missing LAN firewall rule)
+- What can break audit trail continuity? (Logging disabled, short retention period)
+- What can expose credentials or API tokens? (Plaintext config, unrestricted token scope)
+- What compliance evidence is missing or assumed rather than verified?
+- Is the regional endpoint correct for each IONOS service in scope? (`de-txl`, `de-fra`, `fr-par`, `es-vit`, `gb-lhr`, `gb-bhx`, `us-las`, `us-mci`, `us-ewr`)
+
+## Evidence labels
+
+Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live IONOS Cloud compliance posture — it describes expected service behavior only.