Teranode architecture knowledge base and deployment-agnostic debugging methodology. Use this whenever you are reasoning about Teranode internals — the microservice pipeline, transaction or block lifecycle, the UTXO/subtree/block data model, the blockchain FSM states, the pluggable stores (Aerospike/PostgreSQL/SQLite/Kafka/Redpanda), or diagnosing performance bottlenecks, stuck transactions, or blocks that won't validate. Start here for any "how does Teranode work", "why is Teranode slow", or "why is X stuck" question, and use it as the shared foundation beneath the debug-teranode-k8s and debug-teranode-docker skills, which add the environment-specific data collection on top of this reasoning layer.
Drive Teranode's release lifecycle — survey state, triage hotfix candidates, cherry-pick PRs onto release branches, cut numbered beta tags, and promote tested betas to stable patches. Use when the user types "/release", says "cut a release", "tag a beta", "hotfix triage", "what's the release status", "prepare patch release", or works on `release/v*` branches.
Collect and interpret Teranode diagnostics on Docker / docker-compose. Use this whenever you are debugging a Teranode stack running in Docker — a local dev stack, a multi-node compose stack, the operator single-node mainnet/testnet stack, or CI — reached with docker / docker compose: discovering the compose project and its containers, pulling goroutine and CPU profiles (via host port or docker exec), checking Aerospike / PostgreSQL / Redpanda health, scanning container logs, and running the bundled teranode-diag-docker.sh snapshot. Trigger on mentions of docker, docker compose, compose files, container names like teranode1/blockchain/aerospike, settings contexts like docker.m or docker.teranodeN.test, or "why is my local teranode slow / stuck" when the deployment is Docker. This is the "how to collect it on Docker" layer; pair it with the debug-teranode skill for "what it means". For Kubernetes deployments use debug-teranode-k8s instead.
Collect and interpret Teranode diagnostics on Kubernetes. Use this whenever you are debugging a Teranode deployment that runs on k8s — k0s, EKS, GKE, or any operator-managed cluster reached with kubectl: discovering the services/pods/namespaces, pulling goroutine and CPU profiles, checking Aerospike / PostgreSQL / Redpanda health, hunting pipeline bottlenecks, or running the bundled teranode-diag.sh snapshot. Trigger on mentions of kubectl, pods, namespaces, the Teranode operator or its CRs (propagations/blockassemblies/etc), or "why is my teranode cluster slow / stuck" when the deployment is Kubernetes. This is the "how to collect it on k8s" layer; pair it with the debug-teranode skill for "what it means". For Docker / docker-compose deployments use debug-teranode-docker instead.