| name | hep-storm |
| description | Run a force-robust Stormbreaker loop — route to real agents, execute a verified pipeline to completion. |
Update fallback: 자동 업데이트가 안 되면 hephaestus update를 한 번 실행하세요. 업데이트하지 않아도 현재 버전 명령은 그대로 동작합니다.
Hephaestus Stormbreaker loop
Raw arguments: everything the user typed after /skill:hep-storm.
Codex plugins cannot register slash commands, so this custom prompt is the
explicit entrypoint (/prompts:hep-storm). The same contract is also available
implicitly via the hep-storm skill. Also triggered by
@Hephaestus storm <goal>.
Drive a goal through the Stormbreaker Loop — Hephaestus' force-robust,
verifier-first execution loop. Unlike a one-shot answer or a generic parallel
fan-out, Stormbreaker routes the goal to real Agentlas specialists, structures
the work as a dependency-ordered pipeline fabric, drives each work packet as a
hardened goal loop (it does not stall, run away, or claim false success), and
refuses to report success without evidence. In an agentic runtime you are
the executor — the engine gives you the verified plan; you carry it out with
your own tools.
Use it for loop-worthy work: apps, sites, agents, automations, debugging,
multi-step research, data/report generation — anything with files, tools, tests,
or external verification. Trivial questions should be answered directly, not
stormed.
Core-owned Goal + UltraCode harness
Every result includes execution_harness. Apply
execution_harness.system_prompt verbatim before planning or executing any
packet, and retain its prompt_sha256 in the goal ledger. Do not redefine,
summarize, or replace Goal mode or UltraCode mode in this Codex adapter. If live
session JSON is available, expose it as AGENTLAS_SESSION_INVENTORY; otherwise
use Core's explicit host:primary fallback and do not invent workers or models.
With no external executor, status: materialized plus
final_gate.can_report_success: false is the expected handoff to Codex's native
tools, never a completed run.
1. Resolve the runner and materialize the execution fabric
Resolve the runner — first executable wins; runtime cache fallback:
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 \
"${CODEX_HOME:-$HOME/.codex}/plugins/cache/agentlas-core-engine/hephaestus" \
"$HOME/.claude/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
[ -n "$RUNNER" ] || { echo "Hephaestus runtime not found. Run the installer first." >&2; exit 1; }
if [ "${HEPHAESTUS_AUTH_AUTOPOPUP:-1}" != "0" ]; then
"$RUNNER" auth ensure --timeout 180 >/dev/null 2>&1 || true
fi
FABRIC="$("$RUNNER" hep-storm "$ARGUMENTS" --research-evidence --runtime codex)"
printf '%s\n' "$FABRIC"
Read route_decision.action (or route_action) and branch — Stormbreaker only
auto-materializes a full fabric for a pipeline; other actions still start a
storm, just with the workforce the router chose:
pipeline — the result carries the execution_fabric (packets,
parallel_groups, sessions, resume_policy), per-packet write_scope and
goal/verifier, a pipeline_id, a journal path, and final_gate criteria.
Run the full loop in §2.
clarify — the goal is ambiguous. Ask clarify_question with the candidate
list as ONE batch, then re-run "$RUNNER" hep-storm "<refined goal>". This is
the scope-lock ambiguity gate; do not guess past it.
route (single card) — a one-agent storm: borrow and run that card attached
to this project, then still apply the verify → repair → final-gate steps.
hub_fallback / hub_candidates — Hub lookup used redacted keywords only.
If an execution block lists recommended_agents, borrow each in stage order
via "$RUNNER" hep-call "<agent>" "<goal>" --project . and run them attached to
this repo; otherwise report candidates and offer /skill:hep-build.
propose_new — no fit exists; offer to build one via /skill:hep-build.
refuse — explain reasons (e.g. loop guard) and stop. Do not retry around
it.
2. Run the Stormbreaker Loop over the fabric
Execute the goal to completion under this protocol. Do not stop to ask for
confirmation — this is a force-robust run. Only halt when the goal is verified,
or you are genuinely blocked by auth, payment, policy, a missing secret/tool, or
a required user approval.
- scope-lock — Restate the goal as one sentence and lock to it. Check the
route decision's failure-memory. If (and only if) the goal is too ambiguous to
decompose safely, ask ONE batch of 3–5 questions (what NOT to do / smallest
version / done signal / dependencies), then proceed. If it is already specific,
ask nothing.
- issue contract — Write the acceptance criteria: the concrete, checkable
done-signal for each packet and for the whole goal. These become the loop's
stop criteria.
- plan-lock — Adopt the fabric's
parallel_groups and depends_on ordering
as the plan. Open a visible goal ledger: packet, owner, verification gate,
status, resume point.
- act — Execute the next unblocked group. Run independent packets in the
group concurrently where this runtime supports delegation. When a packet's
card names an Agentlas specialist, borrow and run it attached to this
project via "$RUNNER" hep-call "<card>" "<goal>" --project . rather than
role-playing it. Write artifacts to each packet's write_scope.
- verify — A packet passes only with separately attributable, validated
verification. A
loop.goal_command exiting 0 may end the goal loop, but it
cannot verify the executor's own output or self-attest success. Require an
independent verifier and hash-validated artifact evidence. "It ran" is never
success.
- bounded repair/retry — On a concrete validation failure, repair and re-run
that packet — bounded. Honor the goal-loop budget: tolerate transient failures
with backoff, stop a packet as
stalled after consecutive no-progress
iterations, and never exceed its iteration ceiling. A resumed run continues
from the journal, it does not restart.
- final-gate — Report success only if the fabric's final gate clears
(
can_report_success). Run the evidence/security gate on produced artifacts.
Keep visible progress concise: what was attempted, what was verified, and
exactly where to resume if blocked. Never expose hidden reasoning — show
progress, evidence, decisions, and final status only.
3. Loop invariants (why this beats a one-shot loop)
- Don't break (안 끊기게): a transient packet failure is journaled and retried
with backoff, not fatal. Only a genuine streak of hard failures stops the run.
- Don't run away: a hard iteration ceiling plus stall detection — measured
no-progress stops the loop as
stalled instead of spinning.
- Keep the goal until done (될 때까지): the loop reports
reached_goal only
when the verifier proves it. No bare "it ran" ever counts.
- Survive a hard stop: every packet is a journal step, so a killed run resumes
its numbering from the journal instead of colliding or restarting from zero.
4. Hard rules
- No fake pass. If the engine is unavailable, an account/tool/connector/browser
session is missing, or a gate did not run, report the run as blocked or
unverified with the exact next step — never as complete. A scheduled or
materialized run is not proof that an external action succeeded.
- The router only chooses agents and fetches BYOM bundles. Actual tool execution
follows this runtime's own safety and permission model.
- Report the
receipt_id, pipeline_id, and journal path in your final message
so the run is auditable and resumable.
Examples
/prompts:hep-storm ship a working waitlist landing page with a verified signup flow
/prompts:hep-storm 이 리포 결제 버그를 재현 PoC까지 만들어서 고치고 회귀 테스트로 검증해줘
@Hephaestus storm turn this research question into a cited report with evidence