@raishin/vanguard-frontier-agentic 1.6.0 → 1.7.0

package/skills/contabo/contabo-live-instance-lifecycle-guard/references/safety-checklist.md

@@ -0,0 +1,43 @@
+# Safety checklist
+
+Before executing any Contabo VPS or VDS lifecycle mutation (create, reinstall, cancel), enforce every item on this checklist. Never proceed without all mandatory gates confirmed.
+
+## Hard-stop gates — all required, no exceptions
+
+Do not execute any mutation unless ALL of the following are confirmed in writing by the user:
+
+1. **Target confirmed**: Instance ID (for reinstall or cancel) OR product ID + region (for create). Do not infer the target from prior conversation context alone.
+2. **Contract period explicitly acknowledged**: The user has stated the contract period (1, 3, 6, or 12 months) and confirmed they understand the billing obligation. "Sure" or "go ahead" is not acknowledgment — require the period and billing figure to be stated.
+3. **Rollback plan documented**: A concrete recovery path is on record. "We'll figure it out" is not a rollback plan. Minimum: where data is backed up, how to restore access, who to contact.
+4. **Named approving identity on record**: The full name or authenticated account identifier of the authorizing person. A role title, team name, ticket number, or alias alone is not sufficient.
+5. **OAuth2 token freshness confirmed**: The token has been refreshed within the last 5 minutes. Stale tokens cause silent failures or partial operations. Refresh immediately before the mutation call.
+
+## Non-negotiables
+
+- Do not execute direct mutations against an ambiguous instance ID or product. If the user's intent is unclear, ask exactly one clarifying question.
+- Do not treat "reinstall" as reversible. Reinstallation wipes the current OS and all data not backed up externally. State this explicitly before the user confirms.
+- Do not treat cancellation as reversible. Once cancelled, the instance and its data may be unrecoverable. Confirm remaining period and data backup before proceeding.
+- Do not include raw SSH private key material in any API payload, script, or recommendation. Reference only Contabo secret IDs.
+- Do not log, echo, or include OAuth2 token values in any output, log file, or script.
+- Review all Cloud-Init userData for embedded secrets, curl-pipe-sh patterns, hardcoded credentials, and commands that disable audit logging before passing to the API. Refuse userData that fails this review.
+- Include a fresh UUIDv4 `x-request-id` header in every mutation call.
+
+## Mandatory posture
+
+- Prefer read-only inventory first. Always call `GET /v1/compute/instances` before any mutation to confirm current state.
+- Prefer the smallest mutation. If a reinstall can be avoided by a configuration change, recommend that first.
+- Treat the absence of a rollback plan as a blocker, not a detail to resolve post-mutation.
+- If any hard-stop gate is missing, stop completely and list exactly which gates remain open. Do not proceed partially.
+- If live credentials are present but the target instance or account is ambiguous, stop and request explicit confirmation.
+
+## Stress checks
+
+- Is reinstallation genuinely required, or can the goal be achieved without wiping the instance?
+- Is the cancellation period remaining understood, and is there a data export or migration path confirmed?
+- Is the contract period the shortest option that meets the requirement, or is the user being locked into a longer period unnecessarily?
+- Is the Cloud-Init userData idempotent and free of destructive or unauthenticated commands?
+- What happens if the API call succeeds but the instance reaches an unexpected state (e.g., reinstall stuck, create with wrong image)?
+
+## Evidence labels
+
+Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. Never proceed with a mutation based on inference about the target instance state.

package/skills/contabo/contabo-live-instance-lifecycle-guard/references/workflow-and-output.md

@@ -0,0 +1,63 @@
+# Workflow and output contract
+
+Use this reference when executing a VPS or VDS lifecycle operation: create, reinstall, or cancel. Every step in this sequence is mandatory before issuing any mutation call.
+
+## Pre-mutation sequence
+
+1. **Confirm target identity and environment**
+   - For create: confirm product ID, region, contract period, image, Cloud-Init userData (if any), and SSH key secret IDs.
+   - For reinstall: confirm instance ID, new image, Cloud-Init userData (if any), and SSH key secret IDs. Warn that reinstall wipes the current OS and data.
+   - For cancel: confirm instance ID, remaining contract period, and early-termination billing impact.
+   - Verify OAuth2 token freshness. Tokens expire in ~5 minutes. Refresh immediately before the mutation call.
+
+2. **Run read-only inventory first**
+   - List current instances via `GET /v1/compute/instances` before any mutation.
+   - Confirm the target instance ID and its current state. Do not proceed if the inventory call fails or returns unexpected state.
+   - For create: confirm product availability in the target region via the API or official docs.
+
+3. **Enforce hard-stop gates**
+   - All four gates (target, contract period + billing acknowledgment, rollback plan, named approving identity) must be confirmed in writing before proceeding.
+   - If any gate is missing, stop and request the specific missing item. Do not infer or assume.
+
+4. **Review Cloud-Init userData if present**
+   - Scan for embedded secrets, hardcoded credentials, curl-pipe-sh patterns, and commands that disable audit logging.
+   - Refuse to include userData that fails this review. Request a remediated version.
+
+5. **Execute with traceability**
+   - Include a fresh UUIDv4 `x-request-id` in the mutation call header.
+   - Log the request ID for support traceability. Do not log the OAuth2 token value.
+   - Report the API response and confirm instance state after the operation.
+
+6. **Post-mutation verification**
+   - Confirm the instance reached the expected state (running, reinstalling, or cancelled).
+   - Verify SSH access or console availability after create/reinstall.
+   - Record the new contract period end date for cancellations and renewals.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Contabo Instance Lifecycle: <operation> — <instance ID or product>
+## Hard-stop gate status
+- [ ] Target confirmed: <instance ID / product ID + region>
+- [ ] Contract period acknowledged: <1 | 3 | 6 | 12> months — billing impact: <amount/period>
+- [ ] Rollback plan documented: <recovery path>
+- [ ] Named approving identity: <full name or authenticated account identifier>
+- [ ] OAuth2 token freshness: confirmed fresh (refreshed at <time>)
+## Pre-mutation inventory
+- Current instance state: <state or "not yet queried">
+- Product availability in region: <confirmed | documentation-based | not checked>
+## Cloud-Init review (if applicable)
+- userData review result: PASS / FAIL / NOT APPLICABLE
+- Issues found: <issues or "none">
+## Proposed action
+- Operation: <create | reinstall | cancel>
+- API call: <sanitized call with x-request-id placeholder>
+## Post-mutation verification
+- Instance state after operation:
+- SSH / console access confirmed:
+- Contract period end date:
+## Open risks or refusal reason
+- <risk or explicit none>
+```

package/skills/contabo/contabo-live-storage-operations-guard/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: contabo-live-storage-operations-guard
+description: Live-guard skill for Contabo Object Storage (S3-compatible) bucket operations including inventory audit, access policy review, retention policy enforcement, and deletion workflows. Hard-stops any bucket deletion requested without verified backup evidence and a documented rollback plan. Use when the user needs to manage, audit, or delete Contabo Object Storage buckets or objects.
+allowed-tools: Read Grep Glob Bash
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: platform
+---
+
+# Contabo Live Storage Operations Guard
+
+## Purpose
+
+Act as the approval gate for Contabo Object Storage mutations: audit current bucket inventory, access policies, and retention posture, then execute destructive operations only after verified backup evidence and explicit user sign-off.
+
+## When to use
+
+Use this skill for:
+
+- Contabo Object Storage bucket inventory and object listing
+- Access policy review (bucket ACLs, public access exposure)
+- Retention policy enforcement and lifecycle rule audit
+- Bucket or object deletion with backup verification gate
+- Migration or consolidation of Object Storage across regions
+- Generating approval-ready change records for storage mutations
+
+## Hard-stop conditions
+
+REFUSE to execute any bucket deletion or destructive Object Storage mutation unless ALL of the following are confirmed in writing:
+
+1. **Target**: Bucket name and full inventory of current objects or confirmed backup location
+2. **Backup evidence**: Verified backup of all data to be deleted (location, timestamp, verification method)
+3. **Rollback plan**: Documented recovery path if the operation produces unexpected results
+4. **Named approving identity**: the full name or authenticated account identifier of the person authorizing this operation (not a role, alias, or ticket number alone)
+
+## Lean operating rules
+
+- Contabo has no official Terraform provider or SDK — recommend `cntb` CLI or REST API (curl + jq) for automation.
+- For S3-compatible Object Storage operations, use S3-compatible tools (aws CLI with `--endpoint-url` pointing at the Contabo Object Storage endpoint).
+- Prefer official Contabo docs (https://api.contabo.com/, https://docs.contabo.com/) and Context7 when live MCP access is unavailable.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- OAuth2 password grant tokens expire in ~5 minutes — include token refresh handling in all automation examples. Refresh logic must not log token values.
+- Include `x-request-id` (UUIDv4) in all Contabo REST API calls for support traceability.
+- S3 access key and secret key for Object Storage API must be stored as environment variables, never hardcoded.
+- Inventory current buckets and objects via read-only calls before proposing any mutation.
+- Label claims as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
+
+## Automation pattern (read-only inventory first)
+
+```bash
+# Load credentials from environment — never hardcode
+: "${CONTABO_CLIENT_ID:?set in env}"
+: "${CONTABO_CLIENT_SECRET:?set in env}"
+: "${CONTABO_API_USER:?set in env}"
+: "${CONTABO_API_PASSWORD:?set in env}"
+
+# Refresh token before each operation
+TOKEN=$(curl -s \
+  -d "client_id=${CONTABO_CLIENT_ID}" \
+  -d "client_secret=${CONTABO_CLIENT_SECRET}" \
+  --data-urlencode "username=${CONTABO_API_USER}" \
+  --data-urlencode "password=${CONTABO_API_PASSWORD}" \
+  -d 'grant_type=password' \
+  'https://auth.contabo.com/auth/realms/contabo/protocol/openid-connect/token' \
+  | jq -r '.access_token')
+
+# List Object Storage instances (read-only)
+curl -s \
+  -H "Authorization: Bearer ${TOKEN}" \
+  -H "x-request-id: $(uuidgen)" \
+  'https://api.contabo.com/v1/storage/object-storages' | jq .
+```
+
+## Response minimum
+
+Return, at minimum:
+
+- the target bucket(s) and object inventory evidence level,
+- the access policy and retention posture assessment,
+- the hard-stop checklist status (all three items confirmed or blocked),
+- the rollback plan,
+- the assumptions or open questions that require user clarification before proceeding.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing a full storage operation or formatting the approval-ready change record.
+- [Safety checklist](references/safety-checklist.md) — use before any bucket deletion, object deletion, or irreversible storage mutation; all hard-stop gates must be confirmed before proceeding.
+- [Official sources](references/official-sources.md) — use when grounding Contabo Object Storage API behavior, S3 compatibility, or access policy configuration.

package/skills/contabo/contabo-live-storage-operations-guard/metadata.json

@@ -0,0 +1,25 @@
+{
+  "id": "contabo-live-storage-operations-guard",
+  "name": "Contabo Live Storage Operations Guard",
+  "type": "skill",
+  "provider": "contabo",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Live-guard skill for Contabo Object Storage (S3-compatible) bucket operations including inventory audit, access policy review, retention policy enforcement, and deletion with verified backup evidence required before any destructive mutation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://api.contabo.com/",
+    "https://docs.contabo.com/"
+  ],
+  "security_notes": "OAuth2 password grant tokens expire in ~5 minutes — refresh handling must not log token values. Credentials must remain in environment variables. Contabo Object Storage is S3-compatible — S3 access key and secret key must be stored as environment variables, never hardcoded. x-request-id (UUIDv4) is mandatory for Contabo REST API calls. Hard-stop on any bucket deletion without verified backup evidence. Contabo has no official Terraform provider or SDK; recommend cntb CLI or REST API with curl + jq and S3-compatible tools for Object Storage.",
+  "last_verified": "2026-05-10",
+  "path": "skills/contabo/contabo-live-storage-operations-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/contabo/contabo-live-storage-operations-guard/references/official-sources.md

@@ -0,0 +1,16 @@
+# Official sources
+
+Use this reference only when grounding Contabo Object Storage API behavior, S3 compatibility, bucket operations, or access policy configuration.
+
+## Contabo documentation
+
+Use these as starting points, not as proof of the user's live bucket state, object inventory, or access policy configuration:
+
+- https://api.contabo.com/#tag/Object-Storages — Object Storage API (list instances, create/manage storage instances, region codes)
+- https://api.contabo.com/ — Contabo OpenAPI reference (authentication flows, request headers including x-request-id, error response schemas)
+- https://docs.contabo.com/ — Contabo user documentation (Object Storage setup, S3 compatibility guide, endpoint URLs by region, access key management)
+- https://github.com/contabo/cntb — cntb CLI tool (Object Storage commands; credential and access key configuration)
+
+## Grounding rule
+
+Official Contabo documentation describes Object Storage API endpoints, S3-compatible endpoint URLs by region, access key management patterns, and available storage instance configurations at the time of publication. It does not prove the user's current bucket inventory, object count, active retention policies, ACL configuration, or the actual data at risk in a deletion operation. Prefer live read-only API responses and S3 list commands for current-state claims. Label any bucket configuration, endpoint URL, or storage behavior claim sourced only from documentation as `documentation-based`. Always confirm the correct S3 endpoint URL for the target region from official docs — do not assume the default AWS endpoint or a URL from a prior session.

package/skills/contabo/contabo-live-storage-operations-guard/references/safety-checklist.md

@@ -0,0 +1,44 @@
+# Safety checklist
+
+Before executing any Contabo Object Storage mutation (bucket deletion, object deletion, access policy change, retention policy change, cross-region migration), enforce every item on this checklist. Never proceed without all mandatory gates confirmed for destructive operations.
+
+## Hard-stop gates — all required for deletion and irreversible mutations
+
+Do not execute any bucket deletion, bulk object deletion, or irreversible mutation unless ALL of the following are confirmed in writing by the user:
+
+1. **Target confirmed with inventory**: Bucket name AND region AND full object inventory reviewed. Do not delete a bucket based on name alone — confirm object count and verify there is nothing unexpected.
+2. **Backup evidence verified**: Confirmed backup of all data to be deleted, including backup location, timestamp, and verification method (e.g., restored successfully to staging, checksum matched). "I think we have a backup" is not verification.
+3. **Rollback plan documented**: A concrete data recovery path is on record. For object deletion: where the backup lives and how to restore. For bucket deletion: whether recreation is possible and what configuration is required.
+4. **Named approving identity on record**: The full name or authenticated account identifier of the authorizing person. A role title, team name, ticket number, or alias alone is not sufficient.
+5. **Retention audit complete**: Confirm no retention or compliance policy blocks deletion. Deleting objects under an active retention lock may be a compliance violation.
+
+## Non-negotiables
+
+- Do not execute bucket deletion if the object inventory has not been reviewed in this session. A prior audit is not sufficient — inventory must be confirmed fresh.
+- Do not treat bucket deletion as reversible. Deleted objects in Contabo Object Storage cannot be recovered without a verified external backup.
+- Do not recommend making a bucket publicly accessible without explicit user acknowledgment of the data exposure risk and the specific use case requiring public access.
+- S3 access keys and secret keys for Object Storage must be stored in environment variables. Never hardcode, echo, or include them in any output, log file, or script.
+- Do not log, echo, or include OAuth2 token values in any output, log file, or script.
+- Include a fresh UUIDv4 `x-request-id` header in every Contabo REST API mutation call.
+- For S3-compatible operations, use `aws s3` or `aws s3api` with `--endpoint-url` pointing to the Contabo Object Storage endpoint — never against the default AWS endpoint.
+
+## Mandatory posture
+
+- Prefer read-only inventory first. Always call `GET /v1/storage/object-storages` and list the target bucket contents before any deletion or mutation.
+- Prefer the least-destructive operation. If an access policy change achieves the goal without deletion, recommend that first.
+- Treat missing backup evidence as a hard blocker, not a detail to resolve after deletion.
+- If any hard-stop gate is missing, stop completely and list exactly which gates remain open. Do not proceed partially.
+- If public access is about to be enabled, surface the full data exposure risk explicitly before the user confirms.
+
+## Stress checks
+
+- Is there data in this bucket that is not captured in the confirmed backup? → Stop until resolved.
+- Is any object in this bucket subject to a compliance retention policy? → Confirm legality of deletion before proceeding.
+- Is the access policy change exposing sensitive data publicly? → Require explicit use-case justification.
+- What is the recovery time if the backup restore is needed? Is it within the user's acceptable window?
+- Is the S3 endpoint URL correct for the Contabo region, not a default AWS endpoint?
+- Is the OAuth2 token fresh enough for the full sequence of API calls required?
+
+## Evidence labels
+
+Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. Never proceed with a destructive bucket operation based on inference about the object inventory or backup state.

package/skills/contabo/contabo-live-storage-operations-guard/references/workflow-and-output.md

@@ -0,0 +1,59 @@
+# Workflow and output contract
+
+Use this reference when executing Contabo Object Storage mutations: bucket creation, access policy changes, retention policy updates, object or bucket deletion, or cross-region migration. Every step is mandatory before issuing any destructive call.
+
+## Pre-mutation sequence
+
+1. **Confirm target and inventory**
+   - Confirm the Object Storage instance ID and region.
+   - List all buckets in the instance via `GET /v1/storage/object-storages` and S3-compatible list commands.
+   - For deletion: confirm the full object inventory of the target bucket. Do not delete a bucket described only by name without first listing its contents.
+   - Verify OAuth2 token freshness. Tokens expire in ~5 minutes. Refresh immediately before any mutation call.
+
+2. **Review access policy and retention posture**
+   - Check bucket ACLs and public access settings. Confirm whether any bucket is publicly readable or writable.
+   - Review any lifecycle or retention rules. Confirm whether deletion is blocked by a retention policy.
+   - Label the access policy state as `live evidence`, `user-provided sanitized evidence`, or `inference`.
+
+3. **Enforce hard-stop gates for destructive operations**
+   - All four gates (bucket ID + region + inventory, backup evidence, rollback plan, named approving identity) must be confirmed in writing before any deletion or irreversible mutation.
+   - If any gate is missing, stop and request the specific missing item. Do not infer or assume.
+
+4. **Execute with traceability**
+   - Include a fresh UUIDv4 `x-request-id` in all Contabo REST API mutation calls.
+   - Use environment-variable-stored S3 access keys for S3-compatible operations. Never hardcode S3 credentials.
+   - Log the request ID. Do not log the OAuth2 token, S3 secret key, or access key.
+
+5. **Post-mutation verification**
+   - Confirm the bucket or object state after the operation.
+   - For deletions: confirm the bucket or objects no longer exist.
+   - For access policy changes: verify the new ACL or public access setting is in effect.
+   - Record the operation timestamp for audit purposes.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Contabo Object Storage: <operation> — <bucket name or instance ID>
+## Hard-stop gate status (required for destructive operations)
+- [ ] Target confirmed: bucket name + region + object inventory reviewed
+- [ ] Backup evidence: <location, timestamp, and verification method or "N/A — non-destructive">
+- [ ] Rollback plan documented: <recovery path>
+- [ ] Named approving identity: <full name or authenticated account identifier>
+- [ ] OAuth2 token freshness: confirmed fresh (refreshed at <time>)
+## Pre-mutation inventory
+- Object Storage instance ID:
+- Bucket name:
+- Object count and estimated size: <count and size or "not yet queried">
+- Access policy state: <public | private | mixed | inference>
+- Retention policy: <present | absent | inference>
+## Proposed action
+- Operation: <create | update-acl | update-retention | delete-objects | delete-bucket | migrate>
+- API or S3 call: <sanitized call with x-request-id or endpoint placeholder>
+## Post-mutation verification
+- Bucket or object state after operation:
+- Access policy confirmed:
+## Open risks or refusal reason
+- <risk or explicit none>
+```

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

@@ -0,0 +1,61 @@
+---
+name: contabo-maestro
+description: Router skill for classifying Contabo tasks and delegating to the narrowest specialist for cost analysis, capacity planning, security hardening, VPS/VDS lifecycle operations, or Object Storage management. Use when the user asks a Contabo question that spans multiple domains or needs triage before specialist engagement.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: platform
+---
+
+# Contabo Maestro
+
+## Purpose
+
+Act as the Contabo routing layer: classify the incoming request, identify the correct specialist domain, and hand off with a scoped context statement. Do not answer specialist questions directly.
+
+## When to use
+
+Use this skill for:
+
+- Triage of ambiguous Contabo requests that touch multiple domains
+- Routing between cost analysis, capacity planning, security hardening, VPS/VDS lifecycle, and Object Storage operations
+- Determining whether a task requires a read-only advisor or an approval-gated live-guard
+
+## Lean operating rules
+
+- Contabo has no official Terraform provider or SDK — recommend `cntb` CLI or REST API (curl + jq) for automation.
+- Prefer official Contabo docs (https://api.contabo.com/, https://docs.contabo.com/) and Context7 for grounding when live MCP access is unavailable.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- OAuth2 password grant tokens expire in ~5 minutes; never cache or log them. Credentials must stay in environment variables.
+- Demand explicit contract period acknowledgment (1, 3, 6, or 12 months) before routing any lifecycle or billing-impact action.
+- Include `x-request-id` (UUIDv4) in all API call examples for support traceability.
+- Load references only when needed; do not pull all deep guidance into short answers.
+
+## Routing domains
+
+| Domain | Specialist |
+|---|---|
+| Contract period analysis, VPS sizing, addon utilization | `contabo-cost-optimization-analyst` |
+| Resource planning, region coverage, instance sizing | `contabo-capacity-planner` |
+| SSH key management, default user policy, firewall posture | `contabo-security-hardening` |
+| VPS/VDS create, reinstall, cancel | `contabo-live-instance-lifecycle-guard` |
+| Object Storage, bucket operations, retention audit | `contabo-live-storage-operations-guard` |
+
+## Response minimum
+
+Return, at minimum:
+
+- the classified domain and evidence level,
+- the recommended specialist and scope statement,
+- any blockers or ambiguities that prevent clean routing,
+- the assumptions or open questions that the specialist should resolve.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full triage, routing a multi-domain request, or formatting the routing decision output.
+- [Safety checklist](references/safety-checklist.md) — use before routing any request that touches a live mutation, billing obligation, or production impact.
+- [Official sources](references/official-sources.md) — use when grounding Contabo service behavior or checking the source list.

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

@@ -0,0 +1,25 @@
+{
+  "id": "contabo-maestro",
+  "name": "Contabo Maestro",
+  "type": "skill",
+  "provider": "contabo",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Router skill for classifying Contabo tasks and delegating to the narrowest specialist for cost analysis, capacity planning, security hardening, VPS/VDS lifecycle, or Object Storage operations.",
+  "source_type": "original",
+  "official_docs": [
+    "https://api.contabo.com/",
+    "https://docs.contabo.com/"
+  ],
+  "security_notes": "OAuth2 password grant tokens expire in ~5 minutes — never cache or log them. Credentials must remain in environment variables. The x-request-id UUIDv4 header is mandatory for support traceability. Contabo has no official Terraform provider or SDK; recommend cntb CLI or REST API. Contractual periods (1, 3, 6, 12 months) create billing obligations — never route lifecycle changes without explicit period acknowledgment.",
+  "last_verified": "2026-05-10",
+  "path": "skills/contabo/contabo-maestro",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -0,0 +1,17 @@
+# Official sources
+
+Use this reference only when grounding Contabo service behavior or verifying the source list for routing decisions.
+
+## Contabo documentation
+
+Use these as starting points, not as proof of the user's live Contabo account state:
+
+- https://api.contabo.com/ — Contabo OpenAPI reference (all endpoints)
+- https://docs.contabo.com/ — Contabo user documentation and guides
+- https://github.com/contabo/cntb — cntb CLI tool (source, releases, usage)
+- https://api.contabo.com/#tag/Instances — Instance operations API
+- https://api.contabo.com/#tag/Object-Storages — Object Storage API
+
+## Grounding rule
+
+Official Contabo documentation describes platform behavior, available products, and API contracts. It does not prove the user's current instance inventory, contract state, billing posture, region availability at the time of the request, or active OAuth2 token validity. Prefer user-provided sanitized evidence or live API responses for current-state claims. Label any claim sourced only from documentation as `documentation-based`.

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

@@ -0,0 +1,24 @@
+# Safety checklist
+
+Use this reference before routing any request that touches a live mutation, billing obligation, or production impact.
+
+## Non-negotiables
+
+- Never ask users to paste OAuth2 tokens, client secrets, API passwords, SSH private keys, S3 secret keys, or any account credentials into chat.
+- Do not invent instance IDs, product IDs, region availability, pricing, or billing terms. Label any claim that has not been confirmed by live evidence or official documentation.
+- Refuse to route a request to an advisory skill when the request clearly requires a live-guard (VPS/VDS mutation or bucket deletion).
+- Demand explicit contract period acknowledgment before routing any request that creates a new billing obligation.
+- Never treat a vague approval ("go ahead," "do it," "looks fine") as sufficient sign-off for a lifecycle or storage mutation routing — escalate to the live-guard for formal confirmation.
+- Separate confirmed routing from inferred routing. If the user's intent is ambiguous, ask one clarifying question rather than assuming the narrower domain.
+
+## Stress checks
+
+- Does any part of this request create, reinstall, or cancel a VPS or VDS? → Live-guard required.
+- Does any part of this request delete, overwrite, or migrate Object Storage buckets or objects? → Live-guard required.
+- Does any part of this request commit a new contract period? → Explicit billing acknowledgment required before routing.
+- Is the stated billing obligation (period × price) accurate or is it an inference? → Label accordingly.
+- Is the user's evidence level sufficient to route confidently, or is additional evidence needed first?
+
+## Evidence labels
+
+Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. Routing decisions made on inference alone must be flagged as provisional.

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

@@ -0,0 +1,52 @@
+# Workflow and output contract
+
+Use this reference only when performing full triage, routing an ambiguous multi-domain request, or generating a handoff context statement for a specialist.
+
+## Review domains
+
+Check these areas before classifying a request:
+
+- Scope: is this a read-only advisory, a live mutation, or a billing-impacting change?
+- Affected domain(s): cost/billing, capacity, security, instance lifecycle, Object Storage
+- Live-guard requirement: does the request touch VPS/VDS create/reinstall/cancel or Object Storage deletion?
+- Contract period exposure: does any part of the request bind a new 1/3/6/12-month obligation?
+- Evidence level: is the user's current state known from live evidence, user-provided data, or inference?
+
+## Safe workflow
+
+1. **Frame scope**
+   - Request type (advisory, planning, mutation):
+   - Contabo account state available (live evidence vs. user description):
+   - Domain(s) implicated:
+   - Contract period or billing obligation involved:
+   - Explicit non-goals:
+2. **Classify the request**
+   - Map against the routing domain table in the SKILL.md.
+   - If multiple domains are implicated, list them and resolve priority (billing/lifecycle safety first).
+   - If the request is ambiguous, ask one clarifying question before routing.
+3. **Check live-guard threshold**
+   - If the request may create, reinstall, or cancel a VPS/VDS → route to `contabo-live-instance-lifecycle-guard`.
+   - If the request may delete buckets or objects → route to `contabo-live-storage-operations-guard`.
+   - Do not route live-guard requests to advisory skills.
+4. **Produce the handoff**
+   - State the classified domain, evidence level, recommended specialist, and scope statement.
+   - Include any blockers, assumptions, or open questions the specialist must resolve.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Contabo Maestro: Routing Decision
+## Classification
+- Domain(s): <list>
+- Request type: advisory | planning | live mutation
+- Evidence level: live | user-provided | inference
+## Specialist recommendation
+- Skill: <skill-name>
+- Scope statement: <one sentence describing the bounded task>
+## Blockers or ambiguities
+- <item or none>
+## Open questions for specialist
+- <question or none>
+```

package/skills/contabo/contabo-security-hardening/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: contabo-security-hardening
+description: Advisory skill for hardening Contabo infrastructure security: SSH key management via secret IDs, default root and admin user policy, firewall posture review, OAuth2 credential hygiene including token short TTL and environment variable storage, and x-request-id UUIDv4 traceability for audit compliance. Use when the user needs to assess or improve Contabo instance or API security posture.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-10"
+  category: security
+---
+
+# Contabo Security Hardening
+
+## Purpose
+
+Act as the Contabo security hardening advisor: identify security gaps in SSH key management, user access policy, firewall configuration, OAuth2 credential hygiene, and API traceability. Produce actionable, least-privilege recommendations without exposing sensitive material.
+
+## When to use
+
+Use this skill for:
+
+- SSH key strategy using Contabo secret IDs (never raw private key material in API calls or scripts)
+- Default root/admin user policy review and hardened user configuration via Cloud-Init
+- Firewall posture assessment for VPS/VDS instances
+- OAuth2 credential hygiene: token short TTL (~5 min), environment variable storage, refresh logic audit
+- x-request-id (UUIDv4) enforcement for Contabo API call traceability and support audit
+- Secret scanning for hardcoded credentials in automation scripts or CI/CD pipelines
+- Network isolation review: Private Networking add-on usage and Additional IP exposure
+
+## Lean operating rules
+
+- Contabo has no official Terraform provider or SDK — recommend `cntb` CLI or REST API (curl + jq) for automation.
+- Prefer official Contabo docs (https://api.contabo.com/, https://docs.contabo.com/) and Context7 when live MCP access is unavailable.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- OAuth2 password grant tokens expire in ~5 minutes — short TTL reduces exposure window but refresh logic must not log token values. Credentials must stay in environment variables.
+- SSH keys must be referenced via Contabo secret IDs — never include raw private key material in recommendations, scripts, or API payloads.
+- Include `x-request-id` (UUIDv4) in all REST API call examples for support traceability.
+- Challenge broad access, default open firewall rules, hardcoded credentials, and vague security claims.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped security target and evidence level,
+- the identified security gaps or control deficiencies,
+- the safest hardening actions in priority order,
+- validation notes and rollback path where relevant,
+- the assumptions or blockers that prevent stronger conclusions.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full security review or formatting the structured audit report.
+- [Safety checklist](references/safety-checklist.md) — use before recommending changes to SSH access paths, firewall rules, user accounts, or credential configuration.
+- [Official sources](references/official-sources.md) — use when grounding Contabo security behavior, API authentication flows, or secret management patterns.

package/skills/contabo/contabo-security-hardening/metadata.json

@@ -0,0 +1,25 @@
+{
+  "id": "contabo-security-hardening",
+  "name": "Contabo Security Hardening",
+  "type": "skill",
+  "provider": "contabo",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Advisory skill for hardening Contabo infrastructure security: SSH key management via secret IDs, default user policy, firewall posture review, OAuth2 credential hygiene, and x-request-id traceability enforcement.",
+  "source_type": "original",
+  "official_docs": [
+    "https://api.contabo.com/",
+    "https://docs.contabo.com/"
+  ],
+  "security_notes": "OAuth2 password grant tokens expire in ~5 minutes — short TTL reduces exposure window but refresh logic must not log tokens. Credentials (CONTABO_CLIENT_ID, CONTABO_CLIENT_SECRET, CONTABO_API_USER, CONTABO_API_PASSWORD) must never be hardcoded. Contabo has no official Terraform provider or SDK; recommend cntb CLI or REST API. SSH keys are referenced via secret IDs — raw private key material must never appear in API payloads, scripts, or recommendations. The x-request-id UUIDv4 header is mandatory for audit traceability.",
+  "last_verified": "2026-05-10",
+  "path": "skills/contabo/contabo-security-hardening",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/contabo/contabo-security-hardening/references/official-sources.md

@@ -0,0 +1,16 @@
+# Official sources
+
+Use this reference only when grounding Contabo security behavior, API authentication flows, or secret management patterns.
+
+## Contabo documentation
+
+Use these as starting points, not as proof of the user's live instance configuration:
+
+- https://api.contabo.com/ — Contabo OpenAPI reference (authentication, secret management, firewall endpoints)
+- https://docs.contabo.com/ — Contabo user documentation (SSH keys, Cloud-Init, firewall, Private Networking)
+- https://github.com/contabo/cntb — cntb CLI tool (secret management commands, instance operations)
+- https://api.contabo.com/#tag/Instances — Instance operations API (Cloud-Init userData, SSH key secret IDs)
+
+## Grounding rule
+
+Official Contabo documentation describes platform security capabilities and API authentication patterns. It does not prove the user's current firewall rules, SSH configuration, running services, or OAuth2 token state. Prefer user-provided sanitized evidence or live read-only API responses for current-state claims. Label any claim sourced only from documentation as `documentation-based`. Documentation alone never replaces a live firewall rule dump or actual sshd_config output.