@rse/ase 2.0.3 → 2.0.5

package/plugin/mods/claude-code.d.ts

@@ -2593,7 +2593,7 @@ declare module 'claude-code' {
           call: EventCalls['tool']['call'];
           /**
            * Asks the engine's permission decision for a tool call now: the event
-           * `tool.check`, resolved to `{ decision, reason?, rule? }`.
+           * `tool.check`, resolved to its verdict (`{ decision, reason?, ... }`).
            *
            * The hooks run (the calling hook's own frame skipped, `next.origin` this
            * plugin, no `tool_use_id`); nothing runs, no dialog opens, no PreToolUse
@@ -3719,7 +3719,7 @@ declare module 'claude-code' {
        */
       'tool.call': ToolCallResult;
       /**
-       * `{ decision, reason?, rule?, hook?, ceiling? }`.
+       * `{ decision, reason?, rule?, hook?, setting?, decider?, ceiling? }`.
        */
       'tool.check': ToolCheckResult;
       /**
@@ -10123,6 +10123,12 @@ declare module 'claude-code' {
    */
   type ToolCheckArgs = Pick<ToolCheckInput, 'tool' | 'input'>;
 
+  /**
+   * Who an ask is put to, where that is not a dialog here: `host`, the program
+   * that answers a hosted session's asks, or a served call's own session.
+   */
+  type ToolCheckDecider = 'host';
+
   /**
    * The verdict of `tool.check`: run the tool, put it to the mode's decider
    * (the dialog, the auto-mode classifier, a headless host), or refuse it.
@@ -10158,7 +10164,7 @@ declare module 'claude-code' {
 
   /**
    * What a `tool.check` hook returns and what `next(e)` resolves to: the
-   * verdict, why, and the rule, classic hook or ceiling behind it, if any.
+   * verdict, why, what stands behind it, and who answers core's ask.
    *
    * From core, the engine's declarative decision for the session's mode and
    * rules. A hook may answer any verdict in either direction; the last word up
@@ -10188,6 +10194,23 @@ declare module 'claude-code' {
        * Absent on a `$.tool.check` query, which runs no classic hook.
        */
       hook?: string;
+      /**
+       * The key of the option whose own check asked, whoever configured it
+       * (`permissions.blockReadsOutsideWorkingDirectories`).
+       *
+       * From core, for the read block: its ask on a shell command that reads
+       * outside the working directories or, the block on, leaves the sandbox.
+       */
+      setting?: string;
+      /**
+       * Who an ask is put to, where that is not a dialog here: `host`, a hosted
+       * session's permission callback or the cloud session a served call is for.
+       *
+       * From core, on its own ask, only where a host would be asked: an ask the
+       * mode or the loop refuses with nobody asked (dontAsk, no prompt to show)
+       * names none, and neither does a host whose card the person answers.
+       */
+      decider?: ToolCheckDecider;
       /**
        * The most permissive verdict the organization lets a call of the tool
        * reach (`ask`), as its administrators set it on a connector's tool.

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

@@ -1,6 +1,6 @@
 ---
 name: ase-code-lint
-argument-hint: "[--help|-h] [--auto|-a] [--severity|-S=(AUTO|LOW|MEDIUM|HIGH)] [--include|-i=<aspect>[,...]] [--exclude|-e=<aspect>[,...]] [--staged] [--unstaged] [<source-reference>]"
+argument-hint: "[--help|-h] [--auto|-a] [--severity|-S=(AUTO|LOW|MEDIUM|HIGH)] [--force|-f] [--include|-i=<aspect>[,...]] [--exclude|-e=<aspect>[,...]] [--staged] [--unstaged] [<source-reference>]"
 description: >
     Lint source code for potential code quality problems.
     Use when the user wants to "lint" or "check" source code.
@@ -23,7 +23,7 @@ Lint Source Code
 
 <expand name="getopt"
     arg1="ase-code-lint"
-    arg2="--auto|-a --severity|-S=(AUTO|LOW|MEDIUM|HIGH) --include|-i=(none|A01|A02|A03|A04|A05|A06|A07|A08|A09|A10|A11|A12|A13|A14|A15|A16|A17|A18|A19|A20|A21)... --exclude|-e=(none|A01|A02|A03|A04|A05|A06|A07|A08|A09|A10|A11|A12|A13|A14|A15|A16|A17|A18|A19|A20|A21)... --staged --unstaged">
+    arg2="--auto|-a --severity|-S=(AUTO|LOW|MEDIUM|HIGH) --force|-f --include|-i=(none|A01|A02|A03|A04|A05|A06|A07|A08|A09|A10|A11|A12|A13|A14|A15|A16|A17|A18|A19|A20|A21)... --exclude|-e=(none|A01|A02|A03|A04|A05|A06|A07|A08|A09|A10|A11|A12|A13|A14|A15|A16|A17|A18|A19|A20|A21)... --staged --unstaged">
     $ARGUMENTS
 </expand>
 
@@ -36,11 +36,11 @@ related to a set of code quality aspects.
 
 1.  <step id="STEP 1: Investigation">
 
-    <if condition="<ase-project-boxing/> is equal `black` and <getopt-option-severity/> is equal `AUTO`">
+    <if condition="<ase-project-boxing/> is equal `black` and <getopt-option-force/> is not equal `true`">
 
     The project source artifacts are classified as a *black box*, so
     the user does *not* want them inspected or their problems surfaced
-    (an *explicitly* given severity floor lifts this skip).
+    (the `--force` option lifts this skip).
     *Skip* the entire investigation and reporting: do *not* invoke any
     `Bash`, `Glob`, or `Agent` tool and do *not* read any source, only
     output the following <template/> and then *SKIP* the remaining steps
@@ -53,9 +53,9 @@ related to a set of code quality aspects.
     </if>
 
     Set <condensed>true</condensed> if <ase-project-boxing/> is equal
-    `grey` or `black` (the latter reached only under an explicitly given
-    severity floor), and <condensed>false</condensed> otherwise: a
-    *condensed* report suppresses the full unified diffs of STEP 3.
+    `grey` and <getopt-option-force/> is not equal `true`, and
+    <condensed>false</condensed> otherwise: a *condensed* report
+    suppresses the full unified diffs of STEP 3.
 
     First, determine the *effective aspect set* <aspects/>, i.e., the
     code quality aspects which are checked at all. For this, parse
@@ -189,13 +189,13 @@ related to a set of code quality aspects.
 
     <if condition="<getopt-option-severity/> is equal `AUTO`">
     Set <floor>MEDIUM</floor> if <ase-project-boxing/> is equal `grey`
-    (grey boxing surfaces only *material* findings of severity `MEDIUM`
-    and above), and <floor>LOW</floor> otherwise.
+    and <getopt-option-force/> is not equal `true` (grey boxing surfaces
+    only *material* findings of severity `MEDIUM` and above), and
+    <floor>LOW</floor> otherwise.
     </if>
     <else>
     Set <floor><getopt-option-severity/></floor>: an *explicitly* given
-    severity floor always *wins* over the boxing, both over the `grey`
-    floor and over the `black` skip.
+    severity floor always *wins* over the `grey` boxing floor.
     </else>
 
     Then *apply the effective severity floor* <floor/>: *Keep* a problem
@@ -448,9 +448,9 @@ related to a set of code quality aspects.
 
             <if condition="<condensed/> is equal `true`">
 
-            The project source artifacts are classified as a *grey box* (or
-            *black box*), so the user does *not* want the full artifact
-            internals surfaced:
+            The project source artifacts are classified as a *grey box*,
+            so the user does *not* want the full artifact internals
+            surfaced:
             *suppress* the full unified diff and instead show only the
             *condensed* one-line-per-hunk representation. Report the
             solution with the following <template/>:
@@ -578,7 +578,7 @@ related to a set of code quality aspects.
 
         <if condition="<getopt-option-auto/> is not equal `true`">
         <ase-tpl-hint level="verbose">
-        Use `/ase-code-lint --auto` to apply all corrections unattended, `--severity` to raise the reporting floor, `--include`/`--exclude` to narrow the checked aspects, and `--staged`/`--unstaged` to lint only the changed files.
+        Use `/ase-code-lint --auto` to apply all corrections unattended, `--severity` to raise the reporting floor, `--force` to ignore the project boxing, `--include`/`--exclude` to narrow the checked aspects, and `--staged`/`--unstaged` to lint only the changed files.
         </ase-tpl-hint>
         </if>
 

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

@@ -9,6 +9,7 @@
     [`--help`|`-h`]
     [`--auto`|`-a`]
     [`--severity`|`-S`=(`AUTO`|`LOW`|`MEDIUM`|`HIGH`)]
+    [`--force`|`-f`]
     [`--include`|`-i`=*aspect*[`,`...]]
     [`--exclude`|`-e`=*aspect*[`,`...]]
     [`--staged`]
@@ -64,14 +65,20 @@ the code, and comments contradicting the code.
     Set the *severity floor* (default `AUTO`): findings below the chosen
     threshold are silently suppressed, ordered `LOW` < `MEDIUM` <
     `HIGH`. The default `AUTO` means `MEDIUM` for a project with `grey`
-    boxing, no linting at all for a project with `black` boxing, and
-    `LOW` (keep all findings) otherwise; an explicitly given floor always
-    wins over the boxing, i.e. it also lints a project with `black`
-    boxing and, e.g. with `LOW`, acts on all findings of a project with
-    `grey` boxing. `ACCEPTED` findings are never suppressed. Surviving
-    findings are reported in *descending
-    severity* order `HIGH`, `MEDIUM`, `LOW`, `ACCEPTED`, keeping the
-    `file`/`line` order within the same severity.
+    boxing (unless `--force` is given) and `LOW` (keep all findings)
+    otherwise; an explicitly given floor always wins over the `grey`
+    boxing, i.e. e.g. with `LOW`, it acts on all findings of a project
+    with `grey` boxing. `ACCEPTED` findings are never suppressed.
+    Surviving findings are reported in *descending severity* order
+    `HIGH`, `MEDIUM`, `LOW`, `ACCEPTED`, keeping the `file`/`line` order
+    within the same severity.
+
+-   `--force`|`-f`:
+    Ignore the project boxing entirely: lint a project with `black`
+    boxing (which is otherwise not linted at all), and show the full
+    unified diffs and the default `LOW` severity floor for a project
+    with `grey` boxing (which otherwise shows only condensed one-line
+    diffs and defaults to the `MEDIUM` severity floor).
 
 -   `--include`|`-i`=*aspect*[`,`...]:
     Restrict the checked code quality aspects to the given
@@ -132,6 +139,12 @@ Lint a directory, reporting only `MEDIUM` and `HIGH` findings:
 ❯ /ase-code-lint -S MEDIUM src/handlers/
 ```
 
+Lint a directory regardless of the project boxing:
+
+```text
+❯ /ase-code-lint --force src/handlers/
+```
+
 Lint a source file for the formatting and spelling aspects only:
 
 ```text

package/plugin/skills/ase-help-intent/SKILL.md

@@ -72,7 +72,8 @@ catalog you match <intent/> against:
         Match the current <intent/> against the <corpus/> and select
         *every* skill that adequately fits it -- judging the fit
         primarily by each skill's `##  SCENARIOS` ("You want ...") and
-        `##  DESCRIPTION` sections. Order the selected skills from
+        `##  DESCRIPTION` sections, and secondarily by its `##  NAME`
+        and `##  SYNOPSIS` sections. Order the selected skills from
         best-fitting to worst-fitting and keep at most the *8* best
         ones, so the dispatch dialog of sub-step 4 stays addressable.
         Set <count/> to the number of kept skills. Then, for each kept

package/plugin/skills/ase-help-intent/data.md

@@ -633,6 +633,7 @@ Get insights into a specific subsystem:
     [`--help`|`-h`]
     [`--auto`|`-a`]
     [`--severity`|`-S`=(`AUTO`|`LOW`|`MEDIUM`|`HIGH`)]
+    [`--force`|`-f`]
     [`--include`|`-i`=*aspect*[`,`...]]
     [`--exclude`|`-e`=*aspect*[`,`...]]
     [`--staged`]
@@ -688,14 +689,20 @@ the code, and comments contradicting the code.
     Set the *severity floor* (default `AUTO`): findings below the chosen
     threshold are silently suppressed, ordered `LOW` < `MEDIUM` <
     `HIGH`. The default `AUTO` means `MEDIUM` for a project with `grey`
-    boxing, no linting at all for a project with `black` boxing, and
-    `LOW` (keep all findings) otherwise; an explicitly given floor always
-    wins over the boxing, i.e. it also lints a project with `black`
-    boxing and, e.g. with `LOW`, acts on all findings of a project with
-    `grey` boxing. `ACCEPTED` findings are never suppressed. Surviving
-    findings are reported in *descending
-    severity* order `HIGH`, `MEDIUM`, `LOW`, `ACCEPTED`, keeping the
-    `file`/`line` order within the same severity.
+    boxing (unless `--force` is given) and `LOW` (keep all findings)
+    otherwise; an explicitly given floor always wins over the `grey`
+    boxing, i.e. e.g. with `LOW`, it acts on all findings of a project
+    with `grey` boxing. `ACCEPTED` findings are never suppressed.
+    Surviving findings are reported in *descending severity* order
+    `HIGH`, `MEDIUM`, `LOW`, `ACCEPTED`, keeping the `file`/`line` order
+    within the same severity.
+
+-   `--force`|`-f`:
+    Ignore the project boxing entirely: lint a project with `black`
+    boxing (which is otherwise not linted at all), and show the full
+    unified diffs and the default `LOW` severity floor for a project
+    with `grey` boxing (which otherwise shows only condensed one-line
+    diffs and defaults to the `MEDIUM` severity floor).
 
 -   `--include`|`-i`=*aspect*[`,`...]:
     Restrict the checked code quality aspects to the given
@@ -756,6 +763,12 @@ Lint a directory, reporting only `MEDIUM` and `HIGH` findings:
 ❯ /ase-code-lint -S MEDIUM src/handlers/
 ```
 
+Lint a directory regardless of the project boxing:
+
+```text
+❯ /ase-code-lint --force src/handlers/
+```
+
 Lint a source file for the formatting and spelling aspects only:
 
 ```text
@@ -3574,6 +3587,188 @@ Loop over multiple specification edits inside a dedicated Git worktree:
 ❯ /ase-spec-edit -l -w event-series
 ```
 
+</purpose>
+<purpose name="ase-spec-lint">
+
+##  NAME
+
+`ase-spec-lint` - Lint Specification
+
+##  SYNOPSIS
+
+`ase-spec-lint`
+    [`--help`|`-h`]
+    [`--auto`|`-a`]
+    [`--severity`|`-S`=(`AUTO`|`LOW`|`MEDIUM`|`HIGH`)]
+    [`--force`|`-f`]
+    [`--include`|`-i`=*aspect*[`,`...]]
+    [`--exclude`|`-e`=*aspect*[`,`...]]
+    [`--staged`]
+    [`--unstaged`]
+    [*spec-reference*]
+
+##  DESCRIPTION
+
+The `ase-spec-lint` skill lints the *SpecBook*-based specification
+(SPEC) for *potential quality problems* related to a fixed set of
+specification quality aspects: from its syntax and formatting, over
+its individual statements, up to the logical gaps of its model and its
+completeness for an implementation. The investigation is dispatched to
+sub-agents (`ase:ase-spec-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. Every applied correction refreshes the
+`Modified:` timestamp of the changed specification files.
+
+By default all ten specification quality aspects are checked. The
+`--include` and `--exclude` options narrow this to an *effective aspect
+set*: with `--include` only, exactly the listed aspects are checked;
+with `--exclude` only, all aspects except the listed ones; with both,
+the included ones minus the excluded ones. An unknown aspect id, or a
+combination which cancels out to an empty set, aborts the skill with an
+error. The ten aspect ids are:
+
+```text
+S01 SYNTAX      S04 AMBIGUITY     S07 REDUNDANCY    S10 COMPLETENESS
+S02 FORMAT      S05 ATOMICITY     S08 CONSISTENCY
+S03 RATIONALE   S06 REALIZATION   S09 LOGIC
+```
+
+The `S01 SYNTAX` aspect reports the diagnostics of the specification
+linting against the *SpecBook* schema configuration of the project and
+of the generic Markdown linting via *markdownlint* (both as with `ase
+spec lint --markdown`), mapping the severity `error` onto `HIGH` and
+`warning` onto `MEDIUM`. The `S02 FORMAT` aspect checks the formatting
+against the *SpecBook* format variants and the prevailing conventions
+of the specification itself. The aspects `S03 RATIONALE` up to `S07
+REDUNDANCY` check the statements against the *Specifying Tenets* of
+*ASE*: a `, BECAUSE` rationale per statement, unambiguous and
+verifiable statements, atomic statements, intent instead of
+realization, and a single source of truth per fact.
+
+The *model-wide* aspects `S07 REDUNDANCY` up to `S10 COMPLETENESS` are
+judged on the *entire* specification, even if only parts of it are
+linted: `S08 CONSISTENCY` checks for contradictions and drifting
+terminology, `S09 LOGIC` for logical gaps in the specification model
+(like unreachable states or entities without any relationship), and
+`S10 COMPLETENESS` for open ends which would force an implementer to
+guess. As the corrections of `S09 LOGIC` and `S10 COMPLETENESS` fill
+gaps with *best-guess* content, they are proposed for review only and
+are *never* applied under `--auto`.
+
+##  OPTIONS
+
+-   `--auto`|`-a`:
+    Automatically apply every proposed correction without asking the
+    user via the interactive dialog, except for the best-guess
+    corrections of the aspects `S09 LOGIC` and `S10 COMPLETENESS`,
+    which are only reported.
+
+-   `--severity`|`-S`=(`AUTO`|`LOW`|`MEDIUM`|`HIGH`):
+    Set the *severity floor* (default `AUTO`): findings below the chosen
+    threshold are silently suppressed, ordered `LOW` < `MEDIUM` <
+    `HIGH`. The default `AUTO` means `MEDIUM` for a project with `grey`
+    boxing (unless `--force` is given) and `LOW` (keep all findings)
+    otherwise; an explicitly given floor always wins over the `grey`
+    boxing, i.e. e.g. with `LOW`, it acts on all findings of a project
+    with `grey` boxing. `ACCEPTED` findings are never suppressed.
+    Surviving findings are reported in *descending severity* order
+    `HIGH`, `MEDIUM`, `LOW`, `ACCEPTED`, keeping the `file`/`line` order
+    within the same severity.
+
+-   `--force`|`-f`:
+    Ignore the project boxing entirely: lint a project with `black`
+    boxing (which is otherwise not linted at all), and show the full
+    unified diffs and the default `LOW` severity floor for a project
+    with `grey` boxing (which otherwise shows only condensed one-line
+    diffs and defaults to the `MEDIUM` severity floor).
+
+-   `--include`|`-i`=*aspect*[`,`...]:
+    Restrict the checked specification quality aspects to the given
+    comma-separated list of aspect ids (e.g. `S01,S02`). Without this
+    option, all ten aspects are checked.
+
+-   `--exclude`|`-e`=*aspect*[`,`...]:
+    Remove the given comma-separated list of aspect ids from the checked
+    specification quality aspects. Applied *after* `--include`, so
+    `-i S09,S10 -e S10` checks `S09` only.
+
+-   `--staged`:
+    Restrict the linting to the specification files with *staged* Git
+    changes. Deleted files are skipped, and the files are linted in
+    their current working copy state. Combined with `--unstaged`, lint
+    the specification files with *any* uncommitted Git changes.
+
+-   `--unstaged`:
+    Restrict the linting to the specification files with *unstaged* Git
+    changes plus the *untracked* specification files. Deleted files are
+    skipped. Combined with `--staged`, lint the specification files with
+    *any* uncommitted Git changes.
+
+##  ARGUMENTS
+
+-   *spec-reference*:
+    A file, directory, or wildcard reference to the specification files
+    to lint. Without it, the *entire* specification is linted, resp.
+    under `--staged` or `--unstaged` all changed specification files.
+
+##  SCENARIOS
+
+-   You want your specification checked for specification quality problems
+-   You want to know whether your specification is sufficient for an implementation
+-   You want logical gaps in your specification model detected
+-   You want corrections proposed which you accept or reject one by one
+-   You want all mechanical corrections applied automatically
+-   You want only your staged or unstaged specification changes linted before committing
+
+##  EXAMPLES
+
+Lint the entire specification interactively:
+
+```text
+❯ /ase-spec-lint
+```
+
+Lint a single specification file and automatically apply all corrections:
+
+```text
+❯ /ase-spec-lint --auto docs/spec/data-model.md
+```
+
+Lint the specification for its syntax and formatting only:
+
+```text
+❯ /ase-spec-lint -i S01,S02
+```
+
+Check the specification model for logical gaps and completeness only:
+
+```text
+❯ /ase-spec-lint -i S09,S10
+```
+
+Lint the specification, reporting only `MEDIUM` and `HIGH` findings:
+
+```text
+❯ /ase-spec-lint -S MEDIUM
+```
+
+Lint the specification regardless of the project boxing:
+
+```text
+❯ /ase-spec-lint --force
+```
+
+Lint only the specification files with staged Git changes:
+
+```text
+❯ /ase-spec-lint --staged
+```
+
 </purpose>
 <purpose name="ase-sync-export">
 
@@ -4847,6 +5042,7 @@ Switch to a specific task:
     [`--source`|`-s` *source*]
     [`--changeset`|`-c` *changeset*]
     [`--draft`|`-d`]
+    [`--no-cleanup`|`-K`]
     [`--stateless`|`-S`]
     [*id*]
 
@@ -4889,7 +5085,9 @@ overridable via `--changeset`:
 -   `branch:`*name*: the change set is *committed* onto the branch
     *name* -- created from the source if missing -- inside the worktree
     in which this branch is checked out, or inside a newly created
-    worktree `.ase/worktree/<name>`.
+    worktree `.ase/worktree/<name>`, which is removed again after the
+    commit (unless `--no-cleanup` is given), while an already existing
+    worktree is always kept.
 -   `attachment:`*name*: the change set is made and verified in a
     *temporary* worktree, detached at the source commit, and stored as
     the attachment block of type `text/x-diff; charset=utf-8;
@@ -4996,6 +5194,13 @@ plan, unless `--next` pre-selects this choice.
     *implementation draft* of the plan only, leaving all artifacts
     untouched (a dry-run). Mutually exclusive with `--changeset`.
 
+-   `--no-cleanup`|`-K`:
+    For a `branch:` changeset, keep the worktree `.ase/worktree/<name>`
+    newly created by this run, instead of removing it after the commit,
+    so the change set can be reviewed, built, and tested there. Without
+    this option, the worktree is removed only if it has no uncommitted
+    changes, as the change set lives on the branch alone.
+
 -   `--stateless`|`-S`:
     Leave the plan's `Status:` key untouched.
 

package/plugin/skills/ase-help-skill/catalog.md

@@ -23,6 +23,7 @@
 ⎈   **SPECIFICATION**
 ○   `ase-spec-activate`:   Activate Specification Know-How
 ○   `ase-spec-edit`:       Edit Specification
+○   `ase-spec-lint`:       Lint Specification
 
 ⎈   **CODING**
 ○   `ase-code-analyze`:    Analyze Source Code

package/plugin/skills/ase-meta-workflow/workflow.txt

@@ -15,6 +15,7 @@ START               -> ase-arch-discover
 START               -> ase-code-insight
 START               -> ase-code-explain
 START               -> ase-code-lint
+START               -> ase-spec-lint
 START               -> ase-docs-shorten
 START               -> ase-docs-refine
 START               -> ase-docs-proofread
@@ -46,6 +47,7 @@ ase-arch-discover   -> END
 ase-code-insight    -> END
 ase-code-explain    -> END
 ase-code-lint       -> END
+ase-spec-lint       -> END
 ase-docs-shorten    -> END
 ase-docs-refine     -> END
 ase-docs-proofread  -> END

package/plugin/skills/ase-repo-commit/SKILL.md

@@ -71,6 +71,7 @@ currently staged Git changes.
     -   Use imperative mood ("add" not "added")
     -   Use *no* period at the end
     -   Use *no* Markdown formatting
+    -   Never add `Co-Authored-By` trailers to commit messages
 
     Output this crafted commit message with the following <template/>:
 

package/plugin/skills/ase-repo-merge/SKILL.md

@@ -121,6 +121,7 @@ processing the entire current skill:
         imperative-mood summary without a trailing period, without
         Markdown formatting, and without any double-quote (`"`),
         backtick (`` ` ``), dollar (`$`), or backslash (`\`) characters.
+        Never add `Co-Authored-By` trailers to commit messages.
 
     4.  Commit the changes by running the command
         `git -C "<source-dir/>" commit -m "<message/>"`. If it fails,

package/plugin/skills/ase-spec-edit/SKILL.md

@@ -393,9 +393,9 @@ empty <todo-what/> or <todo-how/> renders as `(none)`:
 
         <if condition="<worktree-dir/> is not empty">
         Run the command `ase spec lint` with <worktree-dir/> as its
-        working directory and parse its
-        `<file/>:<line/>:<column/>: <message/>` output lines into
-        <diagnostics/> -- the `ase_specbook_lint` tool always validates
+        working directory and parse its logged
+        `lint: specbook: <file/>:<line/>:<column/>: <message/>` lines
+        (on standard error) into <diagnostics/> -- the `ase_specbook_lint` tool always validates
         the *project* working copy and hence *MUST* *NOT* be used here.
         </if>
         <else>

package/plugin/skills/ase-spec-edit/help.md

@@ -215,5 +215,5 @@ Loop over multiple specification edits inside a dedicated Git worktree:
 
 ##  SEE ALSO
 
-[`ase-spec-activate`](../ase-spec-activate/help.md), [`ase-code-edit`](../ase-code-edit/help.md), [`ase-sync-import`](../ase-sync-import/help.md),
+[`ase-spec-activate`](../ase-spec-activate/help.md), [`ase-spec-lint`](../ase-spec-lint/help.md), [`ase-code-edit`](../ase-code-edit/help.md), [`ase-sync-import`](../ase-sync-import/help.md),
 [`ase-sync-reconcile`](../ase-sync-reconcile/help.md), [`ase-sync-export`](../ase-sync-export/help.md), [`ase-task-grill`](../ase-task-grill/help.md).