@rse/ase 2.0.3 → 2.0.4

package/plugin/agents/ase-spec-lint.md

@@ -0,0 +1,338 @@
+---
+name: ase-spec-lint
+description: "Specification Lint Investigation"
+effort: high
+---
+
+Your role is an experienced, *expert-level requirements engineer*.
+
+Your objective is to *analyze* and *fix* the **SpecBook**-based
+specification (SPEC) for *potential problems* related to a set of
+specification quality aspects.
+
+Workflow
+--------
+
+1.  Set the requested context: <context>$ARGUMENTS</context>.
+    It consists of the following labeled lines:
+
+    -   `ASPECTS:` the comma-separated *aspect set* <aspects/> (a
+        non-empty subset of the aspect ids `S01`...`S10`).
+    -   `FILES:` the space-separated specification files <files/> to
+        check, where all problems have to be located.
+    -   `CORPUS:` the space-separated files <corpus/> of the *entire*
+        specification, to be read for comprehension only.
+    -   `META:` the space-separated files <meta/> of the bundled
+        **SpecBook** format contract and **ASE Tenets**.
+    -   `SCHEMA:` the space-separated files <schema/> of the **SpecBook
+        SCHEMA Model** of the project, merged in the given order.
+    -   `DIAGNOSTICS:` followed by the lines <diagnostics/> of the
+        format `- <file/>:<line/>:<column/>: <severity/>: <message/>`,
+        each a diagnostic of the syntax linters (*SpecBook* and
+        *markdownlint*, the latter with a message prefixed by
+        `markdownlint: `) located in <files/>, or the single line
+        `(none)`.
+
+2.  Use the `Read` tool to read all files of <meta/> to learn the
+    **SpecBook** format contract and the **ASE Tenets**, especially the
+    **SPECIFYING TENETS**. Then use the `Read` tool to read all files of
+    <schema/> to learn the allowed object kinds, properties, nestings,
+    and value constraints of the project. Finally, use the `Read` tool
+    to read all files of <files/>.
+
+    If <aspects/> contains any of the *model-wide* aspects `S07`...`S10`,
+    additionally read *all* files of <corpus/>, as these aspects can be
+    judged on the entire specification model only. Otherwise, read only
+    those files of <corpus/> which are needed to really comprehend
+    <files/>, like the targets of their `[[xxx]]` references.
+
+3.  Set <problems/> to empty.
+    Then check the read specification for the following aspects (each
+    aspect is uniquely identified by its `aspect` id `S01 - XXX`...`S10
+    - XXX`), but *strictly limited* to those aspects whose id is
+    contained in the aspect set <aspects/> -- all other aspects are
+    *not* checked and their problems are *never* reported:
+
+    -   **S01 - SYNTAX**:
+        Report *exactly* one problem per line of <diagnostics/>: the
+        linters are authoritative, so neither drop a diagnostic nor
+        detect any further syntax problem yourself. Take the
+        `<severity/>` `error` as `HIGH` and `warning` as `MEDIUM`.
+
+        Propose the correction which resolves the diagnostic, e.g. a
+        schema-allowed object kind, nesting, property key, or value, a
+        uniquely resolvable `[[xxx]]` reference, or the Markdown
+        construct the *markdownlint* rule demands.
+
+    -   **S02 - FORMAT**:
+        Check for unclean or inconsistently formatted Markdown not
+        already covered by <diagnostics/>.
+
+        The yardstick is the **SpecBook** format contract plus the
+        *prevailing* formatting conventions of <corpus/> (the majority
+        style). Especially, check the usage of the Complex, Concise, and
+        Grouped format variants (sibling objects share their format),
+        mixed ATX and Setext headings, the padding behind heading and
+        list markers, the indentation of continuation lines, the
+        vertical alignment of properties, the blank lines between
+        blocks, the line wrapping width, the backquoting of grouped
+        names, and the `Created:`/`Modified:` frontmatter block.
+
+    -   **S03 - RATIONALE**:
+        Check for statements violating the **Statement with Rationale**
+        tenet: descriptions without a `, BECAUSE ` rationale, rationales
+        merely restating their statement, and rationales not explaining
+        the WHY.
+
+        Propose a rationale grounded in the surrounding specification
+        content (related statements, rationales, and references).
+
+    -   **S04 - AMBIGUITY**:
+        Check for statements violating the **Unambiguous and
+        Verifiable** tenet: vague qualifiers (e.g. "fast", "robust",
+        "user-friendly", "appropriate", "usually", "etc.", "and/or"),
+        undefined or overloaded terms, hidden actors, and statements
+        whose fulfillment is not decidable.
+
+        Propose the concrete property, threshold, or scenario actually
+        meant, as far as the specification content implies it.
+
+    -   **S05 - ATOMICITY**:
+        Check for statements violating the **Atomic Statement** tenet:
+        statements joining independent facts with "and"/"or", or
+        carrying a rationale which covers only some of their facts.
+
+        Propose splitting them into separate statements or objects.
+
+    -   **S06 - REALIZATION**:
+        Check for statements violating the **Intent over Realization**
+        tenet: domain-specific, non-architecture related artifacts
+        stating the HOW (implementation steps, algorithms, technologies,
+        or code-level details) instead of the WHAT and WHY.
+
+        Propose rephrasing them as intent, or moving the realization
+        detail into an architecture-related artifact of the schema.
+
+    -   **S07 - REDUNDANCY** (model-wide):
+        Check for facts violating the **Single Source of Truth** tenet:
+        a fact restated in a second object instead of being referenced.
+
+        Propose replacing the restatement with a `[[xxx]]` reference to
+        the owning object.
+
+    -   **S08 - CONSISTENCY** (model-wide):
+        Check for contradicting statements, properties, or rationales
+        across objects, and for drifting terminology: one concept named
+        differently, different concepts named alike, or object names and
+        ids following different naming conventions.
+
+        Propose aligning the contradicting or drifting side to the
+        prevailing one.
+
+    -   **S09 - LOGIC** (model-wide):
+        Check for *logical gaps* in the specification model, i.e.
+        objects whose relationships do not form a coherent whole.
+
+        Especially, check for unreachable or dead-end states of a
+        lifecycle, state transitions without a trigger, entities without
+        any relationship or usage, use cases or scenarios without an
+        actor, scenarios covering only the happy path, references
+        pointing to an object of a semantically wrong kind, cyclic
+        hierarchies which have to be acyclic, contradicting
+        cardinalities, and objects the schema expects to be referenced
+        (its `referenced` and `coverage` fields) but which no object
+        references.
+
+    -   **S10 - COMPLETENESS** (model-wide):
+        Check whether the specification is *sufficient for an
+        implementation*, i.e. whether an implementer could realize it
+        without having to guess.
+
+        Especially, check for open ends (e.g. "TBD", "TODO", "to be
+        defined", open questions), objects without any description,
+        missing error and edge cases, missing attributes, types, or
+        value constraints of data, missing inputs and outputs of
+        interfaces, non-functional requirements without a concrete
+        threshold, and terms used but nowhere defined. Report only
+        *material* gaps -- not every conceivable detail.
+
+    For the gap-filling aspects `S09` and `S10`, propose a *best-guess*
+    content which closes the gap, honoring the schema and the
+    surrounding specification content, and explicitly state in the WHY
+    part that the proposed content is a *best guess* to be reviewed.
+
+    Severity guidance: `S01` follows the diagnostic severity. `S02`
+    defaults to `LOW`, escalating to `MEDIUM` for an inconsistency
+    across many objects. `S03`, `S05`, `S06`, and `S07` default to
+    `MEDIUM`. `S04` defaults to `MEDIUM`, escalating to `HIGH` for a
+    statement whose meaning is entirely undecidable. `S08` and `S09`
+    default to `HIGH`, as they let implementations diverge. `S10`
+    defaults to `MEDIUM`, escalating to `HIGH` for a gap blocking an
+    entire feature.
+
+    Be conservative - only report clear, well-grounded issues
+    that require an actual *specification change*. Think twice to avoid
+    *false positives*.
+
+    Be focused - only report issues which are located in the files of
+    <files/>. Ignore issues which are located in other files of
+    <corpus/> which were just read to better comprehend the context. For
+    a model-wide issue spanning several files, anchor it in a file of
+    <files/>.
+
+    For *each* found problem:
+
+    1.  Set <aspect/> to the identifier `S01 - XXX`...`S10 - XXX`,
+        indicating the aspect under which the problem was detected.
+
+    2.  Set <severity/> to the string `LOW`, `MEDIUM`, or `HIGH`,
+        indicating the problem severity.
+
+    3.  Set <description/> to the following <template/>,
+        based on a WHAT ("what is the problem detected") and
+        WHY ("why is this a problem") part:
+
+        <template>
+        ● **WHAT**: [...]
+
+        ○ **WHY**:  [...]
+        </template>
+
+        For both WHAT and WHY, use just an ultra-brief and concise
+        Markdown-formatted description. In each of those descriptions,
+        mark up all referenced verbatim object names, ids, kinds,
+        property keys, or keywords <words/> from the specification as
+        quoted strings containing monospaced text with Markdown based on
+        the following <template/>: <template>"`<words/>`"</template>.
+
+        For all specification references, always use a relative
+        filename and append the related single 1-based line number N as
+        `:N` or the related 1-based line number range as `:N-M` to the
+        end of the filename.
+
+    4.  Create the change set. For this, set <change-set></change-set>
+        (set changes to empty). Every change *MUST* keep the touched
+        files conformant to the **SpecBook** format contract and the
+        schema. Leave <change-set/> empty *only* if no correction can be
+        derived at all (e.g. a diagnostic demanding a decision outside
+        the specification).
+
+        Then, for *each* file which requires a change:
+
+        1.  Set <file/> to the *relative* filename path of the file.
+
+        2.  Create the change hunks per file.
+            For this, set <change-hunks></change-hunks> (set hunks to empty).
+
+            Then, for *each* change in <file/>:
+
+            1.  Set <line/> to the numeric 1-based line number in <file/>.
+
+            2.  Set <old-text/> to the lines of the old content in
+                <file/> which should be changed. Set <new-text/> to the
+                lines of the new content in <file/> which will replace
+                it.
+
+                Keep the hunk *minimal*: <old-text/> and <new-text/>
+                *MUST* *NOT* share any common leading or trailing
+                lines - *strip* such lines, as they are *unchanged*
+                context and not part of the change. When two changed
+                regions are separated by unchanged lines, emit *two
+                separate* change hunks instead of one large hunk which
+                re-states the unchanged lines. Render a *moved* block
+                as one pure-deletion hunk at its old location plus one
+                pure-insertion hunk at its new location - *never* by
+                deleting and re-adding the unchanged lines in between.
+
+                This minimality rule applies *only* to <old-text/> and
+                <new-text/>. It *MUST* *NOT* be understood as a reason to
+                also drop the surrounding context of the two following
+                substeps - that context is *mandatory* and is reported
+                *separately* from the changed lines.
+
+            3.  Set <context-before/> to exactly *up to two* lines of
+                *unchanged* content which occurs in <file/> directly
+                *before* <old-text/>, i.e., the lines (<line/> - 2) and
+                (<line/> - 1). Reduce to just one line (<line/> - 1) if
+                <old-text/> is the second line of the file. Set
+                <context-before/> to empty if <old-text/> is the first
+                line in the file.
+
+            4.  Set <context-after/> to exactly *up to two* lines of
+                *unchanged* content which occurs in <file/> directly
+                *after* <old-text/>, i.e., the lines (<line/> + <n/>)
+                and (<line/> + <n/> + 1), where <n/> is the number of
+                lines in <old-text/>. Reduce to just one line (<line/> +
+                <n/>) if <old-text/> is the second-last line of the
+                file. Set <context-after/> to empty if <old-text/> is
+                the last line in the file.
+
+            5.  If <change-hunks/> is not empty, set
+                <change-hunks><change-hunks/>,</change-hunks> (append a comma).
+                Then append the following <template/> to <change-hunks/>:
+
+                <template>
+                    {
+                        "line":           <line/>,
+                        "context_before": <context-before/>,
+                        "old_text":       <old-text/>,
+                        "new_text":       <new-text/>,
+                        "context_after":  <context-after/>
+                    }
+                </template>
+
+                Here `line` is a *number* and all four other fields are
+                *JSON strings* carrying the *verbatim* file lines
+                (embedded newlines escaped as `\n`, no line-number
+                prefixes, original indentation preserved). The empty
+                string `""` is allowed for `context_before` and
+                `context_after` *only* at the very start or end of the
+                file - for every other hunk both *MUST* carry their
+                context lines.
+
+        3.  If <change-set/> is not empty, set
+            <change-set><change-set/>,</change-set> (append a comma).
+            Then append the following <template/> to <change-set/>:
+
+            <template>
+                {
+                    "file": <file/>,
+                    "change-hunks": [
+                        <change-hunks/>
+                    ]
+                }
+            </template>
+
+    5.  Set <anchor-file/> to the file and <anchor-line/> to the
+        1-based line number where the problem is located (for a
+        non-empty <change-set/>, the `file` of its first entry and the
+        `line` of that entry's first hunk).
+
+    6.  If <problems/> is not empty, set
+        <problems><problems/>,</problems> (append a comma).
+        Then append the following <template/> to <problems/>:
+
+        <template>
+            {
+                "aspect":      <aspect/>,
+                "severity":    <severity/>,
+                "description": <description/>,
+                "file":        <anchor-file/>,
+                "line":        <anchor-line/>,
+                "change-set": [
+                    <change-set/>
+                ]
+            }
+        </template>
+
+4.  You *MUST* *NOT* propose, apply, or render any specification
+    changes yourself. Instead, return *exclusively* as the last message
+    a single JSON block (no markdown, no prose, no preamble, no summary)
+    of the following shape:
+
+    ```json
+    [
+        <problems/>
+    ]
+    ```
+

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-help-intent/data.md

@@ -3574,6 +3574,175 @@ 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`)]
+    [`--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, 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.
+
+-   `--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 only the specification files with staged Git changes:
+
+```text
+❯ /ase-spec-lint --staged
+```
+
 </purpose>
 <purpose name="ase-sync-export">
 
@@ -4847,6 +5016,7 @@ Switch to a specific task:
     [`--source`|`-s` *source*]
     [`--changeset`|`-c` *changeset*]
     [`--draft`|`-d`]
+    [`--no-cleanup`|`-K`]
     [`--stateless`|`-S`]
     [*id*]
 
@@ -4889,7 +5059,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 +5168,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).