/hep-graph

description: Build an Agentlas automation by describing it, list saved ones, or request a run.
argument-hint: '[new <what you want> | list | show <name> | run <name>]'
allowed-tools: Bash, Read

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

/hep-graph

Saved automation graphs live in the local Agentlas database, shared with the desktop app. This command reads that database and can ask for a graph to run.

Raw arguments: `$ARGUMENTS`

**What this command can and cannot do.** It lists graphs, shows what a graph does, and *requests* a run. It does not execute the graph — the desktop app is what runs it. Say that plainly when you report back; do not tell the user their automation ran.

Locate the CLI

CLI=""
for candidate in \
  "$(command -v agentlas 2>/dev/null)" \
  "$HOME/.agentlas/runtime/current/bin/agentlas" \
  "./bin/agentlas"
do
  if [ -n "$candidate" ] && [ -x "$candidate" ]; then CLI="$candidate"; break; fi
done
[ -n "$CLI" ] || { echo "Agentlas CLI not found. Install it with: npm i -g agentlas" >&2; exit 1; }

New — build one by talking it through

With `new <what they want>` (or when the user describes an automation they want and no saved graph matches), run the CLI's interview. **It asks the user things it must not decide for them** — when it runs, whether a step goes outside, how many times a repeat may run.

The CLI reads answers from stdin, one per line. So: run it once with no answers to see the first questions, relay them to the user **in their own words**, get their answers, then run it again with every answer so far:

printf '%s\n' "<answer 1>" "<answer 2>" "y" | "$CLI" graph new "<what they want>"

Rules that matter here:

• **Never invent an answer.** If the user has not said when it runs, ask them — do not pick

a time. The whole point of the interview is that these come from the person.

• The interview **proposes a grading checklist** for steps that repeat until good enough

(what must exist / what must not appear). Relay those items so the user can confirm or edit them — they are the pass/fail criteria, and the person should see them before saving.

• If the user does not know or says you decide, pass that through verbatim

(`알아서 해주세요` / `you decide`). The CLI then takes the most conservative option and says what it chose. Do not decide on their behalf yourself.

• The last line must be `y` to save. Until then nothing is written.
• It is created **switched off**. Say so, and relay the two commands the CLI prints

(`graph show` to look it over, `automation on` to turn it on).

• If the CLI stops with "answer 를 받지 못해 멈췄습니다" / "Stopped without an answer to",

it needed one more answer. Relay that exact question to the user and run again with the fuller list. Do not retry with a guess.

List

With no arguments, or with `list`:

"$CLI" graph list

Report each graph with its trigger kind (schedule or input), step count, and whether it is on. If nothing is saved, say so and point at the desktop app's Graph page — do not invent graphs.

Show

With `show <name>`:

"$CLI" graph show "<name>"

The output is a tree, not a list — indentation is the wiring. Relay it as wiring, because on a surface with no canvas this is the only way the user can see where a graph branches. These marks must survive into your summary: a step that **changes something outside**, a step that **asks first**, a branch's `[yes]`/`[no]` sides, a `↩ back to …` line (a repeat), a **checklist** under a verification step (the `· [must] / [must not]` lines — those items are exactly what the result is graded on), and a **code** step (a script the AI wrote runs there, not a model prompt). If the graph starts from a value the user provides, the output says so — carry that into the summary too.

Run

With `run <name>`:

1. Run `"$CLI" graph show "<name>"` first and show the user what the graph does, including any step that changes something outside. 2. Ask the user to confirm. Never skip this — requesting a run is an outward-facing action on the user's behalf.

• A scheduled graph: ask "run it now?".
• A graph that starts from a value (`graph show` says so): ask the user for

that value in their own words. Do not invent one, and do not reuse an example from the graph — an automation started from a value you made up produces work the user never asked for. 3. Only after an explicit yes:

"$CLI" graph run "<name>" -y

If the graph starts from a value, pass it — without it the CLI refuses, because a graph run with a blank value silently produces something else:

"$CLI" graph run "<name>" -y --input "<the value the user gave>"

Report exactly what the CLI reported: the run was **requested**, the desktop app picks it up within a minute while open, and a closed app runs it on next open. If the CLI refuses because the automation is switched off, relay that refusal and its reason rather than retrying.

Failure

If the CLI exits non-zero, show its message verbatim and stop. Do not substitute a guess about why, and do not retry a run request.