NAME
ase-meta-persona - Persona Configuration
SYNOPSIS
ase-meta-persona
[--help|-h]
[persona]
DESCRIPTION
The ase-meta-persona skill gets or sets the active communication
style (persona) of the assistant. Five intensity levels of token
usage are supported, from most verbose to most terse:
writer: decorative, eloquent, and explaining; full prose
sentences bundled into paragraphs separated by blank linesengineer: concise, factual, and accurate (default); prefers
bullet point lists with one aspect per bulletjournalist: layered, pyramid-structured; every aspect a single-line
bullet following **<title>**: <core> ▶ **<keywords>**: <details>.,
with a one-to-two word title, a terse core, one-to-four keywords, and
a one-to-four sentence detailtelegrapher: brief, factual, and abbreviating; every aspect a
single-line bullet following **<title>**: <core>., with a one-to-two
word title and a terse, arrow/em-dash-joined corecaveman: terse, rough, and stuttering; every aspect a single-line
bullet with a very terse core of one-word fields or a one-to-two word
expression
Without arguments, the skill reports the currently active persona.
With a persona argument, it switches to that persona via the
ase_persona MCP tool.
ARGUMENTS
persona:
The persona to activate; one of writer, engineer, journalist,
telegrapher, or caveman. If omitted, the currently active
persona is reported.
EXAMPLES
Show the currently active persona:
❯ /ase-meta-persona
Switch to the telegrapher persona:
❯ /ase-meta-persona telegrapher
SEE ALSO
ase-task-id.
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.
ARGUMENTS
--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.
fact:
The observed fact (symptom, problem, or surprising outcome)
whose root cause should be investigated. The skill implicitly
prepends "Why" to form the initial question.
EXAMPLES
Investigate the root cause of a build failure:
❯ /ase-meta-why the CI build is intermittently failing on macOS runners
Drill down deeper with a tunable chain length of seven:
❯ /ase-meta-why -d 7 the production latency spiked after the last deploy
Weigh several candidate sub-causes per level (with backtracking) to avoid
committing early to the wrong root-cause:
❯ /ase-meta-why -w 3 the release was delayed by two weeks
SEE ALSO
ase-code-analyze, ase-code-resolve, ase-arch-analyze.
NAME
ase-meta-evaluate - Evaluate Alternatives
SYNOPSIS
ase-meta-evaluate
[--help|-h]
request
DESCRIPTION
The ase-meta-evaluate skill evaluates two or more alternatives
through a weighted multi-criteria decision matrix. From the
request, the skill derives the reason for the evaluation, the
alternatives, and the criteria, fills in additional criteria up to a
range of 8-12 (using ase-meta-search where helpful), assigns weights
from { 4.00, 2.00, 1.00, 0.50, 0.25 }, evaluates each alternative
against each criterion on a { -2, -1, 0, +1, +2 } Likert scale, and
computes the final ratings via the ase_decision_matrix MCP tool.
The result is reported as a Markdown decision matrix along with the
single BEST ALTERNATIVE, including a warning if multiple
alternatives tie, if the distance to the second best is small, or if
all alternatives rate negatively.
ARGUMENTS
request:
A description of what should be evaluated, including the
alternatives and, optionally, the criteria to consider.
EXAMPLES
Compare logging libraries for a TypeScript project:
❯ /ase-meta-evaluate Compare pino, winston, and bunyan as logging libraries.
Evaluate database options with hinted criteria:
❯ /ase-meta-evaluate Compare PostgreSQL, MySQL, and SQLite for an
embedded use case; criteria include footprint and write throughput.
SEE ALSO
ase-meta-quorum, ase-meta-search, ase-arch-discover,
ase-meta-why.
NAME
ase-meta-diaboli - Play "Devil's Advocate" (Latin: "Advocatus Diaboli")
SYNOPSIS
ase-meta-diaboli
[--help|-h]
[--count|-c count]
thesis
DESCRIPTION
The ase-meta-diaboli skill plays Devil's Advocate (Latin:
Advocatus Diaboli) by relentlessly challenging or criticising a
supplied thesis. It applies a disciplined set of critical-thinking
tenets - steelmanning, stress-testing fundamentals, surfacing implicit
assumptions, demanding proportional evidence, seeking disconfirming
cases, Reductio Ad Absurdum, exposing hidden costs, and pre-mortem
thinking - while targeting the claim rather than its proponent and
yielding where the argument genuinely holds.
The skill iterates until it has found at least count anti-theses
(counter-arguments) each ranked at least 7 on a 0 (weak) to 10
(strong) Likert scale, reports the top count sorted from strongest to
weakest, and finally applies Hegelian dialectics (Thesis +
Antithesis → Synthesis) to derive a single-sentence SYNTHESIS
that preserves what is true in both the thesis and its antitheses
while discarding what is false.
The --count/-c count option sets the minimum number of strong
anti-theses to surface (default 10), raising or lowering the floor of
counter-arguments hunted for, sorted, and reported in the single
challenge pass. A 0, negative, or non-numeric value falls back to the
default 10.
The intent is constructive: stress-testing the thesis in good faith to
arrive at a better final decision, not obstructing or merely being
contrarian.
ARGUMENTS
--count, -c count:
Surface at least count strong anti-theses (default 10) before
sorting and reporting the top count and deriving the SYNTHESIS. An
invalid or non-positive count reverts to the default 10.
thesis:
The statement, claim, or position to be relentlessly challenged.
It may be technical, factual, or opinion-based; the skill attacks
its strongest ("steelman") interpretation.
EXAMPLES
Challenge a technology-choice claim:
❯ /ase-meta-diaboli HAPI is the best REST framework
Stress-test a design decision:
❯ /ase-meta-diaboli We should rewrite the service in Rust.
Surface at least fifteen anti-theses:
❯ /ase-meta-diaboli --count 15 We should rewrite the service in Rust.
SEE ALSO
ase-meta-why, ase-meta-evaluate, ase-meta-quorum,
ase-meta-persona.
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.
ARGUMENTS
--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.
thesis:
The statement, claim, or position to be charitably strengthened.
It may be technical, factual, or opinion-based; the skill defends
its strongest ("steelman") interpretation.
EXAMPLES
Strengthen a technology-choice claim:
❯ /ase-meta-steelman HAPI is the best REST framework
Build the case for a design decision:
❯ /ase-meta-steelman We should rewrite the service in Rust.
Strengthen across five iterative rounds:
❯ /ase-meta-steelman --rounds 5 We should rewrite the service in Rust.
SEE ALSO
ase-meta-diaboli, ase-meta-why, ase-meta-evaluate,
ase-meta-quorum.
NAME
ase-meta-quorum - Query Multiple AIs for Quorum Answer
SYNOPSIS
ase-meta-quorum
[--help|-h]
[--models|-m model[,...]]
question
DESCRIPTION
The ase-meta-quorum skill finds a quorum answer on an arbitrary
question by querying multiple AIs (Anthropic Claude itself plus
OpenAI ChatGPT, Google Gemini, DeepSeek, xAI Grok, Z.AI GLM, and
Alibaba Qwen) for an optimal consensus.
The skill first previews its own answer, then dispatches the same
query to each available foreign LLM via the ase:ase-meta-chat
sub-agent, summarizes all responses, derives a consensus rate on
a Likert scale of 0..N (where N is the number of available
responders), and reports the consensus answer alongside the
complete, unmodified individual responses.
OPTIONS
--models|-m model[,...]:
Restrict the foreign LLMs that are queried to the given
comma-separated list of model tokens. Recognized tokens are
all, chatgpt, gemini, deepseek, grok, glm, and qwen,
where all selects every model. The default is all. Models that
are not selected (or not available) are silently skipped.
Anthropic Claude (the skill itself) is always included,
independent of this option.
ARGUMENTS
question:
The question to ask all available AIs.
EXAMPLES
Ask the quorum a factual question:
❯ /ase-meta-quorum What are the most common causes of memory leaks in Node.js?
Ask only a subset of the foreign models:
❯ /ase-meta-quorum --models chatgpt,gemini,grok Which sorting algorithm is fastest in practice?
SEE ALSO
ase-meta-chat, ase-meta-search, ase-meta-evaluate.
NAME
ase-meta-chat - Query Foreign LLM for Chat
SYNOPSIS
ase-meta-chat
[--help|-h]
llm query
DESCRIPTION
The ase-meta-chat skill queries a foreign LLM (such as OpenAI
ChatGPT, Google Gemini, DeepSeek, xAI Grok, Z.AI GLM, or Alibaba
Qwen) with a single chat message. The underlying ase:ase-meta-chat
sub-agent is invoked and its plain response is shown back verbatim
without any further interpretation.
ARGUMENTS
llm:
Identifier of the foreign LLM to query, e.g. chatgpt,
gemini, deepseek, grok, glm, or qwen.
query:
The chat message to send to the foreign LLM.
EXAMPLES
Ask ChatGPT a quick question:
❯ /ase-meta-chat chatgpt What is the best way to handle UTF-8 BOMs in JSON?
Ask Gemini for a brief comparison:
❯ /ase-meta-chat gemini Compare gRPC and REST in one paragraph.
SEE ALSO
ase-meta-quorum, ase-meta-search.
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.
ARGUMENTS
--services|-s=(all|perplexity|brave|exa|websearch)...:
The comma-separated list of search backends to query. The default
all queries every available backend (the original behavior);
otherwise only the listed backends are queried.
query:
The search query to dispatch to the search services.
EXAMPLES
Search the Web for a topic across all backends:
❯ /ase-meta-search latest stable release of TypeScript and release notes
Search the Web using only the Brave and Exa backends:
❯ /ase-meta-search --services=brave,exa latest stable release of TypeScript
SEE ALSO
ase-meta-chat, ase-meta-quorum, ase-arch-discover.
NAME
ase-meta-brainstorm - Collaboratively Brainstorm a Topic
SYNOPSIS
ase-meta-brainstorm
[--help|-h]
[--max-clarify|-c=3]
[--min-ideas|-i=12]
[--min-rank|-r=7]
[--max-shortlist|-s=4]
topic
DESCRIPTION
The ase-meta-brainstorm skill guides a collaborative ideation
session on a topic before any implementation begins. It first
clarifies intent by exploring the project context and interviewing
the user - one grounded, multiple-choice question at a time - about
purpose, constraints, scope, and success criteria (asking at most
--max-clarify, default 3, questions). It then diverges into a broad
space of candidate ideas (at least --min-ideas, default 12) pursued from
deliberately diverse angles (MVP-first, risk-first, UX-first,
reuse-first, and wildcard), without judging them.
Next it converges by clustering the ideas into coherent themes,
pruning speculative or out-of-scope ones via YAGNI, and scoring the
survivors on a 0-10 fit scale (keeping only those ranked --min-rank,
default 7, or higher). Finally it distills a shortlist of the top
--max-shortlist, default 4, directions - drawn from distinct clusters
wherever possible - and derives a single RECOMMENDATION, being either
the highest-ranked option or a principled synthesis of the shortlist.
OPTIONS
--max-clarify|-c=3:
The maximum number of essential-unknown clarification questions
asked in the clarify intent phase (default: 3). Lower it for a
faster, leaner intake, raise it for more upfront grounding.
--min-ideas|-i=12:
The minimum number of candidate ideas to generate in the diverge
phase before converging (default: 12). Raise it for a broader idea
space, lower it for a quicker, narrower session.
--min-rank|-r=7:
The minimum 0-10 fit rank an idea must score to survive the
converge phase (default: 7). Raise it for a stricter filter, lower
it to retain more ideas.
--max-shortlist|-s=4:
The maximum number of distilled options on the final shortlist
(default: 4). Lower it for a sharper focus, raise it for more
finalists.
ARGUMENTS
topic:
The subject to brainstorm - a feature, component, behavior, or
design question to explore what to build before how.
EXAMPLES
Brainstorm an approach for a new feature:
❯ /ase-meta-brainstorm an offline-first sync layer for the mobile app
Brainstorm with a broader idea space of at least 20 candidates:
❯ /ase-meta-brainstorm --min-ideas 20 an offline-first sync layer
Brainstorm quickly with a single clarification, a stricter score floor,
and a tighter shortlist:
❯ /ase-meta-brainstorm --max-clarify 1 --min-rank 8 --max-shortlist 3 an offline-first sync layer
SEE ALSO
ase-meta-evaluate, ase-meta-quorum, ase-meta-diaboli
NAME
ase-meta-compat - Self-Test ASE Compatibility
SYNOPSIS
ase-meta-compat
[--help|-h]
DESCRIPTION
The ase-meta-compat skill self-tests how faithfully the current LLM
(and its harness) executes the four core interpreter primitives that
every ASE skill silently relies on, and reports an overall 0%…100%
compatibility rating. ASE skills are not run by a conventional
interpreter - they are interpreted by the model itself, which must honor
control-flow constructs, substitute XML placeholders, evaluate regex
conditions, and perform arithmetic. If a model cannot execute these
primitives reliably, every ASE skill silently misbehaves, so this skill
lets a user measure the fit before relying on ASE.
The skill is both the test definition and the system under test. It
probes four capability categories:
XML Placeholders: the get (<x/>) and set (<x>v</x>) semantics,
including the get-and-set composite, indexed names, and XML-entity
rendering.
Control Flow: the <if>/<elseif>/<else>, <while>/<break>,
<for>, <step condition=…>, and <expand>/<define> constructs.
Regex Matching: the patterns ASE genuinely uses (e.g. the getopt
short-circuit (^|\s)-), plus anchoring, alternation, and captures.
Arithmetic: counter increments, decision-matrix product-sums,
percentage rounding, and bar-width computations.
Each probe embeds a construct with a known expected result; the model
executes it and honestly self-checks its actual result against the
expected one. Per-category pass-rates are combined into the overall rating
via the ase_decision_matrix MCP tool as a weighted average, with
XML Placeholders weighted 4.00 (the backbone of every skill),
Control Flow weighted 3.00, Regex Matching weighted 2.00, and
Arithmetic weighted 1.00. The
result is a boxed per-category table (passes and percentage per category),
a final OVERALL COMPATIBILITY percentage, and a one-line VERDICT
(✓ fully compatible at ≥ 90%, ⚠ partially compatible at 60–89%,
✘ incompatible below 60%) that names any failed probes.
ARGUMENTS
The ase-meta-compat skill takes no arguments (besides --help|-h). It
always runs the most rigorous self-test, with 6 probes per category
(7 for Regex Matching), for 25 probes in total.
EXAMPLES
Run the compatibility self-test:
❯ /ase-meta-compat
SEE ALSO
ase-meta-evaluate, ase-meta-quorum, ase-meta-why.
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 searched per source and retained
in the final ranking (default: 12). Raise it for a broader, more
exhaustive survey, lower it for a quicker, narrower lookup.
--staleness|-s=18:
The staleness threshold in months (default: 18). A component whose
last release is older than this is rank-penalized and flagged with an
aging gotcha; older than twice the threshold, it is penalized
harder and flagged as stale/abandoned.
--small-scope|-S:
Treat the requested functionality as small-scope (default: off).
When enabled, the ranking demotes dependency-heavy components by a
dependency-weight penalty, since a dependency-free/hand-rolled
implementation is a realistic alternative for narrow, self-contained
functionality.
ARGUMENTS
functionality:
A short description of the desired functionality the third-party
component should provide.
EXAMPLES
Discover components for JSON schema validation:
❯ /ase-arch-discover JSON schema validation
Discover components for HTTP client functionality:
❯ /ase-arch-discover HTTP client with retries
Discover a broader set of up to 20 HTTP client components:
❯ /ase-arch-discover --limit 20 HTTP client with retries
Discover HTTP clients, flagging any without a release in the last 12 months:
❯ /ase-arch-discover --staleness 12 HTTP client with retries
SEE ALSO
ase-arch-analyze, ase-meta-search, ase-meta-evaluate.
NAME
ase-code-insight - Project Insight
SYNOPSIS
ase-code-insight
[--help|-h]
code-references
DESCRIPTION
The ase-code-insight skill gives high-level insights into the
project through the referenced source code. The skill produces four
sections: a PROJECT ABSTRACT (summary derived from README.* or
source scanning), a PROJECT AUTHOR list (from git shortlog),
a SOURCE CHURN table (most-committed files in the last year), and
a MODULE STRUCTURE Mermaid diagram of modules and their imports.
ARGUMENTS
code-references:
One or more file or directory references to source code that
should be inspected for insights.
EXAMPLES
Get insights into the current project:
❯ /ase-code-insight src/
Get insights into a specific subsystem:
❯ /ase-code-insight tool/src/
SEE ALSO
ase-code-explain, ase-code-analyze, ase-arch-analyze.
NAME
ase-code-explain - Explain Source Code
SYNOPSIS
ase-code-explain
[--help|-h]
source-reference
DESCRIPTION
The ase-code-explain skill analyzes and explains the source code of
the referenced location in a brief, standardized, and concise
way along six dimensions: WHAT (functionality), WHY (rationale),
ANALOGY (everyday-life comparison in ELI5 style), DIAGRAM (Mermaid
diagram of control flow, data flow, or structure), CRUXES (what to
notice), and GOTCHAS (what to not stumble over).
ARGUMENTS
source-reference:
A file, directory, function, or other reference to the source code
to explain.
EXAMPLES
Explain a single source file:
❯ /ase-code-explain src/parser.ts
Explain a specific function:
❯ /ase-code-explain src/parser.ts#parseExpression
SEE ALSO
ase-code-insight, ase-code-analyze, ase-arch-analyze.
NAME
ase-code-lint - Lint Source Code
SYNOPSIS
ase-code-lint
[--help|-h]
[--auto|-a]
[--severity|-S=(LOW|MEDIUM|HIGH)]
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.
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.
ARGUMENTS
source-reference:
A file, directory, or other reference to the source code to lint.
EXAMPLES
Lint a source file interactively:
❯ /ase-code-lint src/server.ts
Lint a directory and automatically apply all corrections:
❯ /ase-code-lint --auto src/handlers/
Lint a directory, reporting only MEDIUM and HIGH findings:
❯ /ase-code-lint -S MEDIUM src/handlers/
SEE ALSO
ase-code-analyze, ase-code-resolve, ase-code-refactor,
ase-docs-proofread.
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.
ARGUMENTS
--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.
document-reference:
The document to distill - either a path to a readable file or the
text itself pasted inline. If it resolves to a readable file the
file is read; otherwise it is treated verbatim as pasted text.
EXAMPLES
Distill the key points of a document file:
❯ /ase-docs-distill doc/architecture.md
Distill only the top 5 key points:
❯ /ase-docs-distill --top 5 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.
NAME
ase-docs-proofread - Proofread Documents
SYNOPSIS
ase-docs-proofread
[--help|-h]
[--auto|-a]
docs-reference
DESCRIPTION
The ase-docs-proofread skill analyzes the referenced documents for
spelling, punctuation, and grammar errors and proposes
corrections. The investigation is dispatched to a sub-agent
(ase:ase-docs-proofread) so that scanning details do not leak into
the user-visible transcript.
For each detected problem, the skill renders a unified-diff
CORRECTION preview and either asks the user to ACCEPT or REJECT
the proposed correction interactively (or refine it via a free-text
hint, which re-proposes the correction without limit) or - with
--auto - applies all corrections automatically.
OPTIONS
--auto|-a:
Automatically apply every proposed correction without asking the
user via the interactive dialog.
ARGUMENTS
docs-reference:
A file, directory, or other reference to the documents to
proofread.
EXAMPLES
Proofread a single document interactively:
❯ /ase-docs-proofread README.md
Proofread an entire documentation directory automatically:
❯ /ase-docs-proofread --auto docs/
SEE ALSO
ase-code-lint, ase-meta-changelog.
NAME
ase-meta-review - Review Staged Changes
SYNOPSIS
ase-meta-review
[--help|-h]
[--severity|-S=(LOW|MEDIUM|HIGH)]
DESCRIPTION
The ase-meta-review skill performs a holistic,
human-reviewer-style critique of the staged Git changes and emits a
single approve / reject verdict backed by prioritized,
severity-tagged, line-cited findings. Rather than scanning the
code mechanically, it first reconstructs the change's own intent and
then judges the diff as a whole against that intent - the way an
experienced reviewer would on a pull request.
The critique spans a fixed set of reviewer dimensions: intent
(does the diff do what it set out to, without scope creep or stray
residue), correctness (latent bugs, edge cases, broken
control/data flow), design (fit with the surrounding architecture,
naming, abstraction level), clarity (readability and
self-documentation for a future reader), robustness (error handling,
resource and concurrency safety), security and performance (risks
introduced by the change), convention (conformance to the
project's documented conventions - code style and the plan/spec/arch
formats described in AGENTS.md and the ase-format-* meta documents),
testing (inadequate coverage for the change - new or fixed behavior
left untested, adjacent tests not updated, or existing tests silently
broken, disabled, or weakened), and documentation (user- or
developer-facing docs - README, CHANGELOG, help text, or AI
guidance/meta documents - left stale by the change).
Each finding carries a severity - HIGH, MEDIUM, LOW, or
ACCEPTED (a concern that is contractually addressed or accepted as a
documented priority conflict) - and is evidence-grounded: it cites the
exact file:line location it stems from. The overall verdict is
REJECT - DEMANDS CHANGES when any HIGH finding remains, and
APPROVE otherwise. The work is performed by a dedicated ase-meta-review
sub-agent so that the silent reading and read-only repository probing
never leak into the transcript; only the structured verdict and findings
are rendered.
The skill complements rather than duplicates its neighbours:
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 judgement 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. The floor only affects the rendered findings table,
not the overall verdict, which is always derived from all findings
before the floor is applied.
ARGUMENTS
The ase-meta-review skill takes no positional arguments; it always
reviews the currently staged Git changes.
EXAMPLES
Review the currently staged changes before committing:
❯ /ase-meta-review
Review the staged changes, reporting only MEDIUM and HIGH findings:
❯ /ase-meta-review -S MEDIUM
SEE ALSO
ase-meta-diff, ase-meta-commit, ase-code-lint, ase-code-analyze,
ase-meta-diaboli.
NAME
ase-meta-diff - Summarize Diff
SYNOPSIS
ase-meta-diff
[--help|-h]
[--coherence|-c]
[--risk|-r]
[--blast|-b]
DESCRIPTION
The ase-meta-diff skill turns a raw Git diff into a concise,
human-readable narrative of what changed and why, grouped by
intent (such as Feature, Improvement, Bugfix, Update,
Cleanup, or Refactor) rather than by file. It inspects the
staged changes (git diff --cached HEAD). The result is a compact
table, one row per intent group, each naming the affected files
with their per-file [+N/-M] line counts - giving you the essence
of the changes at a glance.
With --coherence, the skill additionally reconstructs the single
intended change the diff is trying to accomplish - phrased as one crisp
thesis sentence - and then walks every hunk to flag those that do
not serve it: scope creep (an unrelated feature or drive-by refactor
riding along) and stray debug (leftover prints, commented-out code, or
disabled tests). It emits an overall COHERENT / INCOHERENT verdict
plus a table of the flagged hunks with what to do with each - keeping the
diff to a single logical and coherent change before it is committed.
With --risk, the skill additionally scores the same diff against a
four-axis coupling-criticality-coverage-reversibility rubric and
emits a graded risk report - one table row per axis (each scored 1-5
with a one-line evidence justification drawn from the actual hunks), an
overall risk band (LOW, MODERATE, HIGH, or CRITICAL),
and one actionable mitigation per high-risk axis. The axes combine
with equal weights, and the rubric is deliberately not tuned to any
specific project: every score is backed by cited evidence so it remains
overridable, and the report is decision support, not a merge gate.
With --blast, the skill additionally renders a blast-radius map - a
Mermaid flowchart of the touched modules and their reverse
dependencies, plus a brief impact summary. It extracts the touched
modules from the changed files, scans the repository for the
first-party code that imports or references those modules, builds a
blast-radius graph (touched modules as origin nodes, dependents fanning
out along the edges), dispatches the rendering to the ase-meta-diagram
sub-agent, and appends a short bullet list of the per-module impact -
giving a visual sense of what a diff endangers before a deeper review.
ARGUMENTS
--coherence, -c:
In addition to the intent-grouped summary, reconstruct the diff's
single intended change as one crisp thesis sentence and flag
every hunk that does not serve it - scope creep or stray
debug - then emit an overall COHERENT / INCOHERENT verdict
with a table of the flagged hunks.
--risk, -r:
In addition to the intent-grouped summary, score the diff against
the coupling-criticality-coverage-reversibility rubric and emit a
graded risk report with an overall risk band and per-axis
mitigations. Scores are equal-weighted, evidence-backed, and
deliberately untuned to the project.
--blast, -b:
In addition to the intent-grouped summary, render a blast-radius
map - a Mermaid flowchart of the touched modules and their
reverse dependencies - plus a brief impact summary of what
depends on the touched code and how far the blast reaches.
EXAMPLES
Summarize the currently staged changes:
❯ /ase-meta-diff
Summarize the staged changes and append an intent-coherence report:
❯ /ase-meta-diff --coherence
Summarize the staged changes and append a graded risk report:
❯ /ase-meta-diff --risk
Summarize the staged changes and append a blast-radius map:
❯ /ase-meta-diff --blast
SEE ALSO
ase-meta-commit, ase-meta-changelog, ase-arch-analyze.
NAME
ase-meta-changelog - Update ChangeLog Entries
SYNOPSIS
ase-meta-changelog
[--help|-h]
DESCRIPTION
The ase-meta-changelog skill helps to complete, consolidate, and
sort the entries of the most recent section of a CHANGELOG.md
file, based on the underlying Git commits and the currently staged
changes in the Git index.
Each entry is formatted as <change-type> [<artifact-kind>]: <summary>
where change-type is one of FEATURE, IMPROVEMENT, BUGFIX,
UPDATE, CLEANUP, or REFACTOR, and artifact-kind is one or more
comma-separated artifact class tags out of spec, arch, code,
docs, infr, or othr. Entries are grouped and sorted by this
prefix. The date in the section header is also updated to the current
date.
EXAMPLES
Update the most recent ChangeLog section:
❯ /ase-meta-changelog
SEE ALSO
ase-meta-commit, ase-docs-proofread.
NAME
ase-meta-commit - Git Commit Message
SYNOPSIS
ase-meta-commit
[--help|-h]
DESCRIPTION
The ase-meta-commit skill helps to craft a concise commit
message for the currently staged Git changes. It inspects the
output of git diff --cached and produces a single-line message of
the form <type>: <summary> where type is one of FEATURE,
IMPROVEMENT, BUGFIX, UPDATE, CLEANUP, or REFACTOR, and
summary is a 60-80 character imperative-mood summary without
trailing period or Markdown formatting.
EXAMPLES
Craft a commit message for the currently staged changes:
❯ /ase-meta-commit
SEE ALSO
ase-meta-changelog.
NAME
ase-task-id - Configure Task Id
SYNOPSIS
ase-task-id
[--help|-h]
[id]
DESCRIPTION
The ase-task-id skill gets or sets the unique task id for the
current session. Without arguments, it reports the currently active
task id. With an id argument, it switches the session to that
task id via the ase_task_id MCP tool.
ARGUMENTS
id:
The new task id to activate. If omitted, the currently active
task id is reported.
EXAMPLES
Show the current task id:
❯ /ase-task-id
Switch to a specific task:
❯ /ase-task-id hello
SEE ALSO
ase-task-list, ase-task-edit, ase-task-view,
ase-task-rename, ase-task-delete.
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.
OPTIONS
--plan|-p option:
Automatically answer the user dialog for the plan refinement
with option, which can be either none (default, interactive
answer required), OVERWRITE (overwrite an existing plan
with instruction), REFINE (refine the existing plan with
instruction), or PRESERVE (preserve the existing plan by
ignoring instruction and stopping skill processing).
--dry|-d:
Generate any new plan without the ## VERIFICATION section.
Applies only to freshly generated plans, not to existing plans
loaded from disk. When ase-task-implement later applies such
a plan, it strictly skips the entire verification phase (no
build, tests, linter, type-checker, or program execution) once
the source files have been modified.
--next|-n option[,...]:
Automatically answer the user dialog for the next step (at the end
of this skill). option is a single token or a comma-separated
chronological list of tokens; each iteration of the planning
loop consumes the first token of the list, and on hand-off
(IMPLEMENT / PREFLIGHT) any remaining tokens are forwarded
(via --next) to the downstream skill so an entire pipeline can
be pre-scripted in one shot. Recognized tokens at this skill:
none (default, interactive answer required), DONE (no next
step), GRILL (hand-over to ase-task-grill), PREFLIGHT
(hand-over to ase-task-preflight), or IMPLEMENT (hand-over to
ase-task-implement). Example: --next GRILL,DONE hands the plan
off to grilling and forwards DONE so grilling exits without asking.
ARGUMENTS
id | id: instruction | instruction:
Edit the task with the unique identifier id (default: default).
Optionally, instruction either gives instructions for creating a
new task or gives instructions for refining an existing task.
EXAMPLES
Edit the current task:
❯ /ase-task-edit
Create a new task under id hello:
❯ /ase-task-delete hello
❯ /ase-task-edit hello: new "ase hello" CLI command which prints
a nice "Hello World!" to the terminal in color blue.
Further refine the task under id hello:
❯ /ase-task-edit hello: change the color to red.
SEE ALSO
ase-task-reboot, ase-task-preflight, ase-task-implement,
ase-task-view, ase-task-list, ase-task-rename, ase-task-delete.
NAME
ase-task-grill - Iteratively Grill a Task Plan
SYNOPSIS
ase-task-grill
[--help|-h]
[--next|-n option[,...]]
[id]
DESCRIPTION
The ase-task-grill skill relentlessly interviews the user about
every essential aspect of an existing task plan until a shared
understanding is reached and no decisions or questions are left open.
The skill identifies the essential aspects of the plan, builds a
decision tree of the open questions, and walks down each branch
one-by-one. For each aspect it presents up to four grounded
alternative answers (the current plan plus alternatives derived from
the code base and world knowledge), marks the current-plan choice, and
lets the user pick via an interactive dialog. It honors checks for
fuzzy language, conflicting terminology, conflicting code, and
non-concrete scenarios. Once all aspects are resolved, the plan is
updated and persisted, and the user is offered a hand-off to editing,
implementation, or preflight.
OPTIONS
--next|-n option[,...]:
Automatically answer the user dialog for the next step (at the end
of this skill). option is a single token or a comma-separated
chronological list of tokens; the first token is consumed by
this skill and any remaining tokens are forwarded (via --next)
to the downstream skill on hand-off so an entire pipeline can be
pre-scripted in one shot. Recognized tokens at this skill: none
(default, interactive answer required), DONE (no next step),
EDIT (hand-over to ase-task-edit), IMPLEMENT (hand-over to
ase-task-implement), or PREFLIGHT (hand-over to
ase-task-preflight).
ARGUMENTS
id:
Grill the task with the unique identifier id (default: default).
The skill accepts only an optional id argument and never a
free-text instruction.
EXAMPLES
Grill the current task plan:
❯ /ase-task-grill
Grill the task plan under id hello:
❯ /ase-task-grill hello
Grill the current task plan and then hand off to editing:
❯ /ase-task-grill --next EDIT
SEE ALSO
ase-task-edit, ase-task-reboot, ase-task-preflight,
ase-task-implement, ase-task-view, ase-task-list,
ase-task-rename, ase-task-delete.
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 a fresh plan
content via ase_task_save.
After the reboot, the user is asked whether to stop or hand off to
ase-task-edit, unless --next pre-selects this choice.
OPTIONS
--next|-n option[,...]:
Automatically answer the user dialog for the next step. option
is a single token or a comma-separated chronological list of
tokens; the first token is consumed by this skill, and any
remaining tokens are forwarded (via --next) to the downstream
skill so an entire pipeline can be pre-scripted in one shot.
Recognized tokens at this skill: none (default, interactive
answer required), DONE (stop), EDIT (hand off to
ase-task-edit), IMPLEMENT (hand off to ase-task-implement),
or PREFLIGHT (hand off to ase-task-preflight). Example: --next EDIT,DONE reboots, hands off to editing, and the editing loop will
exit immediately.
ARGUMENTS
id:
The unique identifier of the task whose plan should be rebooted.
If omitted, the current task id is used.
EXAMPLES
Reboot the current task plan:
❯ /ase-task-reboot
Reboot a specific task and hand off to editing:
❯ /ase-task-reboot --next EDIT hello
SEE ALSO
ase-task-edit, ase-task-preflight, ase-task-implement,
ase-task-view, ase-task-delete.
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).
No source files are modified.
After the preflight, the user is asked whether to stop, hand
off to ase-task-edit, or hand off to ase-task-implement,
unless --next pre-selects this choice.
OPTIONS
--next|-n option[,...]:
Automatically answer the user dialog for the next step. option
is a single token or a comma-separated chronological list of
tokens; the first token is consumed by this skill, and any
remaining tokens are forwarded (via --next) to the downstream
skill so an entire pipeline can be pre-scripted in one shot.
Recognized tokens at this skill: none (default, interactive
answer required), DONE (stop), EDIT (hand off to
ase-task-edit), or IMPLEMENT (hand off to
ase-task-implement). Example: --next IMPLEMENT,DONE runs the
preflight, hands off to implementation, then exits without asking.
ARGUMENTS
id:
The unique identifier of the task whose plan should be
preflighted. If omitted, the current task id is used.
EXAMPLES
Preflight the current task plan:
❯ /ase-task-preflight
Preflight a specific task and hand off to implementation when done:
❯ /ase-task-preflight --next IMPLEMENT hello
SEE ALSO
ase-task-edit, ase-task-implement, ase-task-reboot,
ase-task-view.
NAME
ase-task-implement - Implement a Task Plan
SYNOPSIS
ase-task-implement
[--help|-h]
[--next|-n option[,...]]
[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 used as a hint - the plain
plan content always overrules the draft.
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.
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 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 (preserve task plan and stop), or
DELETE (hand off to ase-task-delete).
ARGUMENTS
id:
The unique identifier of the task whose plan should be
implemented. If omitted, the current task id is used.
EXAMPLES
Implement the current task plan:
❯ /ase-task-implement
Implement a specific task and delete the plan when done:
❯ /ase-task-implement --next DELETE hello
SEE ALSO
ase-task-edit, ase-task-preflight, ase-task-reboot,
ase-task-view, ase-task-delete.
NAME
ase-task-view - View a Task Plan
SYNOPSIS
ase-task-view
[--help|-h]
[--full|-f]
[id]
DESCRIPTION
The ase-task-view skill renders the task plan identified by id.
The plan is loaded via the ase_task_load MCP tool and shown framed
between a ( TASK ) header and footer rule. If id is omitted, the
current task id (inherited from the session context) is used.
By default, when the plan is longer than 90 lines and contains an
IMPLEMENTATION DRAFT section (produced by ase-task-preflight), the
content of that section is collapsed to [...] to keep the view
compact. The --full|-f option suppresses this collapsing and renders
the plan in full, without any truncation or summarization.
OPTIONS
--full|-f:
Render the plan in full, without collapsing the IMPLEMENTATION DRAFT section. By default, that section is replaced with [...]
for plans longer than 90 lines.
ARGUMENTS
id:
The unique identifier of the task plan to view. If omitted,
the current task id is used.
EXAMPLES
View the current task plan:
❯ /ase-task-view
View a specific task plan:
❯ /ase-task-view hello
View a plan in full, including its IMPLEMENTATION DRAFT section:
❯ /ase-task-view --full hello
SEE ALSO
ase-task-list, ase-task-edit, ase-task-id,
ase-task-rename, ase-task-delete.
NAME
ase-task-list - List Task Plans
SYNOPSIS
ase-task-list
[--help|-h]
[--verbose|-v]
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 last-modified timestamp of
each task plan is rendered as an additional column.
OPTIONS
--verbose|-v:
Render an additional Last Modified column with the
YYYY-MM-DD HH:MM timestamp of each task plan.
EXAMPLES
List all task ids:
❯ /ase-task-list
List all task ids together with their last-modified timestamps:
❯ /ase-task-list --verbose
SEE ALSO
ase-task-id, ase-task-view, ase-task-edit,
ase-task-rename, ase-task-delete.
NAME
ase-task-rename - Rename a Task Plan
SYNOPSIS
ase-task-rename
[--help|-h]
[old] new
DESCRIPTION
The ase-task-rename skill renames a task plan from old to
new via the ase_task_rename MCP tool. If only one argument is
given, it is treated as new and old defaults to the current
task id. When the renamed task is the current task, the current
task id is automatically switched to new.
ARGUMENTS
[old] new:
The old task id to rename and the new task id to assign.
If only one token is given, old defaults to the current
task id.
EXAMPLES
Rename the current task:
❯ /ase-task-rename hello-world
Rename a specific task:
❯ /ase-task-rename old-id new-id
SEE ALSO
ase-task-list, ase-task-id, ase-task-edit,
ase-task-view, ase-task-delete.
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: timestamp) and reported as already condensed.
After condensing, the user is asked whether to stop or hand off to
ase-task-edit, ase-task-implement, or ase-task-preflight, unless
--next pre-selects this choice.
OPTIONS
--next|-n option[,...]:
Automatically answer the user dialog for the next step. option
is a single token or a comma-separated chronological list of
tokens; the first token is consumed by this skill, and any
remaining tokens are forwarded (via --next) to the downstream
skill so an entire pipeline can be pre-scripted in one shot.
Recognized tokens at this skill: none (default, interactive
answer required), DONE (stop), EDIT (hand off to
ase-task-edit), IMPLEMENT (hand off to ase-task-implement),
or PREFLIGHT (hand off to ase-task-preflight). Example: --next EDIT,DONE condenses, hands off to editing, and the editing loop will
exit immediately.
ARGUMENTS
id:
The unique identifier of the task whose plan should be condensed.
If omitted, the current task id is used.
EXAMPLES
Condense the current task plan:
❯ /ase-task-condense
Condense a specific task and hand off to editing:
❯ /ase-task-condense --next EDIT hello
SEE ALSO
ase-task-edit, ase-task-reboot, ase-task-view,
ase-task-rename, ase-task-delete.
NAME
ase-task-delete - Delete a Task Plan
SYNOPSIS
ase-task-delete
[--help|-h]
[id]
DESCRIPTION
The ase-task-delete skill deletes the task plan identified by
id. If id is omitted, the current task id (inherited from the
session context) is used. When the deleted task is the current task
and not the default task, the current task id is automatically
switched back to default.
ARGUMENTS
id:
The unique identifier of the task plan to delete. If omitted,
the current task id is used.
EXAMPLES
Delete the current task plan:
❯ /ase-task-delete
Delete a specific task plan:
❯ /ase-task-delete hello
SEE ALSO
ase-task-edit, ase-task-list, ase-task-view,
ase-task-rename, ase-task-reboot.
NAME
ase-arch-analyze - Review Software Architecture
SYNOPSIS
ase-arch-analyze
[--help|-h]
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.
ARGUMENTS
source-reference:
A file, directory, or other reference to the source code that
is to be analyzed architecturally.
EXAMPLES
Analyze architecture of the current project:
❯ /ase-arch-analyze src/
Analyze a specific module:
❯ /ase-arch-analyze src/core
SEE ALSO
ase-arch-discover, ase-code-analyze, ase-code-resolve,
ase-code-refactor, ase-code-insight.
NAME
ase-code-analyze - Analyze Source Code
SYNOPSIS
ase-code-analyze
[--help|-h]
[--performance|-p]
[--security|-s]
[--severity|-S=(LOW|MEDIUM|HIGH)]
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 renumbered contiguously as
P<n>.
The skill investigates the code base silently, reports each detected
problem as a PROBLEM entry with severity (LOW, MEDIUM, HIGH) and
inline file/line references (in the performance lens, each entry
additionally carries an evidence and a trade-off line), and persists
results in the ase MCP key/value store as ase-issue-P<n> entries so
they can later be resolved via ase-code-resolve P<n>.
ARGUMENTS
source-reference:
A file, directory, function, or other reference to the source code
to analyze.
EXAMPLES
Analyze a specific source file for logic/semantic problems:
❯ /ase-code-analyze src/server.ts
Analyze a directory of code:
❯ /ase-code-analyze src/handlers/
Analyze a source file for performance/efficiency opportunities only:
❯ /ase-code-analyze --performance src/server.ts
Analyze a source file for security aspects only:
❯ /ase-code-analyze -s src/handlers/
Analyze a directory, reporting only MEDIUM and HIGH problems:
❯ /ase-code-analyze -S MEDIUM src/handlers/
SEE ALSO
ase-code-resolve, ase-code-refactor, ase-code-lint,
ase-code-explain, ase-arch-analyze.
NAME
ase-code-craft - Craft Source Code
SYNOPSIS
ase-code-craft
[--help|-h]
[--auto|-a]
[--dry|-d]
[--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.
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.
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.
--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 or PREFLIGHT 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), PREFLIGHT (hand off to ase-task-preflight),
or IMPLEMENT (hand off to ase-task-implement). Example:
--next PREFLIGHT,IMPLEMENT,DONE crafts the plan, preflights it,
implements it, and exits without further dialog.
ARGUMENTS
[task-id:] feature:
Description of the feature to craft. Optionally prefixed with
a task-id followed by a colon to bind the resulting plan to
a specific task id.
EXAMPLES
Craft a new logging feature:
❯ /ase-code-craft add structured JSON logging with log levels
Craft a feature under a named task and directly hand off to implementation:
❯ /ase-code-craft --next IMPLEMENT auth: add JWT authentication middleware
SEE ALSO
ase-code-refactor, ase-code-resolve, ase-task-edit,
ase-task-preflight, ase-task-implement.
NAME
ase-code-refactor - Refactor Artifacts
SYNOPSIS
ase-code-refactor
[--help|-h]
[--auto|-a]
[--dry|-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.
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.
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.
--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 or PREFLIGHT 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), PREFLIGHT (hand off to ase-task-preflight),
or IMPLEMENT (hand off to ase-task-implement). Example:
--next PREFLIGHT,IMPLEMENT,DONE refactors, preflights, implements,
and exits without further dialog.
ARGUMENTS
[task-id:] request:
Description of the refactoring request. Optionally prefixed
with a task-id followed by a colon to bind the resulting plan
to a specific task id.
EXAMPLES
Refactor a module into smaller files:
❯ /ase-code-refactor split src/handlers.ts into per-route modules
Refactor under a named task and directly hand off to implementation:
❯ /ase-code-refactor --next IMPLEMENT cleanup: extract HTTP client into its own class
SEE ALSO
ase-code-craft, ase-code-resolve, ase-task-edit,
ase-task-preflight, ase-task-implement.
NAME
ase-code-resolve - Resolve Problem
SYNOPSIS
ase-code-resolve
[--help|-h]
[--auto|-a]
[--dry|-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>.
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.
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.
--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 or PREFLIGHT 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), PREFLIGHT (hand off to ase-task-preflight),
or IMPLEMENT (hand off to ase-task-implement). Example:
--next IMPLEMENT,DONE resolves the problem, implements it, and
exits without further dialog.
ARGUMENTS
[task-id:] problem:
Description of the problem to resolve, or a bare issue
identifier like P1 or T1 previously produced by an analyzer
skill. Optionally prefixed with a task-id followed by a colon
to bind the resulting plan to a specific task id.
EXAMPLES
Resolve a free-text problem:
❯ /ase-code-resolve fix race condition in cache invalidation
Resolve a previously analyzed issue and hand off to implementation:
❯ /ase-code-resolve --next IMPLEMENT P1
SEE ALSO
ase-code-craft, ase-code-refactor, ase-code-analyze,
ase-arch-analyze, ase-task-edit, ase-task-preflight,
ase-task-implement.
NAME
ase-sync-reconcile - Reconcile Artifact Set to Artifact Set
SYNOPSIS
ase-sync-reconcile
[--help|-h]
[--bidirectional|-b]
[--target|-t target[,...]]
[--source|-s source[,...]]
[hint]
DESCRIPTION
The ase-sync-reconcile skill reconciles one set of artifact kinds (the
target) to reflect the current state of another set of artifact
kinds (the source). It reads the source artifacts and then adjusts the
target artifacts directly and surgically to match the source state,
while optionally honoring a filtering hint.
Both target and source are comma-separated lists over the seven
recognized artifact kinds SPEC (Specification), ARCH (Architecture),
CODE (Source Code), DOCS (Documentation), TASK (Task Plans), INFR
(Infrastructure), and OTHR (catch-all). When source is auto, it
resolves to all seven kinds minus the kinds listed in target. Unless
--bidirectional is given, a kind present in target is never used as
its own source.
The file lists for all involved kinds are resolved via the
ase_artifact_list MCP tool of the ase MCP server. While reconciling,
the skill honors the artifact-format conventions of ase-format-meta.md,
ase-format-spec.md, ase-format-arch.md, and ase-format-task.md;
the kinds CODE, DOCS, INFR, and OTHR have no dedicated format
contract and are treated as free-form.
OPTIONS
--bidirectional|-b:
Reconcile the target and source artifacts so that they
faithfully reflect the current state of each other, instead of
only updating the target from the source. With this flag, a kind
present in target is not removed from source.
--target|-t target[,...]:
The comma-separated list of artifact kinds to update. Required (the
skill errors out on an empty target).
--source|-s source[,...]:
The comma-separated list of artifact kinds to update from. The
special value auto resolves to all recognized kinds except those
in target.
ARGUMENTS
hint:
An optional free-form filtering hint that narrows the source and/or
target artifacts, or the aspects of those artifacts to take into
account during reconciliation.
EXAMPLES
Reconcile the code and documentation
to reflect the current specification and architecture
in a "forward engineering" approach:
❯ /ase-sync-reconcile -t CODE,DOCS -s SPEC,ARCH
Reconcile specification and architecture from everything else
in a "reverse engineering" approach:
❯ /ase-sync-reconcile -t SPEC,ARCH -s CODE,DOCS
Bidirectionally reconcile specification and architecture against
each other, limited to the authentication aspect:
❯ /ase-sync-reconcile -b -t SPEC -s ARCH authentication
SEE ALSO
ase-meta-changelog,
ase-task-implement
NAME
ase-sync-import - Import Foreign Sources into Artifact Set
SYNOPSIS
ase-sync-import
[--help|-h]
[--target|-t target[,...]]
hint
DESCRIPTION
The ase-sync-import skill imports information from foreign sources
into a set of artifact kinds (the target), generating or updating the
target artifacts so they faithfully reflect the imported information.
Unlike ase-sync-reconcile, which syncs between existing ASE artifact
kinds, ase-sync-import brings in information from external sources
that live outside the ASE artifact sets.
The foreign sources are named by the free-form hint argument and may
be local files or directories, remote URLs, pasted text passages, or
references to other documents. Local files are read via the Read tool
and remote URLs are fetched via the available web tools.
The target is a comma-separated list over the seven recognized
artifact kinds SPEC (Specification), ARCH (Architecture), CODE
(Source Code), DOCS (Documentation), TASK (Task Plans), INFR
(Infrastructure), and OTHR (catch-all). It defaults to SPEC,ARCH.
The file lists for the involved kinds are resolved via the
ase_artifact_list MCP tool of the ase MCP server.
While importing, the skill honors the artifact-format conventions of
ase-format-meta.md, ase-format-spec.md, ase-format-arch.md, and
ase-format-task.md; the kinds CODE, DOCS, INFR, and OTHR have
no dedicated format contract and are treated as free-form. A target
artifact that does not yet exist but is warranted by the imported
information is generated from scratch, while an existing target
artifact is surgically updated to reflect the imported information.
OPTIONS
--target|-t target[,...]:
The comma-separated list of artifact kinds to generate or update.
Defaults to SPEC,ARCH. The skill errors out on an empty target or
an unknown/unsupported kind.
ARGUMENTS
hint:
The mandatory free-form description of the foreign sources to import
from (e.g. a file path, directory, URL, or pasted text). The skill
errors out on an empty hint.
EXAMPLES
Import a foreign requirements document into the specification:
❯ /ase-sync-import -t SPEC docs/legacy/requirements.txt
Import an external design write-up into the architecture, defaulting
both specification and architecture as targets:
❯ /ase-sync-import https://example.com/design-notes.html
Import a pasted feature description into a task plan:
❯ /ase-sync-import -t TASK the new export feature must support CSV and JSON
SEE ALSO
ase-sync-reconcile,
ase-sync-export,
ase-task-implement
NAME
ase-sync-export - Export Artifact Set to Side-by-Side Files
SYNOPSIS
ase-sync-export
[--help|-h]
[--source|-s source[,...]]
[filter]
DESCRIPTION
The ase-sync-export skill exports the content of a set of artifact
kinds (the source) into derived, ready-to-consume files placed
side-by-side with the artifacts themselves. For every source artifact
that declares an export in its format definition, the skill builds the
declared rendering and writes it to a sibling file.
The source is a comma-separated list over the seven recognized
artifact kinds SPEC (Specification), ARCH (Architecture), CODE
(Source Code), DOCS (Documentation), TASK (Task Plans), INFR
(Infrastructure), and OTHR (catch-all). The file lists for the
involved kinds are resolved via the ase_artifact_list MCP tool of the
ase MCP server.
An export is declared by a - Export: bullet point in an artifact's
format definition (see ase-format-meta.md, ase-format-spec.md, and
ase-format-arch.md); an artifact without such a bullet is not
exported. Each exported file is named
<set>-<no>-<id>-<slug>-<export-name>.<ext> (e.g.
SPEC-07-DM-Data-Model-export.svg) and stored in the artifact's own
base directory. Initially, the Data Model (SPEC-DM) exports as a
Mermaid UML diagram converted to SVG, and the Technology Stack
(ARCH-TS) exports as a compact Markdown table.
OPTIONS
--source|-s source[,...]:
The comma-separated list of artifact kinds to export. Defaults to
SPEC,ARCH (the skill errors out on an empty source).
ARGUMENTS
filter:
An optional free-form filtering hint that narrows the source
artifacts, or the aspects of those artifacts, to take into account
when materializing the exports. If omitted, every export declared by
a source artifact is materialized.
EXAMPLES
Export the specification and architecture artifacts to their
side-by-side files (the default):
❯ /ase-sync-export
Export only the specification artifacts:
❯ /ase-sync-export -s SPEC
Export only the data-model artifact:
❯ /ase-sync-export -s SPEC data model
SEE ALSO
ase-sync-reconcile,
ase-sync-import
