Agent skill

Hep Network

by agentlas-ai in agentlas-ai/Agentlas-OS

Staff a task from registered Local, owner Cloud, and public Hub agents.

Apache-2.0Auto-check passedAgent Workflows

Install Hep Network

skills CLI
$ npx skills add agentlas-ai/Agentlas-OS --skill hep-network -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install agentlas-ai/Agentlas-OS hep-network --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/agentlas-ai/Agentlas-OS.git skills-src && mkdir -p .claude/skills && cp -r skills-src/kimi/skills/hep-network .claude/skills/hep-network && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
hep-network
GitHub stars
1.6k
Token cost
~3.7k tokens
SKILL.md length
1,859 words
Files
1
Skills in repo
53
Repo updated
First seen
Licence
Apache-2.0

At a glance

Staff a task from registered Local, owner Cloud, and public Hub agents.

  • Works in 2 steps: Call workforce.preflight_work_order with… → Call workforce.search_candidates on…
  • Agent Workflows work in your project
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Hep Network is an agent skill from agentlas-ai/Agentlas-OS. Staff a task from registered Local, owner Cloud, and public Hub agents.

Its SKILL.md is about 3.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Agent Workflows. The repository describes itself as: Agent OS: keep specialist agents in a hub, spin up a temporary orchestrator per task. Local-first, works with any model. The licence is Apache-2.0.

When your agent uses it

  • Agent Workflows work in your project

Example prompts

  • “/hep-network”

Workflow steps

2 steps, taken from the first numbered list in SKILL.md.

  1. Call workforce.preflight_work_order with a compact draft: taskBrief,
  2. Call workforce.search_candidates on hephaestus-network with

What it can do on your machine

Read from SKILL.md and the folder at commit 6254906. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are bash).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Hep Network loads about 3.7k tokens when it runs. Until then it costs about 21 tokens; SKILL.md has 1,859 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~21
When it runs · the whole SKILL.md, loaded when a task matches
~3.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from agentlas-ai/Agentlas-OS at commit 6254906, republished under its Apache-2.0 licence (© agentlas-ai). 1,859 words, ~3,696 tokens.

Download SKILL.mdSave it as .claude/skills/hep-network/SKILL.md (or your agent's skills folder).
name
hep-network
description
Staff a task from registered Local, owner Cloud, and public Hub agents.

Update fallback: 자동 업데이트가 안 되면 hephaestus update를 한 번 실행하세요. 업데이트하지 않아도 현재 버전 명령은 그대로 동작합니다.

/hep-network

Raw request: $ARGUMENTS

You are the active top-level workforce orchestrator. Use the local Agentlas OS MCP server named hephaestus-network, the only host-visible Workforce MCP. Core reaches Cloud and Hub through its internal upstream client. Network means all registered Local agents, the signed-in owner's Cloud agents, and public Hub agents.

Before every unpinned discovery, Core refreshes the current safe snapshot for each active registered Local source. A changed Local folder therefore becomes a new candidate release in this search without requiring network reindex; the selected and prepared release remains immutable after that discovery.

The user does not need to say goal. First call workforce.goal_context for the current project, passing knownRevisions with any goalId -> rosterRevision pairs already in this conversation so unchanged goals come back as one line. If it returns an active binding for this ongoing work, reuse that exact roster and goalId before considering recruitment. If it returns pendingExecution, those releases were prepared and never run: either run them now or say so plainly — preparation is not delivery, and the session-end checkpoint reports the same fact to the user.

Before the first Cloud or Hub source call, reuse the installed Agentlas sign-in. Resolve the runner in this order for authentication and supported host-adapter execution; the host LLM still staffs through Workforce MCP tools:

bash
RUNNER=""
for candidate in \
  "$HOME/.agentlas/runtime/current/bin/hephaestus" \
  "${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/bin/hephaestus}" \
  "${PLUGIN_ROOT:+$PLUGIN_ROOT/bin/hephaestus}" \
  "${GEMINI_EXTENSION_ROOT:+$GEMINI_EXTENSION_ROOT/bin/hephaestus}" \
  "./bin/hephaestus"
do
  if [ -n "$candidate" ] && [ -x "$candidate" ]; then RUNNER="$candidate"; break; fi
done
[ -n "$RUNNER" ] && "$RUNNER" auth ensure >/dev/null 2>&1 || true
  1. Call workforce.preflight_work_order with a compact draft: taskBrief, one roles entry per materially distinct responsibility, and edges by 1-based role ordinal. Core compiles the exact redacted agentlas.workforce-work-order.v1, generates every transaction/slot/artifact id, fills omitted arrays, validates the privacy boundary and returns a one-hour workOrderRef. Write required skills as plain English phrases when no ontology id is obvious — Core normalizes them and reports each rewrite as normalizedConcepts. Give each role a specific task, cardinality, criticality, and — only when they genuinely constrain semantic fit — required communities/roles/skills/ knowledge. The title, task, publisher summary, and sample request sentences remain the primary fit evidence. Execution requirements are a separate contract: include requiredToolCapabilities, required/forbidden authorities, runtimes, languages, or modalities only when the requested action genuinely requires the host to prove them. They do not rank or exclude semantic candidates; Core carries them unchanged into the ExecutionContext, where the host must bind its actual tool inventory and permission receipt. Leave every unconstrained list absent (the wire normalizes absent to []). Keep consumes/produces absent and describe ordinary inputs/outputs in the task text and inter-slot handoffs in edges. An edge is a declaration of handoff and never a qualification requirement. Only semantic communities, roles, skills, and knowledge explicitly required by the task may narrow menu fit. Tool capability, authority, runtime, language, and modality fields never filter or rank that menu; they remain post-selection execution proof. Hand-off edges must be acyclic: a review or feedback edge that points back to an earlier slot is rejected as task_force_cycle:<the loop path> — model review as a forward hand-off to the reviewer, not a back-edge (measured 2026-08-19: a researcher→research→quality-engineer order with a reviews back-edge was refused, and because edges live inside the WorkOrder the repair changed workOrderDigest and forced the whole three-source federation to run again). Keep the default selectionPolicy.maximumCandidatesPerSlot at 30 unless a measured recall need justifies widening it (the schema allows up to 100), and never shrink it yourself to save tokens. The Hub and Cloud sources already shrink safely: they order each slot by fit with a decision model and, for a default-sized menu, send only their best 8. Measured 2026-09-24 on 40 live work orders: fit order put the right agent first 40/40, while in the unranked order it sat in the first 8 only 11/38 times — the menu bytes per slot fell 73%. Core still presents the merged menu in canonical_identity_no_rerank order and Local candidates are not fit-ranked, so a smaller cap you set would cut rows arbitrarily, not worst-first. When a slot needs more rows, set the maximum above 30: the sources then return that many, still in fit order. In the returned menu, candidateOrdinal restarts at 1 inside every slot — it is a per-slot position, not a running number across the menu. Keep private files, memory, secrets, direct identifiers, and raw local context on-host. Write every discovery-facing natural-language field (statement, role descriptions, required skills/knowledge) in English, faithfully translating a non-English request rather than passing its original wording through: the candidate corpus is English and cross-lingual matching silently buries the correct agent (measured: an identical query ranked its target 1st in English and 144th in Korean). Keep an untranslatable proper term alongside a short English gloss, e.g. 종합소득세 (Korean comprehensive income tax). The languages slot is the delivery requirement, not the search language — set it to the language the work product must be produced in (e.g. ko) even though the order itself is written in English.
  2. Call workforce.search_candidates on hephaestus-network with {workOrderRef, sourceScope: "network"}. Preserve every source receipt and selectionSessionId; the default projected menu is not a complete federationResult and must not be echoed as one. An unavailable source is explicit; it is not permission to pretend that source participated. 2b. For a multi-slot search, call it with shortlist: true. The response then carries summary cards (ordinal, name, entityKind, communities, one summary, callable, missingMandatory, and publisherTriggerMatch when the publisher's own trigger sentences match this request) instead of full dossiers — measured 40,873B -> 10,087B for one 20-candidate slot. Narrow to the candidates worth a closer look, then call workforce.expand_candidates with {selectionSessionId, candidates:[{slotId, candidateOrdinal}]} and decide from those full cards, never from the summary alone. Keep the shortlist generous (six to eight per slot): the summary is for discarding the obviously wrong, not for picking the winner.
  3. As the active host LLM, decide the staffing from the returned content and qualification evidence, then call workforce.validate_selection with {decision}: selectionSessionId, decisionAuthor (your real model id), and one assignments row per post naming the candidate by its per-slot candidateOrdinal with reasonCodes. Core loads the pinned menu and the pinned WorkOrder from that session, supplies the candidate-set digest and the arrays that are empty in a normal decision, and compiles the exact agentlas.workforce-selection.v1. Keep the accepted response's federatedSelectionDigest. Revise on rejection. Deterministic code may enforce governance but must not choose, rerank, or silently substitute the roster. An accepted result may still carry unmetRequirementCount — that is not a rejection, but read selectionValidation.unmetRequirements and either accept the gap deliberately or reselect. Never report an accepted validation as if nothing were unmet. Use public codes such as reason:best-content-fit, reason:best-contract-fit, and reason:host-semantic-judgment, or exact codes from the chosen candidate's pinned evidence. Do not invent reason vocabulary; omitted compact-decision reasons use reason:host-semantic-judgment.
  4. Call workforce.prepare_execution with {selection: {selectionSessionId}, federatedSelectionDigest, projectDir, goalId?, fullDossier: false}. Use both references from the same accepted validation response. Core restores only the exact digest-matching Selection from its pinned wrapper. The unchanged accepted wrapper under selection, the original exact Selection, or the same compact decision also works. If a legacy normalized receipt cannot restore the original bytes, resend that decision or exact Selection. References never reauthor or substitute an accepted choice. projectDir is mandatory. Pass the incumbent goalId when continuing; otherwise Core joins this project's incumbent active automatic goal, and opens a new one only when there is none. Core must automatically bind a successful preparation before execution, so continuity cannot be skipped because no explicit goal mode was requested. fullDossier: false requests the projected response (projection: "prepare.v2"): executionRoster rows carry identifiers and digests, and each worker's directiveBundle/executionGraph is shipped once per contentDigest in top-level bundleContents — resolve a row's content by its contentDigest there (a same-agent-two-slots roster would otherwise repeat the bundle byte-identically). The bound preparation stores the unprojected original. Omitting the flag returns legacy self-contained rows — the compatible default for machine verifiers that recompute bundleDigest over whole rows and update independently of the runtime. Require each worker to retain its exact source plus release, package hash, content digest, runtime-bundle digest, permission policy, and execution context pins. Recompute digests and fail closed on drift.
  5. On later turns call workforce.goal_context first: reuse the incumbent roster plus local skills when sufficient; recruit only a real gap and pass the same goalId to preparation so new releases append. Record reuse|local-only|recruit|standby|blocked with workforce.record_goal_turn.
  6. Before every bound invocation, advertise the live host sessions and call model.resolve_allocation with that inventory plus the host-owned stage: planner/manager-plan, worker, manager-synthesis/synthesis, or verifier. Use the receipt's exact provider, model, and effort for that invocation. Model pins and ceilings come only from the MCP server's operator policy, never from the task or tool arguments. A missing worker policy inherits orchestrator; orchestrator never falls through to worker. Each advertised session carries session_id, model, provider, and — when the host knows them — tier, supported_efforts, and context_window. Send what the host actually reports and never invent a field: an omitted context window is assumed at a conservative floor and the receipt says so (inventory_context_window_assumed), whereas a fabricated one would be read as measured. Operators set the orchestrator/worker policy with hep-orch orchestrator=<tier|model> worker=<tier|model>.
  7. Run only the bound workers useful for this turn. For a selected team, preserve its authoritative manager/worker graph. Run planner/manager, workers, synthesis, and verifier as distinct invocations with explicit artifact handoffs. Allocation receipts have usage: null before execution, so record actual usage on the later invocation/run receipt instead of inventing zero. If native child execution lacks the required enforcement, inspect the existing external-host transport before stopping at preparation: "$RUNNER" workforce execute --project <project> --goal-id <goalBinding.goalId> --adapter-argv-json '["/absolute/path/to/host-adapter"]'. This uses an explicitly selected available adapter, loads the original full bound preparation locally, orders distinct calls, snapshots artifact handoffs, and validates the resulting receipt. The adapter reads one agentlas.workforce-host-executor-request.v1 JSON request from stdin and writes one correlated agentlas.workforce-host-executor-response.v1 JSON response to stdout; its exact contract is in the installed engine's agentlas_cloud/workforce/host_executor.py. The adapter owns real model execution and measured policy enforcement; this command grants nothing and installs nothing. Check native execution and existing adapters, then use agentlas_resolve_plugins for a missing adapter. An adapter created within already authorized work uses this contract outside Core. An actually empty tool menu is valid for model-only work without required tool bindings; residual CLI authority cannot be reported as zero tools. If no route can enforce the policy, retain prepared and name that exact boundary.
  8. Report executed only when the execution receipt proves every selected invocation, handoff, synthesis, and an independent passing verifier. Otherwise report the last truthful state: selected, prepared, source_unavailable, blocked, or failed. For partial or failed, report each source receipt's exact failureCode: never collapse several receipts into one, substitute a different code, or relabel the outcome.
Show full SKILL.md (111 more words)Show less

Recurring Hub use

Public Hub packages are free to discover and call. Recurring work still uses the host's model, API keys, permissions, and scheduled execution capacity. Explain those prerequisites and obtain the user's scheduling instruction. Do not quote or purchase a retired Hub lease. The exact release remains bound to the goal until explicit completion or cancellation.

Do not call legacy hephaestus_route, register or use direct remote search as a substitute for Core federation, or use popularity/history/local availability as semantic fit. Exact duplicate releases may collapse Local > Cloud > Hub only when Core returns verified identical lineage; a name or slug match is not enough. Name the actual workers in the result.

© agentlas-ai, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in kimi/skills/hep-network of agentlas-ai/Agentlas-OS.

Open the folder on GitHubat commit 6254906

Compare with similar skills

Hep Network next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Hep Network compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Hep Network this skillagentlas-ai/Agentlas-OS1.6k—~3.7kAutomated safety check: PassApache-2.0
MCP Server Builderanthropics/skills180k63 repos~2.3kAutomated safety check: PassApache-2.0
Hook Development for Claude Code Pluginsanthropics/claude-plugins-official38k10 repos~4.1kAutomated safety check: NotesApache-2.0
Using Superpowersfarm-fe/farm5.6k35 repos~1.4kAutomated safety check: PassMIT
Executing Plans Inlineobra/superpowers297k2 repos~5.1kAutomated safety check: PassMIT
Skill CreatorAzure/azqr79589 repos~8.2kAutomated safety check: PassApache-2.0

Similar skills

  • MCP Server Builder

    anthropics/skills

    Official

    Guides the design and implementation of Model Context Protocol servers in TypeScript or Python, from tool naming and error messages to evaluation.

    180k GitHub starsUsed in 63 repos~2.3k tokens
    Agent WorkflowsAuto-check passed
  • Hook Development for Claude Code Plugins

    anthropics/claude-plugins-official

    Official

    Explains how to write Claude Code plugin hooks, both prompt-based checks and bash commands, for events such as PreToolUse, Stop and SessionStart.

    38k GitHub starsUsed in 10 repos~4.1k tokens
    Agent WorkflowsAuto-check: notes
  • Using Superpowers

    farm-fe/farm

    A skill your agent uses when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

    5.6k GitHub starsUsed in 35 repos~1.4k tokens
    Agent WorkflowsAuto-check passed
  • Executing Plans Inline

    obra/superpowers

    Has the agent carry out an implementation plan itself, task by task in the current session, keeping a ledger, proving each step with a test and ending with one whole-branch review.

    297k GitHub starsUsed in 2 repos~5.1k tokens
    Agent WorkflowsAuto-check passed
  • Skill Creator

    Azure/azqr

    Official

    Create new skills, modify and improve existing skills, and measure skill performance.

    795 GitHub starsUsed in 89 repos~8.2k tokens
    Agent WorkflowsAuto-check passed
  • Claude Code Agent Development

    anthropics/claude-plugins-official

    Official

    Explains how to write agents for Claude Code plugins: the markdown file with YAML frontmatter, trigger descriptions, model and color settings, and system prompt design.

    38k GitHub starsUsed in 7 repos~2.8k tokens
    Agent WorkflowsAuto-check passed

More from agentlas-ai/Agentlas-OS

All 53 skills in this repo
  • Agentlas Security Scan

    agentlas-ai/Agentlas-OS

    A skill your agent uses 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…

    1.6k GitHub stars~822 tokensUpdated yesterday
    Auto-check passed
  • Hephaestus Build

    agentlas-ai/Agentlas-OS

    A skill your agent uses when the user types /prompts:hep-build or /agentlas-build, mentions @Hephaestus for build work, asks to create a single Agentlas agent, create a multi-agent team, or package…

    1.6k GitHub stars~2.2k tokensUpdated yesterday
    Auto-check passed
  • Hephaestus Graph

    agentlas-ai/Agentlas-OS

    A skill your agent uses when the user types /hep-graph or asks to create, list, inspect, or request a run of an Agentlas automation graph.

    1.6k GitHub stars~498 tokensUpdated yesterday
    Auto-check passed
  • Hephaestus Upload

    agentlas-ai/Agentlas-OS

    A skill your agent uses when the user types $hephaestus-upload, /hep-upload, or /agentlas-upload, or asks to upload, publish, or list an Agentlas agent or team.

    1.6k GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed
  • Routing Card Authoring

    agentlas-ai/Agentlas-OS

    A skill your agent uses whenever a build emits or repairs .agentlas/routing-card.json — the shared card contract for the single-agent builder, the team builder, and the packager.

    1.6k GitHub stars~2.7k tokensUpdated yesterday
    Auto-check passed
  • Team Builder Packaging

    agentlas-ai/Agentlas-OS

    A skill your agent uses when generating or auditing a multi-role agent team package with orchestrator, PM Soul, Memory Curator, Policy Gate, workers, eval, QA, handoffs, and runtime adapters.

    1.6k GitHub stars~642 tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Hep Network

What does Hep Network do?

Staff a task from registered Local, owner Cloud, and public Hub agents. Hep Network is an agent skill from agentlas-ai/Agentlas-OS. Staff a task from registered Local, owner Cloud, and public Hub agents.

When should I use Hep Network?

Hep Network fits situations like: agent Workflows work in your project.

How do I install Hep Network in Claude Code?

Run `npx skills add agentlas-ai/Agentlas-OS --skill hep-network -a claude-code`. Or copy the skill folder (kimi/skills/hep-network in agentlas-ai/Agentlas-OS) into .claude/skills/hep-network in your project. Claude Code loads it when a task matches its description.

How do I install Hep Network in Codex?

Run `npx skills add agentlas-ai/Agentlas-OS --skill hep-network -a codex`. Or copy the skill folder (kimi/skills/hep-network in agentlas-ai/Agentlas-OS) into .agents/skills/hep-network in your project. Codex loads it when a task matches its description.

Can I use Hep Network in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add agentlas-ai/Agentlas-OS --skill hep-network -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/hep-network, .gemini/skills/hep-network, .github/skills/hep-network and .opencode/skills/hep-network in your project.

What does Hep Network need to run?

SKILL.md names no scripts, command-line tools or credentials: Hep Network is instructions for the agent only.

Does Hep Network access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Hep Network safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Hep Network use?

Hep Network is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Hep Network use?

About 3.7k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Hep Network?

Skills that share tags, products or a category with Hep Network: MCP Server Builder (anthropics/skills, 180k stars), Hook Development for Claude Code Plugins (anthropics/claude-plugins-official, 38k stars), Using Superpowers (farm-fe/farm, 5.6k stars) and Executing Plans Inline (obra/superpowers, 297k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Hep Network?

agentlas-ai (a GitHub organization) maintains it in agentlas-ai/Agentlas-OS, which has 1,582 GitHub stars. The repository holds 53 skills in this directory. The repository was last updated on October 8, 2026.

Source: agentlas-ai/Agentlas-OS on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.