/ase-meta-workflow

name: ase-meta-workflow
argument-hint: "[--help|-h] [--scope|-s local|user] [--force|-f] <skill-name> <workflow-description>"
description: >
    Generate a new agent tool skill, written in the style of ASE
    skills, which orchestrates a workflow of sequential actions,
    parallel actions, sub-agent calls, and skill calls. Use when the
    user wants to "generate a skill", create a "workflow", "orchestrate"
    or "chain" multiple ASE skills, or automate a recurring multi-step
    procedure.
user-invocable: true
disable-model-invocation: false
effort: xhigh
allowed-tools:
    - "Read"
    - "Write"

@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md

<purpose name="ase-meta-workflow"> Generate a Workflow Skill </purpose>

<expand name="getopt" arg1="ase-meta-workflow" arg2="--scope|-s=(local|user) --force|-f"> $ARGUMENTS </expand>

<objective> *Generate* a new skill for the current *agent tool* <ase-agent-tool/>, written in the style of *ASE* skills, which orchestrates the workflow described by: <arguments><getopt-arguments/></arguments> </objective>

References ----------

• The following <sample/> is a *reference skill* demonstrating the

usual *layout* of a generated workflow skill -- its frontmatter, its `ase util meta` preamble, and the indentation of its `<flow>`:

<sample> @${CLAUDE_SKILL_DIR}/sample.md </sample>

*IMPORTANT*: <sample/> is authoritative for the usual *layout* only. The *syntax* of every control construct is defined *exclusively* by the `Control Flow Constructs` section above, and its frontmatter and preamble show the `claude` flavor only -- the actual frontmatter fields and the actual preamble are dispatched on <ase-agent-tool/> as defined by the `Generated Skill Contract` below.

• The following <graph/> is the *ASE workflow graph*, carrying one

`<from/> -> <to/>` transition per line, where each side is either an `ase-xxx-xxx` skill or an upper-case logical state (`START`, `SKETCH`, `APPROACHES`, `TASK`, `ARTIFACT`, `END`):

<graph> @${CLAUDE_SKILL_DIR}/workflow.txt </graph>

The <graph/> tells which ASE skill sequences are *usually meaningful*. It *guides* the workflow, but it does *not* restrict it: a workflow may contain arbitrary *non-ASE* actions, and it may contain ASE transitions the <graph/> does not list.

• The following <catalog/> is the *accumulated help* of all ASE skills --

the concatenation of every skill's `help.md` file -- and is the *sole* source for the options and arguments of every `<skill/>` invocation (for an `ase-xxx-xxx` skill) you emit:

<catalog> @${CLAUDE_SKILL_DIR}/../ase-help-intent/data.md </catalog>

Generated Skill Contract ------------------------

A generated skill is a *regular* skill of the current agent tool <ase-agent-tool/> which is *independent* of the *ASE plugin* installation path. It therefore *MUST* strictly follow this contract:

• **Frontmatter**: `name: <new-skill-name/>` and a `description` of one

to three sentences summarizing the workflow and its trigger phrases.

The *remaining* frontmatter fields are *tool-specific*, because every agent tool accepts its own field set and its own `allowed-tools` grammar, and hence have to be dispatched on <ase-agent-tool/>:

<if condition="<ase-agent-tool/> is `codex`"> Emit *only* an `allowed-tools` field, carrying the space-separated string `Bash(ase util meta *)`, because *OpenAI Codex* accepts *no* frontmatter fields besides `name`, `description`, `license`, `allowed-tools`, and `metadata`. </if>

<elseif condition="<ase-agent-tool/> is `copilot`"> Emit an `argument-hint` derived from the declared options and arguments, plus `user-invocable: true`, `disable-model-invocation: false`, and an `allowed-tools` list which *always* contains `"shell(ase:*)"` plus any further tool the workflow actually uses. *IMPORTANT*: *GitHub Copilot* uses the permission pattern grammar `shell(<command/>:*)`, `write(<path/>)`, and `<mcp-server/>(<tool/>)` -- a `Bash(...)` entry would be misread as an unknown MCP server, and plain tool names like `Skill` or `Agent` are *no* permission patterns at all and hence *MUST NOT* be emitted. </elseif>

<else> Emit an `argument-hint` derived from the declared options and arguments, plus `user-invocable: true`, `disable-model-invocation: false`, and an `allowed-tools` list which *always* contains `"Bash(ase util meta *)"` plus `"Skill"` and/or `"Agent"` whenever the workflow emits `<skill/>` and/or `<agent/>` invocations, plus any further tool the workflow actually uses. </else>

• **Preamble**: the generated skill has to pull in the ASE meta

definitions through the `ase util meta` command, because it resolves them from the bundled tool package, whereas the `@${CLAUDE_SKILL_DIR}/../../meta/` includes used *inside* the ASE plugin have *no* resolvable path from outside of it. Append further meta names only when the workflow needs them (`dialog` for a `custom-dialog`, `tenets`, `format-task`, ...).

*How* the command is pulled in is *tool-specific*, because only *Anthropic Claude Code* expands the ``!`<command/>` `` construct before the skill content reaches the model, hence dispatch on <ase-agent-tool/>:

<if condition="<ase-agent-tool/> is `copilot` or `codex`"> Emit the following <preamble-block/> as the first body element, because the ``!`<command/>` `` construct would otherwise reach the model *verbatim* and silently stay unexpanded:

<preamble-block> *IMPORTANT*: *Before* anything else, run the shell command...

`ase util meta control skill getopt`

...and treat its *entire* output as if it were written here. It defines the control flow construct