Ase Meta Workflow

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

$ARGUMENTS

References

• The following is a reference skill demonstrating the usual layout of a generated workflow skill -- its frontmatter, its ase meta preamble, and the indentation of its <flow>:

  IMPORTANT: 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 as defined by the Generated Skill Contract below.

• The following 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):

  The 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 does not list.

• The following 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:

Generated Skill Contract

A generated skill is a regular skill of the current 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 :

• Preamble: the generated skill has to pull in the ASE meta definitions through the ase 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 :

  IMPORTANT: Before anything else, run the shell command...

  ase 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.

• 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

1. 1. Set to the first whitespace-separated token of and to the entire remainder. Do not output anything.

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

      Then set to the response of the user and set to the entire original . 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 .

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

      Then set to the response of the user.

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

      ~/.claude/skills .claude/skills

      Then set //SKILL.md. Expand a leading ~ in into the absolute home directory of the user, as the file tools accept absolute paths only. Do not output anything.

   5. Check whether already exists.

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

   6. Report the workflow with the following :

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

2. 1. Absorb the to know which ASE skills exist and which options and arguments each of them accepts.

   2. Absorb the 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.

3. 1. Decompose 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 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 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 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.

4. 2. Assemble from the derived workflow, strictly following the Generated Skill Contract above.

   3. Write to , creating the directory <dir/>/<new-skill-name/> if it does not exist yet. Calculate the number of words of .

   4. Report the result with the following :

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

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