genie-editor-cli-workflow

Internal Genie Editor Workflow

Use this skill to handle Genie editor to-dos in the internal host environment: first read the backlog, then modify the code, and finally write back the status and review.

For command templates, field descriptions, and common errors, see references/cli-reference.md。

Internal environment boundaries

• By default, face the internal page host.
• When selecting a client, prioritize looking at channel、pageUrl、sessionId, explicitly provided targetClientId and editor.* capabilities.
• The entire task consistently uses the same set of channel + targetClientId。

Main flow

1. First run npx @axhub/genie status --json. If the service is not up or the command is unavailable, directly explain the blocker.
2. Run editor clients list --channel <channel> to find the target client. Prioritize matching pageUrl、sessionId, explicit client id, and editor.* capabilities.
3. First do a global scan:editor snapshot + editor nodes list --status pending-dispatch,dirty. If there is no backlog, return truthfully.
4. Before handling a node, first editor editing set --state editing. Keep a stable providerfor the same task, and use a unique taskRequestId。
5. Only supplement context when needed: for page-level reference use context-images export, and when node positioning is unclear use node screenshot. Treat exported local images as auxiliary evidence; do not force a one-to-one mapping.
6. After modifying the code, read at least one more round of snapshot and nodes list --status pending-dispatch,dirty,error,editing。
7. Every claimed node must be written to a terminal state: success completed, failure error, interrupted or abandoned idle。

Multi-node parallel strategy

• Nodes in the same UI block should be merged first to reduce repeated scanning and verification.
• Truly independent nodes can modify code in parallel, but client selection, node claiming/releasing, and final review should be uniformly handled by the main agent.
• When the node position has not yet been determined clearly, do not rush to parallelize.

Rules

• Do not conflate "code modification complete" with "backlog consumed"; if the node is still dirty or pending-dispatch, explain both the code status and the backlog status.
• When the service is offline, the client is wrong, capabilities are missing, screenshots fail, or nodes cannot be located, report the problem directly; do not fake completion.
• Do not leave claimed nodes without a terminal state.

Delivery requirements

The final reply must include at least:

• The channel + targetClientId
• Handled in this round elementKey
• Terminal state of each node
• Which files were modified
• What verification was done
• Which nodes are still unhandled or have abnormal status