ase-meta-workflow

@${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 constructs, the skill conventions, and the option parsing used below. Do not proceed before you have done this. </preamble-block> </if>

  <else> Emit the *single* line ``!`ase util meta control skill getopt` `` as the first body line. </else>

• Identification: a <purpose name="<new-skill-name/>"> block carrying a short title-case purpose.

• Argument Parsing: an <expand name="getopt" arg1="<new-skill-name/>" arg2="<spec/>">$ARGUMENTS</expand> block -- but only when the workflow wants to declare options.

• Objective: an optional <objective/> block declaring the official objective of the workflow skill.

• Body: usually the <flow> derived in STEP 3 below. But everything is allowed here.

Procedure

<flow>

1. <step id="STEP 1: Reason About Workflow">

   1. Set <new-skill-name/> to the first whitespace-separated token of <getopt-arguments/> and <workflow-description/> to the entire remainder. Do not output anything.

   2. <if condition="<new-skill-name/> does not match the regexp `^[a-zA-Z][a-zA-Z0-9_-]*$`"> Ask the user interactively, without a special tool, for the skill name with a single question:

      **No valid skill name given. What should the generated skill be named?**

      Then set <new-skill-name/> to the response of the user and set <workflow-description/> to the entire original <getopt-arguments/>. Repeat this question until the response matches the regexp ^[a-zA-Z][a-zA-Z0-9_-]*$, so that no path separator or traversal segment can ever reach <target-skill/>. </if>

   3. <if condition="<workflow-description/> is empty"> Ask the user interactively, without a special tool, for the workflow with a single question:

      **No workflow description yet. Which workflow should the skill perform?**

      Then set <workflow-description/> to the response of the user. </if>

   4. Determine the skill locations of the current agent tool, because every agent tool discovers its skills in its own directories:

      <skill-dir-user>/.claude/skills</skill-dir-user> <skill-dir-local>.claude/skills</skill-dir-local> <if condition="<ase-agent-tool/> is `copilot`"> <skill-dir-user>/.copilot/skills</skill-dir-user> <skill-dir-local>.github/skills</skill-dir-local> </if> <if condition="<ase-agent-tool/> is `codex`"> <skill-dir-user>~/.codex/skills</skill-dir-user> <skill-dir-local>.agents/skills</skill-dir-local> </if>

      <if condition="<getopt-option-scope/> is equal `user`"> Set <dir><skill-dir-user/></dir>. </if> <else> Set <dir><skill-dir-local/></dir>. </else>

      Expand a leading ~ in <dir/> into the absolute home directory of the user, as the file tools accept absolute paths only. Then set <target-skill><dir/>/<new-skill-name/>/SKILL.md</target-skill>. Do not output anything.

   5. Check whether <target-skill/> already exists.

      <if condition="<target-skill/> exists and <getopt-option-force/> is not equal `true`"> Only output the following <template/> and then immediately *STOP* processing the entire current skill: <template> ⧉ **ASE**: ✪ skill: **ase-meta-workflow**, ▶ ERROR: target already exists: **<target-skill/>** </template>

      Directly after this error <template/>, and before stopping, give the corrective hint by expanding the following:

      <ase-tpl-hint level="minimal"> Re-run with `--force`/`-f` to overwrite the existing skill. </ase-tpl-hint> </if>

   6. Report the workflow with the following <template/>:

      <template> ⧉ **ASE**: ✪ workflow: **<new-skill-name/>**, ⎈ tool: **<ase-agent-tool/>**, ◉ target: **<target-skill/>** ⧉ **ASE**: ✪ workflow: **<new-skill-name/>**, ⇌ description: **<workflow-description/>** </template>

   7. Do not output anything else in this STEP 1, unless you asked the user.

   </step>
2. <step id="STEP 2: Internalize ASE Capabilities">

   1. Absorb the <catalog/> to know which ASE skills exist and which options and arguments each of them accepts.

   2. Absorb the <graph/> to know which ASE skill sequences are usually meaningful, and treat every transition it does not list as merely unusual, never as forbidden.

   3. Do not output anything in this STEP 2.

   </step>
3. <step id="STEP 3: Derive Workflow Structure">

   1. Decompose <workflow-description/> into an ordered list of top-level actions. Each top-level action becomes a numbered list item wrapping a <step id="STEP <n/>: <title/>"> element, and all of them together are wrapped into a single <flow> element.

   2. Map every action of <workflow-description/> onto the matching control construct:

      • sequential actions become consecutive <step/> elements,
      • concurrent actions become a <parallel> element,
      • sub-agent invocations become <agent/> elements,
      • ASE skill invocations become <skill name="ase:ase-xxx-xxx" args="..."/> elements, whose options and arguments are taken verbatim from the <catalog/> and never invented,
      • foreign skill invocations become <skill name="..." args="..."/> elements, whose options and arguments are taken verbatim,
      • repetitions become <while/> or <for/> elements,
      • conditional actions become <if/>/<elseif/>/<else/> elements,
      • all remaining actions become plain instruction prose inside their <step/>.

      Every top-level <skill/> element -- one which is not already placed inside an <agent/> element -- MUST be enclosed in its own dedicated <agent/> element, always without an isolation attribute and always with run_in_background=false, because the TaskCreate and TaskUpdate tool calls of the called skill would otherwise interfere with the task tracking of the generated workflow skill itself.

   3. For every <parallel> element which contains at least one <agent isolation="worktree">, you MUST append a dedicated consolidation <step/> directly after the <step/> holding that <parallel> element, and this consolidation step MUST contain an <agent-consolidation/> element, so the Git WorkTrees of the concurrent sub-agents are merged and removed again.

   4. Determine the options of the generated skill: declare an option only when <workflow-description/> actually asks for it, and express it in the --<long/>[|-<short/>][=<default/>|=(<c1/>|<c2/>|...)[...]] spec syntax of the getopt definition, which also covers the fixed choice form and the comma-separated list form.

   5. Do not output anything in this STEP 3.

   </step>
4. <step id="STEP 4: Generate Workflow Skill">
   1. <if condition="<ase-project-boxing/> is not equal `black`"> Set <structure/> to a compact rendering of the derived workflow -- one line per `<step/>`, prefixed with its number, and one indented line per contained `<parallel/>`, `<agent/>`, `<skill/>`, or `<agent-consolidation/>` element -- and report it with the following <template/>: <template> <ase-tpl-boxed title="WORKFLOW" subtitle="<new-skill-name/>"> <structure/> </ase-tpl-boxed> </template> </if>

   2. Assemble <skill-content/> from the derived workflow, strictly following the Generated Skill Contract above.

   3. Write <skill-content/> to <target-skill/>, creating the directory <dir/>/<new-skill-name/> if it does not exist yet. Then call the ase_text_metric(file: "<target-skill/>") tool of the ase MCP server and set <words/> to the words field of its result.

   4. Report the result with the following <template/>:

      <template> ⧉ **ASE**: ✪ workflow: **<new-skill-name/>**, ✎ skill: **<words/>** words, ▶ status: **skill generated** ⧉ **ASE**: ✪ workflow: **<new-skill-name/>**, ◉ files: **<target-skill/>** </template>

   5. Give the follow-up pointer, dispatched on <ase-agent-tool/>, because every agent tool reloads and invokes its skills differently, by expanding the following:

      <if condition="<ase-agent-tool/> is `copilot`"> <ase-tpl-hint level="minimal"> Run `/skills reload` to reload all skills. Run `/<new-skill-name/>` to execute the newly generated workflow. </ase-tpl-hint> </if> <elseif condition="<ase-agent-tool/> is `codex`"> <ase-tpl-hint level="minimal"> Run `/skills` to check that the new skill was picked up. Mention `$<new-skill-name/>` to execute the newly generated workflow. </ase-tpl-hint> </elseif> <else> <ase-tpl-hint level="minimal"> Run `/reload-skills` to reload all skills. Run `/<new-skill-name/>` to execute the newly generated workflow. </ase-tpl-hint> </else>

   6. Do not output anything else in this STEP 4.

   </step>

</flow>