Skip to content
Development
Skill

/hephaestus-network

Use when the user types $hephaestus-network or /hep-network, mentions @Hephaestus, or asks Agentlas to staff a durable goal from registered Local, owner Cloud, and public Hub agents or teams. The active host LLM staffs each turn; the exact roster remains goal-bound until

From plugin
agentlas-os
1.2k41 skills5 agents14 commands1 MCP
Install
$ npx -y skills add agentlas-ai/Agentlas-OS --skill hephaestus-network --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/hephaestus-network

Context preview

The summary Claude sees to decide when to auto-load this skill.

Use when the user types $hephaestus-network or /hep-network, mentions @Hephaestus, or asks Agentlas to staff a durable goal from registered Local, owner Cloud, and public Hub agents or teams. The active host LLM staffs each turn; the exact roster remains goal-bound until

SKILL.md

hephaestus-network.SKILL.md
name: hephaestus-network
description: "Use when the user types $hephaestus-network or /hep-network, mentions @Hephaestus, or asks Agentlas to staff a durable goal from registered Local, owner Cloud, and public Hub agents or teams. The active host LLM staffs each turn; the exact roster remains goal-bound until explicit completion."

Hephaestus Agent Workforce Network

The active host LLM staffs the task. Agentlas Core federates content menus from registered Local, owner Cloud, and public Hub inventory. No source and no deterministic layer is the decision-maker or a server-side LLM executor.

Source scopes are exact:

  • `network`: Local + Cloud + Hub;
  • `local`: registered Local packages only;
  • `cloud`: the signed-in owner's Cloud packages only;
  • `hub`: public Hub packages only.

Public demos and distribution proof use explicit `hub` scope. They must not use private Local/Cloud inventory as evidence of public availability.

Resolve the runner and sign in

Network can query owner Cloud and public Hub inventory, so establish the same saved Agentlas session before staffing:

RUNNER=""
for c in \
  "$HOME/.agentlas/runtime/current/bin/hephaestus" \
  ./bin/hephaestus
do [ -x "$c" ] && RUNNER="$c" && break; done
if [ -z "$RUNNER" ]; then
  for cache in \
    "$HOME/.claude/plugins/cache/agentlas-core-engine/hephaestus" \
    "$HOME/.codex/plugins/cache/agentlas-core-engine/hephaestus"; do
    newest="$(ls -d "$cache"/*/bin/hephaestus 2>/dev/null | sort -V | tail -1)"
    [ -n "$newest" ] && [ -x "$newest" ] && RUNNER="$newest" && break
  done
fi
if [ -n "$RUNNER" ] && [ "${HEPHAESTUS_AUTH_AUTOPOPUP:-1}" != "0" ]; then
  "$RUNNER" auth ensure --timeout 180 >/dev/null 2>&1 || true
fi

The browser opens only when no reusable local sign-in exists. In CI or another headless environment, set `HEPHAESTUS_AUTH_AUTOPOPUP=0`.

Required MCP sequence

Use the Agentlas Core Workforce contracts in this order:

workforce.search_candidates(sourceScope="network")
workforce.validate_selection(workOrder=..., candidateSet=federationResult.candidateSet, selection=..., federationResult=...)
workforce.prepare_execution(workOrder=..., candidateSet=federationResult.candidateSet, selection=..., federationResult=..., federatedSelection=..., projectDir=..., goalId=activeGoalId?)

The source-internal `workforce.fetch_runtime_bundle` call is performed by Core from the pinned original source session/digest. The host must not call it directly or replace it with a slug/`latest` lookup.

The current CLI equivalent is `workforce search --scope network`. A host adapter that does not yet expose typed `sourceScope` must report that wiring gap; it must not silently call public Hub-only search and label it Network. Do not call the legacy lexical router first. Do not turn install count, ratings, invocation history, source precedence, or a deterministic top score into the staffing decision. If a source is unavailable, preserve its finite failure receipt.

1. Perform job analysis

Act as the active top-level orchestrator. Convert the user's task into one redacted `agentlas.workforce-work-order.v1` object. Keep raw local files, secrets, memory, and private prompt details on the host. Create one `roleSlots` entry per materially distinct responsibility. Each slot identifies:

  • role/community and required skill or knowledge concepts;
  • required MCP/tool capabilities;
  • consumed and produced artifact kinds;
  • runtime, language, modality, and entity-kind constraints;
  • required and forbidden authority;
  • cardinality, criticality, and collaboration edges;
  • the minimum evidence level: declared, checked, demonstrated, or attested.

Do not create decorative roles. A single specialist is valid for a genuinely single-role task; a composite task should become a real temporary task force. Executable slots allow only `agent` or `team`; `group` is discovery-only until an authoritative group execution contract exists.

The user never has to write the word `goal` or enable a goal mode. Before a new search, call `workforce.goal_context` for the current project. If an active binding is the same ongoing work, treat its `goalId` and roster as incumbent. Only create a new WorkOrder when no active binding covers the work or the incumbent has a real gap.

2. Retrieve the menu, then make the LLM decision

Before calling any remote source, run the installed deterministic WorkOrder boundary over every schema-declared string and structured identifier, including nested roles, skills, tools, authorities, artifacts, edges, runtime/language, and policy fields—not only prose fields. A path, personal/account identifier, credential URL, private concept identifier, or secret-like value returns only path/class repair evidence with `hubCalls=0` and a null rejected-object digest; never trust the model's `redacted=true` assertion, mutate the object, echo the rejected value, or compute/display a digest over rejected data. Ask Core for `sourceScope="network"` only after that boundary accepts. Each source returns a broad content-only menu; Core validates and unions them using canonical identity ordering. It performs no semantic rerank. Read the exact roles, skills, MCP tools, inputs/outputs, authority, eval evidence, communities, release version, package hash, content digest, source receipt, and provenance.

Source precedence is not ranking. It applies only when the same `agentDefinitionId` has verified identical lineage issuer/digest and the exact same release version, package hash, content digest, and entity kind at multiple sources. Then and only then shadow Local > Cloud > Hub. Similar names/slugs are never deduplicated. Missing lineage or different releases fail closed for that collided identity: Core quarantines the ambiguous definition and preserves unrelated Local/Cloud/Hub candidates with finite aggregate conflict evidence.

You, the active host LLM, choose the ideal roster. Consider complementary coverage and handoffs, n

Read more
Ships withagentlas-os

Agent OS: keep specialist agents in a hub, spin up a temporary orchestrator per task. Local-first, works with any model.

Get the whole plugin

Other skills on agentlas-os.