@rse/ase 0.9.55 → 0.9.57

package/plugin/meta/ase-skill.md

@@ -13,7 +13,7 @@ Skill Output
     the value of a placeholder named `xxx`.
 
 -   *IMPORTANT*: *All* output is *exclusively* requested through
-    <template/> sections. You *MUST* *NOT* output anything *EXCEPT* it
+    <template/> sections. You *MUST* *NOT* output anything *UNLESS* it
     is explicitly included in such a <template/> section. Especially,
     you *MUST* *NOT* output any explanations on your own, unless
     explicitly requested.
@@ -95,8 +95,8 @@ Skill Output
 
         -   *Fix conflicts with documented priority*: the
             recommendation would violate a documented priority
-            (hot-path, allocation-free, lock-free, latency-
-            sensitive, sub-µs budget). Either weaken the
+            (hot-path, allocation-free, lock-free,
+            latency-sensitive, sub-µs budget). Either weaken the
             recommendation, convert it to a tradeoff, or mark
             severity `ACCEPTED` with note "priority-conflict
             accepted".
@@ -113,7 +113,7 @@ Skill Sequential Processing
     Each `<step id="xxx" [...]>...</step>` corresponds to a
     `TaskCreate({ subject: "xxx", description: "xxx" })`. In other
     words, use the text of the `id` attribute of <step/> exactly
-    *as-is* for both the `subject`, and the `description` fields of
+    *as-is* for both the `subject` and the `description` fields of
     `TaskCreate`.
 
     For speed, emit *all* `TaskCreate` calls together in a *single* turn
@@ -121,7 +121,7 @@ Skill Sequential Processing
     rely on the call order to establish the step order, as the parallel
     results carry no guaranteed ordering.
 
-    Instead, in the *immediately single following* turn, first
+    Instead, in the *single immediately following* turn, first
     reconstruct the step-id-to-taskId mapping: because each task's
     `subject` equals the originating <step/> `id` (and <step/> ids are
     unique), match every created task back to its <step/> by comparing
@@ -138,7 +138,7 @@ Skill Sequential Processing
     predecessor step (with `taskId` <prev/>).
 
 -   *IMPORTANT*: For each <step/> you *MUST* use the `TaskUpdate` tool
-    for updating its status *during* processing, once a <step/> finished.
+    for updating its status *during* processing, once a <step/> has finished.
 
 -   *IMPORTANT*: Whenever a skill *stops early* -- because a <step/>
     instructed you to *STOP* processing (on an error, a cancelled
@@ -151,12 +151,12 @@ Skill Sequential Processing
 
 -   *IMPORTANT*: You *MUST* *strictly sequentially* execute every <step/> in
     a <flow/>. You *MUST* not implicitly skip any <step/> during
-    processing, except you were explicitly requested to do this or the
+    processing, unless you were explicitly requested to do this or the
     step is configured to be a conditional step!
 
 -   *IMPORTANT*: You *MUST* *strictly sequentially* execute every numbered
     item in a <step/>. You *MUST* not implicitly skip any numbered item during
-    processing, except you were explicitly requested to do this!
+    processing, unless you were explicitly requested to do this!
 
 -   *IMPORTANT*: For any <step/> that specifies an *agent* in its
     `agent="[...]"` XML attribute, you *MUST* use the specified
@@ -252,7 +252,7 @@ Skill Identification
 
 -   *IMPORTANT*:
     You *MUST* *NOT* output any summaries, explanations, or next
-    steps at the end of a skill beside the explicit outputs via any
+    steps at the end of a skill besides the explicit outputs via any
     <template/>.
 
 Artifact Boxing Transparency
@@ -291,7 +291,7 @@ Artifact Boxing Transparency
         -   Findings surfaced: *none* (report only the *outcome*)
         -   Internals exposed: *none* (no diffs, no code, no per-artifact explanation)
 
--   *IMPORTANT*: Precedence rule: skill's *explicit* `black` branches
+-   *IMPORTANT*: Precedence rule: a skill's *explicit* `black` branches
     deterministically skip or suppress and *win* over the implicit decisions
     above. Where no such branches exist, the decisions above apply.
 
@@ -458,19 +458,6 @@ Template Patterns
         Do not output anything.
     </else>
 
--   When `<ase-tpl-boxline><line/></ase-tpl-boxline>` should be expanded, use:
-
-    <if condition="<line/> is not empty">
-        <template>
-        │ <line/>
-        </template>
-    </if>
-    <else>
-        <template>
-        │
-        </template>
-    </else>
-
 -   When `<ase-tpl-boxed title="<title/>"[ subtitle="<subtitle/>"]><content/></ase-tpl-boxed>`
     should be expanded use the following helper placeholders and then
     the following <template/>:
@@ -487,7 +474,10 @@ Template Patterns
         un-styled text <raw-title/>.
     -   Set <bar/> to the `─` character repeated exactly max(0, 67 - <raw-title-len/>)
         times -- clamped to zero so an over-long title never yields a negative count.
-    -   Set <body/> to <content/> with all line-starts prefixed with `│ `.
+    -   Set <body/> to <content/> with all non-empty lines prefixed with
+        `│ ` and all empty lines prefixed with just `│` (so no trailing
+        whitespace is produced). Do *not* prefix any line twice -- the
+        <content/> itself *MUST* *NOT* contain any `│` prefixes already.
 
     <template>
 

package/plugin/meta/ase-tenets.md

@@ -37,9 +37,9 @@ you *MUST* honor the following so-called **GENERIC TENETS**:
     -   Handle obvious or expected errors near the origin.
     -   Handle theoretical or unexpected errors in parent scopes.
     -   Avoid introducing dedicated state variables for individual error cases.
-    -   If state variables are needed to detect error cases, use minimum
+    -   If state variables are needed to detect error cases, use the minimum
         number of those variables only.
-    -   Use minimum number of state variables to span the maximum of error space.
+    -   Use the minimum number of state variables to span the maximum of error space.
 
 -   **Surgical Changes**:
     *Keep changes as small as possible.*
@@ -61,7 +61,7 @@ you *MUST* honor the following so-called **GENERIC TENETS**:
     -   When one concern changes, the change should not ripple into unrelated ones.
 
 -   **Code Base Alignment**:
-    *Blend in. New aspect should read as if the existing aspects wrote it.*
+    *Blend in. A new aspect should read as if the existing aspects wrote it.*
     -   Follow the established coding style, formatting, and idioms exactly.
     -   Mirror the existing structure, layering, and file organization.
     -   Reuse the prevailing naming conventions, patterns, and libraries.
@@ -150,12 +150,12 @@ you *MUST* honor the following so-called **RECONCILIATION TENETS**:
     Re-express source facts at the *target's* level of abstraction and
     altitude; do not copy verbatim across artifact levels. A SPEC states
     intent, an ARCH states structure, CODE states realization, DOCS
-    states facts, etc -- align the *meaning*, not the wording.
+    states facts, etc. -- align the *meaning*, not the wording.
 
 -   **Format Conformance**:
     Keep every formatted target (SPEC, ARCH, TASK) conformant to its
     format contract (headings, structure, identifiers). Treat CODE,
-    DOCS, INFR, and OTHR kinds of artifacts as foreign defined, but not
+    DOCS, INFR, and OTHR kinds of artifacts as foreign-defined, but not
     as free-form.
 
 -   **Alignment Traceability**:

package/plugin/package.json

@@ -6,7 +6,7 @@
     "homepage":                             "https://ase.tools",
     "repository":                           { "url": "git+https://github.com/rse/ase.git", "type": "git" },
     "bugs":                                 { "url": "https://github.com/rse/ase/issues" },
-    "version":                              "0.9.55",
+    "version":                              "0.9.57",
     "license":                              "Apache-2.0",
     "author": {
         "name":                             "Dr. Ralf S. Engelschall",
@@ -19,7 +19,7 @@
         "markdownlint-cli2":                "0.23.2",
         "eslint":                           "10.8.0",
         "@eslint/markdown":                 "8.0.3",
-        "eslint-markdown":                  "0.12.1"
+        "eslint-markdown":                  "0.13.0"
     },
     "engines": {
         "npm":                              ">=10.0.0",

package/plugin/skills/ase-arch-analyze/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ase-arch-analyze
-argument-hint: "[--help|-h] <source-reference>"
+argument-hint: "[--help|-h] [--prefix|-P=<prefix>] <source-reference>"
 description: Review software architecture, including package cohesion and inter-package coupling
 user-invocable: true
 disable-model-invocation: false
@@ -130,7 +130,7 @@ interface quality, quality attributes, and architecture governance.
     surfaced. *Skip* the entire investigation and reporting: do *not*
     invoke any `Agent` tool and do *not* read any source, only output
     the following <template/> and then *SKIP* the remaining steps STEP 2
-    through STEP 4:
+    and STEP 3:
 
     <template>
     <ase-tpl-bullet-normal/> **ARCHITECTURE ANALYSIS**: *suppressed* (`project.boxing` is `black`)

package/plugin/skills/ase-arch-analyze/help.md

@@ -54,7 +54,7 @@ Analyze a specific module:
 ❯ /ase-arch-analyze src/core
 ```
 
-Analyze a module under an own id namespace, yielding `core-P1`, `core-T1`, ...:
+Analyze a module under its own id namespace, yielding `core-P1`, `core-T1`, ...:
 
 ```text
 ❯ /ase-arch-analyze --prefix core src/core

package/plugin/skills/ase-arch-discover/SKILL.md

@@ -9,7 +9,7 @@ disable-model-invocation: false
 effort: high
 allowed-tools:
     - "Bash(npm search --json *)"
-    - "Bash(curl -s https://search.maven.org/*)"
+    - "Bash(curl -s *)"
     - "Skill"
     - "Agent"
 ---
@@ -78,8 +78,9 @@ for the technology stack to *provide* the *needed functionality*
         2.  Else, if a file `package.json` is found in the top-level directory
             of the project, then <stack>JavaScript</stack>.
 
-        3.  Else, if a file `build.gradle.kts` or `settings.gradle.kts`
-            is found in the top-level directory, then <stack>Kotlin</stack>.
+        3.  Else, if a file `build.gradle.kts` is found in the top-level directory and
+            is applying `kotlin`, `org.jetbrains.kotlin.jvm`, `kotlin-android`,
+            or `kotlin-multiplatform` plugins, then <stack>Kotlin</stack>.
 
         4.  Else, if a file `build.gradle` is found in the top-level directory and
             is applying `kotlin`, `org.jetbrains.kotlin.jvm`, `kotlin-android`,
@@ -89,8 +90,8 @@ for the technology stack to *provide* the *needed functionality*
             contains `kotlin-maven-plugin` or `kotlin-stdlib` dependencies, then
             <stack>Kotlin</stack>.
 
-        6.  Else, if a file `pom.xml` or `build.gradle` is found in the top-level directory
-            of the project, then <stack>Java</stack>.
+        6.  Else, if a file `pom.xml`, `build.gradle`, or `build.gradle.kts` is found
+            in the top-level directory of the project, then <stack>Java</stack>.
 
         7.  Else, use <stack>Unknown</stack>.
 
@@ -123,7 +124,7 @@ for the technology stack to *provide* the *needed functionality*
         (which alone is governed by <getopt-option-limit/>) has a
         meaningful set to choose from.
 
-        In the to be discovered candidate set of components <component-K/>
+        In the to-be-discovered candidate set of components <component-K/>
         (K=1-C, where C is the merged and deduplicated candidate count),
         remember the component name as <name-K/>, the
         official package name as <package-K/>, the latest version as
@@ -178,7 +179,8 @@ for the technology stack to *provide* the *needed functionality*
         and fetches all metadata in maximum parallel and returns an array
         of objects `{ name, version, created, updated, repository, stars,
         downloads, deps, rank }`. For each component <component-K/>
-        (K=1-C) read from its corresponding entry: <version-K/> from
+        (K=1-C) read from its corresponding entry: <name-K/> from `name`
+        (unless already known from the discovery above), <version-K/> from
         `version`, <updated-K/> from `updated`, <created-K/> from
         `created`, <repository-K/> from `repository`, <stars-K/> from
         `stars` (numeric or `N.A.`), <downloads-K/> from `downloads`

package/plugin/skills/ase-code-analyze/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ase-code-analyze
-argument-hint: "[--help|-h] [--performance|-p] [--security|-s] [--severity|-S=(LOW|MEDIUM|HIGH)] <source-reference>"
+argument-hint: "[--help|-h] [--performance|-p] [--security|-s] [--severity|-S=(LOW|MEDIUM|HIGH)] [--prefix|-P=<prefix>] <source-reference>"
 description: >
     Analyze the source code for problems in either the logic and
     semantics and its related control flow, performance and efficiency,

package/plugin/skills/ase-code-analyze/help.md

@@ -92,7 +92,7 @@ Analyze a directory, reporting only `MEDIUM` and `HIGH` problems:
 ❯ /ase-code-analyze -S MEDIUM src/handlers/
 ```
 
-Analyze a directory under an own id namespace, yielding `auth-P1`, `auth-P2`, ...:
+Analyze a directory under its own id namespace, yielding `auth-P1`, `auth-P2`, ...:
 
 ```text
 ❯ /ase-code-analyze --prefix auth src/auth/

package/plugin/skills/ase-code-craft/SKILL.md

@@ -138,91 +138,7 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
 4.  <step id="STEP 4: Choose Feature Crafting Approaches">
 
-    You *MUST* perform the following sub-steps *internally* and *without
-    any output* until and including the recommendation decision. Only
-    sub-steps 4-7 below are allowed to produce output; sub-steps 4-6 only if
-    <getopt-option-auto/> is equal `false` *and* <ase-project-boxing/>
-    is *not* equal `black`.
-
-    If <getopt-option-auto/> is equal `true` or <ase-project-boxing/> is
-    equal `black`, *skip* the reporting sub-steps 4-6 entirely (they
-    perform no output at all) to speed up processing.
-
-    1.  *Propose* a corresponding *feature approach*, optionally including
-        some *alternative* feature approaches. Do *not* output anything
-        in this sub-step.
-
-    2.  *Reflect* on and *critique* the proposed approaches by deriving,
-        per approach, a small set of concrete *pros* and *cons*. Do
-        *not* output anything in this sub-step.
-
-    3.  Based on the reflection, *decide* which approach to recommend
-        and annotate it with an <annotation/> of
-        ` ⚝ **RECOMMENDATION** ⚝`. All other approaches receive an
-        empty <annotation/>. Do *not* output anything in this sub-step.
-
-    4.  Indicate start of reporting by showing the following <template/>:
-
-        <template>
-        <ase-tpl-head title="APPROACHES"/>
-        </template>
-
-    5.  Now report each approach with the following <template/>,
-        inlining its pros/cons derived in sub-step 2, and do not output
-        anything else in this step:
-
-        <template>
-        ●   **APPROACH A<n/>**<annotation/>: **<summary/>**
-        ○   [...]
-        ⊕   *PRO*: [...]
-        ⊖   *CON*: [...]
-        </template>
-
-        Hints:
-
-        -   Give a short one-sentence <summary/> of the feature
-            approach plus *precise* and *ultra brief and concise*
-            feature information. Try to keep the number of bullet points
-            (`○ [...]`) in the range of 1-4.
-
-    6.  Indicate end of reporting by showing the following <template/>:
-
-        <template>
-        <ase-tpl-foot title="APPROACHES"/>
-        </template>
-
-    7.  <if condition="<getopt-option-auto/> is not equal `true` and <ase-project-boxing/> is not equal `black`">
-
-        In the following, you *MUST* *NOT* use your built-in
-        <user-dialog-tool/> tool! Instead, you *MUST* just show a
-        custom dialog according to the expanded `custom-dialog`
-        definition. You *MUST* closely follow this definition.
-
-        Let the user choose the preferred approach A<n/> by raising
-        a question with the following custom dialog, where per
-        approach A<n/>, you determine an ultra brief summary
-        <short-summary/> and then use the answer option `A<n/>:
-        ⚝ **RECOMMENDATION** ⚝ - <short-summary/>` for your
-        recommended approach plus zero or more answer options `A<n/>:
-        <short-summary/>` for all other approaches:
-
-        <expand name="custom-dialog" arg1="--no-other">
-            Select Approach: Select your preferred crafting approach to follow?
-            A<n/>: <short-summary/>
-            [...]
-        </expand>
-
-        </if>
-        <else>
-
-        Set <n/> to the number of the feature approach A<n/> you recommend.
-        Output a hint with the following <template/>:
-
-        <template>
-        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **auto-chosen approach A<n/>**
-        </template>
-
-        </else>
+    <expand name="code-approaches" arg1="feature" arg2="crafting"></expand>
 
     </step>
 
@@ -267,74 +183,7 @@ permitted way to persist artifacts is via `ase_task_save(...)`.
 
     5.  Directly pass-through control to the next skill:
 
-        Treat <getopt-option-next/> as a comma-separated chronological
-        list of pre-selected next-step tokens. *Peek* the *first* token
-        as <head/> (or `none` if the list is `none`/empty).
-        Set <args>--int-reuse-task</args>.
-
-        1.  <if condition="<head/> is equal `DONE`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty). `DONE`
-            means the freshly composed plan is finalized as-is, so do
-            *not* hand off to `ase-task-edit`. Only output the following
-            <template/> and then *STOP*. Do *not* implement the plan.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **plan finalized -- done**
-            </template>
-            </if>
-
-        2.  <elseif condition="<head/> is equal `IMPLEMENT`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty).
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Call the tool `Skill(skill: "ase:ase-task-implement", args: "<args/>")`
-            to *implement* the freshly composed plan, bypassing `ase-task-edit`.
-            </elseif>
-
-        3.  <elseif condition="<head/> is equal `PREFLIGHT`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty).
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Call the tool `Skill(skill: "ase:ase-task-preflight", args: "<args/>")`
-            to *preflight* the freshly composed plan, bypassing `ase-task-edit`.
-            </elseif>
-
-        4.  <elseif condition="<head/> is equal `GRILL`">
-            Consume the head: set <getopt-option-next/> to the remaining
-            tokens (joined back with `,`, or `none` if empty). `GRILL`
-            is this skill's own dispatch token, *not* part of
-            `ase-task-grill`'s `--next` vocabulary, so it must be
-            stripped here rather than forwarded. All remaining tokens are
-            `ase-task-grill`'s own vocabulary and are forwarded verbatim.
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Call the tool `Skill(skill: "ase:ase-task-grill", args: "<args/>")`
-            to *grill* the freshly composed plan, bypassing `ase-task-edit`.
-            </elseif>
-
-        5.  <else>
-            Hand off to `ase-task-edit`.
-            <if condition="<head/> is equal `EDIT`">
-                Consume the head: set <getopt-option-next/> to the remaining
-                tokens (joined back with `,`, or `none` if empty). `EDIT`
-                is this skill's own dispatch token, *not* part of
-                `ase-task-edit`'s `--next` vocabulary, so it must be
-                stripped here rather than forwarded.
-            </if>
-            All remaining tokens are `ase-task-edit`'s own vocabulary
-            and are forwarded verbatim, so `ase-task-edit` consumes its
-            own head itself.
-            <if condition="<getopt-option-next/> is not equal `none`">
-                Set <args><args/> --next <getopt-option-next/></args>
-            </if>
-            Then call the tool `Skill(skill: "ase:ase-task-edit", args: "<args/>")`.
-            </else>
+        <expand name="code-next-dispatch"></expand>
 
     </step>
 

package/plugin/skills/ase-code-craft/help.md

@@ -56,7 +56,7 @@ plan via `ase_task_save` and then hands off to `ase-task-edit`,
     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`
+    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`),

package/plugin/skills/ase-code-explain/SKILL.md

@@ -25,7 +25,7 @@ Explain Source Code
 
 <objective>
 *Analyze* the source code of <getopt-arguments/>, and its directly related source
-code and *explain* it in a *brief*, *standardized*, and *concise* way.
+code, and *explain* it in a *brief*, *standardized*, and *concise* way.
 </objective>
 
 <flow>
@@ -126,10 +126,10 @@ code and *explain* it in a *brief*, *standardized*, and *concise* way.
 4.  <step id="STEP 4: CRUXES and GOTCHAS">
     **Highlight CRUXES and GOTCHAS**.
 
-    First, tell what are the *cruxes* of the code.
+    First, tell what the *cruxes* of the code are.
     Is there something one should really *notice*?
 
-    Second, tell what are the gotchas of the code.
+    Second, tell what the gotchas of the code are.
     Is there something one could really *stumble over*?
 
     Keep your explanation *brief* and *concise*.

package/plugin/skills/ase-code-insight/SKILL.md

@@ -51,7 +51,8 @@ Give *insights* into the project through the source code of <getopt-arguments/>.
 
     Determine an <abstract/> summary of this project.
     For this, check a potentially existing `README.*` file
-    or scan the source files and figure it out indirectly.
+    or scan the source files of <getopt-arguments/> and figure it out
+    indirectly.
 
     Display the results with the following <template/>:
 
@@ -80,8 +81,8 @@ Give *insights* into the project through the source code of <getopt-arguments/>.
     </step>
 
 3.  <step id="STEP 3: SOURCE CHURN">
-    Display the source files which caused the most churn by
-    figuring out which source files have the most commits.
+    Display the source files of <getopt-arguments/> which caused the
+    most churn by figuring out which of them have the most commits.
     Display the following <template/>:
 
     <template>
@@ -91,7 +92,7 @@ Give *insights* into the project through the source code of <getopt-arguments/>.
     Then run the following command...
 
     ```
-    git log --format=format: --name-only --since="1 year ago" | grep -v '^$' | sort | uniq -c | sort -nr | head -10
+    git log --format=format: --name-only --since="1 year ago" -- <getopt-arguments/> | grep -v '^$' | sort | uniq -c | sort -nr | head -10
     ```
 
     ...and then display its result as a table with a table head and
@@ -106,9 +107,10 @@ Give *insights* into the project through the source code of <getopt-arguments/>.
     <ase-tpl-bullet-normal/> **MODULE STRUCTURE**:
     </template>
 
-    Find all modules (or OOP classes) and build a Mermaid specification
-    <mermaid-spec/> for a `flowchart TB` diagram with all modules as
-    boxes and the imports between modules as the directed edges. Then
+    Find all modules (or OOP classes) of <getopt-arguments/> and build a
+    Mermaid specification <mermaid-spec/> for a `flowchart TB` diagram
+    with all modules as boxes and the imports between modules as the
+    directed edges. Then
     dispatch the rendering to the `ase-meta-diagram` sub-agent by
     calling the tool `Agent(description: "Diagram Rendering",
     subagent_type: "ase:ase-meta-diagram", prompt: <mermaid-spec/>,

package/plugin/skills/ase-code-lint/SKILL.md

@@ -276,10 +276,12 @@ related to a set of code quality aspects.
 
                     Set <old-start/> to the 1-based line number of the
                     *first* old-side hunk line: if <context-before/> is
-                    non-empty, that is its line (one before <line/>);
-                    otherwise it is <line/> itself (the first line of
-                    <old-text/>). For a hunk that *only inserts* new lines
-                    (empty <old-text/> *and* empty context), set it to the
+                    non-empty, that is the line of its *first* context
+                    line, i.e. <line/> minus the number of lines in
+                    <context-before/>; otherwise it is <line/> itself
+                    (the first line of <old-text/>). For a hunk that
+                    *only inserts* new lines (empty <old-text/> *and*
+                    empty context), set it to the
                     line *before* which the insertion happens, clamped to a
                     minimum of `0`, so a top-of-file insertion yields
                     `@@ -0,0 ... @@`.
@@ -341,7 +343,7 @@ related to a set of code quality aspects.
 
             </template>
 
-        5.  <if condition="<getopt-option-auto/> is not equal `true` and <ase-project-boxing/> is not equal `black`">
+        5.  <if condition="<getopt-option-auto/> is not equal `true`">
 
             <if condition="<ase-project-boxing/> is equal `grey`">