From a founder of the
Apache Software Foundation...

Agentic Software Engineering

Boost your daily productivity while
keeping yourself in the driver's seat!

Fuse Agentic AI Coding with
traditional Software Engineering!

Let the agent handle the chores while
you stay in control of the craft!

Various operation modes provided —
you choose the best for the job!

If you like ASE,
please support it
by giving a star!
Many thanks.

Agentic Software Engineering (ASE) is the opinionated Open Source toolkit of renowned and prolific author Dr. Ralf S. Engelschall, for fusing the concepts of Agentic AI Coding and traditional Software Engineering. ASE ships as a plugin for the software development tool Anthropic Claude Code CLI — and with reduced support also for the alternative tools GitHub Copilot CLI and OpenAI Codex CLI. It comprises agent hooks, parametrizable agent skills, an underlying Model-Context-Protocol (MCP) service, and a companion Command-Line Interface (CLI).

Dr. Ralf S. Engelschall in a
studio interview on ASE

ASE incorporates reasonable methodology and automation aspects to support the daily, recurring tasks of a Software Developer and Software Architect. The comprehensive functionality spans from brainstorming ideas, searching the Web, asking foreign LLMs, discovering components, through evaluating alternatives, challenging statements, analyzing root causes, managing tasks, grilling task plans, all the way to analyzing, fixing, refactoring, and crafting code, reviewing changesets, and many more.

Claude Code:

❯

Testimonials from Practitioners

How ASE holds up in the daily work of the Software Developers and Software Architects who fold it into their own engineering practice — in their own words.

ASE keeps me in the driver's seat while the agent does the chores.
— Dr. Ralf S. Engelschall

Thanks to Agentic AI Coding, developing software is fun again. ASE is a great added bonus here!
— Matthias Brusdeylins

After 40 years of traditional software development, ASE finally allowed me to make peace with today's Agentic AI Coding era.
— Dr. Ralf S. Engelschall

Finally, I get to work with a professional again. ASE is that long-awaited professional.
— Jochen Hörtreiter

I put all my methodology know-how and experience into ASE. Now it's your turn to leverage from it.
— Dr. Ralf S. Engelschall

I use ASE in GitHub Copilot CLI and here especially the various non-coding skills. They work great, even for consulting tasks!
— Zoltan Ruzman

ASE is the Swiss Army knife for my daily tasks performed in Claude Code!
— Maximilian Marsch

Know it up-front
instead of
wasting your time!
Check Your Fit

ASE is deliberately opinionated, so it fits some people well and others not at all. Rather than letting you find that out after wasting your time, here it is up-front — read both columns and decide before you go any further.

ASE is for YOU, if …

You want to stay in the driver's seat
You decide and trigger the next operation, and you review what came back. ASE hands you the wheel — it does not take it.
You are an experienced developer or architect
You can tell a good result from a plausible one. ASE raises the ceiling of what you produce; it does not raise the floor of what you know.
You prefer thinking before acting
You accept an approach funnel and a written plan before the first line changes, because post-hoc repair of a wrong change set costs more than the detour.
You have to defend your decisions
Component picks, architecture calls, and refactorings get challenged sooner or later. ASE hands you weighted decision matrices, an Advocatus Diaboli, and a Steelman — so you arrive with reasoning instead of a hunch.
You like the Unix command-line style
ASE skills are explicit commands with Unix-style options, like /ase-code-craft --next IMPLEMENT — not a chat you nudge until it complies.
You run Claude Code CLI with a strong LLM
ASE is primarily developed against Anthropic Claude Code CLI plus Claude Opus or Claude Fable, and needs that class of instruction-following.

ASE is not for YOU, if …

You want plain Vibe Coding
If "prompt it, ship it, never read it" is your goal, ASE only adds ceremony you will route around anyway.
You want a fully autonomous agent fleet
ASE deliberately keeps a human in the loop at every decision point. It, by default, is not an unattended, self-dispatching swarm, even if it can be forced into it to some extent.
You do consulting or management
ASE primarily targets the recurring tasks of Software Engineering and Software Architecture, although various skills are also useful outside this scope.
You optimize for the smallest token bill
Methodology costs tokens: a preloaded constitution, on-demand meta descriptions, approach funnels, and plans. Even if the persona setting can trim the output tokens, stringency has its price.
You want an unopinionated framework
ASE ships strict artifact formats, fixed skill families, and built-in tenets. You can configure it to some extent, but you cannot make it neutral.
You are on weak LLM or non-mainstream harness
ASE leans on elaborate control constructs and XML placeholders. Weaker models and non-mainstream harnesses follow them only partially.

Notice: The right column is a consequence of the ASE design, not a defect of it — every one of those boundaries buys something in the left column.

Standalone Mode 1/2

Standalone Mode 2/2

Task Mode

Funnel Mode

Quick Mode

Sync Mode

ase-help-skill - Show the Manual Page of an ASE Skill

NAME

ase-help-skill - Show the Manual Page of an ASE Skill

SYNOPSIS

ase-help-skill [--help|-h] [skill-name]

DESCRIPTION

The ase-help-skill skill renders the manual page (help.md) of the ASE skill addressed by skill-name. The page is emitted verbatim, framed between a ( HELP ) header and footer rule.

The skill-name is resolved against a catalog of all ASE skills -- one name: purpose entry per skill, generated into skills/ase-help-skill/data.md by npm start build in plugin/. Before resolving, any leading / and ase: prefix is stripped, so ase-code-lint, /ase-code-lint, and ase:ase-code-lint are equivalent. Resolution then proceeds in three tiers, each tried only if all preceding ones found nothing: an exact match on the full skill name wins outright, otherwise every skill name containing skill-name as a substring becomes a candidate, and otherwise skill-name is fuzzily matched against the skill purposes -- so a topical phrase such as root cause still finds ase-meta-why -- with the candidates ordered by descending match quality.

A skill-name matching no skill in any tier is reported as an error. A skill-name matching more than one skill opens an interactive dialog listing the candidates with their purposes; as the dialog renders at most nine answer lines, a broader abbreviation such as task shows the first nine candidates and states how many exist in total.

If skill-name is omitted, the whole catalog is rendered as a browsable Skill/Purpose table instead.

The skill exposes no option flags beyond --help/-h.

ARGUMENTS

skill-name: The full name of the ASE skill, any abbreviation of it, or a description of its purpose. If omitted, the entire skill catalog is listed.

SCENARIOS

You want the manual page of an ASE skill
You want to know what a certain ase-xxx-xxx skill does
You want a skill found by an abbreviation or a purpose description
You want to browse the whole catalog of ASE skills

EXAMPLES

Show the manual page of ase-code-lint via its shortest abbreviation:

❯ /ase-help-skill lint

Show the same manual page via its full, plugin-qualified name:

❯ /ase-help-skill ase:ase-code-lint

Pick a manual page from the candidates of an ambiguous abbreviation:

❯ /ase-help-skill analyze

Find a manual page by the purpose of the skill instead of its name:

❯ /ase-help-skill root cause

List the entire skill catalog:

❯ /ase-help-skill

NAME

ase-help-intent - Match an Intent to ASE Commands

SYNOPSIS

ase-help-intent [--help|-h] intent

DESCRIPTION

The ase-help-intent skill matches a free-text intent against the accumulated help of all ASE skills -- the concatenation of every skill's help.md file into skills/ase-help-intent/data.md, built by npm start build in plugin/ -- and generates all adequately fitting /ase:ase-xxx-xxx commands that realize the intent, ranked best-fitting first and limited to the eight best ones. The fit is judged primarily against each skill's SCENARIOS ("You want ...") and DESCRIPTION sections, and each command is complete with concrete option flags and positional arguments derived from the skill's SYNOPSIS, OPTIONS, and ARGUMENTS.

The generated commands are presented together with a brief per-command rationale in an interactive dialog. The dialog lets the user execute one of the commands C1...C8 (which dispatches the target skill via its generated arguments), cancel the operation, or refine the intent by typing any free-text instruction -- the instruction is folded into the intent and the fitting commands are re-matched and re-rendered. If no skill confidently matches the intent, a warning is emitted and the user is prompted to refine or clarify it.

The skill exposes no option flags beyond --help/-h; it is driven entirely through the intent argument and the interactive dialog.

ARGUMENTS

intent: The free-text intent to be realized. It describes what the user wants to achieve; the skill determines which ASE skills and which options and arguments realize it.

SCENARIOS

You want to know which ASE skills realize what you have in mind
You want free text turned into concrete slash commands with options
You want all matching commands proposed, ranked best-fitting first
You want to refine an intent in a dialog until a command fits

EXAMPLES

Route an intent to the matching commands and pick one from the dialog:

❯ /ase-help-intent lint the TypeScript sources for high-severity issues only

Route a planning intent to the matching commands:

❯ /ase-help-intent explain how the authentication module works

NAME

ase-meta-config - Configuration Management

SYNOPSIS

ase-meta-config [--help|-h] [--scope|-s scope] operation [args]

DESCRIPTION

The ase-meta-config skill lists, reads, writes, and removes the values of the layered ASE configuration from inside the assistant session. It mirrors the non-interactive subcommands of the ase config CLI, but performs every access through the ase_config_list, ase_config_get, ase_config_set, and ase_config_delete tools of the ase MCP server - it never shells out and never touches a file directly.

The configuration is organized as a chain of scopes, canonically ordered default < user < project < task < session. Reads cascade from the strongest (rightmost) scope down to the weakest and return the first value that is defined; writes are always confined to the strongest (target) scope of the chain.

The recognized keys are grouped under project.* (project.id, project.name, project.boxing, and the project.artifact.kind.{basedir,files} globs) and agent.* (agent.persona, agent.guidance, agent.task, and agent.skill). Some keys are writable on selected scopes only; in particular agent.task and agent.skill are writable on a session scope only, and the project.artifact.* globs are writable on the user and project scopes only.

The three keys steering the behaviour of the agent itself accept fixed value sets: agent.persona selects the communication style and is one of the decorative, eloquent, and explaining writer, the concise, factual, and accurate engineer (the default), the layered, pyramid-structured journalist, the brief, factual, and abbreviating telegrapher, or the terse, rough, and stuttering caveman; agent.guidance selects the number of unsolicited hints and is one of none, minimal, normal (the default), or verbose; and project.boxing selects the artifact transparency and is one of white, grey, or black. Setting agent.persona, agent.guidance, or project.boxing takes effect immediately, i.e. still within the running session.

The following operations exist:

list: List all effective configuration entries of the scope chain as a table of key, value, and the scope that supplied the value. For overlapping keys only the value of the strongest scope is shown.
get key: Report the effective value at the dotted key, or (not set) if no scope of the chain defines it.
set key value: Write value at the dotted key on the target scope. The value is validated against the configuration schema before it is persisted.
delete key: Remove the value at the dotted key from the target scope. A key that is not present is silently ignored.

The init and edit subcommands of the ase config CLI are deliberately not mirrored: edit is bound to the interactive $EDITOR and therefore has no meaning inside an assistant turn, and init is a preset-bootstrapping operation that stays a shell concern next to ase setup. Both remain available as ase config init and ase config edit on the command line.

OPTIONS

--scope|-s scope: The scope chain to operate on, given as a comma-separated list of user, project, task:id, and/or session:id terms, in any order and at most one term per kind. The user term is always implicitly added at the bottom of the chain, and project is implicitly added whenever a project context exists, but never above the strongest explicitly requested term. If the option is omitted, the chain of the current session (session:id) is used, so that reads see the full user -> project -> session cascade and writes -- including those to the session-only keys agent.task and agent.skill -- land on the session layer.

ARGUMENTS

operation: The operation to perform; one of list, get, set, or delete.
args: The operands of the operation: none for list, a dotted key for get and delete, and a dotted key plus a value for set.

SCENARIOS

You want the ASE configuration inspected or changed
You want the persona, guidance, or boxing switched for a session
You want a configuration value persisted at user or project scope
You want to see which scope supplies each effective value

EXAMPLES

List all effective configuration entries:

❯ /ase-meta-config list

Report the effective persona style:

❯ /ase-meta-config get agent.persona

Switch the communication style for the current session only:

❯ /ase-meta-config set agent.persona telegrapher

Switch the project boxing for the current session only:

❯ /ase-meta-config set project.boxing grey

Persist the guidance level for the whole project instead:

❯ /ase-meta-config --scope project set agent.guidance minimal

Remove a value from the user-level configuration:

❯ /ase-meta-config --scope user delete project.name

NAME

ase-meta-why - Five-Whys Root-Cause Analysis

SYNOPSIS

ase-meta-why [--help|-h] [--depth|-d N] [--width|-w M] fact

DESCRIPTION

The ase-meta-why skill applies the Five-Whys root-cause analysis technique to the supplied fact. The skill iteratively asks "why" - up to N times (see --depth, default five) - to drill down from surface symptoms to the underlying root cause, considering technical, domain-specific, process-related, and organizational causes. By default it walks a single causality chain, but with --width M (> 1) it walks a widened chain: at each level it surfaces up to M candidate sub-causes, descends into the most significant one with an explicit justification for the choice, and keeps the unchosen candidates as fallbacks. If backward validation later shows the chosen path was mis-rooted, it backtracks into a fallback and re-descends - guarding against the classic Five-Whys failure of committing early to the wrong sub-cause. After identifying (and validating) the root cause it proposes a SOLUTION that addresses it, optionally including concrete source code changes.

OPTIONS

--depth|-d N: The maximum number of "why" iterations (the Five-Whys chain length), acting as an upper bound only - the analysis still stops early once the root cause is reached. Defaults to 5. A non-numeric or non-positive value falls back to the default.
--width|-w M: The maximum number of candidate sub-causes to surface per "why" level. With the default 1, the skill walks a single causality chain (classic Five-Whys); with M > 1, each level surfaces up to M candidate sub-causes, descends into the single most significant one (justifying the choice), and retains the rest as fallbacks. During backward validation a mis-rooted choice is backtracked into a fallback and re-descended, so the widening actively improves which root cause is reached rather than merely listing alternatives. The result is still a single, but better-justified, root cause. A non-numeric or non-positive value falls back to the default.

ARGUMENTS

fact: The observed fact (symptom, problem, or surprising outcome) whose root cause should be investigated. The skill implicitly prepends "Why" to form the initial question.

SCENARIOS

You want the root cause of a problem, not just its symptom
You want a Five-Whys causality chain walked for an observed fact
You want candidate causes weighed with backtracking
You want a solution proposed which addresses the root cause

EXAMPLES

Investigate the root cause of a build failure:

❯ /ase-meta-why the CI build is intermittently failing on macOS runners

Drill down deeper with a tunable chain length of seven:

❯ /ase-meta-why -d 7 the production latency spiked after the last deploy

Weigh several candidate sub-causes per level (with backtracking) to avoid committing early to the wrong root cause:

❯ /ase-meta-why -w 3 the release was delayed by two weeks

NAME

ase-meta-eli5 - Explain a Topic Like I'm 5

SYNOPSIS

ase-meta-eli5 [--help|-h] [--ground|-g] topic

DESCRIPTION

The ase-meta-eli5 skill explains the supplied topic in "Explain Like I'm 5" (ELI5) style, so that even a five-year-old child could understand it. The explanation uses simple, jargon-free wording -- short sentences, everyday words, and familiar images -- and is structured into three labeled blocks: WHAT (a plain-words summary), ANALOGY (a concrete everyday-life comparison), and WHY (why the topic matters), each kept brief with 1-3 bullet points.

By default the explanation is derived from model knowledge only. With the --ground/-g option, the skill first searches the Internet/Web for facts about the topic via the ase-meta-search skill (dispatched in a sub-agent, querying all available search backends) and grounds the explanation in the found facts. If the grounding yields no usable facts, a warning is emitted and the explanation falls back to model knowledge.

OPTIONS

--ground|-g: Ground the explanation in Internet/Web facts gathered via the ase-meta-search skill before explaining. Without this option, the explanation is derived from model knowledge only.

ARGUMENTS

topic: The topic to be explained. It may be a technical concept, a phenomenon, or any other subject; the skill explains it in a child-friendly way.

SCENARIOS

You want a topic explained so simply a child could follow
You want a jargon-free summary with an everyday analogy
You want a simple explanation grounded in current Internet/Web facts

EXAMPLES

Explain a technical concept from model knowledge:

❯ /ase-meta-eli5 What is a Fourier transform?

Explain a recent topic grounded in Internet/Web facts:

❯ /ase-meta-eli5 --ground What is Agentic Software Engineering?

NAME

ase-meta-proximity - Determine the Conceptual Proximity of a Topic

SYNOPSIS

ase-meta-proximity [--help|-h] [--ground|-g] [--loop|-l] topic

DESCRIPTION

The ase-meta-proximity skill determines the conceptual proximity of the supplied topic along three dimensions and reports the neighboring topics grouped into three labeled sections: PARENT (the single broader topic that topic specializes), SIBLINGS (the four most relevant topics on the same level, sharing the same parent), and CHILDREN (the four most relevant narrower topics that specialize topic).

The determination itself is delegated to the ase-meta-proximity agent, which is shared with the ase-meta-quotes skill. By default the proximity is derived from model knowledge only. With the --ground/-g option, the agent first searches the Internet/Web for facts about the topic, about its broader topic, and about its narrower topics, and grounds the determination in the found facts.

Without the --loop/-l option, the skill determines and prints the proximity of the given topic once and then stops. With the --loop/-l option, the skill instead presents the nine neighboring topics in an interactive dialog; selecting one of them makes it the new current topic and restarts the determination from the beginning, so the user can navigate the topic taxonomy up (parent), sideways (siblings), and down (children). Cancelling the dialog exits the loop. When --loop is combined with --ground, each newly selected topic is re-grounded by the ase-meta-proximity sub-agent before its proximity is re-determined.

OPTIONS

--ground|-g: Ground the determination in Internet/Web facts gathered by the ase-meta-proximity agent before determining the proximity. Without this option, the determination is derived from model knowledge only. When combined with --loop, every newly navigated-to topic is re-grounded.
--loop|-l: Present the neighboring topics in an interactive dialog and, upon selection, adopt the picked topic as the new current topic and restart the determination. Without this option, the proximity of the given topic is printed once and the skill stops.

ARGUMENTS

topic: The topic whose conceptual proximity is to be determined. It may be a technical concept, a phenomenon, or any other subject; the skill determines its parent, sibling, and child topics.

SCENARIOS

You want the conceptual neighborhood of a topic explored
You want the parent, sibling, and child topics of a subject
You want a topic taxonomy navigated interactively
You want related topics grounded in Internet/Web facts

EXAMPLES

Determine the proximity of a topic from model knowledge:

❯ /ase-meta-proximity Fourier transform

Interactively navigate the conceptual neighborhood, grounded in Internet/Web facts:

❯ /ase-meta-proximity --ground --loop Agentic Software Engineering

NAME

ase-meta-quotes - Find Quotes on a Topic

SYNOPSIS

ase-meta-quotes [--help|-h] [--ground|-g] [--proximity|-p] [--count|-c count] topic-keywords

DESCRIPTION

The ase-meta-quotes skill finds quotes -- sayings, aphorisms, maxims, proverbs, and citations -- for the supplied topic-keywords and places them into a 2x2 matrix, reported as four labeled quadrant sections.

Per quote, the skill records its text, its author (a named person or organization, if known), its origin (a named work, standard, or document, if known), and the topic it was harvested for (its source topic).

The first dimension of the matrix is the attribution of a quote: a quote is ATTRIBUTED when a named author and/or a named origin is known for it, and ANONYMOUS otherwise. The second dimension is the literalness of a quote: a quote is LITERAL when its text contains at least one of the topic-keywords as a whole word -- matched case-insensitively and tolerating inflections (e.g. architect and architectural match the keyword architecture), but never as a mere substring (e.g. art does not match architecture) -- and THEMATIC otherwise. The two dimensions span the quadrants Q1 (ATTRIBUTED/LITERAL), Q2 (ATTRIBUTED/THEMATIC), Q3 (ANONYMOUS/LITERAL), and Q4 (ANONYMOUS/THEMATIC). A quadrant without any quote is rendered as (none).

Every quote is rendered on its own line and carries, where applicable, the suffixes — <author>, <origin> (in the two ATTRIBUTED quadrants, omitting whichever part is unknown), [from proximity: <source-topic>] (when the quote was contributed by a neighborhood topic under --proximity instead of by topic-keywords itself), and (unverified) (when the exact wording or the attribution could not be established with confidence). The (unverified) marker is dropped as soon as the Internet/Web search under --ground confirms the wording and the attribution of the quote.

OPTIONS

--ground|-g: Gather quotes from the Internet/Web via the ase-meta-search skill (dispatched in a sub-agent, querying all available search backends) in addition to -- and never instead of -- the model knowledge, merge them into the harvest while deduplicating quotes which differ only in punctuation, capitalization, or attribution wording, and use the search results to confirm the wording and the attribution of the found quotes. When combined with --proximity, the determination of the conceptual neighborhood is grounded in Internet/Web facts as well. Should the search return no usable quotes, a warning is emitted and the skill falls back to the model knowledge only. Without this option, the quotes are derived from model knowledge only.
--proximity|-p: Widen the harvest beyond the given topic to its conceptual neighborhood -- the parent (more general) topic, the four sibling (same-level) topics, and the four child (more specialized) topics -- as determined by the ase-meta-proximity agent, which is shared with the ase-meta-proximity skill. Each of these nine neighborhood topics is harvested exactly like the given topic itself. Quotes contributed by a neighborhood topic carry that topic in brackets and mostly land in the THEMATIC quadrants, which is exactly where the widening pays off. Should the agent return no usable neighborhood, a warning is emitted and the skill continues with the narrow topic only. Without this option, only the given topic is harvested.
--count|-c count: Maximum total number of quotes across all four quadrants (default: 8, i.e. about two quotes per quadrant). The quotes are distributed as evenly as possible across the quadrants, preferring the most relevant and most well-known quote per quadrant. A non-numeric value or a value less than or equal to 0 falls back to the default.

ARGUMENTS

topic-keywords: The topic keywords the quotes are searched for. They act both as the search query and as the keyword set of the literalness dimension of the matrix.

SCENARIOS

You want quotes, sayings, or aphorisms on a topic
You want citations arranged by attribution and literalness
You want quote wording and attribution verified against the Web
You want the quote harvest widened to related topics

EXAMPLES

Find quotes from model knowledge:

❯ /ase-meta-quotes software architecture

Find a wider set of quotes, grounded in Internet/Web facts and widened to the conceptual neighborhood of the topic:

❯ /ase-meta-quotes --ground --proximity --count 12 technical debt

NAME

ase-meta-evaluate - Evaluate Alternatives

SYNOPSIS

ase-meta-evaluate [--help|-h] request

DESCRIPTION

The ase-meta-evaluate skill evaluates two or more alternatives through a weighted multi-criteria decision matrix. From the request, the skill derives the reason for the evaluation, the alternatives, and the criteria, fills in additional criteria up to a range of 8-12 (using ase-meta-search where helpful), assigns weights from { 4.00, 2.00, 1.00, 0.50, 0.25 }, evaluates each alternative against each criterion on a { -2, -1, 0, +1, +2 } Likert scale, and computes the final ratings via the ase_decision_matrix MCP tool.

The result is reported as a Markdown decision matrix along with the single BEST ALTERNATIVE, including a warning if multiple alternatives tie, if the distance to the second best is small, or if all alternatives rate negatively.

ARGUMENTS

request: A description of what should be evaluated, including the alternatives and, optionally, the criteria to consider.

SCENARIOS

You want alternatives compared and the best one named
You want a weighted multi-criteria decision matrix
You want a defensible, criteria-based technology choice
You want to know which option out of a list wins and by how much

EXAMPLES

Compare logging libraries for a TypeScript project:

❯ /ase-meta-evaluate Compare pino, winston, and bunyan as logging libraries.

Evaluate database options with hinted criteria:

❯ /ase-meta-evaluate Compare PostgreSQL, MySQL, and SQLite for an
  embedded use case; criteria include footprint and write throughput.

NAME

ase-meta-diaboli - Play "Devil's Advocate" (Latin: "Advocatus Diaboli")

SYNOPSIS

ase-meta-diaboli [--help|-h] [--count|-c count] thesis

DESCRIPTION

The ase-meta-diaboli skill plays Devil's Advocate (Latin: Advocatus Diaboli) by relentlessly challenging or criticising a supplied thesis. It applies a disciplined set of critical-thinking tenets - steelmanning, stress-testing fundamentals, surfacing implicit assumptions, demanding proportional evidence, seeking disconfirming cases, Reductio Ad Absurdum, exposing hidden costs, and pre-mortem thinking - while targeting the claim rather than its proponent and yielding where the argument genuinely holds.

The skill iterates until it has found at least count anti-theses (counter-arguments) each ranked at least 7 on a 0 (weak) to 10 (strong) Likert scale, reports the top count sorted from strongest to weakest, and finally applies Hegelian dialectics (Thesis + Antithesis → Synthesis) to derive a single-sentence SYNTHESIS that preserves what is true in both the thesis and its antitheses while discarding what is false.

The --count/-c count option sets the minimum number of strong anti-theses to surface (default 10), raising or lowering the floor of counter-arguments hunted for, sorted, and reported in the single challenge pass. A 0, negative, or non-numeric value falls back to the default 10.

The intent is constructive: stress-testing the thesis in good faith to arrive at a better final decision, not obstructing or merely being contrarian.

ARGUMENTS

--count, -c count: Surface at least count strong anti-theses (default 10) before sorting and reporting the top count and deriving the SYNTHESIS. An invalid or non-positive count reverts to the default 10.
thesis: The statement, claim, or position to be relentlessly challenged. It may be technical, factual, or opinion-based; the skill attacks its strongest ("steelman") interpretation.

SCENARIOS

You want a thesis relentlessly challenged with counter-arguments
You want a decision stress-tested before you commit to it
You want the strongest anti-theses ranked plus a synthesis
You want a devil's advocate against a claim or plan

EXAMPLES

Challenge a technology-choice claim:

❯ /ase-meta-diaboli HAPI is the best REST framework

Stress-test a design decision:

❯ /ase-meta-diaboli We should rewrite the service in Rust.

Surface at least fifteen anti-theses:

❯ /ase-meta-diaboli --count 15 We should rewrite the service in Rust.

NAME

ase-meta-steelman - Build the "Steelman" Argument

SYNOPSIS

ase-meta-steelman [--help|-h] [--count|-c count] [--rounds|-r rounds] thesis

DESCRIPTION

The ase-meta-steelman skill builds the strongest possible case for a supplied thesis - the constructive mirror of its adversarial counterpart ase-meta-diaboli. It applies a disciplined set of constructive-thinking tenets - charitable interpretation, strengthening the fundamentals, surfacing the enabling assumptions, supplying proportional evidence, seeking confirming cases, Reductio Ad Bonum, surfacing the upside, and pre-parade thinking - while crediting the claim rather than the proponent's authority and conceding where the thesis genuinely falls short.

The skill iterates until it has found at least count pro-theses (supporting arguments) each ranked at least 7 on a 0 (weak) to 10 (strong) Likert scale, reports the top count sorted from strongest to weakest, and finally consolidates them (Thesis + Pro-Theses → Fortification) to derive a single-sentence FORTIFICATION that consolidates everything genuinely strengthening the thesis while honestly bounding where it holds.

The --rounds/-r rounds option turns the single defense pass into an iterative chain of rounds rounds (default 1): each round's FORTIFICATION becomes the thesis of the next round, so the position is progressively re-fortified and sharpened. A 0, negative, or non-numeric value falls back to the default 1; with a single round the output is identical to running without the option.

The --count/-c count option sets the minimum number of strong pro-theses to surface (default 10), raising or lowering the floor of supporting arguments hunted for, sorted, and reported in each defense pass. A 0, negative, or non-numeric value falls back to the default 10.

The intent is constructive: building the best honest case for the thesis to arrive at a better final decision, not overselling or merely cheerleading.

OPTIONS

--count|-c count: Surface at least count strong pro-theses (default 10) per defense pass before sorting and reporting the top count and deriving the FORTIFICATION. An invalid or non-positive count reverts to the default 10.
--rounds|-r rounds: Run rounds iterative defense rounds (default 1), feeding each round's FORTIFICATION in as the next round's thesis. An invalid or non-positive rounds reverts to the default 1.

ARGUMENTS

thesis: The statement, claim, or position to be charitably strengthened. It may be technical, factual, or opinion-based; the skill defends its strongest ("steelman") interpretation.

SCENARIOS

You want the strongest possible case built for a thesis
You want supporting arguments ranked plus a fortification
You want a charitable defense before pitching a decision

EXAMPLES

Strengthen a technology-choice claim:

❯ /ase-meta-steelman HAPI is the best REST framework

Build the case for a design decision:

❯ /ase-meta-steelman We should rewrite the service in Rust.

Strengthen across five iterative rounds:

❯ /ase-meta-steelman --rounds 5 We should rewrite the service in Rust.

NAME

ase-meta-quorum - Query Multiple AIs for Quorum Answer

SYNOPSIS

ase-meta-quorum [--help|-h] [--models|-m model[,...]] question

DESCRIPTION

The ase-meta-quorum skill finds a quorum answer on an arbitrary question by querying multiple AIs (Anthropic Claude itself plus OpenAI ChatGPT, Google Gemini, DeepSeek, xAI Grok, Z.AI GLM, and Alibaba Qwen) for an optimal consensus.

The skill first previews its own answer, then dispatches the same query to each available foreign LLM via the ase:ase-meta-chat sub-agent, summarizes all responses, derives a consensus rate on a Likert scale of 0..N (where N is the number of available responders), and reports the consensus answer alongside the complete, unmodified individual responses.

OPTIONS

--models|-m model[,...]: Restrict the foreign LLMs that are queried to the given comma-separated list of model tokens. Recognized tokens are all, chatgpt, gemini, deepseek, grok, glm, and qwen, where all selects every model. The default is all. Models that are not selected (or not available) are silently skipped. Anthropic Claude (the skill itself) is always included, independent of this option.

ARGUMENTS

question: The question to ask all available AIs.

SCENARIOS

You want a consensus answer from multiple AIs
You want to know whether different models agree on a question
You want the individual responses plus a consensus rate

EXAMPLES

Ask the quorum a factual question:

❯ /ase-meta-quorum What are the most common causes of memory leaks in Node.js?

Ask only a subset of the foreign models:

❯ /ase-meta-quorum --models chatgpt,gemini,grok Which sorting algorithm is fastest in practice?

NAME

ase-meta-chat - Query Foreign LLM for Chat

SYNOPSIS

ase-meta-chat [--help|-h] llm query

DESCRIPTION

The ase-meta-chat skill queries a foreign LLM (such as OpenAI ChatGPT, Google Gemini, DeepSeek, xAI Grok, Z.AI GLM, or Alibaba Qwen) with a single chat message. The underlying ase:ase-meta-chat sub-agent is invoked and its plain response is shown back verbatim without any further interpretation.

ARGUMENTS

llm: Identifier of the foreign LLM to query, e.g. chatgpt, gemini, deepseek, grok, glm, or qwen.
query: The chat message to send to the foreign LLM.

SCENARIOS

You want a single question answered by one specific foreign LLM
You want an answer from ChatGPT, Gemini, DeepSeek, Grok, GLM, or Qwen
You want a second opinion from exactly one other model, verbatim

EXAMPLES

Ask ChatGPT a quick question:

❯ /ase-meta-chat chatgpt What is the best way to handle UTF-8 BOMs in JSON?

Ask Gemini for a brief comparison:

❯ /ase-meta-chat gemini Compare gRPC and REST in one paragraph.

NAME

ase-meta-search - Search the Internet/Web

SYNOPSIS

DESCRIPTION

The ase-meta-search skill searches the Internet/Web for the given query. It dispatches the query in parallel to the selected search services (Perplexity, Brave, Exa, and Claude's built-in WebSearch) via the ase:ase-meta-search sub-agent and consolidates all responses into a single answer without removing original information.

This skill should be preferred over directly invoking Perplexity, Brave, or WebSearch individually.

OPTIONS

--services|-s=(all|perplexity|brave|exa|websearch)...: The comma-separated list of search backends to query. The default all queries every available backend; otherwise only the listed backends are queried.

ARGUMENTS

query: The search query to dispatch to the search services.

SCENARIOS

You want the Internet/Web searched for a query
You want results from several search backends consolidated
You want current facts which model knowledge may lack

EXAMPLES

Search the Web for a topic across all backends:

❯ /ase-meta-search latest stable release of TypeScript and release notes

Search the Web using only the Brave and Exa backends:

❯ /ase-meta-search --services=brave,exa latest stable release of TypeScript

NAME

ase-meta-brainstorm - Collaboratively Brainstorm a Topic

SYNOPSIS

DESCRIPTION

The ase-meta-brainstorm skill guides a collaborative ideation session on a topic before any implementation begins. It first clarifies intent by exploring the project context and interviewing the user - one grounded, multiple-choice question at a time - about purpose, constraints, scope, and success criteria (asking at most --max-clarify, default 3, questions). It then diverges into a broad space of candidate ideas (at least --min-ideas, default 12) pursued from deliberately diverse angles (MVP-first, risk-first, UX-first, reuse-first, and wildcard), without judging them.

Next it converges by clustering the ideas into coherent themes, pruning speculative or out-of-scope ones via YAGNI, and scoring the survivors on a 0-10 fit scale (keeping only those ranked --min-rank, default 7, or higher). Finally it distills a shortlist of the top --max-shortlist, default 4, directions - drawn from distinct clusters wherever possible - and derives a single RECOMMENDATION, being either the highest-ranked option or a principled synthesis of the shortlist.

OPTIONS

--max-clarify|-c=3: The maximum number of essential-unknown clarification questions asked in the clarify intent phase (default: 3). Lower it for a faster, leaner intake, raise it for more upfront grounding.
--min-ideas|-i=12: The minimum number of candidate ideas to generate in the diverge phase before converging (default: 12). Raise it for a broader idea space, lower it for a quicker, narrower session.
--min-rank|-r=7: The minimum 0-10 fit rank an idea must score to survive the converge phase (default: 7). Raise it for a stricter filter, lower it to retain more ideas.
--max-shortlist|-s=4: The maximum number of distilled options on the final shortlist (default: 4). Lower it for a sharper focus, raise it for more finalists.

ARGUMENTS

topic: The subject to brainstorm - a feature, component, behavior, or design question to explore what to build before how.

SCENARIOS

You want to get fresh ideas for an open-ended question
You want to explore what to build before deciding how to build it
You want to widen a solution space that holds a single candidate
You want to get a shortlist of distinct directions with a recommendation
You want to ideate on a feature, component, or design question

EXAMPLES

Brainstorm an approach for a new feature:

❯ /ase-meta-brainstorm an offline-first sync layer for the mobile app

Brainstorm with a broader idea space of at least 20 candidates:

❯ /ase-meta-brainstorm --min-ideas 20 an offline-first sync layer

Brainstorm quickly with a single clarification, a stricter score floor, and a tighter shortlist:

❯ /ase-meta-brainstorm --max-clarify 1 --min-rank 8 --max-shortlist 3 an offline-first sync layer

NAME

ase-meta-compat - Self-Test ASE Compatibility

SYNOPSIS

ase-meta-compat [--help|-h]

DESCRIPTION

The ase-meta-compat skill self-tests how faithfully the current LLM (and its harness) executes the four core interpreter primitives that every ASE skill silently relies on, and reports an overall 0%…100% compatibility rating. ASE skills are not run by a conventional interpreter - they are interpreted by the model itself, which must honor control-flow constructs, substitute XML placeholders, evaluate regex conditions, and perform arithmetic. If a model cannot execute these primitives reliably, every ASE skill silently misbehaves, so this skill lets a user measure the fit before relying on ASE.

The skill is both the test definition and the system under test. It probes four capability categories:

XML Placeholders: the get (<x/>) and set (<x>v</x>) semantics, including the get-and-set composite, indexed names, and XML-entity rendering.
Control Flow: the <if>/<elseif>/<else>, <while>/<break>, <for>, <step condition=…>, and <expand>/<define> constructs.
Regex Matching: the patterns ASE genuinely uses (e.g. the getopt short-circuit (^|\s)-), plus anchoring, alternation, and captures.
Arithmetic: counter increments, decision-matrix product-sums, percentage rounding, and bar-width computations.

Each probe embeds a construct with a known expected result; the model executes it and honestly self-checks its actual result against the expected one. Per-category pass-rates are combined into the overall rating via the ase_decision_matrix MCP tool as a weighted average, with XML Placeholders weighted 4.00 (the backbone of every skill), Control Flow weighted 3.00, Regex Matching weighted 2.00, and Arithmetic weighted 1.00. The result is a boxed per-category table (passes and percentage per category), a final OVERALL COMPATIBILITY percentage, and a one-line VERDICT (✓ fully compatible at ≥ 90%, ⚠ partially compatible at 60–89%, ✘ incompatible below 60%) that names any failed probes.

ARGUMENTS

The ase-meta-compat skill takes no arguments (besides --help|-h). It always runs the most rigorous self-test, with 6 probes per category (7 for Regex Matching), for 25 probes in total.

SCENARIOS

You want to know how faithfully the current model runs ASE skills
You want a 0-100% compatibility rating of the LLM and its harness
You want the core interpreter primitives checked before relying on ASE

EXAMPLES

Run the compatibility self-test:

❯ /ase-meta-compat

NAME

ase-meta-mint - Mint an Identifier or Name

SYNOPSIS

DESCRIPTION

The ase-meta-mint skill mints an identifier or a name of a requested type out of the free-text hint formed by the positional arguments. It dispatches on --type and emits the generated strings as its result.

The two hash-derived types are delegated to the ase_mint tool of the ase MCP server, which derives them reproducibly instead of guessing them:

uuid: a deterministic UUID V5 over the hint, within the fixed ASE namespace (itself a UUID V5 over https://ase.tools in the standard URL namespace), or a random UUID V4 if no hint is given.
sha1: the 40-character hexadecimal SHA-1 digest of the hint.

The six linguistic types are derived by the skill itself: the hint is distilled into its essential words, which are then assembled according to the conventions of the type:

const: an UPPER_SNAKE_CASE constant identifier, such as FOO_BAR_QUUX.
var: a lowerCamelCase variable identifier, such as fooBarQuux, whose last part is a substantive naming what the value is, never a verb.
func: a lowerCamelCase function identifier, such as fooBarQuux, whose first part is a verb naming what the function does.
class: an UpperCamelCase class identifier, such as FooBarQuux, as a singular substantive phrase naming the modeled entity.
path: a kebab-case path component, such as foo-bar-quux.
name: an UpperCamelCase product name, such as FooBarQuux, optimized for a brand rather than for a description: short, pronounceable, memorable, and distinctive.

A hint is mandatory for every type except uuid, which falls back to a random UUID V4 without one.

OPTIONS

--count|-c count: Mint count identifiers instead of just one (default: 1, maximum: 100). For the hash-derived types it is honored only for an empty hint, where count random UUID V4 values are emitted; with a non-empty hint, hashing is a pure function of that hint and hence always yields exactly one identifier, so count is clamped to 1 and a warning is emitted. For the linguistic types, count distinct candidates are emitted, ordered best-first.

ARGUMENTS

hint: The free-text hint the identifier or name is derived from. It may be a short description, a phrase, or a few keywords. It is mandatory for all types except uuid.

SCENARIOS

You need a stable, reproducible UUID or SHA-1 digest for a concept
You need a well-formed constant, variable, function, or class identifier
You need a path component or slug derived from a description
You need a catchy product name for a new component or tool

EXAMPLES

Mint a deterministic UUID for a concept:

❯ /ase-meta-mint --type uuid the ASE artifact kind resolution cache

Mint a function identifier from a description:

❯ /ase-meta-mint -t func compute the checksum of an artifact file

Mint three product name candidates:

❯ /ase-meta-mint -t name -c 3 a background service bridging a project into the agent tool

NAME

ase-meta-workflow - Generate a Workflow Skill

SYNOPSIS

ase-meta-workflow [--help|-h] [--scope|-s local|user] [--force|-f] skill-name workflow-description

DESCRIPTION

The ase-meta-workflow skill generates a new, regular skill of the currently used agent tool -- written in the style of ASE skills -- which orchestrates the workflow given as workflow-description.

The workflow-description is treated as a combination of sequential actions, concurrent actions, sub-agent invocations, skill invocations, and arbitrary other action statements. The skill maps them onto the ASE control constructs: top-level sequential actions become numbered <step> items inside a single <flow>, concurrent actions become a <parallel> block, sub-agent invocations become <agent> elements, and skill invocations become <skill> elements. Whenever a <parallel> block contains at least one <agent isolation="worktree">, a dedicated consolidation step holding <agent-consolidation/> is appended right after it, so the Git WorkTrees of the concurrent sub-agents are merged and removed again. Every top-level <skill> invocation is additionally enclosed in its own <agent> element -- without isolation and with run_in_background=false -- so the TaskCreate and TaskUpdate tool calls of the called skill cannot interfere with the task tracking of the generated workflow skill itself.

To keep the emitted <skill> invocations correct, the skill consults the accumulated manual pages of all ASE skills and takes every option and argument verbatim from them. To keep the emitted flow meaningful, it consults the ASE workflow graph -- a list of <from> -> <to> transitions between ASE skills and logical states such as START, SKETCH, TASK, ARTIFACT, and END. That graph guides the derivation but never restricts it: arbitrary non-ASE actions and unlisted transitions stay allowed.

The generated skill is independent of the ASE plugin installation path: it loads the ASE meta definitions through the ase meta command instead of plugin-relative includes.

The skill is portable across the supported agent tools, because Anthropic Claude Code, GitHub Copilot, and OpenAI Codex differ in three relevant ways, each of which is dispatched on the currently used agent tool:

the target directory, because every agent tool discovers its skills in its own locations,
the frontmatter fields, because every agent tool accepts its own field set and its own allowed-tools permission grammar, and
the preamble, because only Anthropic Claude Code expands the !`... construct before the skill content reaches the model. The other agent tools receive it verbatim and would silently leave it unexpanded, so they instead get an explicit instruction to run ase meta ... themselves before anything else.

OPTIONS

--scope|-s local|user: Where the generated skill is stored. With local (the default), it is written into the current project, where it can be committed and reviewed alongside the code. With user, it is written into the personal skill directory, where it is available across all projects. The concrete directory depends on the currently used agent tool: .claude/skills/ and ~/.claude/skills/ under Anthropic Claude Code, .github/skills/ and ~/.copilot/skills/ under GitHub Copilot, and .agents/skills/ and ~/.codex/skills/ under OpenAI Codex.
--force|-f: Overwrite an already existing skill. Without this option, the skill refuses with an error as soon as the target SKILL.md exists, so hand-edited skills are never lost silently.

ARGUMENTS

skill-name: Name of the skill to generate, matching ^[a-zA-Z][a-zA-Z0-9_-]*$. It is used as the directory name, as the frontmatter name, and as the resulting /skill-name command (respectively the $skill-name mention under OpenAI Codex).
workflow-description: Free-text description of the workflow the generated skill should perform. Mentioning that actions run "in parallel", that they are dispatched "in a sub-agent", or naming concrete ase-xxx-xxx skills steers the derived structure accordingly.

SCENARIOS

You want a recurring multi-step procedure automated as its own skill
You want several ASE skills orchestrated or chained into one command
You want sequential and parallel actions woven into a generated skill
You want a new agent tool skill generated in the style of ASE skills

EXAMPLES

Generate a project-local skill which analyzes the code and then resolves every finding concurrently in isolated worktrees:

❯ /ase-meta-workflow optimizer run ase-code-analyze, then for each finding P<n> resolve, implement and delete it in a parallel isolated sub-agent

Generate a user-wide skill and overwrite a previous generation:

❯ /ase-meta-workflow --scope user --force release lint the code, update the changelog, then propose a commit message

NAME

ase-arch-discover - Discover Components

SYNOPSIS

ase-arch-discover [--help|-h] [--limit|-l=12] [--staleness|-s=18] [--small-scope|-S] functionality

DESCRIPTION

The ase-arch-discover skill discovers additional, third-party components (libraries/frameworks) for the technology stack that provide the needed functionality.

The skill determines the project's technology stack (TypeScript, JavaScript, Kotlin, or Java), derives essential keywords from the requested functionality, queries the corresponding package registry (NPM or Maven Central), retrieves metadata (version, downloads, stars, dates, dependency count) via the ase_component_info MCP tool, and reports the top-ranked components as a Markdown table together with a single distinguishing hint (USP, Crux, or Gotcha) per component.

The ranking penalizes stale components (last release older than the --staleness threshold) and, when the --small-scope option is given, demotes dependency-heavy components.

OPTIONS

--limit|-l=12: The maximum number of components retained in the final ranking (default: 12); each discovery source may fetch up to twice this number of candidates for ranking. Raise it for a broader, more exhaustive survey, lower it for a quicker, narrower lookup.
--staleness|-s=18: The staleness threshold in months (default: 18). A component whose last release is older than this is rank-penalized and flagged with an aging gotcha; older than twice the threshold, it is penalized harder and flagged as stale/abandoned.
--small-scope|-S: Treat the requested functionality as small-scope (default: off). When enabled, the ranking demotes dependency-heavy components by a dependency-weight penalty, since a dependency-free/hand-rolled implementation is a realistic alternative for narrow, self-contained functionality.

ARGUMENTS

functionality: A short description of the desired functionality the third-party component should provide.

SCENARIOS

You want a third-party library or framework for a needed functionality
You want a ranked survey of candidate components from NPM or Maven Central
You want to know whether a package is healthy or stale and abandoned
You want to decide between a dependency and hand-rolling a small feature

EXAMPLES

Discover components for JSON schema validation:

❯ /ase-arch-discover JSON schema validation

Discover components for HTTP client functionality:

❯ /ase-arch-discover HTTP client with retries

Discover a broader set of up to 20 HTTP client components:

❯ /ase-arch-discover --limit 20 HTTP client with retries

Discover HTTP clients, flagging any without a release in the last 12 months:

❯ /ase-arch-discover --staleness 12 HTTP client with retries

NAME

ase-code-insight - Project Insight

SYNOPSIS

ase-code-insight [--help|-h] code-references

DESCRIPTION

The ase-code-insight skill gives high-level insights into the project through the referenced source code. The skill produces four sections: a PROJECT ABSTRACT (summary derived from README.* or source scanning), a PROJECT AUTHOR list (from git shortlog), a SOURCE CHURN table (most-committed files in the last year), and a MODULE STRUCTURE Mermaid diagram of modules and their imports.

ARGUMENTS

code-references: One or more file or directory references to source code that should be inspected for insights.

SCENARIOS

You want a high-level overview of a project
You want to know who wrote the project and which files churn most
You want a module structure diagram of the imports
You want to get familiar with an unknown code base quickly

EXAMPLES

Get insights into the current project:

❯ /ase-code-insight src/

Get insights into a specific subsystem:

❯ /ase-code-insight tool/src/

NAME

ase-code-explain - Explain Source Code

SYNOPSIS

ase-code-explain [--help|-h] source-reference

DESCRIPTION

The ase-code-explain skill analyzes and explains the source code of the referenced location in a brief, standardized, and concise way along six dimensions: WHAT (functionality), WHY (rationale), ANALOGY (everyday-life comparison in ELI5 style), DIAGRAM (Mermaid diagram of control flow, data flow, or structure), CRUXES (what to notice), and GOTCHAS (what to not stumble over).

ARGUMENTS

source-reference: A file, directory, function, or other reference to the source code to explain.

SCENARIOS

You want to understand how a piece of code works
You want an explanation with WHAT, WHY, analogy, and diagram
You want the cruxes and gotchas of unfamiliar code pointed out
You want a quick orientation before touching foreign code

EXAMPLES

Explain a single source file:

❯ /ase-code-explain src/parser.ts

Explain a specific function:

❯ /ase-code-explain src/parser.ts#parseExpression

NAME

ase-code-lint - Lint Source Code

SYNOPSIS

DESCRIPTION

The ase-code-lint skill lints the source code of the referenced location for potential code quality problems related to a fixed set of code quality aspects. The investigation is dispatched to a sub-agent (ase:ase-code-lint) so that scanning details do not leak into the user-visible transcript.

For each detected problem, the skill renders a unified-diff SOLUTION preview and either asks the user to ACCEPT or REJECT the proposed correction interactively (or refine it via a free-text hint, which re-proposes the correction without limit) or - with --auto - applies all corrections automatically.

By default all twenty-one code quality aspects are checked. The --include and --exclude options narrow this to an effective aspect set: with --include only, exactly the listed aspects are checked; with --exclude only, all aspects except the listed ones; with both, the included ones minus the excluded ones. An unknown aspect id, or a combination which cancels out to an empty set, aborts the skill with an error. The twenty-one aspect ids are:

A01 FORMATTING     A07 PATTERNS         A13 MEMORY-LEAK    A19 FLOW
A02 COMPREHENSION  A08 COMPLICATEDNESS  A14 CONCURRENCY    A20 DEAD-CODE
A03 CLEANLINESS    A09 CONCISENESS      A15 PERFORMANCE    A21 DOCUMENTATION
A04 SPELLING       A10 SMELLS           A16 SECURITY
A05 COMPLEXITY     A11 TYPING           A17 ARCHITECTURE
A06 REDUNDANCY     A12 ERROR-HANDLING   A18 LOGIC

The A21 DOCUMENTATION aspect checks the code documentation in both directions: it flags functions, methods, classes, and modules - private ones included - which lack a minimal 1-2 line description in the idiomatic documentation convention of the target language, and it flags excessive comments (narrated decision logs, change history, line-by-line explanations of the obvious), comments merely restating the code, and comments contradicting the code.

OPTIONS

--auto|-a: Automatically apply every proposed correction without asking the user via the interactive dialog.
--severity|-S=(LOW|MEDIUM|HIGH): Set the severity floor (default LOW): findings below the chosen threshold are silently suppressed, ordered LOW < MEDIUM < HIGH. The default LOW keeps all findings; ACCEPTED findings are never suppressed. Surviving findings are reported in descending severity order HIGH, MEDIUM, LOW, ACCEPTED, keeping the file/line order within the same severity.
--include|-i=aspect[,...]: Restrict the checked code quality aspects to the given comma-separated list of aspect ids (e.g. A01,A04). Without this option, all twenty-one aspects are checked.
--exclude|-e=aspect[,...]: Remove the given comma-separated list of aspect ids from the checked code quality aspects. Applied after --include, so -i A01,A02 -e A02 checks A01 only.

ARGUMENTS

source-reference: A file, directory, or other reference to the source code to lint.

SCENARIOS

You want your code checked for code quality problems
You want corrections proposed which you accept or reject one by one
You want all quality corrections applied automatically
You want only specific quality aspects like formatting or spelling checked
You want missing or excessive code documentation flagged

EXAMPLES

Lint a source file interactively:

❯ /ase-code-lint src/server.ts

Lint a directory and automatically apply all corrections:

❯ /ase-code-lint --auto src/handlers/

Lint a directory, reporting only MEDIUM and HIGH findings:

❯ /ase-code-lint -S MEDIUM src/handlers/

Lint a source file for the formatting and spelling aspects only:

❯ /ase-code-lint -i A01,A04 src/server.ts

Lint a directory for all aspects except dead code:

❯ /ase-code-lint --exclude A20 src/handlers/

Lint a directory for the documentation aspect only:

❯ /ase-code-lint -i A21 src/handlers/

NAME

ase-docs-shorten - Shorten a Document to a Target Length

SYNOPSIS

DESCRIPTION

The ase-docs-shorten skill reduces the length of a single document until it reaches a requested target length. The investigation is dispatched to a sub-agent (ase:ase-docs-shorten) so that scanning details do not leak into the user-visible transcript.

The target length is stated either as --chars N or as --words N. The two options are mutually exclusive, exactly one of them is mandatory, and neither carries a default, because the target length is the very quantity the shortening optimizes for. A document reference which expands to more than one document is rejected, as it would leave open whether the target bounds each document or their sum.

The shortening runs as a three-stage cascade, and a stage is entered only while the target is still not met:

Tighten: shorten individual sentences without losing any content - filler words struck, nominal constructions turned into verbs, redundant restatements within a sentence cut.
Drop: remove low-value content - redundant restatements, illustrative examples, asides, parentheticals, and the whole sentences or list items which carry the least value for the reader. Content is genuinely lost in this stage.
Compress: merge and rewrite the remaining content into shorter expressions and sentences - related sentences fused, prose enumerations turned into compact lists, multi-sentence passages re-expressed as single sentences.

The skill never shortens beyond the target: it stops at the first change which reaches it. What survives the shortening stays exact - every surviving fact, number, technical term, qualifier, and negation is preserved verbatim, nothing is invented, the order of the surviving argument is kept, and fenced code blocks, inline code spans, link targets, Markdown frontmatter, and the heading structure are never touched.

Each proposed change is cut as a whole block - a paragraph, a list item, a blockquote, or a heading with its following paragraph - because a shortening is only judgeable in the context of the whole block it rewrites. It is rendered as a unified diff with up to two lines of context, annotated with the length it saves, exactly as in ase-docs-refine and ase-docs-proofread. The user either accepts or rejects each block interactively (or refines it via a free-text hint, which re-proposes the block without limit) or - with --auto - applies all of them automatically. A closing LENGTH REPORT states the achieved length against the target, so rejected blocks stay visible in the outcome.

ase-docs-shorten is the length-reducing member of the document triple. The recommended order over one document is ase-docs-shorten first (cut the bulk), then ase-docs-refine (polish what survives), then ase-docs-proofread (final correctness pass), so no polishing effort is spent on text which is later dropped.

OPTIONS

--chars|-c N: Shorten the document to at most N characters, counted over the entire document content including whitespace and newlines. Mutually exclusive with --words.
--words|-w N: Shorten the document to at most N whitespace-separated words, counted over the entire document content. Mutually exclusive with --chars.
--auto|-a: Automatically apply every proposed shortening without asking the user via the interactive dialog.

ARGUMENTS

docs-reference: A reference to the single document to shorten. A reference expanding to more than one document is rejected.

SCENARIOS

You want a README section cut down to a hard character budget
You want an abstract brought under a word limit for a submission
You want the least valuable examples and asides dropped first
You want to see what a shortening costs before accepting it
You want a whole document shortened unattended in one pass
You want the achieved length reported against the target

EXAMPLES

Shorten a document to at most 4000 characters interactively:

❯ /ase-docs-shorten --chars 4000 README.md

Shorten a document to at most 250 words unattended:

❯ /ase-docs-shorten --auto --words 250 docs/abstract.md

NAME

ase-docs-refine - Refine Document Wording

SYNOPSIS

ase-docs-refine [--help|-h] [--auto|-a] docs-reference

DESCRIPTION

The ase-docs-refine skill performs a light rewriting of awkward or unclear sentences in the referenced documents, without reshaping the argument: restructuring sentences for rhythm and clarity, making enumerations parallel, cutting filler and redundancy, fixing awkward transitions, and adjusting voice. Content, numbers, and technical terms stay exactly as they are. The investigation is dispatched to a sub-agent (ase:ase-docs-refine) so that scanning details do not leak into the user-visible transcript.

The checked refinement types are:

Structure: overlong, convoluted, or awkwardly built sentences, split or restructured for rhythm and clarity.
Nominalization: cumbersome nominal constructions, replaced with plain verbs.
Parallelism: non-parallel enumerations, brought into one grammatical shape - a list whose items mix noun phrases, imperatives, and full sentences, a heading set mixing gerunds and nouns, or an inline series whose members do not share their form.
Filler: filler words, empty intensifiers, and redundant restatements, struck.
Transition: abrupt or misleading transitions between sentences or paragraphs, smoothed. An existing transition is only smoothed or removed - a connective is never inserted where the original asserted no such relation, as that would add a logical claim.
Voice: needless passive voice turned active, needless hedging struck, and shifts in grammatical person or mood aligned with the rest of the document.

The rewriting always stays within a sentence. Dropping a whole sentence, paragraph, example, or list item for the sake of brevity is length reduction, not refinement, and belongs to ase-docs-shorten. The recommended order over one document is ase-docs-shorten first (cut the bulk), then ase-docs-refine (polish what survives), then ase-docs-proofread (final correctness pass), so no polishing effort is spent on text which is later dropped.

For each detected problem, the skill renders a unified-diff REFINEMENT preview and either asks the user to ACCEPT or REJECT the proposed refinement interactively (or refine it via a free-text hint, which re-proposes the refinement without limit) or - with --auto - applies all refinements automatically. A proposal which shifts the meaning even slightly - a lost negation, a changed qualifier, a renamed technical term - is dropped instead of applied.

OPTIONS

--auto|-a: Automatically apply every proposed refinement without asking the user via the interactive dialog.

ARGUMENTS

docs-reference: A file, directory, or other reference to the documents to refine.

SCENARIOS

You want long, convoluted sentences broken into readable ones
You want nominal style like "perform a validation of" turned into verbs
You want a bullet list of mixed noun phrases and sentences made parallel
You want filler words and redundant restatements struck
You want abrupt transitions between paragraphs smoothed
You want needless passive voice or hedging adjusted
You want the wording polished without touching facts or figures

EXAMPLES

Refine a single document interactively:

❯ /ase-docs-refine README.md

Refine an entire documentation directory automatically:

❯ /ase-docs-refine --auto docs/

NAME

ase-docs-proofread - Proofread Documents

SYNOPSIS

ase-docs-proofread [--help|-h] [--auto|-a] docs-reference

DESCRIPTION

The ase-docs-proofread skill analyzes the referenced documents for spelling, capitalization, punctuation, word break, and grammar errors and proposes corrections. The investigation is dispatched to a sub-agent (ase:ase-docs-proofread) so that scanning details do not leak into the user-visible transcript.

For each detected problem, the skill renders a unified-diff CORRECTION preview and either asks the user to ACCEPT or REJECT the proposed correction interactively (or refine it via a free-text hint, which re-proposes the correction without limit) or - with --auto - applies all corrections automatically.

ase-docs-proofread is the correctness-fixing member of the document triple. The recommended order over one document is ase-docs-shorten first (cut the bulk), then ase-docs-refine (polish what survives), then ase-docs-proofread (final correctness pass), so no correction effort is spent on text which is later dropped.

OPTIONS

--auto|-a: Automatically apply every proposed correction without asking the user via the interactive dialog.

ARGUMENTS

docs-reference: A file, directory, or other reference to the documents to proofread.

SCENARIOS

You want documents checked for spelling, capitalization, punctuation, word break, and grammar
You want inconsistent capitalization of terms and headings unified
You want wrong word breaks like "data base" or "check-list" repaired
You want corrections proposed which you accept or reject one by one
You want a whole documentation directory corrected automatically
You want a final language pass over a text before publishing

EXAMPLES

Proofread a single document interactively:

❯ /ase-docs-proofread README.md

Proofread an entire documentation directory automatically:

❯ /ase-docs-proofread --auto docs/

NAME

ase-docs-distill - Distill Document Key Points

SYNOPSIS

ase-docs-distill [--help|-h] [--top|-t N] document-reference

DESCRIPTION

The ase-docs-distill skill reads a provided document and distills it into a flat, importance-ranked list of its key points. The document-reference is resolved probe-as-file-first: if the argument names a readable file it is read from disk; otherwise the argument is taken verbatim as pasted text. The document is read silently - only the final ranked list is shown - so even a large document does not flood the transcript.

Each emitted point is one atomic claim, decision, or fact (not a section-level summary) and carries four things: a 0-10 salience rank reflecting its importance to the reader (impact and centrality, not its position in the document), a one-line rationale justifying why it earns that rank, an exact line-range citation (file:Ls-Le, or :Ls-Le for pasted text), and a verbatim evidence snippet copied from the source that proves the point. The points are emitted as a bulleted list - one block per point, each showing its LOCATION, EVIDENCE, RATIONALE, and RANK - sorted from highest to lowest salience, so the ranking is auditable rather than an opaque ordering.

The --top/-t N option is a length dial that bounds the list to at most N points (default 5). It is an upper bound only: when the document has fewer salient points than N, the skill emits only the points it found and never pads the list with filler; a 0, negative, or non-numeric value falls back to the default 5.

OPTIONS

--top|-t N: Bound the ranked list to at most N key points (default 5). The bound is a cap, never a quota - fewer points are emitted when the document does not contain N salient ones, and an invalid or non-positive N reverts to the default.

ARGUMENTS

document-reference: The document to distill - either a path to a readable file or the text itself pasted inline. If it resolves to a readable file the file is read; otherwise it is treated verbatim as pasted text.

SCENARIOS

You want the key points of a document extracted and ranked
You want the essence of a long text without reading all of it
You want each key point backed by verbatim, line-cited evidence
You want a pasted text or file boiled down to what matters

EXAMPLES

Distill the key points of a document file:

❯ /ase-docs-distill doc/architecture.md

Distill only the top 3 key points:

❯ /ase-docs-distill --top 3 doc/architecture.md

Distill a pasted block of text:

❯ /ase-docs-distill The system shall accept payments in EUR and USD only.

NAME

ase-meta-review - Review Staged Changes

SYNOPSIS

ase-meta-review [--help|-h] [--severity|-S=(LOW|MEDIUM|HIGH)]

DESCRIPTION

The ase-meta-review skill performs a holistic, human-reviewer-style critique of the staged Git changes and emits a single approve / reject verdict backed by prioritized, severity-tagged, line-cited findings. Rather than scanning the code mechanically, it first reconstructs the change's own intent and then judges the diff as a whole against that intent - the way an experienced reviewer would on a pull request.

The critique spans a fixed set of reviewer dimensions: intent (does the diff do what it set out to, without scope creep or stray residue), correctness (latent bugs, edge cases, broken control/data flow), design (fit with the surrounding architecture, naming, abstraction level), clarity (readability and self-documentation for a future reader), robustness (error handling, resource and concurrency safety), security and performance (risks introduced by the change), convention (conformance to the project's documented conventions - code style and the plan/spec formats described in AGENTS.md and the ase-format-* meta documents), testing (inadequate coverage for the change - new or fixed behavior left untested, adjacent tests not updated, or existing tests silently broken, disabled, or weakened), and documentation (user- or developer-facing docs - README, CHANGELOG, help text, or AI guidance/meta documents - left stale by the change).

Each finding carries a severity - HIGH, MEDIUM, LOW, or ACCEPTED (a concern that is contractually addressed or accepted as a documented priority conflict) - and is evidence-grounded: it cites the exact file:line location it stems from. The overall verdict is REJECT - DEMANDS CHANGES when any HIGH finding remains, and APPROVE otherwise. The work is performed by a dedicated ase-meta-review sub-agent so that the silent reading and read-only repository probing never leak into the transcript; only the structured verdict and findings are rendered.

The skill complements rather than duplicates its neighbors: ase-code-lint flags mechanical code-quality issues, ase-code-analyze inspects logic and semantics, ase-meta-diff narrates what changed (with optional coherence, risk, and blast-radius reports), and ase-meta-diaboli adversarially challenges a thesis - whereas ase-meta-review renders a reviewer's judgment on a concrete diff before it is committed.

OPTIONS

--severity|-S=(LOW|MEDIUM|HIGH): Set the severity floor (default LOW): findings below the chosen threshold are silently suppressed, ordered LOW < MEDIUM < HIGH. The default LOW keeps all findings; ACCEPTED findings are never suppressed. Surviving findings are rendered in descending severity order HIGH, MEDIUM, LOW, ACCEPTED. The floor only affects the rendered findings table, not the overall verdict, which is always derived from all findings before the floor is applied.

ARGUMENTS

The ase-meta-review skill takes no positional arguments; it always reviews the currently staged Git changes.

SCENARIOS

You want the staged changes reviewed like a human reviewer would
You want an approve or reject verdict before committing
You want severity-tagged, line-cited findings on a diff
You want a holistic judgment instead of a mechanical lint

EXAMPLES

Review the currently staged changes before committing:

❯ /ase-meta-review

Review the staged changes, reporting only MEDIUM and HIGH findings:

❯ /ase-meta-review -S MEDIUM

NAME

ase-meta-diff - Summarize Diff

SYNOPSIS

ase-meta-diff [--help|-h] [--coherence|-c] [--risk|-r] [--blast|-b]

DESCRIPTION

The ase-meta-diff skill turns a raw Git diff into a concise, human-readable narrative of what changed and why, grouped by intent (such as Feature, Improvement, Bugfix, Update, Cleanup, or Refactor) rather than by file. It inspects the staged changes (git diff --cached HEAD). The result is a compact table, one row per intent group, each naming the affected files with their per-file [+N/-M] line counts - giving you the essence of the changes at a glance.

With --coherence, the skill additionally reconstructs the single intended change the diff is trying to accomplish - phrased as one crisp thesis sentence - and then walks every hunk to flag those that do not serve it: scope creep (an unrelated feature or drive-by refactor riding along) and stray debug (leftover prints, commented-out code, or disabled tests). It emits an overall COHERENT / INCOHERENT verdict plus a table of the flagged hunks with what to do with each - keeping the diff to a single logical and coherent change before it is committed.

With --risk, the skill additionally scores the same diff against a four-axis coupling-criticality-coverage-reversibility rubric and emits a graded risk report - one table row per axis (each scored 1-5 with a one-line evidence justification drawn from the actual hunks), an overall risk band (LOW, MODERATE, HIGH, or CRITICAL), and one actionable mitigation per high-risk axis. The axes combine with equal weights, and the rubric is deliberately not tuned to any specific project: every score is backed by cited evidence so it remains overridable, and the report is decision support, not a merge gate.

With --blast, the skill additionally renders a blast-radius map - a Mermaid flowchart of the touched modules and their reverse dependencies, plus a brief impact summary. It extracts the touched modules from the changed files, scans the repository for the first-party code that imports or references those modules, builds a blast-radius graph (touched modules as origin nodes, dependents fanning out along the edges), dispatches the rendering to the ase-meta-diagram sub-agent, and appends a short bullet list of the per-module impact - giving a visual sense of what a diff endangers before a deeper review.

ARGUMENTS

--coherence, -c: In addition to the intent-grouped summary, reconstruct the diff's single intended change as one crisp thesis sentence and flag every hunk that does not serve it - scope creep or stray debug - then emit an overall COHERENT / INCOHERENT verdict with a table of the flagged hunks.
--risk, -r: In addition to the intent-grouped summary, score the diff against the coupling-criticality-coverage-reversibility rubric and emit a graded risk report with an overall risk band and per-axis mitigations. Scores are equal-weighted, evidence-backed, and deliberately untuned to the project.
--blast, -b: In addition to the intent-grouped summary, render a blast-radius map - a Mermaid flowchart of the touched modules and their reverse dependencies - plus a brief impact summary of what depends on the touched code and how far the blast reaches.

SCENARIOS

You want a readable, intent-grouped summary of the staged changes
You want a diff checked for scope creep and stray debug leftovers
You want a graded risk report of a change before committing
You want a blast-radius map of what depends on the touched code

EXAMPLES

Summarize the currently staged changes:

❯ /ase-meta-diff

Summarize the staged changes and append an intent-coherence report:

❯ /ase-meta-diff --coherence

Summarize the staged changes and append a graded risk report:

❯ /ase-meta-diff --risk

Summarize the staged changes and append a blast-radius map:

❯ /ase-meta-diff --blast

NAME

ase-meta-changelog - Update ChangeLog Entries

SYNOPSIS

ase-meta-changelog [--help|-h]

DESCRIPTION

The ase-meta-changelog skill helps to complete, consolidate, and sort the entries of the most recent section of a CHANGELOG.md file, based on the underlying Git commits and the currently staged changes in the Git index.

Each entry is formatted as <change-type> [<artifact-kind>]: <summary> where change-type is one of FEATURE, IMPROVEMENT, BUGFIX, UPDATE, CLEANUP, or REFACTOR, and artifact-kind is one or more comma-separated artifact class tags out of spec, arch, code, docs, infr, or othr. Entries are grouped and sorted by this prefix. The date in the section header is also updated to the current date.

SCENARIOS

You want the CHANGELOG.md brought up to date with recent commits
You want changelog entries completed, consolidated, and sorted
You want a tidy changelog section before a release

EXAMPLES

Update the most recent ChangeLog section:

❯ /ase-meta-changelog

NAME

ase-meta-commit - Git Commit Message

SYNOPSIS

ase-meta-commit [--help|-h]

DESCRIPTION

The ase-meta-commit skill helps to craft a concise commit message for the currently staged Git changes. It inspects the output of git diff --cached and produces a single-line message of the form <type>: <summary> where type is one of FEATURE, IMPROVEMENT, BUGFIX, UPDATE, CLEANUP, or REFACTOR, and summary is a 60-80 character imperative-mood summary without trailing period or Markdown formatting.

SCENARIOS

You want a commit message for the currently staged changes
You want a typed one-line summary derived from the staged diff
You want to commit but cannot phrase what changed

EXAMPLES

Craft a commit message for the currently staged changes:

❯ /ase-meta-commit

NAME

ase-code-dissect - Dissect a Change Set

SYNOPSIS

DESCRIPTION

The ase-code-dissect skill treats the current Git change set as an epic and dissects it domain-wise and logically into cohesive parts. Each part is a self-contained unit of change with a single coherent purpose, so it can be reviewed and committed atomically and independently of the others.

The change set is captured from the working copy (git diff), with untracked files folded in read-only, or -- under --staged/-s -- from the Git index (git diff --cached HEAD). The dissection follows a strict ruleset: at least 2 and at most count parts are derived, every hunk is assigned to exactly one part, mutually dependent hunks are kept together, all hunks of one file normally stay in the same part, and nothing beyond the actual change set is invented. The cut follows the semantics of the change, not its technical structure -- a split by file, directory, or technical layer is usually not the intended one. If the change set carries only a single cohesive purpose, it is reported as not dissectable and nothing is created.

An optional dissect-hint steers how the change set is split -- which changes belong together, along which axis to cut, or how many parts to aim at. It is especially useful after a --dry run showed an unintended dissection. The hint overrides the default grouping, but never the ruleset itself.

The derived parts are first reported as a dissection table (part number, worktree id, scope, and rationale). Then -- unless --dry is given -- each part's patch is written to a temporary file and applied inside a fresh Git WorkTree .ase/worktree/<project-id>-<feature-slug>, whose branch carries the same name and is created from HEAD. If a CHANGELOG.md file exists, a matching entry summarizing that part is added inside the worktree.

Every part stays uncommitted, a failing git apply is reported for that part while the remaining parts continue, and the original working copy is never mutated.

Note that the working-copy patch (without --staged) is taken relative to the Git index while the worktrees are created from HEAD. So if changes are also staged, the affected part patches may not apply cleanly and are then reported as failed; stage everything and use --staged in that situation.

OPTIONS

--max-parts|-m count: Upper bound for the number of derived parts (default: 8). The lower bound is always 2, because fewer parts are no dissection.
--staged|-s: Dissect the staged changes (the Git index against HEAD) instead of the working copy changes. Untracked files are then not folded in, because they are by definition not part of the index.
--dry|-d: Report only -- print the dissection table but create no artifacts at all, so the decision stays fully reversible. Note that this meaning differs from --dry/-d in ase-code-craft, where it instead omits the ## VERIFICATION section of the composed plan.
--force|-f: Remove and re-create already existing worktrees and branches of the derived names. Without this option, the skill detects colliding targets before writing anything, reports them, and stops with status targets exist.

ARGUMENTS

dissect-hint: A free-text hint telling how the change set should be split. If omitted, the parts are derived from the change set alone.

The worktree names are not argument-driven: they are always derived from the current project id and the per-part feature slug.

SCENARIOS

You want a large uncommitted change set split into atomic parts
You want each cohesive part of a diff in its own Git worktree
You want mixed-up changes untangled before committing them
You want a preview of how a change set would be divided

EXAMPLES

Dissect the current working copy changes:

❯ /ase-code-dissect

Preview the dissection of the staged changes into at most four parts:

❯ /ase-code-dissect --staged --dry --max-parts 4

Re-dissect the changes, re-creating the previously created worktrees:

❯ /ase-code-dissect --force

Dissect the changes along an explicitly given axis:

❯ /ase-code-dissect keep the plugin and tool changes in separate parts

NAME

ase-task-id - Configure Task Id

SYNOPSIS

ase-task-id [--help|-h] [id]

DESCRIPTION

The ase-task-id skill gets or sets the unique task id for the current session. Without arguments, it reports the currently active task id. With an id argument, it switches the session to that task id via the ase_task_id MCP tool.

ARGUMENTS

id: The new task id to activate. If omitted, the currently active task id is reported.

SCENARIOS

You want to know which task is currently active
You want the session switched to another task
You want to work on a certain task

EXAMPLES

Show the current task id:

❯ /ase-task-id

Switch to a specific task:

❯ /ase-task-id hello

NAME

ase-task-edit - Iteratively Edit a Task Plan

SYNOPSIS

DESCRIPTION

The ase-task-edit skill establishes and refines a task plan purely through a chat-driven loop. The user steers each round via an interactive dialog that offers continued refinement, finalization, or hand-off to implementation or preflight.

When a refinement changes the plan text while an IMPLEMENTATION DRAFT section (produced by ase-task-preflight) exists, that section became stale and is removed -- together with the preflighted value of the Properties: frontmatter key -- and a hint is emitted that ase-task-preflight has to be run again to re-create the draft for the changed plan.

OPTIONS

--plan|-p option: Automatically answer the user dialog for the plan refinement with option, which can be either none (default, interactive answer required), OVERWRITE (overwrite an existing plan with instruction), REFINE (refine the existing plan with instruction), or PRESERVE (preserve the existing plan by ignoring instruction and stopping skill processing).
--dry|-d: Generate any new plan without the ## VERIFICATION section. Applies only to freshly generated plans, not to existing plans loaded from disk. When ase-task-implement later applies such a plan, it strictly skips the entire verification phase (no build, tests, linter, type-checker, or program execution) once the source files have been modified.
--next|-n option[,...]: Automatically answer the user dialog for the next step (at the end of this skill). option is a single token or a comma-separated chronological list of tokens; each iteration of the planning loop consumes the first token of the list, and on hand-off (IMPLEMENT / PREFLIGHT) any remaining tokens are forwarded (via --next) to the downstream skill so an entire pipeline can be pre-scripted in one shot. Recognized tokens at this skill: none (default, interactive answer required), DONE (no next step), GRILL (hand-over to ase-task-grill), PREFLIGHT (hand-over to ase-task-preflight), or IMPLEMENT (hand-over to ase-task-implement). Example: --next GRILL,DONE hands the plan off to grilling and forwards DONE so grilling exits without asking.

ARGUMENTS

id | id: instruction | instruction: Edit the task with the unique identifier id (default: default). Optionally, instruction either gives instructions for creating a new task or gives instructions for refining an existing task.

SCENARIOS

You want a task planned through chat-driven refinement
You want a plan created or refined round by round
You want a plan iterated on before implementing it
You want plan refinement with hand-off to preflight or implementation

EXAMPLES

Edit the current task:

❯ /ase-task-edit

Create a new task under id hello:

❯ /ase-task-delete hello
❯ /ase-task-edit hello: new "ase hello" CLI command which prints
  a nice "Hello World!" to the terminal in color blue.

Further refine the task under id hello:

❯ /ase-task-edit hello: change the color to red.

NAME

ase-task-grill - Iteratively Grill a Task Plan

SYNOPSIS

ase-task-grill [--help|-h] [--rounds|-r n] [--next|-n option[,...]] [id]

DESCRIPTION

The ase-task-grill skill relentlessly interviews the user about every essential aspect of an existing task plan until a shared understanding is reached and no decisions or questions are left open.

The skill identifies the essential aspects of the plan and raises up to 10 questions per round which resolve its open points. Each question carries a FOCUS-AREA -- DOMAIN (domain-specifics, must be clarified), INTERFACE (externally observable behavior or UI/API interfaces, must be clarified), ARCHITECTURE (structure, wiring, placement, or dependencies, should be clarified), or IMPLEMENTATION (inner technical details, can be clarified) -- and a 1-2 word ASPECT hint. The questions are sorted primarily by descending focus area importance (DOMAIN, INTERFACE, ARCHITECTURE, IMPLEMENTATION) and secondarily by the decision tree of their dependencies, so each decision is asked after the decisions it depends on. It honors checks for fuzzy language, conflicting terminology, conflicting code, non-concrete scenarios, unspecified architecture patterns, and unspecified dependencies.

In contrast to the batch grilling of ase-code-edit --grill, the questions are asked sequentially, one at a time: each question is announced as an ASPECT n/N ▶ FOCUS ▷ ASPECT, QUESTION line and then raised via an interactive dialog presenting two to four grounded answer alternatives labeled A1-A4 (the current plan, marked with ⚑, plus alternatives derived from the code base and world knowledge), the fixed SKIP GRILLING option (skip the remaining questions and rounds, keeping the answers gathered so far), and free-text input. Cancelling the dialog stops the skill and leaves the plan untouched. Once all aspects are resolved, the plan is updated and persisted, its Properties: frontmatter key gains the value grilled, and the user is offered a hand-off to editing, implementation, or preflight.

OPTIONS

--rounds|-r n: The number of grill rounds to apply (default: 1). Each round starts from scratch from only the current plan, as updated by all previous rounds, and re-derives its questions from it, forgetting all questions and answers of previous rounds. With more than one round, each round is announced as GRILLING ROUND K/L.
--next|-n option[,...]: Automatically answer the user dialog for the next step (at the end of this skill). option is a single token or a comma-separated chronological list of tokens; the first token is consumed by this skill and any remaining tokens are forwarded (via --next) to the downstream skill on hand-off so an entire pipeline can be pre-scripted in one shot. Recognized tokens at this skill: none (default, interactive answer required), DONE (no next step), EDIT (hand-over to ase-task-edit), IMPLEMENT (hand-over to ase-task-implement), or PREFLIGHT (hand-over to ase-task-preflight).

ARGUMENTS

id: Grill the task with the unique identifier id (default: default). The skill accepts only an optional id argument and never a free-text instruction.

SCENARIOS

You want to be interviewed about your plan until it is watertight
You want the open decisions of a plan resolved question by question
You want fuzzy language and conflicts flushed out of a plan
You want shared understanding before the implementation starts

EXAMPLES

Grill the current task plan:

❯ /ase-task-grill

Grill the task plan under id hello:

❯ /ase-task-grill hello

Grill the current task plan in two rounds:

❯ /ase-task-grill --rounds 2

Grill the current task plan and then hand off to editing:

❯ /ase-task-grill --next EDIT

NAME

ase-task-reboot - Reboot a Task Plan

SYNOPSIS

ase-task-reboot [--help|-h] [--next|-n option[,...]] [id]

DESCRIPTION

The ase-task-reboot skill re-creates an existing task plan from scratch by extracting the original **WHAT** and **WHY** sections (if present) from the current plan, using them as the new instruction, preserving the original creation timestamp, and writing fresh plan content via ase_task_save.

After the reboot, the user is asked whether to stop or hand off to ase-task-edit, ase-task-implement, or ase-task-preflight, unless --next pre-selects this choice.

OPTIONS

--next|-n option[,...]: Automatically answer the user dialog for the next step. option is a single token or a comma-separated chronological list of tokens; the first token is consumed by this skill, and any remaining tokens are forwarded (via --next) to the downstream skill so an entire pipeline can be pre-scripted in one shot. Recognized tokens at this skill: none (default, interactive answer required), DONE (stop), EDIT (hand off to ase-task-edit), IMPLEMENT (hand off to ase-task-implement), or PREFLIGHT (hand off to ase-task-preflight). Example: --next EDIT,DONE reboots, hands off to editing, and the editing loop will exit immediately.

ARGUMENTS

id: The unique identifier of the task whose plan should be rebooted. If omitted, the current task id is used.

SCENARIOS

You want a task plan re-created from scratch
You want a fresh plan from the original WHAT and WHY
You want planning restarted after a plan degraded

EXAMPLES

Reboot the current task plan:

❯ /ase-task-reboot

Reboot a specific task and hand off to editing:

❯ /ase-task-reboot --next EDIT hello

NAME

ase-task-preflight - Preflight a Task Plan

SYNOPSIS

ase-task-preflight [--help|-h] [--next|-n option[,...]] [id]

DESCRIPTION

The ase-task-preflight skill performs a preflight (dry-run, test-drive) of the implementation of a task plan by creating a draft for a corresponding, complete artifact change set in unified diff format. The draft is appended to the task plan as an IMPLEMENTATION DRAFT section (replacing any previous draft) and the plan's Properties: frontmatter key gains the value preflighted. No source files are modified. The draft is produced under the same tenets and with the same rigor as a final implementation, because ase-task-implement later takes it over 1:1 after user review -- only the actual artifact modification and the verification phase are deferred.

The kind of change stated by the plan's Kind: frontmatter key (CRAFTING, REFACTORING, or RESOLVING) selects which operation-specific tenet set of the ASE Tenets is internalized before the draft is produced, in addition to the always applying GENERIC TENETS. If a plan carries no such key, the kind is inferred from the plan content, defaulting to CRAFTING.

After the preflight, the user is asked whether to stop, hand off to ase-task-edit, or hand off to ase-task-implement, unless --next pre-selects this choice.

OPTIONS

--next|-n option[,...]: Automatically answer the user dialog for the next step. option is a single token or a comma-separated chronological list of tokens; the first token is consumed by this skill, and any remaining tokens are forwarded (via --next) to the downstream skill so an entire pipeline can be pre-scripted in one shot. Recognized tokens at this skill: none (default, interactive answer required), DONE (stop), EDIT (hand off to ase-task-edit), or IMPLEMENT (hand off to ase-task-implement). Example: --next IMPLEMENT,DONE runs the preflight, hands off to implementation, then exits without asking.

ARGUMENTS

id: The unique identifier of the task whose plan should be preflighted. If omitted, the current task id is used.

SCENARIOS

You want a dry-run of a plan's implementation
You want the change set previewed as a unified diff before applying
You want an implementation draft to review before committing to it
You want a plan test-driven without touching any source files

EXAMPLES

Preflight the current task plan:

❯ /ase-task-preflight

Preflight a specific task and hand off to implementation when done:

❯ /ase-task-preflight --next IMPLEMENT hello

NAME

ase-task-implement - Implement a Task Plan

SYNOPSIS

ase-task-implement [--help|-h] [--next|-n option[,...]] [--worktree|-w] [id]

DESCRIPTION

The ase-task-implement skill performs the final implementation of a task plan by modifying the corresponding artifacts with a complete change set. The plan is loaded and any optional IMPLEMENTATION DRAFT section produced by ase-task-preflight is taken over 1:1 as the change set -- the draft is assumed to be user-reviewed, so no fresh implementation is created and only parts which actually fail are adjusted, guided by the plain plan content. Afterwards the plan's Properties: frontmatter key gains the value implemented (plus verified, if the verification phase actually ran and succeeded), and its Status: key becomes COMPLETED if the change set was applied completely and successfully.

The kind of change stated by the plan's Kind: frontmatter key (CRAFTING, REFACTORING, or RESOLVING) selects which operation-specific tenet set of the ASE Tenets is internalized before any artifact is touched, in addition to the always applying GENERIC TENETS. If a plan carries no such key, the kind is inferred from the plan content, defaulting to CRAFTING.

If the task plan deliberately omits the ## VERIFICATION section (as produced by ase-code-craft, ase-code-refactor, ase-code-resolve, or ase-task-edit when invoked with --dry), the entire verification phase is strictly skipped: no build, tests, linter, type-checker, or program execution is performed once the source files have been modified.

With --worktree|-w, the change set is not applied to the current working copy: a fresh Git WorkTree .ase/worktree/<id> and its equally named branch are created from HEAD before any artifact is touched, and the entire implementation -- including all verification runs -- then happens inside that worktree, which is left uncommitted. The worktree is not named by an option value: it always carries the unique task id, so worktree and branch stay tied to the very task plan implemented in them. As the worktree branches off HEAD, uncommitted changes of the current working copy are not carried over into it.

After implementation, the user is asked whether to preserve or delete the task plan, unless --next pre-selects this choice.

OPTIONS

--next|-n option[,...]: Automatically answer the user dialog for the next step. option is a single token or a comma-separated chronological list of tokens; the first token is consumed by this skill, and any remaining tokens are intentionally discarded, because the downstream ase-task-delete skill accepts no --next option. Recognized tokens at this skill: none (default, interactive answer required), DONE (preserve task plan and stop), or DELETE (hand off to ase-task-delete).
--worktree|-w: Apply the change set inside a dedicated Git WorkTree instead of the current working copy. The worktree directory .ase/worktree/<id> and its equally named branch are derived from the task id and created from HEAD. If either the directory or the branch already exists, the skill stops and touches nothing. By default, the change set is applied to the current working copy.

ARGUMENTS

id: The unique identifier of the task whose plan should be implemented. If omitted, the current task id is used.

SCENARIOS

You want a task plan turned into actual changes
You want the planned change set applied and verified
You want a reviewed implementation draft applied 1:1
You want the implementation isolated in a Git worktree

EXAMPLES

Implement the current task plan:

❯ /ase-task-implement

Implement a specific task and delete the plan when done:

❯ /ase-task-implement --next DELETE hello

Implement the task hello inside the isolated Git WorkTree .ase/worktree/hello:

❯ /ase-task-implement --worktree hello

NAME

ase-task-view - View a Task Plan

SYNOPSIS

ase-task-view [--help|-h] [--full|-f] [id]

DESCRIPTION

The ase-task-view skill renders the task plan identified by id. The plan is loaded via the ase_task_load MCP tool and shown framed between a ( TASK ) header and footer rule. If id is omitted, the current task id (inherited from the session context) is used.

By default, when the plan is longer than 90 lines and contains an IMPLEMENTATION DRAFT section (produced by ase-task-preflight), the content of that section is collapsed to [...] to keep the view compact. The --full|-f option suppresses this collapsing and renders the plan in full, without any truncation or summarization.

OPTIONS

--full|-f: Render the plan in full, without collapsing the IMPLEMENTATION DRAFT section. By default, that section is replaced with [...] for plans longer than 90 lines.

ARGUMENTS

id: The unique identifier of the task plan to view. If omitted, the current task id is used.

SCENARIOS

You want the current or a given task plan shown
You want a plan rendered before deciding the next steps
You want a plan inspected including its implementation draft

EXAMPLES

View the current task plan:

❯ /ase-task-view

View a specific task plan:

❯ /ase-task-view hello

View a plan in full, including its IMPLEMENTATION DRAFT section:

❯ /ase-task-view --full hello

NAME

ase-task-list - List Task Plans

SYNOPSIS

ase-task-list [--help|-h] [--verbose|-v] [--include|-i=state[,...]] [--exclude|-e=state[,...]]

DESCRIPTION

The ase-task-list skill lists all available task ids in the current project by calling the ase_task_list MCP tool. In the default mode, only the task ids are rendered as a single-column Markdown table. In verbose mode, the lifecycle status and the last-modified timestamp of each task plan are rendered as additional columns.

The listing is restricted to an effective state set, derived from the Status: frontmatter key of each task plan (which defaults to DRAFTED for a plan carrying no such key): with --include only, exactly the listed states are shown; with --exclude only, all states except the listed ones; with both, the included ones minus the excluded ones. An unknown state, or a combination which cancels out to an empty set, aborts the skill with an error. By default, --exclude COMPLETED,CANCELLED is in effect, so finished and abandoned task plans stay out of the way. The eight states are:

DRAFTED   APPROVED  STARTED  COMPLETED
REJECTED  DEFERRED  BLOCKED  CANCELLED

OPTIONS

--verbose|-v: Render an additional Status column with the lifecycle state and an additional Last Modified column with the YYYY-MM-DD HH:MM timestamp of each task plan.
--include|-i=state[,...]: Restrict the listed task plans to the given comma-separated list of lifecycle states (e.g. STARTED,BLOCKED). Without this option, all eight states are listed. The none sentinel selects no state at all.
--exclude|-e=state[,...]: Remove the given comma-separated list of lifecycle states from the listed task plans. Applied after --include, so -i DRAFTED,STARTED -e STARTED lists DRAFTED only. Defaults to COMPLETED,CANCELLED; pass --exclude none to suppress the default and list task plans in every state.

SCENARIOS

You want an overview of all task plans
You want task ids listed with status and timestamps
You want the unfinished or in-progress tasks found

EXAMPLES

List all unfinished task ids:

❯ /ase-task-list

List all task ids together with their status and last-modified timestamps:

❯ /ase-task-list --verbose

List the task ids of every task plan, including the finished ones:

❯ /ase-task-list --exclude none

List only the task ids of the task plans currently under work:

❯ /ase-task-list --include STARTED,BLOCKED

NAME

ase-task-rename - Rename a Task Plan

SYNOPSIS

ase-task-rename [--help|-h] [old] new

DESCRIPTION

The ase-task-rename skill renames a task plan from old to new via the ase_task_rename MCP tool. If only one argument is given, it is treated as new and old defaults to the current task id. When the renamed task is the current task, the current task id is automatically switched to new.

ARGUMENTS

[old] new: The old task id to rename and the new task id to assign. If only one token is given, old defaults to the current task id.

SCENARIOS

You want a task plan renamed
You want a task given a better id
You want the current task moved to a new id

EXAMPLES

Rename the current task:

❯ /ase-task-rename hello-world

Rename a specific task:

❯ /ase-task-rename old-id new-id

NAME

ase-task-condense - Condense a Task Plan

SYNOPSIS

ase-task-condense [--help|-h] [--next|-n option[,...]] [id]

DESCRIPTION

The ase-task-condense skill compresses the wording of an existing task plan to make it require as little reading as possible, while keeping all semantics fully preserved and unchanged. It loads the current (or given) plan, applies a self-contained, telegrapher-like "remove-fluff" ruleset to the free-text parts only (the **WHAT** / **WHY** prose and each bullet's specification text), and writes the shorter plan back via ase_task_save.

The plan structure is never altered: all headings, section markers, - **<aspect>**: bullet labels, code spans, technical terms, file paths, numbers, and severities are kept exactly. Only genuinely redundant bullets may be merged, and a shortening that would change meaning is always rejected in favor of the longer wording. The condense ruleset overrides the active session persona, so the plan is compressed telegrapher-like even under the writer persona.

The plan is saved only when condensing actually makes it smaller; if no further reduction is possible, the plan is left untouched (including its Modified: frontmatter timestamp) and reported as already condensed.

After condensing, the user is asked whether to stop or hand off to ase-task-edit, ase-task-implement, or ase-task-preflight, unless --next pre-selects this choice.

OPTIONS

--next|-n option[,...]: Automatically answer the user dialog for the next step. option is a single token or a comma-separated chronological list of tokens; the first token is consumed by this skill, and any remaining tokens are forwarded (via --next) to the downstream skill so an entire pipeline can be pre-scripted in one shot. Recognized tokens at this skill: none (default, interactive answer required), DONE (stop), EDIT (hand off to ase-task-edit), IMPLEMENT (hand off to ase-task-implement), or PREFLIGHT (hand off to ase-task-preflight). Example: --next EDIT,DONE condenses, hands off to editing, and the editing loop will exit immediately.

ARGUMENTS

id: The unique identifier of the task whose plan should be condensed. If omitted, the current task id is used.

SCENARIOS

You want a task plan shortened without losing meaning
You want plan wording compressed for faster reading
You want fluff removed from a plan while keeping all semantics

EXAMPLES

Condense the current task plan:

❯ /ase-task-condense

Condense a specific task and hand off to editing:

❯ /ase-task-condense --next EDIT hello

NAME

ase-task-dissect - Dissect a Task Plan

SYNOPSIS

ase-task-dissect [--help|-h] [--max-parts|-m count] [--dry|-d] [--force|-f] [task-id[:]] [dissect-hint]

DESCRIPTION

The ase-task-dissect skill treats an existing task plan as an epic and dissects it domain-wise and logically into cohesive parts. Each part is a self-contained unit of work with a single coherent purpose, so it can be implemented, reviewed, and committed entirely on its own.

The dissection follows a strict ruleset: at least 2 and at most count parts are derived, every bullet point of the epic's ## CHANGES and ## VERIFICATION sections is assigned to exactly one part, mutually dependent bullet points are kept together, and nothing beyond the epic's own content is invented. A bullet point which itself covers multiple domains is split into fragments, which are then assigned individually -- together they still reproduce the original bullet point completely and without duplication. The cut follows the semantics, not the technical structure -- a split by file, directory, or technical layer is usually not the intended one. If the epic carries only a single cohesive purpose, it is reported as not dissectable and nothing is created.

An optional dissect-hint steers how the epic is split -- which bullet points belong together, along which axis to cut, or how many parts to aim at. It is especially useful after a --dry run showed an unintended dissection. The hint overrides the default grouping, but never the ruleset itself.

The derived parts are first reported as a dissection table (part number, sub-task id, scope, and rationale). Then -- unless --dry is given -- each part is materialized as its own complete sub-task plan (with its own ## CONTEXT, ## CHANGES, and ## VERIFICATION sections) and persisted under the task id <task-id>-<feature-slug>. The epic plan itself always stays untouched.

OPTIONS

--max-parts|-m count: Upper bound for the number of derived parts (default: 8). The lower bound is always 2, because fewer parts are no dissection.
--dry|-d: Report only -- print the dissection table but create no artifacts at all, so the decision stays fully reversible. Note that this meaning differs from --dry/-d in ase-code-craft, where it instead omits the ## VERIFICATION section of the composed plan.
--force|-f: Overwrite already existing sub-task plans. Without this option, the skill detects colliding sub-task ids before writing anything, reports them, and stops with status targets exist.

ARGUMENTS

task-id: The unique identifier of the task whose plan should be dissected. If omitted, the current task id is used. A lone argument matching the task id syntax is always taken as the task id, never as a hint; to combine both, separate them with a : character, as in auth: split by API and UI.
dissect-hint: A free-text hint telling how the epic should be split. If omitted, the parts are derived from the plan alone.

SCENARIOS

You want a large task plan split into cohesive sub-tasks
You want an epic decomposed into independently implementable parts
You want a preview of how a plan would be divided
You want each part of a plan persisted as its own separate plan

EXAMPLES

Dissect the current task plan:

❯ /ase-task-dissect

Preview the dissection of a specific task into at most three parts:

❯ /ase-task-dissect --dry --max-parts 3 auth

Re-dissect a task, overwriting the previously created sub-task plans:

❯ /ase-task-dissect --force auth

Dissect the current task plan along an explicitly given axis:

❯ /ase-task-dissect keep the meta file with the skills, docs separate

Dissect a specific task plan with a hint:

❯ /ase-task-dissect auth: one part per authentication provider

NAME

ase-task-delete - Delete a Task Plan

SYNOPSIS

ase-task-delete [--help|-h] [id]

DESCRIPTION

The ase-task-delete skill deletes the task plan identified by id. If id is omitted, the current task id (inherited from the session context) is used. When the deleted task is the current task and not the default task, the current task id is automatically switched back to default.

ARGUMENTS

id: The unique identifier of the task plan to delete. If omitted, the current task id is used.

SCENARIOS

You want a task plan removed
You want a finished or obsolete task cleared
You want a plan discarded, falling back to the default task

EXAMPLES

Delete the current task plan:

❯ /ase-task-delete

Delete a specific task plan:

❯ /ase-task-delete hello

NAME

ase-arch-analyze - Review Software Architecture

SYNOPSIS

ase-arch-analyze [--help|-h] [--prefix|-P prefix] source-reference

DESCRIPTION

The ase-arch-analyze skill reviews the software architecture of the referenced source code, including package cohesion and inter-package coupling, for potential problems across component boundaries, structural organization, architecture principles, interface quality, quality attributes, and architecture governance.

The skill investigates 21 architecture quality aspects across 7 thematic blocks (component boundaries, structural organization, architecture principles, interface quality, quality attributes, architecture governance, and package cohesion), renders a high-level architecture diagram, and reports findings as either PROBLEM or TRADEOFF entries based on a built-in tension matrix.

The --prefix|-P prefix option prefixes every reported finding id with prefix and a hyphen, so P1 becomes <prefix>-P1 and T1 becomes <prefix>-T1, with the persisted keys becoming ase-issue-<prefix>-P1 and ase-issue-<prefix>-T1 accordingly. The purge of stale results is narrowed to the same namespace, so analyses run under distinct prefixes coexist instead of overwriting each other. Without the option (the default), ids stay unprefixed and the purge covers the entire ase-issue-* space, including any prefixed results.

ARGUMENTS

source-reference: A file, directory, or other reference to the source code that is to be analyzed architecturally.

SCENARIOS

You want the software architecture of your code base reviewed
You want coupling and cohesion problems between packages found
You want an architecture diagram plus PROBLEM and TRADEOFF findings
You want architecture findings persisted for later resolution

EXAMPLES

Analyze architecture of the current project:

❯ /ase-arch-analyze src/

Analyze a specific module:

❯ /ase-arch-analyze src/core

Analyze a module under its own id namespace, yielding core-P1, core-T1, ...:

❯ /ase-arch-analyze --prefix core src/core

NAME

ase-code-analyze - Analyze Source Code

SYNOPSIS

DESCRIPTION

The ase-code-analyze skill analyzes the source code of the referenced location, and its directly related source code, for problems. It is read-only and advisory: it reports problems but applies no changes.

The analysis lens depends on the selected options:

default (neither --performance nor --security): problems in its logic, semantics, and related control flow.
--performance|-p: problems in performance and efficiency.
--security|-s: problems in security.

The --performance and --security options are mutually exclusive.

The --severity|-S=(LOW|MEDIUM|HIGH) option sets a severity floor (default LOW): problems below the chosen threshold are silently suppressed (neither reported nor persisted), ordered LOW < MEDIUM < HIGH. The default LOW keeps all problems; ACCEPTED problems are never suppressed. Surviving problems are reported in descending severity order HIGH, MEDIUM, LOW, ACCEPTED - keeping the file/line order within the same severity - and are renumbered contiguously as P<n>, so P1 is the most severe problem.

The --prefix|-P prefix option prefixes every reported problem id with prefix and a hyphen, so P1 becomes <prefix>-P1 and its persisted key becomes ase-issue-<prefix>-P1. The purge of stale results is narrowed to the same namespace accordingly, so analyses run under distinct prefixes coexist instead of overwriting each other. Without the option (the default), ids stay unprefixed and the purge covers the entire ase-issue-* space, including any prefixed results.

The skill investigates the code base silently, reports each detected problem as a PROBLEM entry with severity (LOW, MEDIUM, HIGH) and inline file/line references (in the performance lens, each entry additionally carries an evidence and a trade-off line), and persists results in the ase MCP key/value store as ase-issue-P<n> entries so they can later be resolved via ase-code-resolve P<n> or directly fixed via ase-code-edit P<n>.

ARGUMENTS

source-reference: A file, directory, function, or other reference to the source code to analyze.

SCENARIOS

You want your code checked for logic, semantics, and control-flow problems
You want a read-only report of problems without any changes applied
You want performance and efficiency opportunities surfaced
You want a security-focused inspection of your code
You want problems persisted as issue ids like P1 for later resolving

EXAMPLES

Analyze a specific source file for logic/semantic problems:

❯ /ase-code-analyze src/server.ts

Analyze a directory of code:

❯ /ase-code-analyze src/handlers/

Analyze a source file for performance/efficiency opportunities only:

❯ /ase-code-analyze --performance src/server.ts

Analyze a source file for security aspects only:

❯ /ase-code-analyze -s src/handlers/

Analyze a directory, reporting only MEDIUM and HIGH problems:

❯ /ase-code-analyze -S MEDIUM src/handlers/

Analyze a directory under its own id namespace, yielding auth-P1, auth-P2, ...:

❯ /ase-code-analyze --prefix auth src/auth/

NAME

ase-code-craft - Craft Source Code

SYNOPSIS

DESCRIPTION

The ase-code-craft skill crafts a new feature from scratch by investigating the existing code base, internalizing crafting tenets (KISS, YAGNI, DRY, SRP, loose coupling, ...), proposing one or more feature approaches with pros and cons, letting the user pick the preferred approach, and composing a corresponding task plan aligned with the existing architecture.

By default the skill does not directly modify source files. It persists the plan via ase_task_save and then hands off to ase-task-edit, ase-task-preflight, or ase-task-implement, as selected by --next. Only under --direct it skips the plan entirely and applies the change set to the affected artifacts itself.

OPTIONS

--auto|-a: Automatically pick the recommended feature approach without asking the user via the interactive dialog.
--dry|-d: Compose the plan without the ## VERIFICATION section. When ase-task-implement later applies such a plan, it strictly skips the entire verification phase (no build, tests, linter, type-checker, or program execution) once the source files have been modified.
--direct|-D: Craft the feature immediately and in place: skip the feature approaches, the interactive dialog, and the entire task plan ceremony, and directly apply the complete change set to the affected artifacts, including a corresponding entry in an existing CHANGELOG.md file. In this mode --auto, --dry, --quick, and --next have no effect, as neither approaches are proposed nor a plan is composed.
--interactive|-i: Craft interactively: implies --direct and, once the initial feature has been applied, repeatedly asks for the next change with a free-text dialog and immediately applies it in place, too, until the user stops the loop by answering DONE.
--quick|-Q: Shorthand alias for -a -d -n IMPLEMENT,DELETE: automatically pick the recommended feature approach, compose the plan without the ## VERIFICATION section, immediately hand off to ase-task-implement, and finally ase-task-delete the now-consumed plan. This gives a single, fast one-shot crafting mode.
--next|-n option[,...]: Automatically choose the next step after composing the plan. option is a single token or a comma-separated chronological list of tokens; an IMPLEMENT, PREFLIGHT, or GRILL head token is consumed by this skill (bypassing ase-task-edit), and any remaining tokens are forwarded (via --next) to the downstream skill. For all other head tokens, the entire list is forwarded to ase-task-edit, which consumes its head itself. This lets an entire pipeline be pre-scripted in one shot. Recognized tokens at this skill: none (default, hand off to ase-task-edit interactively), DONE (stop), EDIT (hand off to ase-task-edit), GRILL (hand off to ase-task-grill), PREFLIGHT (hand off to ase-task-preflight), or IMPLEMENT (hand off to ase-task-implement). Example: --next PREFLIGHT,IMPLEMENT,DONE crafts the plan, preflights it, implements it, and exits without further dialog.

ARGUMENTS

[task-id:] feature: Description of the feature to craft. Optionally prefixed with a task-id followed by a colon to bind the resulting plan to a specific task id.

SCENARIOS

You want to add a new feature to the code base
You want feature approaches with pros and cons before any code changes
You want a task plan composed for building something new
You want a fast one-shot crafting without any plan ceremony

EXAMPLES

Craft a new logging feature:

❯ /ase-code-craft add structured JSON logging with log levels

Craft a feature under a named task and directly hand off to implementation:

❯ /ase-code-craft --next IMPLEMENT auth: add JWT authentication middleware

Craft interactively, applying one change after the other in place:

❯ /ase-code-craft -i add a --verbose option to the CLI

NAME

ase-code-refactor - Refactor Artifacts

SYNOPSIS

DESCRIPTION

The ase-code-refactor skill refactors existing artifacts by investigating the related code, internalizing refactoring tenets (Behavior Preservation, Boy Scout Rule, DRY, SRP, loose coupling, clear interfaces, ...), proposing one or more refactoring approaches with pros and cons, letting the user pick the preferred approach, and composing a corresponding task plan.

OPTIONS

--auto|-a: Automatically pick the recommended refactoring approach without asking the user via the interactive dialog.
--dry|-d: Compose the plan without the ## VERIFICATION section. When ase-task-implement later applies such a plan, it strictly skips the entire verification phase (no build, tests, linter, type-checker, or program execution) once the source files have been modified.
--direct|-D: Apply the refactoring immediately and in place: skip the refactoring approaches, the interactive dialog, and the entire task plan ceremony, and directly apply the complete change set to the affected artifacts, including a corresponding entry in an existing CHANGELOG.md file. In this mode --auto, --dry, --quick, and --next have no effect, as neither approaches are proposed nor a plan is composed.
--quick|-Q: Shorthand alias for -a -d -n IMPLEMENT,DELETE: automatically pick the recommended refactoring approach, compose the plan without the ## VERIFICATION section, immediately hand off to ase-task-implement, and finally ase-task-delete the now-consumed plan. This gives a single, fast one-shot refactoring mode.
--next|-n option[,...]: Automatically choose the next step after composing the plan. option is a single token or a comma-separated chronological list of tokens; an IMPLEMENT, PREFLIGHT, or GRILL head token is consumed by this skill (bypassing ase-task-edit), and any remaining tokens are forwarded (via --next) to the downstream skill. For all other head tokens, the entire list is forwarded to ase-task-edit, which consumes its head itself. This lets an entire pipeline be pre-scripted in one shot. Recognized tokens at this skill: none (default, hand off to ase-task-edit interactively), DONE (stop), EDIT (hand off to ase-task-edit), GRILL (hand off to ase-task-grill), PREFLIGHT (hand off to ase-task-preflight), or IMPLEMENT (hand off to ase-task-implement). Example: --next PREFLIGHT,IMPLEMENT,DONE refactors, preflights, implements, and exits without further dialog.

ARGUMENTS

[task-id:] request: Description of the refactoring request. Optionally prefixed with a task-id followed by a colon to bind the resulting plan to a specific task id.

SCENARIOS

You want existing code restructured without changing its behavior
You want refactoring approaches with pros and cons before any changes
You want a task plan composed for a cleanup
You want a one-shot refactoring applied directly in place

EXAMPLES

Refactor a module into smaller files:

❯ /ase-code-refactor split src/handlers.ts into per-route modules

Refactor under a named task and directly hand off to implementation:

❯ /ase-code-refactor --next IMPLEMENT cleanup: extract HTTP client into its own class

NAME

ase-code-resolve - Resolve Problem

SYNOPSIS

DESCRIPTION

The ase-code-resolve skill resolves a bug or problem by investigating the related code, internalizing resolution tenets (Surgical Changes, No Cleanups, Minimum Flags, Code Adequacy, Origin Proximity, ...), proposing one or more resolution approaches with pros and cons, letting the user pick the preferred approach, and composing a corresponding task plan.

The problem may also be given as a bare issue identifier (e.g. P1 or T1) previously produced by ase-code-analyze or ase-arch-analyze and persisted in the ase MCP key/value store under ase-issue-<id>.

OPTIONS

--auto|-a: Automatically pick the recommended resolution approach without asking the user via the interactive dialog.
--dry|-d: Compose the plan without the ## VERIFICATION section. When ase-task-implement later applies such a plan, it strictly skips the entire verification phase (no build, tests, linter, type-checker, or program execution) once the source files have been modified.
--direct|-D: Resolve the problem immediately and in place: skip the resolution approaches, the interactive dialog, and the entire task plan ceremony, and directly apply the complete change set to the affected artifacts, including a corresponding entry in an existing CHANGELOG.md file. In this mode --auto, --dry, --quick, and --next have no effect, as neither approaches are proposed nor a plan is composed.
--quick|-Q: Shorthand alias for -a -d -n IMPLEMENT,DELETE: automatically pick the recommended resolution approach, compose the plan without the ## VERIFICATION section, immediately hand off to ase-task-implement, and finally ase-task-delete the now-consumed plan. This gives a single, fast one-shot resolution mode.
--next|-n option[,...]: Automatically choose the next step after composing the plan. option is a single token or a comma-separated chronological list of tokens; an IMPLEMENT, PREFLIGHT, or GRILL head token is consumed by this skill (bypassing ase-task-edit), and any remaining tokens are forwarded (via --next) to the downstream skill. For all other head tokens, the entire list is forwarded to ase-task-edit, which consumes its head itself. This lets an entire pipeline be pre-scripted in one shot. Recognized tokens at this skill: none (default, hand off to ase-task-edit interactively), DONE (stop), EDIT (hand off to ase-task-edit), GRILL (hand off to ase-task-grill), PREFLIGHT (hand off to ase-task-preflight), or IMPLEMENT (hand off to ase-task-implement). Example: --next IMPLEMENT,DONE resolves the problem, implements it, and exits without further dialog.

ARGUMENTS

[task-id:] problem: Description of the problem to resolve, or a bare issue identifier like P1 or T1 previously produced by an analyzer skill. Optionally prefixed with a task-id followed by a colon to bind the resulting plan to a specific task id.

SCENARIOS

You want a bug fixed or a problem resolved in the code
You want an issue like P1 reported by an analyzer resolved
You want resolution approaches with pros and cons before any changes
You want a task plan composed for a bugfix

EXAMPLES

Resolve a free-text problem:

❯ /ase-code-resolve fix race condition in cache invalidation

Resolve a previously analyzed issue and hand off to implementation:

❯ /ase-code-resolve --next IMPLEMENT P1

NAME

ase-code-edit - Edit Source Code

SYNOPSIS

DESCRIPTION

The ase-code-edit skill edits the code base directly from a query, in one shot and without any task plan ceremony. It is a plan-less fusion of ase-code-craft, ase-code-refactor, ase-code-resolve, ase-task-grill, and ase-task-implement.

Each single-shot run (or each --loop iteration) walks through five states: querying (take the query argument or ask for a query via an interactive Edit Query dialog, and split it into its domain-specific WHAT and its implementation-detail HOW parts), discovering (read the source artifacts related to the query), grilling (optionally stress-test the query with rounds of questions), implementing (apply the change set in place, honoring the tenet set selected via --mode), and verifying (optionally verify the implementation until it passes). The querying state and every grilling round close with an EDIT TODO box showing the established WHAT and HOW information.

OPTIONS

--mode|-m auto|craft|refactor|resolve: Select the tenet set internalized for the implementation: craft (CRAFTING), refactor (REFACTORING), or resolve (RESOLVING). The default auto infers the tenet set from the query itself.
--grill|-g: Grill the query before implementing, similar to ase-task-grill: raise 1-10 questions per round which resolve the open points of the query. Each question carries a FOCUS-AREA -- DOMAIN (domain-specifics, must be clarified), INTERFACE (externally observable behavior or UI/API interfaces, must be clarified), ARCHITECTURE (structure, wiring, placement, or dependencies, should be clarified), or IMPLEMENTATION (inner technical details, can be clarified) -- and a 1-2 word TOPIC hint. The questions of a round are sorted by descending focus area importance (DOMAIN, INTERFACE, ARCHITECTURE, IMPLEMENTATION). All questions of a round are announced together below a GRILLING ROUND K/L line (the announcement line and round numbering are omitted when only a single round is performed) as an #/FOCUS ▶ TOPIC/QUESTION table with one row per question, each row carrying two to four grounded answer alternatives (with the alternative reflecting the current understanding marked as CURRENT). They are then asked in one batch via a single interactive dialog titled GRILLING ROUND K/L (or plain GRILLING for a single round), whose question asks for the combined answer to all (or a subset) of the listed aspect questions and whose only answer options are the fixed STOP SKILL (stop the skill) and SKIP GRILLING (skip the remaining grilling) ones, plus free-text input. The answers are merged back into the WHAT and HOW parts of the query. Without --grill, no questions are asked at all.
--grill-rounds|-r n: The number of grill rounds to apply (default: 1). Each round starts from scratch from only the current WHAT and HOW parts, forgetting all information of previous rounds, and closes with an EDIT TODO box. Only effective together with --grill.
--verify|-v: Verify whether the implementation fulfills the requirements, by running the available verification commands (build, tests, linter, type-checker) and adjusting the failing parts of the change set until the verification passes. Without --verify, strictly no verification is performed at all.
--worktree|-w: Apply the change sets inside a dedicated Git worktree (as ase-task-implement --worktree) instead of the current working copy. One single worktree, named by a two-word id derived from the first query, serves the whole skill run: all --loop iterations land in it and it is left uncommitted for review.
--loop|-l: Loop the whole state cycle: after each iteration, ask for the next edit query via the interactive Edit Query dialog and repeat, until the user answers with its fixed STOP SKILL option or cancels the dialog.

ARGUMENTS

query: Description of the edit to perform. When omitted, the skill asks for the query via an interactive Edit Query dialog, carrying the fixed STOP SKILL option plus free-text input.

SCENARIOS

You want the code base edited in one shot from a plain description
You want an analyzer issue like P1 fixed directly without a plan
You want a quick change with optional grilling and verification
You want several edits chained in a loop, optionally in a worktree

EXAMPLES

Edit in one shot, without any questions or verification:

❯ /ase-code-edit add a --verbose option to the CLI

Grill the query with two rounds first, then implement and verify:

❯ /ase-code-edit -g -r 2 -v refactor the config loading into layers

Loop over multiple edits inside a dedicated Git worktree:

❯ /ase-code-edit -l -w

NAME

ase-spec-edit - Edit Specification

SYNOPSIS

DESCRIPTION

The ase-spec-edit skill edits the SpecBook-based specification (SPEC) directly from a query, in one shot and without any task plan ceremony. It is the specification-level counterpart of ase-code-edit and a plan-less alternative to ase-sync-import and ase-sync-reconcile whenever the specification has to be changed from a plain description instead of from a foreign source or another artifact kind.

Each single-shot run (or each --loop iteration) walks through five states: querying (take the query argument or ask for a query via an interactive Edit Query dialog, and split it into its domain-specific WHAT and its implementation-detail HOW parts), discovering (resolve the SPEC artifacts, read the SpecBook schema configuration of the project, and read the specification artifacts related to the query), grilling (optionally stress-test the query with rounds of questions), implementing (apply the change set in place, honoring the GENERIC and SPECIFYING tenets and the SPEC format contract), and verifying (optionally validate the specification until it passes). The querying state and every grilling round close with an EDIT TODO box showing the established WHAT and HOW information.

The change set stays strictly restricted to the SPEC artifacts -- the artifact kinds CODE, DOCS, TASK, INFR, and OTHR are never touched. Every generated artifact carries the current Created: and Modified: timestamps, and every changed artifact gets its Modified: timestamp refreshed.

OPTIONS

--grill|-g: Grill the query before implementing, similar to ase-task-grill: raise 1-10 questions per round which resolve the open points of the query. Each question carries a FOCUS-AREA -- DOMAIN (domain-specifics, must be clarified), INTERFACE (externally observable behavior or UI/API interfaces, must be clarified), ARCHITECTURE (structure, wiring, placement, or dependencies, should be clarified), or IMPLEMENTATION (inner technical details, can be clarified) -- and a 1-3 word TOPIC hint. The questions of a round are sorted by descending focus area importance (DOMAIN, INTERFACE, ARCHITECTURE, IMPLEMENTATION) and are announced together below a GRILLING ROUND K/L line (the round numbering is omitted when only a single round is performed) as a QUESTION/ANSWERS table with one row per question, each row carrying two to three grounded answer alternatives (with the alternative reflecting the current understanding marked with ⚑). They are then asked in one batch via a single interactive dialog, whose question asks for the combined answer to all (or a subset) of the listed questions and whose only answer options are the fixed SKIP GRILLING (skip the remaining grilling) and STOP SKILL (stop the skill) ones, plus free-text input. The answers are merged back into the WHAT and HOW parts of the query. Without --grill, no questions are asked at all.
--grill-rounds|-r n: The number of grill rounds to apply (default: 1). Each round starts from scratch from only the current WHAT and HOW parts, forgetting all information of previous rounds, and closes with an EDIT TODO box. Only effective together with --grill.
--verify|-v: Verify the edited specification by validating it via SpecBook linting and fixing the reported diagnostics in the affected SPEC artifacts, for at most three rounds. Any diagnostics remaining after the last round are listed as REMAINING DIAGNOSTICS. Without --verify, strictly no validation is performed at all.
--worktree|-w: Apply the change sets inside a dedicated Git worktree (as ase-task-implement --worktree) instead of the current working copy. One single worktree, named by a two-word id derived from the first query, serves the whole skill run: all --loop iterations land in it and it is left uncommitted for review. Under --verify, the validation then runs as the ase spec lint command inside the worktree.
--loop|-l: Loop the whole state cycle: after each iteration, ask for the next edit query via the interactive Edit Query dialog and repeat, until the user answers with its fixed STOP SKILL option or cancels the dialog.

ARGUMENTS

query: Description of the specification edit to perform. When omitted, the skill asks for the query via an interactive Edit Query dialog, carrying the fixed STOP SKILL option plus free-text input.

SCENARIOS

You want the specification edited in one shot from a description
You want SPEC changes without the task plan ceremony
You want the query stress-tested by grilling before the spec is edited
You want specification edits validated by SpecBook linting

EXAMPLES

Edit in one shot, without any questions or validation:

❯ /ase-spec-edit add a Reviewer persona to the persona model

Grill the query with two rounds first, then edit and validate:

❯ /ase-spec-edit -g -r 2 -v split the Event entity into Event and EventSeries

Loop over multiple specification edits inside a dedicated Git worktree:

❯ /ase-spec-edit -l -w

NAME

ase-sync-reconcile - Reconcile Artifact Set to Artifact Set

SYNOPSIS

DESCRIPTION

The ase-sync-reconcile skill reconciles one set of artifact kinds (the target) to reflect the current state of another set of artifact kinds (the source). It reads the source artifacts and then adjusts the target artifacts directly and surgically to match the source state, while optionally honoring a filtering hint.

Both target and source are comma-separated lists over the six recognized artifact kinds SPEC (Specification, covering both requirements and architecture), CODE (Source Code), DOCS (Documentation), TASK (Task Plans), INFR (Infrastructure), and OTHR (catch-all). When source is auto, it resolves to all six kinds minus the kinds listed in target. Unless --bidirectional is given, a kind present in target is never used as its own source.

The file lists for all involved kinds are resolved via the ase_artifact_list MCP tool of the ase MCP server. While reconciling, the skill honors the artifact-format conventions of ase-format-meta.md, ase-format-spec.md (the SpecBook models and formats plus the SpecBook schema configuration), and ase-format-task.md; the kinds CODE, DOCS, INFR, and OTHR have no dedicated format contract and are treated as free-form. Changed SPEC artifacts are validated via the ase_specbook_lint MCP tool and the reported diagnostics are fixed in at most three rounds; any remaining diagnostics are surfaced.

The changes on the target side are the three operations add (create content and files the source warrants but the target lacks), update (change existing content the source contradicts), and remove (delete content and files the source no longer supports). The --operation option restricts which of them are applied; whatever an excluded operation would have changed stays untouched. With --dry, no target artifact is modified at all and the intended changes are shown as a unified diff instead.

OPTIONS

--bidirectional|-b: Reconcile the target and source artifacts so that they faithfully reflect the current state of each other, instead of only updating the target from the source. With this flag, a kind present in target is not removed from source, and the --operation restriction applies to both directions.
--operation|-o op[,...]: The comma-separated list of operations to apply on the target side, each one of add, update, or remove. The special value all (the default) selects all three operations.
--dry|-d: Perform the regular reconciliation, but do not modify any target artifact (neither files nor task plans). Instead, show the intended changes as a single unified diff. The SpecBook validation is skipped, as nothing is written to disk.
--target|-t target[,...]: The comma-separated list of artifact kinds to update. Required (the skill errors out on an empty target).
--source|-s source[,...]: The comma-separated list of artifact kinds to update from. The special value auto resolves to all recognized kinds except those in target.

ARGUMENTS

hint: An optional free-form filtering hint that narrows the source and/or target artifacts, or the aspects of those artifacts to take into account during reconciliation.

SCENARIOS

You want one artifact set updated to reflect another one
You want code and docs aligned with the specification
You want the specification recovered from the code base
You want spec and code bidirectionally synchronized
You want only missing parts added to the documentation, never anything removed
You want to preview the reconciliation as a diff before applying it

EXAMPLES

Reconcile the code and documentation to reflect the current specification in a "forward engineering" approach:

❯ /ase-sync-reconcile -t CODE,DOCS -s SPEC

Reconcile the specification from everything else in a "reverse engineering" approach:

❯ /ase-sync-reconcile -t SPEC -s CODE,DOCS

Bidirectionally reconcile specification and code against each other, limited to the authentication aspect:

❯ /ase-sync-reconcile -b -t SPEC -s CODE authentication

Add missing and update outdated parts of the documentation from the code, but never remove anything:

❯ /ase-sync-reconcile -o add,update -t DOCS -s CODE

Preview the reconciliation of the code from the specification as a unified diff, without applying it:

❯ /ase-sync-reconcile -d -t CODE -s SPEC

NAME

ase-sync-import - Import Foreign Sources into Artifact Set

SYNOPSIS

ase-sync-import [--help|-h] [--target|-t target[,...]] hint

DESCRIPTION

The ase-sync-import skill imports information from foreign sources into a set of artifact kinds (the target), generating or updating the target artifacts so they faithfully reflect the imported information. Unlike ase-sync-reconcile, which syncs between existing ASE artifact kinds, ase-sync-import brings in information from external sources that live outside the ASE artifact sets.

The foreign sources are named by the free-form hint argument and may be local files or directories, remote URLs, pasted text passages, or references to other documents. Local files are read via the Read tool and remote URLs are fetched via the available web tools.

The target is a comma-separated list over the six recognized artifact kinds SPEC (Specification, covering both requirements and architecture), CODE (Source Code), DOCS (Documentation), TASK (Task Plans), INFR (Infrastructure), and OTHR (catch-all). It defaults to SPEC. The file lists for the involved kinds are resolved via the ase_artifact_list MCP tool of the ase MCP server.

While importing, the skill honors the artifact-format conventions of ase-format-meta.md, ase-format-spec.md (the SpecBook models and formats plus the SpecBook schema configuration), and ase-format-task.md; the kinds CODE, DOCS, INFR, and OTHR have no dedicated format contract and are treated as free-form. A target artifact that does not yet exist but is warranted by the imported information is generated from scratch, while an existing target artifact is surgically updated to reflect the imported information. Generated or updated SPEC artifacts are validated via the ase_specbook_lint MCP tool and the reported diagnostics are fixed in at most three rounds; any remaining diagnostics are surfaced.

OPTIONS

--target|-t target[,...]: The comma-separated list of artifact kinds to generate or update. Defaults to SPEC. The skill errors out on an empty target or an unknown/unsupported kind.

ARGUMENTS

hint: The mandatory free-form description of the foreign sources to import from (e.g. a file path, directory, URL, or pasted text). The skill errors out on an empty hint.

SCENARIOS

You want external sources brought into the project artifacts
You want a foreign document, URL, or pasted text reflected in the SPEC
You want requirements from outside imported into a task plan
You want legacy material ingested into the specification

EXAMPLES

Import a foreign requirements document into the specification:

❯ /ase-sync-import -t SPEC docs/legacy/requirements.txt

Import an external design write-up into the specification (the default target), which covers the architecture, too:

❯ /ase-sync-import https://example.com/design-notes.html

Import a pasted feature description into a task plan:

❯ /ase-sync-import -t TASK the new export feature must support CSV and JSON

NAME

ase-sync-export - Export Specification into Rendered Files

SYNOPSIS

ase-sync-export [--help|-h] [--output|-o output[,...]]

DESCRIPTION

The ase-sync-export skill exports the SPEC artifact set -- the SpecBook-based specification of the project, located via the project.artifact.spec.basedir configuration -- into derived, ready-to-consume renderings. The specification is first validated against the SpecBook schema configuration via the ase_specbook_lint MCP tool of the ase MCP server; on any diagnostic the skill errors out and exports nothing, as a partial or invalid specification must never be rendered. Otherwise every requested output is rendered via the ase_specbook_export MCP tool.

Each output is an [<format>:]<file> entry, where the format is one of json, json5, yaml, toon (the specification object model), html (self-contained single document with table of contents, full-text search, and light/dark theme), pdf (paginated print document), or md (normalized single Markdown document). The format is inferred from the filename extension unless it is explicitly given as a prefix. The standard output sentinel - is not supported.

The pdf format is the only one with an external prerequisite: it prints the rendering through a Chromium-class browser. Neither npm install -g @rse/ase nor ase setup install downloads one, so unless a Google Chrome is installed system-wide, the Playwright Chromium has to be fetched once via npx playwright install chromium. Without any such browser the export fails up-front, before the specification is parsed, and reports that very command; when it falls back onto a system-installed Google Chrome, the skill reports this as an environment notice.

OPTIONS

--output|-o output[,...]: The comma-separated list of [<format>:]<file> entries to render, with each file path relative to the project root. Defaults to the single HTML rendering index.html inside the SPEC base directory (e.g. docs/specbook/index.html).

SCENARIOS

You want the specification rendered as HTML, PDF, Markdown, or JSON
You want a shareable, ready-to-consume export of the SPEC artifacts
You want the specification validated and then materialized into files

EXAMPLES

Export the specification to its default HTML rendering:

❯ /ase-sync-export

Export the specification as HTML and PDF:

❯ /ase-sync-export -o docs/spec.html,docs/spec.pdf

Export the specification object model as YAML into a file without a telling extension:

❯ /ase-sync-export -o yaml:docs/spec.model