ase-help-skill - Show the Manual Page of an ASE Skill
NAME
ase-help-skill - Show the Manual Page of an ASE Skill
SYNOPSIS
ase-help-skill
[--help|-h]
[skill-name]
DESCRIPTION
The ase-help-skill skill renders the manual page (help.md) of the
ASE skill addressed by skill-name. The page is emitted verbatim,
framed between a ( HELP ) header and footer rule.
The skill-name is resolved against a catalog of all ASE skills --
one name: purpose entry per skill, generated into
skills/ase-help-skill/data.md by npm start build in plugin/.
Before resolving, any leading / and ase: prefix is stripped, so
ase-code-lint, /ase-code-lint, and ase:ase-code-lint are
equivalent. Resolution then proceeds in three tiers, each tried only if
all preceding ones found nothing: an exact match on the full skill
name wins outright, otherwise every skill name containing
skill-name as a substring becomes a candidate, and otherwise
skill-name is fuzzily matched against the skill purposes -- so
a topical phrase such as root cause still finds ase-meta-why --
with the candidates ordered by descending match quality.
A skill-name matching no skill in any tier is reported as an error. A
skill-name matching more than one skill opens an interactive dialog
listing the candidates with their purposes; as the dialog renders at
most nine answer lines, a broader abbreviation such as task shows the
first nine candidates and states how many exist in total.
If skill-name is omitted, the whole catalog is rendered as a
browsable Skill/Purpose table instead.
The skill exposes no option flags beyond --help/-h.
ARGUMENTS
- skill-name:
The full name of the ASE skill, any abbreviation of it, or a
description of its purpose. If omitted, the entire skill catalog is
listed.
SCENARIOS
- You want the manual page of an ASE skill
- You want to know what a certain
ase-xxx-xxx skill does
- You want a skill found by an abbreviation or a purpose description
- You want to browse the whole catalog of ASE skills
EXAMPLES
Show the manual page of ase-code-lint via its shortest abbreviation:
❯ /ase-help-skill lint
Show the same manual page via its full, plugin-qualified name:
❯ /ase-help-skill ase:ase-code-lint
Pick a manual page from the candidates of an ambiguous abbreviation:
❯ /ase-help-skill analyze
Find a manual page by the purpose of the skill instead of its name:
❯ /ase-help-skill root cause
List the entire skill catalog:
❯ /ase-help-skill
SEE ALSO
ase-help-intent, ase-meta-proximity.
ase-help-intent - Match an Intent to ASE Commands
NAME
ase-help-intent - Match an Intent to ASE Commands
SYNOPSIS
ase-help-intent
[--help|-h]
intent
DESCRIPTION
The ase-help-intent skill matches a free-text intent against the
accumulated help of all ASE skills -- the concatenation of every
skill's help.md file into skills/ase-help-intent/data.md, built by
npm start build in plugin/ -- and generates all adequately fitting
/ase:ase-xxx-xxx commands that realize the intent, ranked best-fitting
first and limited to the eight best ones. The fit is judged primarily
against each skill's SCENARIOS ("You want ...") and DESCRIPTION
sections, and each command is complete with concrete option flags and
positional arguments derived from the skill's SYNOPSIS, OPTIONS,
and ARGUMENTS.
The generated commands are presented together with a brief per-command
rationale in an interactive dialog. The dialog lets the user execute
one of the commands C1...C8 (which dispatches the target skill via
its generated arguments), cancel the operation, or refine the intent
by typing any free-text instruction -- the instruction is folded into
the intent and the fitting commands are re-matched and re-rendered. If
no skill confidently matches the intent, a warning is emitted and the
user is prompted to refine or clarify it.
The skill exposes no option flags beyond --help/-h; it is driven
entirely through the intent argument and the interactive dialog.
ARGUMENTS
- intent:
The free-text intent to be realized. It describes what the user
wants to achieve; the skill determines which ASE skills and which
options and arguments realize it.
SCENARIOS
- You want to know which ASE skills realize what you have in mind
- You want free text turned into concrete slash commands with options
- You want all matching commands proposed, ranked best-fitting first
- You want to refine an intent in a dialog until a command fits
EXAMPLES
Route an intent to the matching commands and pick one from the dialog:
❯ /ase-help-intent lint the TypeScript sources for high-severity issues only
Route a planning intent to the matching commands:
❯ /ase-help-intent explain how the authentication module works
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.
SCENARIOS
- You want the ASE configuration inspected or changed
- You want the persona, guidance, or boxing switched for a session
- You want a configuration value persisted at user or project scope
- You want to see which scope supplies each effective value
EXAMPLES
List all effective configuration entries:
❯ /ase-meta-config list
Report the effective persona style:
❯ /ase-meta-config get agent.persona
Switch the communication style for the current session only:
❯ /ase-meta-config set agent.persona telegrapher
Switch the project boxing for the current session only:
❯ /ase-meta-config set project.boxing grey
Persist the guidance level for the whole project instead:
❯ /ase-meta-config --scope project set agent.guidance minimal
Remove a value from the user-level configuration:
❯ /ase-meta-config --scope user delete project.name
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.
SCENARIOS
- You want the root cause of a problem, not just its symptom
- You want a Five-Whys causality chain walked for an observed fact
- You want candidate causes weighed with backtracking
- You want a solution proposed which addresses the root cause
EXAMPLES
Investigate the root cause of a build failure:
❯ /ase-meta-why the CI build is intermittently failing on macOS runners
Drill down deeper with a tunable chain length of seven:
❯ /ase-meta-why -d 7 the production latency spiked after the last deploy
Weigh several candidate sub-causes per level (with backtracking) to avoid
committing early to the wrong root cause:
❯ /ase-meta-why -w 3 the release was delayed by two weeks
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.
SCENARIOS
- You want a topic explained so simply a child could follow
- You want a jargon-free summary with an everyday analogy
- You want a simple explanation grounded in current Internet/Web facts
EXAMPLES
Explain a technical concept from model knowledge:
❯ /ase-meta-eli5 What is a Fourier transform?
Explain a recent topic grounded in Internet/Web facts:
❯ /ase-meta-eli5 --ground What is Agentic Software Engineering?
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.
SCENARIOS
- You want the conceptual neighborhood of a topic explored
- You want the parent, sibling, and child topics of a subject
- You want a topic taxonomy navigated interactively
- You want related topics grounded in Internet/Web facts
EXAMPLES
Determine the proximity of a topic from model knowledge:
❯ /ase-meta-proximity Fourier transform
Interactively navigate the conceptual neighborhood, grounded in
Internet/Web facts:
❯ /ase-meta-proximity --ground --loop Agentic Software Engineering
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.
SCENARIOS
- You want quotes, sayings, or aphorisms on a topic
- You want citations arranged by attribution and literalness
- You want quote wording and attribution verified against the Web
- You want the quote harvest widened to related topics
EXAMPLES
Find quotes from model knowledge:
❯ /ase-meta-quotes software architecture
Find a wider set of quotes, grounded in Internet/Web facts and widened
to the conceptual neighborhood of the topic:
❯ /ase-meta-quotes --ground --proximity --count 12 technical debt
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.
SCENARIOS
- You want alternatives compared and the best one named
- You want a weighted multi-criteria decision matrix
- You want a defensible, criteria-based technology choice
- You want to know which option out of a list wins and by how much
EXAMPLES
Compare logging libraries for a TypeScript project:
❯ /ase-meta-evaluate Compare pino, winston, and bunyan as logging libraries.
Evaluate database options with hinted criteria:
❯ /ase-meta-evaluate Compare PostgreSQL, MySQL, and SQLite for an
embedded use case; criteria include footprint and write throughput.
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.
SCENARIOS
- You want a thesis relentlessly challenged with counter-arguments
- You want a decision stress-tested before you commit to it
- You want the strongest anti-theses ranked plus a synthesis
- You want a devil's advocate against a claim or plan
EXAMPLES
Challenge a technology-choice claim:
❯ /ase-meta-diaboli HAPI is the best REST framework
Stress-test a design decision:
❯ /ase-meta-diaboli We should rewrite the service in Rust.
Surface at least fifteen anti-theses:
❯ /ase-meta-diaboli --count 15 We should rewrite the service in Rust.
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.
SCENARIOS
- You want the strongest possible case built for a thesis
- You want supporting arguments ranked plus a fortification
- You want a charitable defense before pitching a decision
EXAMPLES
Strengthen a technology-choice claim:
❯ /ase-meta-steelman HAPI is the best REST framework
Build the case for a design decision:
❯ /ase-meta-steelman We should rewrite the service in Rust.
Strengthen across five iterative rounds:
❯ /ase-meta-steelman --rounds 5 We should rewrite the service in Rust.
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.
SCENARIOS
- You want a consensus answer from multiple AIs
- You want to know whether different models agree on a question
- You want the individual responses plus a consensus rate
EXAMPLES
Ask the quorum a factual question:
❯ /ase-meta-quorum What are the most common causes of memory leaks in Node.js?
Ask only a subset of the foreign models:
❯ /ase-meta-quorum --models chatgpt,gemini,grok Which sorting algorithm is fastest in practice?
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.
SCENARIOS
- You want a single question answered by one specific foreign LLM
- You want an answer from ChatGPT, Gemini, DeepSeek, Grok, GLM, or Qwen
- You want a second opinion from exactly one other model, verbatim
EXAMPLES
Ask ChatGPT a quick question:
❯ /ase-meta-chat chatgpt What is the best way to handle UTF-8 BOMs in JSON?
Ask Gemini for a brief comparison:
❯ /ase-meta-chat gemini Compare gRPC and REST in one paragraph.
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.
SCENARIOS
- You want the Internet/Web searched for a query
- You want results from several search backends consolidated
- You want current facts which model knowledge may lack
EXAMPLES
Search the Web for a topic across all backends:
❯ /ase-meta-search latest stable release of TypeScript and release notes
Search the Web using only the Brave and Exa backends:
❯ /ase-meta-search --services=brave,exa latest stable release of TypeScript
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.
SCENARIOS
- You want to get fresh ideas for an open-ended question
- You want to explore what to build before deciding how to build it
- You want to widen a solution space that holds a single candidate
- You want to get a shortlist of distinct directions with a recommendation
- You want to ideate on a feature, component, or design question
EXAMPLES
Brainstorm an approach for a new feature:
❯ /ase-meta-brainstorm an offline-first sync layer for the mobile app
Brainstorm with a broader idea space of at least 20 candidates:
❯ /ase-meta-brainstorm --min-ideas 20 an offline-first sync layer
Brainstorm quickly with a single clarification, a stricter score floor,
and a tighter shortlist:
❯ /ase-meta-brainstorm --max-clarify 1 --min-rank 8 --max-shortlist 3 an offline-first sync layer
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.
SCENARIOS
- You want to know how faithfully the current model runs ASE skills
- You want a 0-100% compatibility rating of the LLM and its harness
- You want the core interpreter primitives checked before relying on ASE
EXAMPLES
Run the compatibility self-test:
❯ /ase-meta-compat
SEE ALSO
ase-meta-evaluate, ase-meta-quorum, ase-meta-why.
ase-meta-mint - Mint an Identifier or Name
NAME
ase-meta-mint - Mint an Identifier or Name
SYNOPSIS
ase-meta-mint
[--help|-h]
[--type|-t uuid|sha1|const|var|class|func|path|name]
[--count|-c count]
[hint]
DESCRIPTION
The ase-meta-mint skill mints an identifier or a name of a requested
type out of the free-text hint formed by the positional arguments. It
dispatches on --type and emits the generated strings as its result.
The two hash-derived types are delegated to the ase_mint tool of the
ase MCP server, which derives them reproducibly instead of guessing
them:
uuid:
a deterministic UUID V5 over the hint, within the fixed ASE
namespace (itself a UUID V5 over https://ase.tools in the
standard URL namespace), or a random UUID V4 if no hint is
given.
sha1:
the 40-character hexadecimal SHA-1 digest of the hint.
The six linguistic types are derived by the skill itself: the hint
is distilled into its essential words, which are then assembled
according to the conventions of the type:
const:
an UPPER_SNAKE_CASE constant identifier, such as FOO_BAR_QUUX.
var:
a lowerCamelCase variable identifier, such as fooBarQuux, whose
last part is a substantive naming what the value is, never a
verb.
func:
a lowerCamelCase function identifier, such as fooBarQuux, whose
first part is a verb naming what the function does.
class:
an UpperCamelCase class identifier, such as FooBarQuux, as a
singular substantive phrase naming the modeled entity.
path:
a kebab-case path component, such as foo-bar-quux.
name:
an UpperCamelCase product name, such as FooBarQuux, optimized
for a brand rather than for a description: short, pronounceable,
memorable, and distinctive.
A hint is mandatory for every type except uuid, which falls back to
a random UUID V4 without one.
OPTIONS
--type|-t uuid|sha1|const|var|class|func|path|name:
Select the type of the minted identifier or name (default: uuid).
--count|-c count:
Mint count identifiers instead of just one (default: 1, maximum:
100). For the hash-derived types it is honored only for an empty
hint, where count random UUID V4 values are emitted; with a
non-empty hint, hashing is a pure function of that hint and
hence always yields exactly one identifier, so count is clamped to
1 and a warning is emitted. For the linguistic types, count
distinct candidates are emitted, ordered best-first.
ARGUMENTS
hint:
The free-text hint the identifier or name is derived from. It may be
a short description, a phrase, or a few keywords. It is mandatory
for all types except uuid.
SCENARIOS
- You need a stable, reproducible UUID or SHA-1 digest for a concept
- You need a well-formed constant, variable, function, or class identifier
- You need a path component or slug derived from a description
- You need a catchy product name for a new component or tool
EXAMPLES
Mint a deterministic UUID for a concept:
❯ /ase-meta-mint --type uuid the ASE artifact kind resolution cache
Mint a function identifier from a description:
❯ /ase-meta-mint -t func compute the checksum of an artifact file
Mint three product name candidates:
❯ /ase-meta-mint -t name -c 3 a background service bridging a project into the agent tool
SEE ALSO
ase-task-id, ase-meta-brainstorm, ase-code-craft, ase-arch-discover.
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.
SCENARIOS
- You want a recurring multi-step procedure automated as its own skill
- You want several ASE skills orchestrated or chained into one command
- You want sequential and parallel actions woven into a generated skill
- You want a new agent tool skill generated in the style of ASE skills
EXAMPLES
Generate a project-local skill which analyzes the code and then resolves
every finding concurrently in isolated worktrees:
❯ /ase-meta-workflow optimizer run ase-code-analyze, then for each finding P<n> resolve, implement and delete it in a parallel isolated sub-agent
Generate a user-wide skill and overwrite a previous generation:
❯ /ase-meta-workflow --scope user --force release lint the code, update the changelog, then propose a commit message
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.
SCENARIOS
- You want a third-party library or framework for a needed functionality
- You want a ranked survey of candidate components from NPM or Maven Central
- You want to know whether a package is healthy or stale and abandoned
- You want to decide between a dependency and hand-rolling a small feature
EXAMPLES
Discover components for JSON schema validation:
❯ /ase-arch-discover JSON schema validation
Discover components for HTTP client functionality:
❯ /ase-arch-discover HTTP client with retries
Discover a broader set of up to 20 HTTP client components:
❯ /ase-arch-discover --limit 20 HTTP client with retries
Discover HTTP clients, flagging any without a release in the last 12 months:
❯ /ase-arch-discover --staleness 12 HTTP client with retries
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.
SCENARIOS
- You want a high-level overview of a project
- You want to know who wrote the project and which files churn most
- You want a module structure diagram of the imports
- You want to get familiar with an unknown code base quickly
EXAMPLES
Get insights into the current project:
❯ /ase-code-insight src/
Get insights into a specific subsystem:
❯ /ase-code-insight tool/src/
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.
SCENARIOS
- You want to understand how a piece of code works
- You want an explanation with WHAT, WHY, analogy, and diagram
- You want the cruxes and gotchas of unfamiliar code pointed out
- You want a quick orientation before touching foreign code
EXAMPLES
Explain a single source file:
❯ /ase-code-explain src/parser.ts
Explain a specific function:
❯ /ase-code-explain src/parser.ts#parseExpression
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-one code quality aspects are checked. The --include
and --exclude options narrow this to an effective aspect set: with
--include only, exactly the listed aspects are checked; with
--exclude only, all aspects except the listed ones; with both, the
included ones minus the excluded ones. An unknown aspect id, or a
combination which cancels out to an empty set, aborts the skill with an
error. The twenty-one aspect ids are:
A01 FORMATTING A07 PATTERNS A13 MEMORY-LEAK A19 FLOW
A02 COMPREHENSION A08 COMPLICATEDNESS A14 CONCURRENCY A20 DEAD-CODE
A03 CLEANLINESS A09 CONCISENESS A15 PERFORMANCE A21 DOCUMENTATION
A04 SPELLING A10 SMELLS A16 SECURITY
A05 COMPLEXITY A11 TYPING A17 ARCHITECTURE
A06 REDUNDANCY A12 ERROR-HANDLING A18 LOGIC
The A21 DOCUMENTATION aspect checks the code documentation in both
directions: it flags functions, methods, classes, and modules - private
ones included - which lack a minimal 1-2 line description in the
idiomatic documentation convention of the target language, and it
flags excessive comments (narrated decision logs, change history,
line-by-line explanations of the obvious), comments merely restating
the code, and comments contradicting the code.
OPTIONS
--auto|-a:
Automatically apply every proposed correction without asking the
user via the interactive dialog.
--severity|-S=(LOW|MEDIUM|HIGH):
Set the severity floor (default LOW): findings below the chosen
threshold are silently suppressed, ordered LOW < MEDIUM <
HIGH. The default LOW keeps all findings; ACCEPTED findings are
never suppressed. Surviving findings are reported in descending
severity order HIGH, MEDIUM, LOW, ACCEPTED, keeping the
file/line order within the same severity.
--include|-i=aspect[,...]:
Restrict the checked code quality aspects to the given
comma-separated list of aspect ids (e.g. A01,A04). Without this
option, all twenty-one aspects are checked.
--exclude|-e=aspect[,...]:
Remove the given comma-separated list of aspect ids from the checked
code quality aspects. Applied after --include, so
-i A01,A02 -e A02 checks A01 only.
ARGUMENTS
- source-reference:
A file, directory, or other reference to the source code to lint.
SCENARIOS
- You want your code checked for code quality problems
- You want corrections proposed which you accept or reject one by one
- You want all quality corrections applied automatically
- You want only specific quality aspects like formatting or spelling checked
- You want missing or excessive code documentation flagged
EXAMPLES
Lint a source file interactively:
❯ /ase-code-lint src/server.ts
Lint a directory and automatically apply all corrections:
❯ /ase-code-lint --auto src/handlers/
Lint a directory, reporting only MEDIUM and HIGH findings:
❯ /ase-code-lint -S MEDIUM src/handlers/
Lint a source file for the formatting and spelling aspects only:
❯ /ase-code-lint -i A01,A04 src/server.ts
Lint a directory for all aspects except dead code:
❯ /ase-code-lint --exclude A20 src/handlers/
Lint a directory for the documentation aspect only:
❯ /ase-code-lint -i A21 src/handlers/
SEE ALSO
ase-code-analyze, ase-code-resolve, ase-code-refactor,
ase-docs-proofread.
ase-docs-shorten - Shorten a Document to a Target Length
NAME
ase-docs-shorten - Shorten a Document to a Target Length
SYNOPSIS
ase-docs-shorten
[--help|-h]
[--auto|-a]
(--chars|-c N | --words|-w N)
docs-reference
DESCRIPTION
The ase-docs-shorten skill reduces the length of a single document
until it reaches a requested target length. The investigation is
dispatched to a sub-agent (ase:ase-docs-shorten) so that scanning
details do not leak into the user-visible transcript.
The target length is stated either as --chars N or as --words N.
The two options are mutually exclusive, exactly one of them is
mandatory, and neither carries a default, because the target length is
the very quantity the shortening optimizes for. A document reference
which expands to more than one document is rejected, as it would leave
open whether the target bounds each document or their sum.
The shortening runs as a three-stage cascade, and a stage is entered
only while the target is still not met:
Tighten: shorten individual sentences without losing any content -
filler words struck, nominal constructions turned into verbs,
redundant restatements within a sentence cut.
Drop: remove low-value content - redundant restatements,
illustrative examples, asides, parentheticals, and the whole
sentences or list items which carry the least value for the reader.
Content is genuinely lost in this stage.
Compress: merge and rewrite the remaining content into shorter
expressions and sentences - related sentences fused, prose
enumerations turned into compact lists, multi-sentence passages
re-expressed as single sentences.
The skill never shortens beyond the target: it stops at the first
change which reaches it. What survives the shortening stays exact -
every surviving fact, number, technical term, qualifier, and negation is
preserved verbatim, nothing is invented, the order of the surviving
argument is kept, and fenced code blocks, inline code spans, link
targets, Markdown frontmatter, and the heading structure are never
touched.
Each proposed change is cut as a whole block - a paragraph, a list
item, a blockquote, or a heading with its following paragraph - because
a shortening is only judgeable in the context of the whole block it
rewrites. It is rendered as a unified diff with up to two lines of
context, annotated with the length it saves, exactly as in
ase-docs-refine and
ase-docs-proofread. The user
either accepts or rejects each block interactively (or refines it via a
free-text hint, which re-proposes the block without limit) or - with
--auto - applies all of them automatically. A closing LENGTH REPORT
states the achieved length against the target, so rejected blocks stay
visible in the outcome.
ase-docs-shorten is the length-reducing member of the document triple.
The recommended order over one document is ase-docs-shorten first (cut
the bulk), then ase-docs-refine (polish
what survives), then
ase-docs-proofread (final correctness
pass), so no polishing effort is spent on text which is later dropped.
OPTIONS
--chars|-c N:
Shorten the document to at most N characters, counted over the
entire document content including whitespace and newlines.
Mutually exclusive with --words.
--words|-w N:
Shorten the document to at most N whitespace-separated words,
counted over the entire document content.
Mutually exclusive with --chars.
--auto|-a:
Automatically apply every proposed shortening without asking the
user via the interactive dialog.
ARGUMENTS
- docs-reference:
A reference to the single document to shorten. A reference
expanding to more than one document is rejected.
SCENARIOS
- You want a README section cut down to a hard character budget
- You want an abstract brought under a word limit for a submission
- You want the least valuable examples and asides dropped first
- You want to see what a shortening costs before accepting it
- You want a whole document shortened unattended in one pass
- You want the achieved length reported against the target
EXAMPLES
Shorten a document to at most 4000 characters interactively:
❯ /ase-docs-shorten --chars 4000 README.md
Shorten a document to at most 250 words unattended:
❯ /ase-docs-shorten --auto --words 250 docs/abstract.md
SEE ALSO
ase-docs-refine, ase-docs-proofread, ase-docs-distill.
ase-docs-refine - Refine Document Wording
NAME
ase-docs-refine - Refine Document Wording
SYNOPSIS
ase-docs-refine
[--help|-h]
[--auto|-a]
docs-reference
DESCRIPTION
The ase-docs-refine skill performs a light rewriting of awkward or
unclear sentences in the referenced documents, without reshaping the
argument: restructuring sentences for rhythm and clarity, making
enumerations parallel, cutting filler and redundancy, fixing awkward
transitions, and adjusting voice. Content, numbers, and technical
terms stay exactly as they are. The investigation is dispatched to a
sub-agent (ase:ase-docs-refine) so that scanning details do not leak
into the user-visible transcript.
The checked refinement types are:
Structure: overlong, convoluted, or awkwardly built sentences,
split or restructured for rhythm and clarity.
Nominalization: cumbersome nominal constructions, replaced with
plain verbs.
Parallelism: non-parallel enumerations, brought into one
grammatical shape - a list whose items mix noun phrases,
imperatives, and full sentences, a heading set mixing gerunds and
nouns, or an inline series whose members do not share their form.
Filler: filler words, empty intensifiers, and redundant
restatements, struck.
Transition: abrupt or misleading transitions between sentences or
paragraphs, smoothed. An existing transition is only smoothed or
removed - a connective is never inserted where the original
asserted no such relation, as that would add a logical claim.
Voice: needless passive voice turned active, needless hedging
struck, and shifts in grammatical person or mood aligned with the
rest of the document.
The rewriting always stays within a sentence. Dropping a whole
sentence, paragraph, example, or list item for the sake of brevity is
length reduction, not refinement, and belongs to
ase-docs-shorten. The recommended order
over one document is ase-docs-shorten first (cut the bulk), then
ase-docs-refine (polish what survives), then ase-docs-proofread
(final correctness pass), so no polishing effort is spent on text which
is later dropped.
For each detected problem, the skill renders a unified-diff
REFINEMENT preview and either asks the user to ACCEPT or REJECT
the proposed refinement interactively (or refine it via a free-text
hint, which re-proposes the refinement without limit) or - with
--auto - applies all refinements automatically. A proposal which
shifts the meaning even slightly - a lost negation, a changed
qualifier, a renamed technical term - is dropped instead of applied.
OPTIONS
--auto|-a:
Automatically apply every proposed refinement without asking the
user via the interactive dialog.
ARGUMENTS
- docs-reference:
A file, directory, or other reference to the documents to
refine.
SCENARIOS
- You want long, convoluted sentences broken into readable ones
- You want nominal style like "perform a validation of" turned into verbs
- You want a bullet list of mixed noun phrases and sentences made parallel
- You want filler words and redundant restatements struck
- You want abrupt transitions between paragraphs smoothed
- You want needless passive voice or hedging adjusted
- You want the wording polished without touching facts or figures
EXAMPLES
Refine a single document interactively:
❯ /ase-docs-refine README.md
Refine an entire documentation directory automatically:
❯ /ase-docs-refine --auto docs/
SEE ALSO
ase-docs-shorten, ase-docs-proofread, ase-docs-distill.
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, capitalization, punctuation, word break, and grammar
errors and proposes corrections. The investigation is dispatched to a
sub-agent (ase:ase-docs-proofread) so that scanning details do not
leak into the user-visible transcript.
For each detected problem, the skill renders a unified-diff
CORRECTION preview and either asks the user to ACCEPT or REJECT
the proposed correction interactively (or refine it via a free-text
hint, which re-proposes the correction without limit) or - with
--auto - applies all corrections automatically.
ase-docs-proofread is the correctness-fixing member of the document
triple. The recommended order over one document is
ase-docs-shorten first (cut the bulk),
then ase-docs-refine (polish what
survives), then ase-docs-proofread (final correctness pass), so no
correction effort is spent on text which is later dropped.
OPTIONS
--auto|-a:
Automatically apply every proposed correction without asking the
user via the interactive dialog.
ARGUMENTS
- docs-reference:
A file, directory, or other reference to the documents to
proofread.
SCENARIOS
- You want documents checked for spelling, capitalization,
punctuation, word break, and grammar
- You want inconsistent capitalization of terms and headings unified
- You want wrong word breaks like "data base" or "check-list" repaired
- You want corrections proposed which you accept or reject one by one
- You want a whole documentation directory corrected automatically
- You want a final language pass over a text before publishing
EXAMPLES
Proofread a single document interactively:
❯ /ase-docs-proofread README.md
Proofread an entire documentation directory automatically:
❯ /ase-docs-proofread --auto docs/
SEE ALSO
ase-docs-shorten, ase-docs-refine, ase-docs-distill, ase-code-lint, ase-meta-changelog.
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.
SCENARIOS
- You want the key points of a document extracted and ranked
- You want the essence of a long text without reading all of it
- You want each key point backed by verbatim, line-cited evidence
- You want a pasted text or file boiled down to what matters
EXAMPLES
Distill the key points of a document file:
❯ /ase-docs-distill doc/architecture.md
Distill only the top 3 key points:
❯ /ase-docs-distill --top 3 doc/architecture.md
Distill a pasted block of text:
❯ /ase-docs-distill The system shall accept payments in EUR and USD only.
SEE ALSO
ase-meta-search, ase-docs-proofread, ase-meta-why.
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
formats described in AGENTS.md and the ase-format-* meta documents),
testing (inadequate coverage for the change - new or fixed behavior
left untested, adjacent tests not updated, or existing tests silently
broken, disabled, or weakened), and documentation (user- or
developer-facing docs - README, CHANGELOG, help text, or AI
guidance/meta documents - left stale by the change).
Each finding carries a severity - HIGH, MEDIUM, LOW, or
ACCEPTED (a concern that is contractually addressed or accepted as a
documented priority conflict) - and is evidence-grounded: it cites the
exact file:line location it stems from. The overall verdict is
REJECT - DEMANDS CHANGES when any HIGH finding remains, and
APPROVE otherwise. The work is performed by a dedicated ase-meta-review
sub-agent so that the silent reading and read-only repository probing
never leak into the transcript; only the structured verdict and findings
are rendered.
The skill complements rather than duplicates its neighbors:
ase-code-lint flags mechanical code-quality issues, ase-code-analyze
inspects logic and semantics, ase-meta-diff narrates what changed
(with optional coherence, risk, and blast-radius reports), and
ase-meta-diaboli adversarially challenges a thesis - whereas
ase-meta-review renders a reviewer's judgment on a concrete diff
before it is committed.
OPTIONS
--severity|-S=(LOW|MEDIUM|HIGH):
Set the severity floor (default LOW): findings below the chosen
threshold are silently suppressed, ordered LOW < MEDIUM <
HIGH. The default LOW keeps all findings; ACCEPTED findings are
never suppressed. Surviving findings are rendered in descending
severity order HIGH, MEDIUM, LOW, ACCEPTED. The floor only
affects the rendered findings table, not the overall verdict, which
is always derived from all findings before the floor is applied.
ARGUMENTS
The ase-meta-review skill takes no positional arguments; it always
reviews the currently staged Git changes.
SCENARIOS
- You want the staged changes reviewed like a human reviewer would
- You want an approve or reject verdict before committing
- You want severity-tagged, line-cited findings on a diff
- You want a holistic judgment instead of a mechanical lint
EXAMPLES
Review the currently staged changes before committing:
❯ /ase-meta-review
Review the staged changes, reporting only MEDIUM and HIGH findings:
❯ /ase-meta-review -S MEDIUM
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.
SCENARIOS
- You want a readable, intent-grouped summary of the staged changes
- You want a diff checked for scope creep and stray debug leftovers
- You want a graded risk report of a change before committing
- You want a blast-radius map of what depends on the touched code
EXAMPLES
Summarize the currently staged changes:
❯ /ase-meta-diff
Summarize the staged changes and append an intent-coherence report:
❯ /ase-meta-diff --coherence
Summarize the staged changes and append a graded risk report:
❯ /ase-meta-diff --risk
Summarize the staged changes and append a blast-radius map:
❯ /ase-meta-diff --blast
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.
SCENARIOS
- You want the
CHANGELOG.md brought up to date with recent commits
- You want changelog entries completed, consolidated, and sorted
- You want a tidy changelog section before a release
EXAMPLES
Update the most recent ChangeLog section:
❯ /ase-meta-changelog
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.
SCENARIOS
- You want a commit message for the currently staged changes
- You want a typed one-line summary derived from the staged diff
- You want to commit but cannot phrase what changed
EXAMPLES
Craft a commit message for the currently staged changes:
❯ /ase-meta-commit
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.
SCENARIOS
- You want a large uncommitted change set split into atomic parts
- You want each cohesive part of a diff in its own Git worktree
- You want mixed-up changes untangled before committing them
- You want a preview of how a change set would be divided
EXAMPLES
Dissect the current working copy changes:
❯ /ase-code-dissect
Preview the dissection of the staged changes into at most four parts:
❯ /ase-code-dissect --staged --dry --max-parts 4
Re-dissect the changes, re-creating the previously created worktrees:
❯ /ase-code-dissect --force
Dissect the changes along an explicitly given axis:
❯ /ase-code-dissect keep the plugin and tool changes in separate parts
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.
SCENARIOS
- You want to know which task is currently active
- You want the session switched to another task
- You want to work on a certain task
EXAMPLES
Show the current task id:
❯ /ase-task-id
Switch to a specific task:
❯ /ase-task-id hello
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.
SCENARIOS
- You want a task planned through chat-driven refinement
- You want a plan created or refined round by round
- You want a plan iterated on before implementing it
- You want plan refinement with hand-off to preflight or implementation
EXAMPLES
Edit the current task:
❯ /ase-task-edit
Create a new task under id hello:
❯ /ase-task-delete hello
❯ /ase-task-edit hello: new "ase hello" CLI command which prints
a nice "Hello World!" to the terminal in color blue.
Further refine the task under id hello:
❯ /ase-task-edit hello: change the color to red.
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]
[--rounds|-r n]
[--next|-n option[,...]]
[id]
DESCRIPTION
The ase-task-grill skill relentlessly interviews the user about
every essential aspect of an existing task plan until a shared
understanding is reached and no decisions or questions are left open.
The skill identifies the essential aspects of the plan and raises up to
10 questions per round which resolve its open points. Each question
carries a FOCUS-AREA -- DOMAIN (domain-specifics, must be
clarified), INTERFACE (externally observable behavior or UI/API
interfaces, must be clarified), ARCHITECTURE (structure, wiring,
placement, or dependencies, should be clarified), or IMPLEMENTATION
(inner technical details, can be clarified) -- and a 1-2 word ASPECT
hint. The questions are sorted primarily by descending focus area
importance (DOMAIN, INTERFACE, ARCHITECTURE, IMPLEMENTATION)
and secondarily by the decision tree of their dependencies, so each
decision is asked after the decisions it depends on. It honors checks
for fuzzy language, conflicting terminology, conflicting code,
non-concrete scenarios, unspecified architecture patterns, and
unspecified dependencies.
In contrast to the batch grilling of ase-code-edit --grill, the
questions are asked sequentially, one at a time: each question is
announced as an ASPECT n/N ▶ FOCUS ▷ ASPECT, QUESTION line and then
raised via an interactive dialog presenting two to four grounded
answer alternatives labeled A1-A4 (the current plan, marked with
⚑, plus alternatives derived from the code base and world knowledge),
the fixed SKIP GRILLING option (skip the remaining questions and
rounds, keeping the answers gathered so far), and free-text input.
Cancelling the dialog stops the skill and leaves the plan untouched.
Once all aspects are resolved, the plan is updated and persisted, its
Properties: frontmatter key gains the value grilled, and the user is
offered a hand-off to editing, implementation, or preflight.
OPTIONS
--rounds|-r n:
The number of grill rounds to apply (default: 1). Each round
starts from scratch from only the current plan, as updated by all
previous rounds, and re-derives its questions from it, forgetting
all questions and answers of previous rounds. With more than one
round, each round is announced as GRILLING ROUND K/L.
--next|-n option[,...]:
Automatically answer the user dialog for the next step (at the end
of this skill). option is a single token or a comma-separated
chronological list of tokens; the first token is consumed by
this skill and any remaining tokens are forwarded (via --next)
to the downstream skill on hand-off so an entire pipeline can be
pre-scripted in one shot. Recognized tokens at this skill: none
(default, interactive answer required), DONE (no next step),
EDIT (hand-over to ase-task-edit), IMPLEMENT (hand-over to
ase-task-implement), or PREFLIGHT (hand-over to
ase-task-preflight).
ARGUMENTS
- id:
Grill the task with the unique identifier id (default:
default).
The skill accepts only an optional id argument and never a
free-text instruction.
SCENARIOS
- You want to be interviewed about your plan until it is watertight
- You want the open decisions of a plan resolved question by question
- You want fuzzy language and conflicts flushed out of a plan
- You want shared understanding before the implementation starts
EXAMPLES
Grill the current task plan:
❯ /ase-task-grill
Grill the task plan under id hello:
❯ /ase-task-grill hello
Grill the current task plan in two rounds:
❯ /ase-task-grill --rounds 2
Grill the current task plan and then hand off to editing:
❯ /ase-task-grill --next EDIT
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-code-edit.
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.
SCENARIOS
- You want a task plan re-created from scratch
- You want a fresh plan from the original WHAT and WHY
- You want planning restarted after a plan degraded
EXAMPLES
Reboot the current task plan:
❯ /ase-task-reboot
Reboot a specific task and hand off to editing:
❯ /ase-task-reboot --next EDIT hello
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.
SCENARIOS
- You want a dry-run of a plan's implementation
- You want the change set previewed as a unified diff before applying
- You want an implementation draft to review before committing to it
- You want a plan test-driven without touching any source files
EXAMPLES
Preflight the current task plan:
❯ /ase-task-preflight
Preflight a specific task and hand off to implementation when done:
❯ /ase-task-preflight --next IMPLEMENT hello
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.
SCENARIOS
- You want a task plan turned into actual changes
- You want the planned change set applied and verified
- You want a reviewed implementation draft applied 1:1
- You want the implementation isolated in a Git worktree
EXAMPLES
Implement the current task plan:
❯ /ase-task-implement
Implement a specific task and delete the plan when done:
❯ /ase-task-implement --next DELETE hello
Implement the task hello inside the isolated Git WorkTree
.ase/worktree/hello:
❯ /ase-task-implement --worktree hello
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.
SCENARIOS
- You want the current or a given task plan shown
- You want a plan rendered before deciding the next steps
- You want a plan inspected including its implementation draft
EXAMPLES
View the current task plan:
❯ /ase-task-view
View a specific task plan:
❯ /ase-task-view hello
View a plan in full, including its IMPLEMENTATION DRAFT section:
❯ /ase-task-view --full hello
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.
SCENARIOS
- You want an overview of all task plans
- You want task ids listed with status and timestamps
- You want the unfinished or in-progress tasks found
EXAMPLES
List all unfinished task ids:
❯ /ase-task-list
List all task ids together with their status and last-modified timestamps:
❯ /ase-task-list --verbose
List the task ids of every task plan, including the finished ones:
❯ /ase-task-list --exclude none
List only the task ids of the task plans currently under work:
❯ /ase-task-list --include STARTED,BLOCKED
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.
SCENARIOS
- You want a task plan renamed
- You want a task given a better id
- You want the current task moved to a new id
EXAMPLES
Rename the current task:
❯ /ase-task-rename hello-world
Rename a specific task:
❯ /ase-task-rename old-id new-id
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.
SCENARIOS
- You want a task plan shortened without losing meaning
- You want plan wording compressed for faster reading
- You want fluff removed from a plan while keeping all semantics
EXAMPLES
Condense the current task plan:
❯ /ase-task-condense
Condense a specific task and hand off to editing:
❯ /ase-task-condense --next EDIT hello
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.
SCENARIOS
- You want a large task plan split into cohesive sub-tasks
- You want an epic decomposed into independently implementable parts
- You want a preview of how a plan would be divided
- You want each part of a plan persisted as its own separate plan
EXAMPLES
Dissect the current task plan:
❯ /ase-task-dissect
Preview the dissection of a specific task into at most three parts:
❯ /ase-task-dissect --dry --max-parts 3 auth
Re-dissect a task, overwriting the previously created sub-task plans:
❯ /ase-task-dissect --force auth
Dissect the current task plan along an explicitly given axis:
❯ /ase-task-dissect keep the meta file with the skills, docs separate
Dissect a specific task plan with a hint:
❯ /ase-task-dissect auth: one part per authentication provider
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.
SCENARIOS
- You want a task plan removed
- You want a finished or obsolete task cleared
- You want a plan discarded, falling back to the default task
EXAMPLES
Delete the current task plan:
❯ /ase-task-delete
Delete a specific task plan:
❯ /ase-task-delete hello
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.
SCENARIOS
- You want the software architecture of your code base reviewed
- You want coupling and cohesion problems between packages found
- You want an architecture diagram plus PROBLEM and TRADEOFF findings
- You want architecture findings persisted for later resolution
EXAMPLES
Analyze architecture of the current project:
❯ /ase-arch-analyze src/
Analyze a specific module:
❯ /ase-arch-analyze src/core
Analyze a module under its own id namespace, yielding core-P1, core-T1, ...:
❯ /ase-arch-analyze --prefix core src/core
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> or directly
fixed via ase-code-edit P<n>.
ARGUMENTS
- source-reference:
A file, directory, function, or other reference to the source code
to analyze.
SCENARIOS
- You want your code checked for logic, semantics, and control-flow problems
- You want a read-only report of problems without any changes applied
- You want performance and efficiency opportunities surfaced
- You want a security-focused inspection of your code
- You want problems persisted as issue ids like
P1 for later resolving
EXAMPLES
Analyze a specific source file for logic/semantic problems:
❯ /ase-code-analyze src/server.ts
Analyze a directory of code:
❯ /ase-code-analyze src/handlers/
Analyze a source file for performance/efficiency opportunities only:
❯ /ase-code-analyze --performance src/server.ts
Analyze a source file for security aspects only:
❯ /ase-code-analyze -s src/handlers/
Analyze a directory, reporting only MEDIUM and HIGH problems:
❯ /ase-code-analyze -S MEDIUM src/handlers/
Analyze a directory under its own id namespace, yielding auth-P1, auth-P2, ...:
❯ /ase-code-analyze --prefix auth src/auth/
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.
SCENARIOS
- You want to add a new feature to the code base
- You want feature approaches with pros and cons before any code changes
- You want a task plan composed for building something new
- You want a fast one-shot crafting without any plan ceremony
EXAMPLES
Craft a new logging feature:
❯ /ase-code-craft add structured JSON logging with log levels
Craft a feature under a named task and directly hand off to implementation:
❯ /ase-code-craft --next IMPLEMENT auth: add JWT authentication middleware
Craft interactively, applying one change after the other in place:
❯ /ase-code-craft -i add a --verbose option to the CLI
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.
SCENARIOS
- You want existing code restructured without changing its behavior
- You want refactoring approaches with pros and cons before any changes
- You want a task plan composed for a cleanup
- You want a one-shot refactoring applied directly in place
EXAMPLES
Refactor a module into smaller files:
❯ /ase-code-refactor split src/handlers.ts into per-route modules
Refactor under a named task and directly hand off to implementation:
❯ /ase-code-refactor --next IMPLEMENT cleanup: extract HTTP client into its own class
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.
SCENARIOS
- You want a bug fixed or a problem resolved in the code
- You want an issue like
P1 reported by an analyzer resolved
- You want resolution approaches with pros and cons before any changes
- You want a task plan composed for a bugfix
EXAMPLES
Resolve a free-text problem:
❯ /ase-code-resolve fix race condition in cache invalidation
Resolve a previously analyzed issue and hand off to implementation:
❯ /ase-code-resolve --next IMPLEMENT P1
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.
SCENARIOS
- You want the code base edited in one shot from a plain description
- You want an analyzer issue like
P1 fixed directly without a plan
- You want a quick change with optional grilling and verification
- You want several edits chained in a loop, optionally in a worktree
EXAMPLES
Edit in one shot, without any questions or verification:
❯ /ase-code-edit add a --verbose option to the CLI
Grill the query with two rounds first, then implement and verify:
❯ /ase-code-edit -g -r 2 -v refactor the config loading into layers
Loop over multiple edits inside a dedicated Git worktree:
❯ /ase-code-edit -l -w
SEE ALSO
ase-code-craft, ase-code-refactor, ase-code-resolve,
ase-task-grill, ase-task-implement.
ase-spec-edit - Edit Specification
NAME
ase-spec-edit - Edit Specification
SYNOPSIS
ase-spec-edit
[--help|-h]
[--grill|-g]
[--grill-rounds|-r n]
[--verify|-v]
[--worktree|-w]
[--loop|-l]
[query]
DESCRIPTION
The ase-spec-edit skill edits the SpecBook-based specification
(SPEC) directly from a query, in one shot and without any task
plan ceremony. It is the specification-level counterpart of
ase-code-edit and a plan-less alternative to ase-sync-import and
ase-sync-reconcile whenever the specification has to be changed from a
plain description instead of from a foreign source or another artifact
kind.
Each single-shot run (or each --loop iteration) walks through five
states: querying (take the query argument or ask for a query via an
interactive Edit Query dialog, and split it into its domain-specific
WHAT and its implementation-detail HOW parts), discovering (resolve
the SPEC artifacts, read the SpecBook schema configuration of the
project, and read the specification artifacts related to the query),
grilling (optionally stress-test the query with rounds of questions),
implementing (apply the change set in place, honoring the GENERIC and
SPECIFYING tenets and the SPEC format contract), and verifying
(optionally validate the specification until it passes). The querying
state and every grilling round close with an EDIT TODO box showing
the established WHAT and HOW information.
The change set stays strictly restricted to the SPEC artifacts -- the
artifact kinds CODE, DOCS, TASK, INFR, and OTHR are never
touched. Every generated artifact carries the current Created: and
Modified: timestamps, and every changed artifact gets its Modified:
timestamp refreshed.
OPTIONS
--grill|-g:
Grill the query before implementing, similar to ase-task-grill:
raise 1-10 questions per round which resolve the open points of the
query. Each question carries a FOCUS-AREA -- DOMAIN
(domain-specifics, must be clarified), INTERFACE (externally
observable behavior or UI/API interfaces, must be clarified),
ARCHITECTURE (structure, wiring, placement, or dependencies,
should be clarified), or IMPLEMENTATION (inner technical details,
can be clarified) -- and a 1-3 word TOPIC hint. The questions of a
round are sorted by descending focus area importance (DOMAIN,
INTERFACE, ARCHITECTURE, IMPLEMENTATION) and are announced
together below a GRILLING ROUND K/L line (the round numbering is
omitted when only a single round is performed) as a
QUESTION/ANSWERS table with one row per question, each row
carrying two to three grounded answer alternatives (with the
alternative reflecting the current understanding marked with ⚑).
They are then asked in one batch via a single interactive dialog,
whose question asks for the combined answer to all (or a subset) of
the listed questions and whose only answer options are the fixed
SKIP GRILLING (skip the remaining grilling) and STOP SKILL (stop
the skill) ones, plus free-text input. The answers are merged back
into the WHAT and HOW parts of the query. Without --grill, no
questions are asked at all.
--grill-rounds|-r n:
The number of grill rounds to apply (default: 1). Each round
starts from scratch from only the current WHAT and HOW parts,
forgetting all information of previous rounds, and closes with an
EDIT TODO box. Only effective together with --grill.
--verify|-v:
Verify the edited specification by validating it via SpecBook
linting and fixing the reported diagnostics in the affected SPEC
artifacts, for at most three rounds. Any diagnostics remaining after
the last round are listed as REMAINING DIAGNOSTICS. Without
--verify, strictly no validation is performed at all.
--worktree|-w:
Apply the change sets inside a dedicated Git worktree (as
ase-task-implement --worktree) instead of the current working
copy. One single worktree, named by a two-word id derived from the
first query, serves the whole skill run: all --loop iterations
land in it and it is left uncommitted for review. Under --verify,
the validation then runs as the ase spec lint command inside the
worktree.
--loop|-l:
Loop the whole state cycle: after each iteration, ask for the next
edit query via the interactive Edit Query dialog and repeat, until
the user answers with its fixed STOP SKILL option or cancels the
dialog.
ARGUMENTS
- query:
Description of the specification edit to perform. When omitted, the
skill asks for the query via an interactive
Edit Query dialog,
carrying the fixed STOP SKILL option plus free-text input.
SCENARIOS
- You want the specification edited in one shot from a description
- You want
SPEC changes without the task plan ceremony
- You want the query stress-tested by grilling before the spec is edited
- You want specification edits validated by SpecBook linting
EXAMPLES
Edit in one shot, without any questions or validation:
❯ /ase-spec-edit add a Reviewer persona to the persona model
Grill the query with two rounds first, then edit and validate:
❯ /ase-spec-edit -g -r 2 -v split the Event entity into Event and EventSeries
Loop over multiple specification edits inside a dedicated Git worktree:
❯ /ase-spec-edit -l -w
SEE ALSO
ase-spec-activate, ase-code-edit, ase-sync-import,
ase-sync-reconcile, ase-sync-export, ase-task-grill.
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]
[--operation|-o op[,...]]
[--dry|-d]
[--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 six
recognized artifact kinds SPEC (Specification, covering both
requirements and architecture), CODE (Source Code), DOCS
(Documentation), TASK (Task Plans), INFR (Infrastructure), and
OTHR (catch-all). When source is auto, it resolves to all six
kinds minus the kinds listed in target. Unless --bidirectional is
given, a kind present in target is never used as its own source.
The file lists for all involved kinds are resolved via the
ase_artifact_list MCP tool of the ase MCP server. While reconciling,
the skill honors the artifact-format conventions of ase-format-meta.md,
ase-format-spec.md (the SpecBook models and formats plus the
SpecBook schema configuration), and ase-format-task.md; the kinds
CODE, DOCS, INFR, and OTHR have no dedicated format contract and
are treated as free-form. Changed SPEC artifacts are validated via
the ase_specbook_lint MCP tool and the reported diagnostics are fixed
in at most three rounds; any remaining diagnostics are surfaced.
The changes on the target side are the three operations add
(create content and files the source warrants but the target lacks),
update (change existing content the source contradicts), and remove
(delete content and files the source no longer supports). The
--operation option restricts which of them are applied; whatever an
excluded operation would have changed stays untouched. With --dry, no
target artifact is modified at all and the intended changes are shown as
a unified diff instead.
OPTIONS
--bidirectional|-b:
Reconcile the target and source artifacts so that they
faithfully reflect the current state of each other, instead of
only updating the target from the source. With this flag, a kind
present in target is not removed from source, and the
--operation restriction applies to both directions.
--operation|-o op[,...]:
The comma-separated list of operations to apply on the target side,
each one of add, update, or remove. The special value all
(the default) selects all three operations.
--dry|-d:
Perform the regular reconciliation, but do not modify any target
artifact (neither files nor task plans). Instead, show the intended
changes as a single unified diff. The SpecBook validation is skipped,
as nothing is written to disk.
--target|-t target[,...]:
The comma-separated list of artifact kinds to update. Required (the
skill errors out on an empty target).
--source|-s source[,...]:
The comma-separated list of artifact kinds to update from. The
special value auto resolves to all recognized kinds except those
in target.
ARGUMENTS
- hint:
An optional free-form filtering hint that narrows the source and/or
target artifacts, or the aspects of those artifacts to take into
account during reconciliation.
SCENARIOS
- You want one artifact set updated to reflect another one
- You want code and docs aligned with the specification
- You want the specification recovered from the code base
- You want spec and code bidirectionally synchronized
- You want only missing parts added to the documentation, never anything removed
- You want to preview the reconciliation as a diff before applying it
EXAMPLES
Reconcile the code and documentation
to reflect the current specification
in a "forward engineering" approach:
❯ /ase-sync-reconcile -t CODE,DOCS -s SPEC
Reconcile the specification from everything else
in a "reverse engineering" approach:
❯ /ase-sync-reconcile -t SPEC -s CODE,DOCS
Bidirectionally reconcile specification and code against
each other, limited to the authentication aspect:
❯ /ase-sync-reconcile -b -t SPEC -s CODE authentication
Add missing and update outdated parts of the documentation
from the code, but never remove anything:
❯ /ase-sync-reconcile -o add,update -t DOCS -s CODE
Preview the reconciliation of the code from the
specification as a unified diff, without applying it:
❯ /ase-sync-reconcile -d -t CODE -s SPEC
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 six recognized
artifact kinds SPEC (Specification, covering both requirements and
architecture), CODE (Source Code), DOCS (Documentation), TASK
(Task Plans), INFR (Infrastructure), and OTHR (catch-all). It
defaults to SPEC. The file lists for the involved kinds are resolved
via the ase_artifact_list MCP tool of the ase MCP server.
While importing, the skill honors the artifact-format conventions of
ase-format-meta.md, ase-format-spec.md (the SpecBook models and
formats plus the SpecBook schema configuration), and
ase-format-task.md; the kinds CODE, DOCS, INFR, and OTHR have
no dedicated format contract and are treated as free-form. A target
artifact that does not yet exist but is warranted by the imported
information is generated from scratch, while an existing target
artifact is surgically updated to reflect the imported information.
Generated or updated SPEC artifacts are validated via the
ase_specbook_lint MCP tool and the reported diagnostics are fixed in
at most three rounds; any remaining diagnostics are surfaced.
OPTIONS
--target|-t target[,...]:
The comma-separated list of artifact kinds to generate or update.
Defaults to SPEC. The skill errors out on an empty target or
an unknown/unsupported kind.
ARGUMENTS
- hint:
The mandatory free-form description of the foreign sources to import
from (e.g. a file path, directory, URL, or pasted text). The skill
errors out on an empty hint.
SCENARIOS
- You want external sources brought into the project artifacts
- You want a foreign document, URL, or pasted text reflected in the
SPEC
- You want requirements from outside imported into a task plan
- You want legacy material ingested into the specification
EXAMPLES
Import a foreign requirements document into the specification:
❯ /ase-sync-import -t SPEC docs/legacy/requirements.txt
Import an external design write-up into the specification (the default
target), which covers the architecture, too:
❯ /ase-sync-import https://example.com/design-notes.html
Import a pasted feature description into a task plan:
❯ /ase-sync-import -t TASK the new export feature must support CSV and JSON
SEE ALSO
ase-sync-reconcile,
ase-sync-export,
ase-task-implement.
ase-sync-export - Export Specification into Rendered Files
NAME
ase-sync-export - Export Specification into Rendered Files
SYNOPSIS
ase-sync-export
[--help|-h]
[--output|-o output[,...]]
DESCRIPTION
The ase-sync-export skill exports the SPEC artifact set -- the
SpecBook-based specification of the project, located via the
project.artifact.spec.basedir configuration -- into derived,
ready-to-consume renderings. The specification is first validated
against the SpecBook schema configuration via the ase_specbook_lint
MCP tool of the ase MCP server; on any diagnostic the skill errors out
and exports nothing, as a partial or invalid specification must never be
rendered. Otherwise every requested output is rendered via the
ase_specbook_export MCP tool.
Each output is an [<format>:]<file> entry, where the format is one
of json, json5, yaml, toon (the specification object model),
html (self-contained single document with table of contents, full-text
search, and light/dark theme), pdf (paginated print document), or md
(normalized single Markdown document). The format is inferred from the
filename extension unless it is explicitly given as a prefix. The
standard output sentinel - is not supported.
The pdf format is the only one with an external prerequisite: it
prints the rendering through a Chromium-class browser. Neither npm install -g @rse/ase nor ase setup install downloads one, so unless a
Google Chrome is installed system-wide, the Playwright Chromium has to
be fetched once via npx playwright install chromium. Without any such
browser the export fails up-front, before the specification is parsed,
and reports that very command; when it falls back onto a system-installed
Google Chrome, the skill reports this as an environment notice.
OPTIONS
--output|-o output[,...]:
The comma-separated list of [<format>:]<file> entries to render,
with each file path relative to the project root. Defaults to the
single HTML rendering index.html inside the SPEC base directory
(e.g. docs/specbook/index.html).
SCENARIOS
- You want the specification rendered as HTML, PDF, Markdown, or JSON
- You want a shareable, ready-to-consume export of the
SPEC artifacts
- You want the specification validated and then materialized into files
EXAMPLES
Export the specification to its default HTML rendering:
❯ /ase-sync-export
Export the specification as HTML and PDF:
❯ /ase-sync-export -o docs/spec.html,docs/spec.pdf
Export the specification object model as YAML into a file without a
telling extension:
❯ /ase-sync-export -o yaml:docs/spec.model
SEE ALSO
ase-sync-reconcile,
ase-sync-import.
