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.
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
SEE ALSO
ase-help-intent, ase-meta-proximity.
ase-help-intent - Match an Intent to an ASE Command
NAME
ase-help-intent - Match an Intent to an ASE Command
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 the single best-fitting
/ase:ase-xxx-xxx command that realizes the intent, complete with
concrete option flags and positional arguments derived from the selected
skill's SYNOPSIS, OPTIONS, and ARGUMENTS.
The generated command is presented together with a brief rationale in an
interactive dialog. The dialog lets the user execute the command (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 best-fitting command is
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 skill and which
options and arguments realize it.
EXAMPLES
Route an intent to the matching command and pick from the dialog:
❯ /ase-help-intent lint the TypeScript sources for high-severity issues only
Route a planning intent to the matching command:
❯ /ase-help-intent explain how the authentication module works
SEE ALSO
ase-help-skill, ase-meta-proximity, ase-meta-search,
ase-code-craft.
ase-meta-config - Configuration Management
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.
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
SEE ALSO
ase-task-id.
ase-meta-why - Five-Whys Root-Cause Analysis
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.
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
SEE ALSO
ase-code-analyze, ase-code-resolve, ase-arch-analyze.
ase-meta-eli5 - Explain a Topic Like I'm 5
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.
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?
SEE ALSO
ase-code-explain, ase-meta-search, ase-meta-quotes, ase-docs-distill.
ase-meta-proximity - Determine the Conceptual Proximity of a Topic
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.
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
SEE ALSO
ase-meta-quotes, ase-meta-eli5, ase-meta-search, ase-code-explain.
ase-meta-quotes - Find Quotes on a Topic
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.
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
SEE ALSO
ase-meta-proximity, ase-meta-search, ase-meta-eli5.
ase-meta-evaluate - Evaluate Alternatives
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.
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.
SEE ALSO
ase-meta-quorum, ase-meta-search, ase-arch-discover,
ase-meta-why.
ase-meta-diaboli - Play "Devil's Advocate" (Latin: "Advocatus Diaboli")
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.
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.
SEE ALSO
ase-meta-why, ase-meta-evaluate, ase-meta-quorum,
ase-meta-steelman.
ase-meta-steelman - Build the "Steelman" Argument
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.
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.
SEE ALSO
ase-meta-diaboli, ase-meta-why, ase-meta-evaluate,
ase-meta-quorum.
ase-meta-quorum - Query Multiple AIs for Quorum Answer
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.
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?
SEE ALSO
ase-meta-chat, ase-meta-search, ase-meta-evaluate.
ase-meta-chat - Query Foreign LLM for Chat
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.
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.
SEE ALSO
ase-meta-quorum, ase-meta-search.
ase-meta-search - Search the Internet/Web
NAME
ase-meta-search - Search the Internet/Web
SYNOPSIS
ase-meta-search
[--help|-h]
[--services|-s=(all|perplexity|brave|exa|websearch)...]
query
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.
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
SEE ALSO
ase-meta-chat, ase-meta-quorum, ase-arch-discover.
ase-meta-brainstorm - Collaboratively Brainstorm a Topic
NAME
ase-meta-brainstorm - Collaboratively Brainstorm a Topic
SYNOPSIS
ase-meta-brainstorm
[--help|-h]
[--max-clarify|-c=3]
[--min-ideas|-i=12]
[--min-rank|-r=7]
[--max-shortlist|-s=4]
topic
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.
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
SEE ALSO
ase-meta-evaluate, ase-meta-quorum, ase-meta-diaboli.
ase-meta-compat - Self-Test ASE Compatibility
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.
EXAMPLES
Run the compatibility self-test:
❯ /ase-meta-compat
SEE ALSO
ase-meta-evaluate, ase-meta-quorum, ase-meta-why.
ase-meta-workflow - Generate a Workflow Skill
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.
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
SEE ALSO
ase-help-intent, ase-help-skill,
ase-code-analyze, ase-code-resolve, ase-task-implement.
ase-arch-discover - Discover Components
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.
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
SEE ALSO
ase-arch-analyze, ase-meta-search, ase-meta-evaluate.
ase-code-insight - Project Insight
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.
EXAMPLES
Get insights into the current project:
❯ /ase-code-insight src/
Get insights into a specific subsystem:
❯ /ase-code-insight tool/src/
SEE ALSO
ase-code-explain, ase-code-analyze, ase-arch-analyze.
ase-code-explain - Explain Source Code
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.
EXAMPLES
Explain a single source file:
❯ /ase-code-explain src/parser.ts
Explain a specific function:
❯ /ase-code-explain src/parser.ts#parseExpression
SEE ALSO
ase-code-insight, ase-code-analyze, ase-arch-analyze.
ase-code-lint - Lint Source Code
NAME
ase-code-lint - Lint Source Code
SYNOPSIS
ase-code-lint
[--help|-h]
[--auto|-a]
[--severity|-S=(LOW|MEDIUM|HIGH)]
[--include|-i=aspect[,...]]
[--exclude|-e=aspect[,...]]
source-reference
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 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 aspect ids are:
A01 FORMATTING A06 REDUNDANCY A11 TYPING A16 SECURITY
A02 COMPREHENSION A07 PATTERNS A12 ERROR-HANDLING A17 ARCHITECTURE
A03 CLEANLINESS A08 COMPLICATEDNESS A13 MEMORY-LEAK A18 LOGIC
A04 SPELLING A09 CONCISENESS A14 CONCURRENCY A19 FLOW
A05 COMPLEXITY A10 SMELLS A15 PERFORMANCE A20 DEAD-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 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.
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/
SEE ALSO
ase-code-analyze, ase-code-resolve, ase-code-refactor,
ase-docs-proofread.
ase-docs-distill - Distill Document Key Points
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.
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.
SEE ALSO
ase-meta-search, ase-docs-proofread, ase-meta-why.
ase-docs-proofread - Proofread Documents
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, punctuation, 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.
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.
EXAMPLES
Proofread a single document interactively:
❯ /ase-docs-proofread README.md
Proofread an entire documentation directory automatically:
❯ /ase-docs-proofread --auto docs/
SEE ALSO
ase-code-lint, ase-meta-changelog.
ase-meta-review - Review Staged Changes
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/arch
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.
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
SEE ALSO
ase-meta-diff, ase-meta-commit, ase-code-lint, ase-code-analyze,
ase-meta-diaboli.
ase-meta-diff - Summarize Diff
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.
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
SEE ALSO
ase-meta-commit, ase-meta-changelog, ase-arch-analyze.
ase-meta-changelog - Update ChangeLog Entries
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.
EXAMPLES
Update the most recent ChangeLog section:
❯ /ase-meta-changelog
SEE ALSO
ase-meta-commit, ase-docs-proofread.
ase-meta-commit - Git Commit Message
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.
EXAMPLES
Craft a commit message for the currently staged changes:
❯ /ase-meta-commit
SEE ALSO
ase-meta-changelog.
ase-code-dissect - Dissect a Change Set
NAME
ase-code-dissect - Dissect a Change Set
SYNOPSIS
ase-code-dissect
[--help|-h]
[--max-parts|-m count]
[--staged|-s]
[--dry|-d]
[--force|-f]
[dissect-hint]
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.
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
SEE ALSO
ase-task-dissect, ase-meta-diff, ase-meta-review,
ase-meta-changelog, ase-meta-commit.
ase-task-id - Configure Task Id
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.
EXAMPLES
Show the current task id:
❯ /ase-task-id
Switch to a specific task:
❯ /ase-task-id hello
SEE ALSO
ase-task-list, ase-task-edit, ase-task-view,
ase-task-rename, ase-task-delete.
ase-task-edit - Iteratively Edit a Task Plan
NAME
ase-task-edit - Iteratively Edit a Task Plan
SYNOPSIS
ase-task-edit
[--help|-h]
[--plan|-p option]
[--dry|-d]
[--next|-n option[,...]]
[id | id: instruction | instruction]
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.
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.
SEE ALSO
ase-task-reboot, ase-task-preflight, ase-task-implement,
ase-task-view, ase-task-list, ase-task-rename, ase-task-delete.
ase-task-grill - Iteratively Grill a Task Plan
NAME
ase-task-grill - Iteratively Grill a Task Plan
SYNOPSIS
ase-task-grill
[--help|-h]
[--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, builds a
decision tree of the open questions, and walks down each branch
one-by-one. For each aspect it presents up to four grounded
alternative answers (the current plan plus alternatives derived from
the code base and world knowledge), marks the current-plan choice, and
lets the user pick via an interactive dialog. It honors checks for
fuzzy language, conflicting terminology, conflicting code, and
non-concrete scenarios. 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
--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.
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 and then hand off to editing:
❯ /ase-task-grill --next EDIT
SEE ALSO
ase-task-edit, ase-task-reboot, ase-task-preflight,
ase-task-implement, ase-task-view, ase-task-list,
ase-task-rename, ase-task-delete.
ase-task-reboot - Reboot a Task Plan
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.
EXAMPLES
Reboot the current task plan:
❯ /ase-task-reboot
Reboot a specific task and hand off to editing:
❯ /ase-task-reboot --next EDIT hello
SEE ALSO
ase-task-edit, ase-task-preflight, ase-task-implement,
ase-task-view, ase-task-delete.
ase-task-preflight - Preflight a Task Plan
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.
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
SEE ALSO
ase-task-edit, ase-task-implement, ase-task-reboot,
ase-task-view.
ase-task-implement - Implement a Task Plan
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.
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
SEE ALSO
ase-task-edit, ase-task-preflight, ase-task-reboot,
ase-task-view, ase-task-delete.
ase-task-view - View a Task Plan
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.
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
SEE ALSO
ase-task-list, ase-task-edit, ase-task-id,
ase-task-rename, ase-task-delete.
ase-task-list - List Task Plans
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.
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
SEE ALSO
ase-task-id, ase-task-view, ase-task-edit,
ase-task-rename, ase-task-delete.
ase-task-rename - Rename a Task Plan
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.
EXAMPLES
Rename the current task:
❯ /ase-task-rename hello-world
Rename a specific task:
❯ /ase-task-rename old-id new-id
SEE ALSO
ase-task-list, ase-task-id, ase-task-edit,
ase-task-view, ase-task-delete.
ase-task-condense - Condense a Task Plan
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.
EXAMPLES
Condense the current task plan:
❯ /ase-task-condense
Condense a specific task and hand off to editing:
❯ /ase-task-condense --next EDIT hello
SEE ALSO
ase-task-edit, ase-task-reboot, ase-task-view,
ase-task-rename, ase-task-delete.
ase-task-dissect - Dissect a Task Plan
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.
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
SEE ALSO
ase-code-dissect, ase-task-edit, ase-task-condense,
ase-task-implement, ase-task-list, ase-task-delete.
ase-task-delete - Delete a Task Plan
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.
EXAMPLES
Delete the current task plan:
❯ /ase-task-delete
Delete a specific task plan:
❯ /ase-task-delete hello
SEE ALSO
ase-task-edit, ase-task-list, ase-task-view,
ase-task-rename, ase-task-reboot.
ase-arch-analyze - Review Software Architecture
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.
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
SEE ALSO
ase-arch-discover, ase-code-analyze, ase-code-resolve,
ase-code-refactor, ase-code-insight.
ase-code-analyze - Analyze Source Code
NAME
ase-code-analyze - Analyze Source Code
SYNOPSIS
ase-code-analyze
[--help|-h]
[--performance|-p]
[--security|-s]
[--severity|-S=(LOW|MEDIUM|HIGH)]
[--prefix|-P prefix]
source-reference
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>.
ARGUMENTS
source-reference:
A file, directory, function, or other reference to the source code
to analyze.
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/
SEE ALSO
ase-code-resolve, ase-code-refactor, ase-code-lint,
ase-code-explain, ase-arch-analyze.
ase-code-craft - Craft Source Code
NAME
ase-code-craft - Craft Source Code
SYNOPSIS
ase-code-craft
[--help|-h]
[--auto|-a]
[--dry|-d]
[--direct|-D]
[--interactive|-i]
[--quick|-Q]
[--next|-n option[,...]]
[task-id:] feature
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.
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
SEE ALSO
ase-code-refactor, ase-code-resolve, ase-task-edit,
ase-task-grill, ase-task-preflight, ase-task-implement.
ase-code-refactor - Refactor Artifacts
NAME
ase-code-refactor - Refactor Artifacts
SYNOPSIS
ase-code-refactor
[--help|-h]
[--auto|-a]
[--dry|-d]
[--direct|-D]
[--quick|-Q]
[--next|-n option[,...]]
[task-id:] request
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.
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 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.
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
SEE ALSO
ase-code-craft, ase-code-resolve, ase-task-edit,
ase-task-grill, ase-task-preflight, ase-task-implement.
ase-code-resolve - Resolve Problem
NAME
ase-code-resolve - Resolve Problem
SYNOPSIS
ase-code-resolve
[--help|-h]
[--auto|-a]
[--dry|-d]
[--direct|-D]
[--quick|-Q]
[--next|-n option[,...]]
[task-id:] problem
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>.
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 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.
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
SEE ALSO
ase-code-craft, ase-code-refactor, ase-code-analyze,
ase-arch-analyze, ase-task-edit, ase-task-grill,
ase-task-preflight, ase-task-implement.
ase-code-edit - Edit Source Code
NAME
ase-code-edit - Edit Source Code
SYNOPSIS
ase-code-edit
[--help|-h]
[--mode|-m auto|craft|refactor|resolve]
[--grill|-g]
[--grill-rounds|-r n]
[--verify|-v]
[--worktree|-w]
[--loop|-l]
[query]
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.
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
SEE ALSO
ase-code-craft, ase-code-refactor, ase-code-resolve,
ase-task-grill, ase-task-implement.
ase-sync-reconcile - Reconcile Artifact Set to Artifact Set
NAME
ase-sync-reconcile - Reconcile Artifact Set to Artifact Set
SYNOPSIS
ase-sync-reconcile
[--help|-h]
[--bidirectional|-b]
[--target|-t target[,...]]
[--source|-s source[,...]]
[hint]
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 seven
recognized artifact kinds SPEC (Specification), ARCH (Architecture),
CODE (Source Code), DOCS (Documentation), TASK (Task Plans), INFR
(Infrastructure), and OTHR (catch-all). When source is auto, it
resolves to all seven 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, ase-format-arch.md, and ase-format-task.md;
the kinds CODE, DOCS, INFR, and OTHR have no dedicated format
contract and are treated as free-form.
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.
--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.
EXAMPLES
Reconcile the code and documentation
to reflect the current specification and architecture
in a "forward engineering" approach:
❯ /ase-sync-reconcile -t CODE,DOCS -s SPEC,ARCH
Reconcile specification and architecture from everything else
in a "reverse engineering" approach:
❯ /ase-sync-reconcile -t SPEC,ARCH -s CODE,DOCS
Bidirectionally reconcile specification and architecture against
each other, limited to the authentication aspect:
❯ /ase-sync-reconcile -b -t SPEC -s ARCH authentication
SEE ALSO
ase-meta-changelog,
ase-task-implement.
ase-sync-import - Import Foreign Sources into Artifact Set
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 seven recognized
artifact kinds SPEC (Specification), ARCH (Architecture), CODE
(Source Code), DOCS (Documentation), TASK (Task Plans), INFR
(Infrastructure), and OTHR (catch-all). It defaults to SPEC,ARCH.
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, ase-format-arch.md, 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.
OPTIONS
--target|-t target[,...]:
The comma-separated list of artifact kinds to generate or update.
Defaults to SPEC,ARCH. 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.
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 architecture, defaulting to
both specification and architecture as targets:
❯ /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
SEE ALSO
ase-sync-reconcile,
ase-sync-export,
ase-task-implement.
ase-sync-export - Export Artifact Set to Side-by-Side Files
NAME
ase-sync-export - Export Artifact Set to Side-by-Side Files
SYNOPSIS
ase-sync-export
[--help|-h]
[--source|-s source[,...]]
[filter]
DESCRIPTION
The ase-sync-export skill exports the content of a set of artifact
kinds (the source) into derived, ready-to-consume files placed
side-by-side with the artifacts themselves. For every source artifact
that declares an export in its format definition, the skill builds the
declared rendering and writes it to a sibling file.
The source is a comma-separated list over the seven recognized
artifact kinds SPEC (Specification), ARCH (Architecture), CODE
(Source Code), DOCS (Documentation), TASK (Task Plans), INFR
(Infrastructure), and OTHR (catch-all). The file lists for the
involved kinds are resolved via the ase_artifact_list MCP tool of the
ase MCP server.
An export is declared by a - Export: bullet point in an artifact's
format definition (see ase-format-meta.md, ase-format-spec.md, and
ase-format-arch.md); an artifact without such a bullet is not
exported. Each exported file is named
<set>-<no>-<id>-<slug>-<export-name>.<ext> (e.g.
SPEC-07-DM-Data-Model-export.svg) and stored in the artifact's own
base directory. Initially, the Data Model (SPEC-DM) exports as a
Mermaid UML diagram converted to SVG, and the Technology Stack
(ARCH-TS) exports as a compact Markdown table.
OPTIONS
--source|-s source[,...]:
The comma-separated list of artifact kinds to export. Defaults to
SPEC,ARCH (the skill errors out on an empty source).
ARGUMENTS
filter:
An optional free-form filtering hint that narrows the source
artifacts, or the aspects of those artifacts, to take into account
when materializing the exports. If omitted, every export declared by
a source artifact is materialized.
EXAMPLES
Export the specification and architecture artifacts to their
side-by-side files (the default):
❯ /ase-sync-export
Export only the specification artifacts:
❯ /ase-sync-export -s SPEC
Export only the data-model artifact:
❯ /ase-sync-export -s SPEC data model
SEE ALSO
ase-sync-reconcile,
ase-sync-import.
