hephaestus-build

$npx mdskill add agentlas-ai/Agentlas-OS/hephaestus-build

Build or package Agentlas agents and teams from user requests.

  • Creates single agents or multi-agent teams for complex tasks.
  • Reads AGENTS.md and .agentlas/mode-map.json for workspace context.
  • Classifies requests by ownership boundaries, not keywords like team.
  • Runs builder interview and research gate before generating package files.

SKILL.md

.github/skills/hephaestus-buildView on GitHub ↗
---
name: hephaestus-build
description: "Use 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 Build

## Procedure

1. Treat this as the public Codex build surface. Do not expose or ask the user
   to invoke the older internal support skill names.
2. Read `AGENTS.md` and `.agentlas/mode-map.json` when they exist in the
   current workspace.
3. Run the public mode classifier by independent ownership boundaries, not by
   keywords such as "team":
   - package or repair existing material -> `30-agentlas-packager`;
   - one independently owned context/tools/success standard ->
     `10-single-agent-builder`;
   - two or more roles with separate context, permissions, success standards,
     handoff, or synthesis needs -> `20-multi-agent-team-builder`.
   If the shape is unclear, ask before generating. The user-facing question
   must be plain language, for example: "이 일을 한 명의 전문가가 처음부터 끝까지
   맡으면 되나요, 아니면 조사/분석/검토처럼 여러 전문가가 나눠 맡고 마지막에
   합쳐야 하나요?" Do not expose internal labels such as `single-agent`,
   `team-builder`, ownership boundary, memory/context, synthesis, or
   produces/consumes.
4. Run the Builder Interview and Research Gate from
   `docs/builder-interview-research-gate.md` before writing substantial package
   files:
   - ask an 8-12 question first batch when the request is vague;
   - continue follow-ups until target user, tasks, inputs, outputs, examples,
     role count, separated tools or permissions, final merge needs, execution
     order, memory, failure modes, and evals are clear;
   - phrase shape questions in everyday language. Ask who handles which part,
     whether each role needs different files/accounts/tools, whether someone
     must merge the result, and whether work can run at the same time or must
     pass from one person to the next;
   - research official or primary docs, similar agent repositories or
     comparables, GitHub examples, academic/professional theory, and
     tool/plugin docs;
   - compare selected and rejected tools/plugins with permission, secret,
     fallback, and smoke-test notes;
   - synthesize domain-expert behavior from interview answers, comparable
     agents/repos, theory, and tool choices;
   - write `docs/builder-interview.md`, `docs/research-sources.md`,
     `docs/tool-selection.md`, `docs/domain-expert-synthesis.md`,
     `docs/prompt-performance-contract.md`, and
     `.agentlas/capability-eval-plan.json`.
5. If missing narrow details still change files, adapters, or public/private
   boundaries, ask one to five clarify questions before generating.
6. Pick one:
   - `10-single-agent-builder`;
   - `20-multi-agent-team-builder`;
   - `30-agentlas-packager`.
7. Load matching support skills.
8. Write all generated or repaired runtime agent instructions in English:
   `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `agent.md`, skills, workflow/command
   adapters, runtime prompts, handoff contracts, return contracts, and
   operating docs. Translate Korean or other-language source material into
   English agent behavior. Localized public copy, routing trigger examples, and
   sample user inputs may use the target user language.
9. Emit or repair Agentlas contracts, including `.agentlas` activation seed
   files and `.agentlas/global-commands.json` when local continuity is part of
   the output.
10. Add the generated command to Claude Code, Codex, Gemini CLI, generic
   AGENTS.md, and terminal adapters. For teams, expose the orchestrator/HQ
   command and route workers through HQ unless direct worker commands were
   requested.
11. Run `scripts/verify-team-package.sh <generated-package-root>` for generated
    or repaired packages. If it fails, do not report completion; collapse the
    output to a single-agent package or add the required orchestrator/HQ and
    team contracts.
12. Verify with `scripts/verify-package.sh`.
13. Once verification and local registration have succeeded, ask one final
    two-choice storage question using structured controls when available:
    **Cloud에 올리기** or **로컬에만 저장**. Cloud means owner-private Agent
    Cloud storage, restorable on another signed-in Desktop. Mobile can use the
    package only after a paired Desktop restores/installs it; Cloud is not a
    hosted LLM runtime. Local-only performs no network mutation.
14. Never upload by default. Missing input and non-interactive execution are
    local-only. Only after explicit Cloud consent, run the trusted Hephaestus
    runner with `upload <exact-verified-package-root> --visibility
    private-link`. Keep the local package on every auth/offline/CAS/quota/scan
    failure and report an exact retry command. Public Hub publication remains
    a separate explicit action.

## Output

Return `status`, `evidence`, `output`, `global_commands`, `interview_research`,
and `blockers`.

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-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.
install-verificationUse when verifying that a generated agent package can be installed, discovered by runtimes, and checked without private dependencies.