actions

Actions: custom workflow-helper management

Contents

• Sub-commands — the verb → phase map
• What is a custom action?
• Loop invariants
• Anti-rationalization
• Definition of done
• Budgets — quality-first
• ACI per-phase tool surface
• Memory I/O
• Termination case → state mapping
• Phase 1 — parse intent
• Phases 2-7 — one pointer per sub-command (list / create / run / edit / delete / validate); the bodies live in sibling files
• Cross-references

Stateless loop: Parse → Execute → Done. Execute branches into exactly one of six sub-commands, so a run passes through Phase 1, one sub-command body, and the terminal report. CRUD frontend + runner over .geniro/actions/ — user-authored workflow-helper actions stored as plain Markdown files. Six operations: list, create, edit, run, delete, validate.

Sub-command bodies. Each sub-command's Steps live in ${CLAUDE_PLUGIN_ROOT}/skills/actions/subcommand-<verb>.md. Read the one Phase 1 dispatches to — the five it did not dispatch to are never read. Two procedures more than one sub-command needs are shared in ${CLAUDE_PLUGIN_ROOT}/skills/actions/actions-reference.md: §Target resolution (which action file to operate on) and §Validation gate (the create/validate checks).

Runtime portability. ${CLAUDE_PLUGIN_ROOT} is a path placeholder Claude Code substitutes into file references, never a shell export — it reads empty in a Bash call under every host, Claude Code included, so an empty probe is no evidence of another runtime (CLAUDECODE in the environment marks Claude Code). Resolve the root by working these in order: the ancestor directory of this file containing .claude-plugin/plugin.json; a copy of the referenced file sitting beside this one (the Cursor build ships each skill's own phase and reference files there); a plugin checkout inside the workspace. Substitute the resolved root for every ${CLAUDE_PLUGIN_ROOT} occurrence and export it as CLAUDE_PLUGIN_ROOT in every Bash call. Work the rungs with a command, not a judgment: the run's first Bash call lists the directory this file was read from and each candidate root, and its output is echoed verbatim before anything else. Read the rungs against that output — a path it does not show did not resolve, and a file it does not show cannot be read, however confidently a later step would report otherwise. A ladder that resolves is bookkeeping, not a finding: keep the echo to the probe output and the resolved root, and reserve a degraded-run notice for a rung that actually failed. Read ${CLAUDE_PLUGIN_ROOT}/skills/_shared/runtime-portability.md before deciding a step cannot run here: it substitutes mechanisms, not steps, and routes a host with no one to ask to ${CLAUDE_PLUGIN_ROOT}/skills/_shared/non-interactive-host.md. When no rung resolves, the files are missing but the contract is not — open your first message by naming what is unavailable, run every phase and gate this skill declares, never let the project's own rules stand in for its decision gates, and take no outward-facing action (ready-for-review PR, merge, force-push, protected-branch push, posted comment, tracker transition) without an explicit answer.