llm-runtime-architecture

$npx mdskill add agentlas-ai/Agentlas-OS/llm-runtime-architecture

Design a canonical agent core that runs across multiple LLM runtimes.

  • Ensures consistent agent behavior across Codex, Claude Code, Gemini CLI, and Cursor.
  • Depends on AGENTS.md, adapter files, and global-commands.json.
  • Analyzes each runtime's capabilities and limitations to define thin adapters.
  • Outputs a runtime matrix with entry points, tools, memory access, and verification.

SKILL.md

.github/skills/llm-runtime-architectureView on GitHub ↗
---
name: llm-runtime-architecture
description: "Use when designing how one canonical agent core runs across Codex, Claude Code, Gemini CLI, Cursor, and AGENTS.md-compatible tools."
---

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

More from agentlas-ai/Agentlas-OS

SkillDescription
agent-team-designUse 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.
agentlas-auto-activationUse when adding or auditing local runtime behavior that turns a project folder into an Agentlas-aware workspace with .agentlas memory and sitemap files.
agentlas-core-engine-meta-agentUse 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.
agentlas-packagingUse when converting, repairing, or packaging an existing local or external agent/team into Agentlas architecture for local install, Agentlas import, Codex plugin use, Claude adapter use, or open-source release.
agentlas-security-scanUse when an agent folder must pass the Agentlas Cloud 2-stage security scan (static rules + BYOK LLM judgment) before private sync or public publish, or when asked to run/interpret `hephaestus security scan`.
clarify-question-loopUse when a meta-agent request is too ambiguous to safely generate, package, publish, or adapt without one to five targeted questions.
hephaestus-buildUse when the user types /prompts:hep-build, mentions @Hephaestus for build work, asks to create a single Agentlas agent, create a multi-agent team, or package an existing local/external agent into Agentlas architecture.
hephaestus-cloudUse when the user types /hep-cloud or asks to staff from THEIR OWN Agentlas cloud packages only. Cloud is one exact source scope; Network means Local + owner Cloud + public Hub.
hephaestus-networkUse when the user types /hep-network, mentions @Hephaestus, or asks Agentlas to staff a task from registered Local, owner Cloud, and public Hub agents or teams. The active host LLM is the temporary orchestrator.
hephaestus-stormUse when the user types /hep-storm, says @Hephaestus storm <goal>, or asks to drive a goal to verified completion through a force-robust Stormbreaker loop. Stormbreaker routes the goal to real Agentlas specialists, materializes a dependency-ordered pipeline fabric, and runs each work packet as a verifier-first hardened loop that does not stall, run away, or claim false success. Use it for loop-worthy work — apps, sites, agents, automations, debugging, multi-step research, data/report generation. Trivial questions are answered directly, not stormed.