llm-runtime-architecture
Use when designing how one canonical agent core runs across Codex, Claude Code, Gemini CLI, Cursor, and AGENTS.md-compatible tools.
git clone --depth 1 https://github.com/agentlas-ai/Agentlas-OS /tmp/llm-runtime-architecture && cp -r /tmp/llm-runtime-architecture/.agents/skills/llm-runtime-architecture ~/.claude/skills/llm-runtime-architectureSKILL.md
# LLM Runtime Architecture ## Procedure 1. Keep `AGENTS.md` as the canonical behavior contract. 2. For each runtime, name entry point, global command, adapter files, available tools, memory access, limitations, and verification command. 3. Keep adapters thin and point them back to the canonical core. 4. Write or repair `.agentlas/global-commands.json` when creating or packaging an agent. 5. State unsupported capabilities explicitly. ## Output Return a runtime matrix with `runtime`, `entry_point`, `global_command`, `adapter_files`, `memory_access`, `limitations`, and `verification`.
Use when designing a new multi-agent team, visible agents folder, role boundaries, handoff flow, PM Soul, Memory Curator, Policy Gate, or evaluation role. Use for agent-team repo creation even when the user only says they want a meta-agent or agent operating system.
Use when adding or auditing local runtime behavior that turns a project folder into an Agentlas-aware workspace with .agentlas memory and sitemap files.
Use the Agentlas browser hardpoint for browser-required work.
Use when the user types /agentlas-build, /agentlas build, or /hep-build to design, build, and package a single agent or multi-agent team.
Prepare explicitly named Agentlas Hub or Cloud agents.
Use when the user types /agentlas-cloud, /agentlas cloud, or /hep-cloud to staff only from the signed-in owner's private Cloud packages.
Connect Agentlas agents or teams to Telegram.
Use when creating a single Agentlas agent, creating a multi-agent team, or packaging an existing local/external agent into Agentlas architecture. Make sure to use this for /meta-agent requests.