teleo-infrastructure/.agents/skills/teleo-leo-onboarding/SKILL.md

name	description
teleo-leo-onboarding	Use when a worker needs fast context on Teleo/Living IP, Leo architecture, VPS/GCP and Hermes runtime boundaries, database provenance, ingestion/apply/reconstruction, identity, testing, security, secrets, or incident recovery before doing Leo or Teleo 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 without rediscovering the system from historical chat.

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"
• "recover or reconstruct Leo"
• "which skill should I use"

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 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. Direct passwordless SSH and sudo -n work as of 2026-07-14. The newest VPS DB was restored to a disposable private Cloud SQL clone with exact parity, and a real ID-free no-send reasoning turn passed. The merged helper/skill were deployed, supported KB commands now fail closed to Cloud SQL, and the service survived a controlled restart with live post-restart status/search receipts. Persistent GCP teleo_canonical is still an older staging copy; Telegram delivery, GCP canonical mutation, ongoing replication, promotion, and cutover remain separate proof rows.

Architecture Boundaries

• VPS canonical KB: Docker Postgres teleo-pg, database teleo.
• GCP canonical KB: private Cloud SQL database teleo_canonical.
• Canonical rows: public.claims, public.sources, public.claim_evidence, public.claim_edges, and related identity/strategy tables; staging/review is kb_stage.*.
• Hermes state.db and session JSONL files are conversation continuity, not canonical collective knowledge. GCP memory-sync success does not prove the canonical KB was restored or updated.
• SOUL.md is a rendered/runtime artifact. Direct file edits are not canonical identity changes without DB row and render/sync proof.

Clean-Context First Commands

From the repository root, validate the pack without a virtual environment or network access:

.agents/skills/teleo-leo-onboarding/scripts/validate_skill_pack.py --root .

Install exactly the manifest-indexed skills into an empty temporary agent skill root with:

.agents/skills/teleo-leo-onboarding/scripts/install_skill_pack.py \
  --root . \
  --target /private/tmp/teleo-clean-agent/skills

Installed skills still resolve repository-relative routes against the current teleo-infrastructure checkout. Keep the agent working directory at the repo root. For pytest, use .venv/bin/python; if .venv is absent, create it from README.md before running tests. Do not guess a bare python command.

Run the deterministic isolated acceptance canary with:

.agents/skills/teleo-leo-onboarding/scripts/run_clean_context_canary.py \
  --root . \
  --output docs/reports/leo-working-state-20260709/skill-pack-clean-context-canary-current.json

Task Router

Area	Skill	Canonical first route
Company, product, architecture	teleo-leo-onboarding	docs/reports/leo-working-state-20260709/current-truth-index.md
VPS runtime and incidents	teleo-vps-runtime-ops	Fresh service, deploy, DB, and cleanup readbacks
GCP and Cloud SQL	teleo-gcp-parity-ops	Current main evidence; keep open PR #148 candidate-only
Hermes packaging/runtime	nousresearch-hermes-agent	hermes-agent/ plus the live service-specific ops skill
Database provenance	teleo-infra-provenance and teleo-db-operator	Separate Git, runtime, SQLite, Postgres, and retained proof
Source ingestion and proposal/apply	teleo-kb-db-change-workflow	Hash-bound source, review, guarded apply, receipt
Reconstruction and recovery	teleo-reconstruction-recovery	docs/kb-rebuild-and-recompile.md
Identity and rendered soul	working-leo-m3taversal-outcomes	Canonical identity rows before SOUL.md
Testing and proof tiers	teleo-proof-handoff	Exact tier, command, receipt, cleanup, claim ceiling
Secrets	private-password-storage	Provider login first; never paste or retrieve a secret

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/gcp-db-first-working-leo-20260714.md
3. docs/reports/leo-working-state-20260709/gcp-db-first-parity-current.json
4. docs/reports/leo-working-state-20260709/gcp-db-first-blind-claim-current.json
5. docs/reports/leo-working-state-20260709/gcp-db-first-cleanup-current.json
6. docs/reports/leo-working-state-20260709/gcp-db-first-live-deploy-restart-current.json
7. docs/reports/leo-working-state-20260709/operator-surface-map.md
8. docs/reports/leo-working-state-20260709/working-leo-definition-20260709.md
9. .agents/skills/working-leo-m3taversal-outcomes/SKILL.md
10. docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.md
11. docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.md
12. docs/kb-rebuild-and-recompile.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.
• PRs #146 and #147 are merged repository truth. PR #148 remains an open GCP least-privilege candidate until live gh pr view 148 readback says otherwise; never route a deployment from its branch as though it were main.
• Use ssh -o BatchMode=yes teleo-gcp-staging true to preflight passwordless GCP VM access. If the firewall route drifts, rediscover the authenticated non-secret route before declaring a blocker. The OIDC/IAP workflow is still not bootstrapped. Do not print the Cloud SQL or Google password or create IAM/users inside a read-only lane.
• A benchmark score is not sufficient when an answer contradicts the DB receipt. Compare every printed count to teleo-kb status or the canonical manifest.

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.