agentlas-ai

hephaestus-cloud

Use when the user types /hephaestus-cloud or asks to find/route to one of THEIR OWN Agentlas cloud packages (보관함, 내 클라우드, 내 보관함, my cloud, my own agents). This is the owner-scoped leg of the three-scope model — it searches ONLY the signed-in user's own cloud packages, not the public marketplace (use hephaestus-network for that) and not local cards. The user's own cloud packages are restorable/owned by them and call-priced at a flat 1 credit.

hephaestus-network

Use when the user types /hephaestus-network, mentions @Hephaestus, or asks to find/invoke the right Agentlas Hub agent, team, or plugin for a task. For public demos, distribution docs, README GIFs, and user-facing MCP tests, Hephaestus Network means Hub-first/Hub-only invocation, not Mason's local Paid/Free folders.

agentlas-security-scan

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

agent-team-design

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.

agentlas-auto-activation

Use when adding or auditing local runtime behavior that turns a project folder into an Agentlas-aware workspace with .agentlas memory and sitemap files.

clarify-question-loop

Use when a meta-agent request is too ambiguous to safely generate, package, publish, or adapt without one to five targeted questions.

llm-runtime-architecture

Use when designing how one canonical agent core runs across Codex, Claude Code, Gemini CLI, Cursor, and AGENTS.md-compatible tools.

memory-ticketing

Use when adding Memory Events, Memory Tickets, memory-map.json, vault-references.json, PM Soul memory ownership, or Memory Curator routing to an agent repo.

mode-classification

Use before routing a /meta-agent request to choose single-agent-creator, team-builder, or agentlas-packager.

public-plugin-packaging

Use when packaging an Agentlas agent repo for public GitHub release, Codex plugin submission, Claude adapter distribution, or one-line terminal installation.

runtime-adapters

Use when creating Codex, Claude Code, Gemini CLI, Cursor, or AGENTS.md runtime adapters from one canonical agent core. Use whenever a generated repo needs multiple AI runtimes without duplicating instructions.

sitemap-task-bias

Use when creating or auditing an agent-team sitemap, Task Bias ledger, concept coverage, product surface map, validation chain, or missing-concept check.

skill-lifecycle-promotion

Use when adding or auditing Agentlas skill lifecycle metadata, skill-registry.json, trial evidence, Curator promotion decisions, or first-class skill promotion gates.

agentlas-core-engine-meta-agent

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-style requests in Codex.

agentlas-packaging

Use when converting or repairing an existing local/external agent or team into Agentlas architecture for install, import, plugin use, or public release.

self-evolving-single-agent

Use when a single installable agent should keep learning, refresh research, track sources, or propose repairs without becoming a multi-agent team.

team-builder-packaging

Use when generating a multi-role team package with orchestrator, PM Soul, Memory Curator, policy, eval, QA, handoffs, and runtime adapters.

install-verification

Use when verifying that a generated agent package can be installed, discovered by runtimes, and checked without private dependencies.

pm-soul

Use when preserving product intent, acceptance criteria, decision memory, open loops, roadmap context, or the product-manager continuity layer of an agent team.