teleo-infrastructure/.agents/skills/teleo-leo-onboarding/SKILL.md
twentyOne2x 15f9133920 Teach Teleo skills current VPS and GCP runtime truth
- Distinguish source synchronization from service, migration, worker, and database state changes.
- Bound GCP claims to current VM, Cloud SQL inventory, logs, and serial evidence.
- Keep the operating pack reliable with 14 skill validations and 809 passing tests.

`.agents/skills/teleo-gcp-parity-ops/SKILL.md`
`.agents/skills/teleo-infra-provenance/SKILL.md`
`.agents/skills/teleo-kb-db-change-workflow/SKILL.md`
`.agents/skills/teleo-leo-onboarding/SKILL.md`
`.agents/skills/teleo-vps-runtime-ops/SKILL.md`
`docs/reports/leo-working-state-20260709/current-truth-index.md`
`docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.json`
`docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.md`
`docs/reports/leo-working-state-20260709/pr72-vps-auto-deploy-runtime-nonchange-current.json`
`docs/reports/leo-working-state-20260709/pr72-vps-auto-deploy-runtime-nonchange-current.md`
`docs/reports/leo-working-state-20260709/skill-pack-manifest.json`
`docs/reports/leo-working-state-20260709/skill-pack-readme.md`
`tests/test_repo_skill_pack.py`
2026-07-10 18:13:39 +02:00

76 lines
3.1 KiB
Markdown

---
name: teleo-leo-onboarding
description: Use when a worker needs fast context on Teleo/Living IP, Leo, the product architecture, current VPS/GCP split, and the July 9 working-state evidence before doing Leo, Teleo, KB, Telegram, VPS, or GCP work.
---
# Teleo / Leo Onboarding
## Job
Orient the worker before action. Build a current, proof-linked understanding of the company/product, Leo's role, the infrastructure surfaces, and the exact claim ceiling.
## Trigger Phrases
- "onboard to Leo"
- "what is Teleo / Living IP"
- "load Leo VPS context"
- "Fable handoff for Leo"
- "before working on Teleo infra"
- "explain the architecture"
## Core Model
- Teleo is the knowledge/agent infrastructure layer behind Leo.
- Leo is the operator-facing agent expected to answer in Telegram, remember operator context, reason from canonical KB state, stage concrete KB changes, and support approved changes becoming canonical DB rows with proof.
- The immediate July 9 issue is not generic bot liveness. It is Cory/m3taversal's expectation that approved KB changes move beyond proposal state when appropriate.
- The VPS is the currently proven Telegram-visible Leo surface.
- GCP is a separate lane. Project, VM, private Cloud SQL inventory, and bounded
serial unit activity are current. Current gateway PID/SHA/model/auth,
canonical DB rows, Cory answers, and cutover are not proven.
## Read First
From the repo root, read:
1. `docs/reports/leo-working-state-20260709/current-truth-index.md`
2. `docs/reports/leo-working-state-20260709/operator-surface-map.md`
3. `docs/reports/leo-working-state-20260709/working-leo-definition-20260709.md`
4. `docs/reports/leo-working-state-20260709/cory-expected-working-leo-outcomes-20260709.md`
5. `docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.md`
6. `docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.md`
7. `docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.md`
8. `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.md`
## Required Status Split
Every status answer must split:
- `VPS runtime`
- `Telegram-visible Leo`
- `KB proposal/staging`
- `Canonical DB apply`
- `GCP parity`
- `Runtime/code provenance`
Do not collapse GCP demo readiness into Telegram completion. Do not collapse proposal approval into canonical DB application.
## Hard Boundaries
- Do not do paid route work or introduce paid-route naming.
- Do not change live VPS Leo runtime behavior unless explicitly authorized.
- Do not production-apply DB packets unless explicitly authorized.
- Do not expose secret contents.
- Do not treat an old summary as current if a fresh readback is cheap.
- Do not call GCP blocked on CLI login when authenticated Chrome can answer the
control-plane question. Conversely, do not submit a raw DB password or create
IAM/users under a read-only lane.
## Output Format
For onboarding handoffs, return:
1. Product/architecture summary in 8 bullets or fewer.
2. Current proof split by VPS, Telegram, DB, GCP.
3. Evidence files actually read.
4. Exact claim ceiling.
5. Next runnable non-production action.