# 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`.

# 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.

# 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>
```