@rse/ase 2.0.6 → 2.0.7

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

@@ -321,7 +321,7 @@ Analyze only the unstaged and untracked source files below a directory:
     [`--grill-until`|`-u` `MUST`|`SHOULD`|`MAY`]
     [`--grill-perspective`|`-p` *perspective*]
     [`--grill-ground`|`-G`]
-    [`--verify`|`-v`]
+    [`--verify`|`-v` `light`|`none`|`full`]
     [`--worktree`|`-w` *name*[`:`*branch*]]
     [`--loop`|`-l`]
     [*query*]
@@ -341,7 +341,8 @@ parts), *discovering* (read the source artifacts related to the query),
 *grilling* (optionally stress-test the query with rounds of questions),
 *implementing* (optionally select an approach, then apply the change
 set in place, honoring the tenet set selected via `--mode`), and
-*verifying* (optionally verify the implementation until it passes). The
+*verifying* (verify the implementation until it passes, unless
+disabled via `--verify none`). The
 *querying* state, every *grilling* round, and the approach selection
 close with an `EDIT TODO` box showing the established `WHAT` and `HOW`
 information.
@@ -376,8 +377,9 @@ information.
     of a round are sorted by descending focus area importance
     (`DOMAIN`, `INTERFACE`, `ARCHITECTURE`, `IMPLEMENTATION`,
     `REGRESSION`, `CONFIRMATION`). Questions of focus area
-    `REGRESSION` and `CONFIRMATION` are raised only together with
-    `--verify`, as only then a verification honors their decisions.
+    `REGRESSION` are raised only under `--verify light` or `full`, and
+    those of focus area `CONFIRMATION` only under `--verify full`, as
+    only then a verification honors their decisions.
     All questions of a round are announced together below a
     `GRILLING ROUND K/L` line (the round numbering is omitted when only
     a single round is performed) as a `QUESTION`/`ANSWERS` table with
@@ -437,12 +439,17 @@ information.
     no usable facts are found, a warning is shown and the grilling falls
     back to model knowledge. Only effective together with `--grill`.
 
--   `--verify`|`-v`:
-    Verify whether the implementation fulfills the requirements, by
-    running the available verification commands (build, tests, linter,
-    type-checker) and adjusting the failing parts of the change set
-    until the verification passes. Without `--verify`, strictly no
-    verification is performed at all.
+-   `--verify`|`-v` `light`|`none`|`full`:
+    Verify whether the implementation fulfills the requirements, and
+    adjust the failing parts of the change set until the verification
+    passes, for at most ten rounds, listing any failures remaining after
+    the last round as `REMAINING FAILURES`. The default `light` runs the
+    available lint and build commands (including the type-checker) and
+    the already existing regression test suite, if any. The level `full`
+    additionally performs individual, change-specific manual tests
+    through ad-hoc scratch tests and program runs, which are cleaned up
+    afterwards. The level `none` strictly performs no verification at
+    all.
 
 -   `--worktree`|`-w` *name*[`:`*branch*]:
     Apply the change sets inside the dedicated Git worktree
@@ -483,16 +490,22 @@ information.
 
 ##  EXAMPLES
 
-Edit in one shot, without any questions or verification:
+Edit in one shot, without any questions, but with light verification:
 
 ```text
 ❯ /ase-code-edit add a --verbose option to the CLI
 ```
 
-Grill the query with two rounds first, then implement and verify:
+Edit in one shot, without any questions or verification:
 
 ```text
-❯ /ase-code-edit -g -r 2 -v refactor the config loading into layers
+❯ /ase-code-edit -v none add a --verbose option to the CLI
+```
+
+Grill the query with two rounds first, then implement and fully verify:
+
+```text
+❯ /ase-code-edit -g -r 2 -v full refactor the config loading into layers
 ```
 
 Let the user pick one of several resolution approaches first, then
@@ -2618,7 +2631,7 @@ The `ase-repo-changelog` skill helps to *complete*, *consolidate*, and
 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>`
+Each entry starts with `<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`, `code`, `docs`,
@@ -2626,6 +2639,10 @@ comma-separated *artifact class* tags out of `spec`, `code`, `docs`,
 prefix. The date in the section header is also updated to the current
 date.
 
+The layout of the entries follows the style of the existing entries
+of the file (e.g. a single line, a title line plus an explaining body,
+or a wrapped sentence), and each entry is kept within about 5 lines.
+
 ##  SCENARIOS
 
 -   You want the `CHANGELOG.md` brought up to date with recent commits
@@ -3295,6 +3312,123 @@ Review the last commit:
 ❯ /ase-repo-review -c HEAD
 ```
 
+</purpose>
+<purpose name="ase-repo-stage">
+
+##  NAME
+
+`ase-repo-stage` - Stage a Part of the Changes
+
+##  SYNOPSIS
+
+`ase-repo-stage`
+    [`--help`|`-h`]
+    [`--entry`|`-e`]
+    [`--turn`|`-t`]
+    [`--session`|`-s`]
+    [`--merge`|`-m`]
+    [`--no-verify`|`-V`]
+    [`--worktree`|`-w`]
+    [`--changelog`|`-c`]
+    [`--commit`|`-C`]
+    [*topic*]
+
+##  DESCRIPTION
+
+The `ase-repo-stage` skill stages only the *part* of the current Git working copy changes which
+belongs to a *selection*, so a mixed change set can be committed in cohesive portions without
+hand-crafted partial patches.
+
+The selection is either a free-text *topic*, the *last* `CHANGELOG.md` entry (`--entry`), the
+changes of the *last turn* (`--turn`), or all changes of the current *session* (`--session`).
+Without an option, the selection is inferred from the *topic* text, so `stage the last turn`
+works, too. An explicitly given option overrides the inference, and a remaining *topic* narrows
+the entry, turn, and session selections.
+
+The changes are picked at the granularity of individual *lines*: hunks which belong to the
+selection only partially are *split*, and untracked files are selectable, even partially.
+Mutually dependent changes, like a use and its import, are kept together. Unless `--merge` is
+given, the selection *replaces* the current index content. Only the Git index is changed, never
+the content of a working copy file.
+
+After staging, the skill checks that the *staged state alone builds*, with the build command
+auto-detected from the project. By default, the remaining unstaged changes are temporarily
+stashed for this, or -- under `--worktree` -- the staged state is built in a temporary worktree.
+A failed build keeps the staged selection and is reported with its essential error lines.
+
+Finally, the skill optionally chains into the ChangeLog updating and the commit message
+crafting, both for the staged selection.
+
+##  OPTIONS
+
+-   `--entry`|`-e`:
+    Select the changes which realize the *last* `CHANGELOG.md` entry, i.e. the entry added or
+    modified by the uncommitted change of `CHANGELOG.md`, plus the entry itself.
+
+-   `--turn`|`-t`:
+    Select the changes made by the agent in the *last turn* before the skill invocation.
+
+-   `--session`|`-s`:
+    Select all changes made by the agent in the current *session*.
+
+-   `--merge`|`-m`:
+    Stage the selection *on top* of the already staged changes, instead of replacing them.
+
+-   `--no-verify`|`-V`:
+    Skip the check that the staged state builds on its own.
+
+-   `--worktree`|`-w`:
+    Check the build in a *temporary Git worktree* holding only the staged state, instead of
+    temporarily stashing the unstaged changes of the working copy.
+
+-   `--changelog`|`-c`:
+    Afterwards, update the `CHANGELOG.md` entries via `ase-repo-changelog` and stage exactly the
+    entries it added or updated.
+
+-   `--commit`|`-C`:
+    Afterwards, craft the commit message of the staged selection via `ase-repo-commit`.
+
+The options `--entry`, `--turn`, and `--session` are mutually exclusive.
+
+##  ARGUMENTS
+
+-   *topic*:
+    A free-text description of the changes to stage, or -- without an option -- a reference
+    like `last turn` or `last changelog entry` the selection is inferred from.
+
+##  SCENARIOS
+
+-   You want only the hunks related to a certain topic staged
+-   You want only the changes of the last turn or of the session staged
+-   You want the changes behind a `CHANGELOG.md` entry staged and committed
+-   You want to be sure the staged part builds without the rest of the changes
+
+##  EXAMPLES
+
+Stage only the hunks related to a topic:
+
+```text
+❯ /ase-repo-stage the getopt negation handling
+```
+
+Stage the changes of the last turn, checking the build in a temporary worktree:
+
+```text
+❯ /ase-repo-stage --turn --worktree
+```
+
+Stage the changes of the last ChangeLog entry and craft its commit message:
+
+```text
+❯ /ase-repo-stage --entry --commit
+```
+
+Add the session changes related to a topic to the already staged ones:
+
+```text
+❯ /ase-repo-stage --session --merge task board
+```
+
 </purpose>
 <purpose name="ase-spec-activate">
 
@@ -3387,7 +3521,7 @@ Activate and directly answer a question about the specification:
     [`--grill-until`|`-u` `MUST`|`SHOULD`|`MAY`]
     [`--grill-perspective`|`-p` *perspective*]
     [`--grill-ground`|`-G`]
-    [`--verify`|`-v`]
+    [`--verify`|`-v` `light`|`none`|`full`]
     [`--worktree`|`-w` *name*[`:`*branch*]]
     [`--loop`|`-l`]
     [*query*]
@@ -3411,8 +3545,8 @@ project, and read the specification artifacts related to the query),
 *grilling* (optionally stress-test the query with rounds of questions),
 *implementing* (optionally select an approach, then apply the change set
 in place, honoring the GENERIC and SPECIFYING tenets and the `SPEC`
-format contract), and *verifying* (optionally validate the specification
-until it passes). The *querying* state, every *grilling* round, and the
+format contract), and *verifying* (validate the specification until it
+passes, unless disabled via `--verify none`). The *querying* state, every *grilling* round, and the
 approach selection close with an `EDIT TODO` box showing the established
 `WHAT` and `HOW` information.
 
@@ -3448,8 +3582,9 @@ timestamp refreshed.
     of a round are sorted by descending focus area importance
     (`DOMAIN`, `INTERFACE`, `ARCHITECTURE`, `IMPLEMENTATION`,
     `REGRESSION`, `CONFIRMATION`). Questions of focus area
-    `REGRESSION` and `CONFIRMATION` are raised only together with
-    `--verify`, as only then a verification honors their decisions.
+    `REGRESSION` are raised only under `--verify light` or `full`, and
+    those of focus area `CONFIRMATION` only under `--verify full`, as
+    only then a verification honors their decisions.
     All questions of a round are announced together below a `GRILLING ROUND K/L` line (the round numbering is
     omitted when only a single round is performed) as a
     `QUESTION`/`ANSWERS` table with one row per question, each row
@@ -3508,12 +3643,13 @@ timestamp refreshed.
     no usable facts are found, a warning is shown and the grilling falls
     back to model knowledge. Only effective together with `--grill`.
 
--   `--verify`|`-v`:
+-   `--verify`|`-v` `light`|`none`|`full`:
     Verify the edited specification by validating it via *SpecBook*
     linting and fixing the reported diagnostics in the affected `SPEC`
-    artifacts, for at most three rounds. Any diagnostics remaining after
-    the last round are listed as `REMAINING DIAGNOSTICS`. Without
-    `--verify`, strictly no validation is performed at all.
+    artifacts, for at most ten rounds. Any diagnostics remaining after
+    the last round are listed as `REMAINING DIAGNOSTICS`. The default
+    `light` and the level `full` perform the same validation. The level
+    `none` strictly performs no validation at all.
 
 -   `--worktree`|`-w` *name*[`:`*branch*]:
     Apply the change sets inside the dedicated Git worktree
@@ -3525,8 +3661,8 @@ timestamp refreshed.
     single worktree serves the whole skill run: it is prepared before
     the first discovery, so discovering, grilling, and implementing all
     operate on it, all `--loop` iterations land in it, and it is left
-    uncommitted for review. Under
-    `--verify`, the validation then runs as the `ase spec lint` command
+    uncommitted for review. Unless
+    `--verify none` is given, the validation then runs as the `ase spec lint` command
     inside the worktree. If *name* is a bare lower-case word naming no
     existing worktree and a *query* follows (like `-w fix the crash`, a
     former boolean `-w` usage), the skill asks whether *name* is the
@@ -3555,16 +3691,22 @@ timestamp refreshed.
 
 ##  EXAMPLES
 
-Edit in one shot, without any questions or validation:
+Edit in one shot, without any questions, but with validation:
 
 ```text
 ❯ /ase-spec-edit add a Reviewer persona to the persona model
 ```
 
-Grill the query with two rounds first, then edit and validate:
+Edit in one shot, without any questions or validation:
+
+```text
+❯ /ase-spec-edit -v none add a Reviewer persona to the persona model
+```
+
+Grill the query with two rounds first, then edit and fully validate:
 
 ```text
-❯ /ase-spec-edit -g -r 2 -v split the Event entity into Event and EventSeries
+❯ /ase-spec-edit -g -r 2 -v full split the Event entity into Event and EventSeries
 ```
 
 Let the user pick one of several specification approaches first, then

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

@@ -47,6 +47,7 @@
 ○   `ase-repo-diff`:       Summarize Diff
 ○   `ase-repo-review`:     Review Changes
 ○   `ase-repo-dissect`:    Dissect a Change Set
+○   `ase-repo-stage`:      Stage a Part of the Changes
 ○   `ase-repo-merge`:      Merge a Branch
 ○   `ase-repo-resolve`:    Resolve Merge Conflicts
 

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

@@ -28,6 +28,7 @@ START               -> ase-meta-proximity
 START               -> ase-meta-mint
 START               -> ase-meta-workflow
 START               -> ase-repo-dissect
+START               -> ase-repo-stage
 START               -> ase-repo-merge
 START               -> ase-repo-resolve
 ase-help-skill      -> END
@@ -60,6 +61,7 @@ ase-meta-proximity  -> END
 ase-meta-mint       -> END
 ase-meta-workflow   -> END
 ase-repo-dissect    -> END
+ase-repo-stage      -> END
 ase-repo-merge      -> END
 ase-repo-resolve    -> END
 START               -> SKETCH

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

@@ -2,7 +2,9 @@
 name: ase-repo-changelog
 argument-hint: "[--help|-h]"
 description: >
-    Update ChangeLog entries in CHANGELOG.md files
+    Update ChangeLog entries in CHANGELOG.md files. Use when the user wants to
+    "add a changelog entry", or to "update", "complete", or "consolidate" the
+    "changelog", "ChangeLog", or "CHANGELOG.md", e.g. before committing or releasing.
 user-invocable: true
 disable-model-invocation: false
 model: sonnet
@@ -41,7 +43,7 @@ Format
 The *ChangeLog* file is a Markdown formatted file named `CHANGELOG.md`,
 and contains sections with headers in the style `N.M.K (YYYY-MM-DD)`.
 
-Each *ChangeLog* entry is always formatted as...
+Each *ChangeLog* entry always starts with a line formatted as...
 
     `<change-type/> [<artifact-kind/>]: <summary/>`
 
@@ -66,9 +68,19 @@ multiple artifact kinds apply, comma-separate them
     -   `infr`:  infrastructure/build/tooling artifacts
     -   `othr`:  any other artifacts
 
-The <summary/> is not longer than about 60-80 characters. The
-*ChangeLog* entries for a single product release version are also always
-grouped and sorted according to the above <change-type/> list.
+The *layout* of the entries *MUST* follow the *style* of the existing
+entries of the *ChangeLog* file, especially its list item marker and
+indentation, its blank lines between entries, its line width, and its
+entry shape, e.g. a single-line <summary/>, a short <summary/> title
+line followed by an indented body of explaining sentences, or a
+<summary/> sentence wrapped over multiple indented lines. Only if the
+file contains no entries yet, use a single-line <summary/> of about
+60-80 characters.
+
+Each entry, including all its title and body lines, *MUST* be kept
+within about *5 lines* in total. The *ChangeLog* entries for a single
+product release version are also always grouped and sorted according
+to the above <change-type/> list.
 
 Processing
 ----------
@@ -144,8 +156,9 @@ Processing
     the entries in the first (most recent) section only, by adding the
     corresponding (most recent) Git *commits* and *staged* changes only.
 
-    For each Git commit, reduce the Git commit messages to a single
-    short <summary/> sentence, not longer than 60-80 characters.
+    For each Git commit, reduce the Git commit messages to an entry in
+    the *style* of the existing entries, kept within about *5 lines*
+    (see section *Format* above).
 
     For each entry, also determine the <artifact-kind/> *artifact kind*
     tag(s) from the paths of the changed files. To classify a changed
@@ -178,7 +191,8 @@ Processing
     Without immediately modifying the `CHANGELOG.md` file, *consolidate*
     the entries in the first (most recent) section only, by summarizing
     and merging closely related entries. Perform the entry consolidation
-    per <change-type/> group only.
+    per <change-type/> group only. Also condense any entry of this
+    section, which exceeds about *5 lines*, by compressing its wording.
 
     Without immediately modifying the `CHANGELOG.md` file, *sort* the
     entries in the first (most recent) section only. Instead of the
@@ -200,8 +214,13 @@ Processing
     `YYYY-MM-DD` in the `N.M.K (YYYY-MM-DD)` header of the *first* (most
     recent) section.
 
-    You *MUST* *NOT* output any further summary or give any further
-    explanations.
+    For this, you *MUST* use the `Edit` tool, replacing just the *first*
+    (most recent) section, instead of re-writing the entire file with
+    the `Write` tool, so that the resulting changes are shown to the
+    user as a diff by the agent tool itself.
+
+    You *MUST* *NOT* output the resulting entries a second time, any
+    further summary, or any further explanations.
 
     </step>
 

package/plugin/skills/ase-repo-changelog/help.md

@@ -15,7 +15,7 @@ The `ase-repo-changelog` skill helps to *complete*, *consolidate*, and
 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>`
+Each entry starts with `<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`, `code`, `docs`,
@@ -23,6 +23,10 @@ comma-separated *artifact class* tags out of `spec`, `code`, `docs`,
 prefix. The date in the section header is also updated to the current
 date.
 
+The layout of the entries follows the style of the existing entries
+of the file (e.g. a single line, a title line plus an explaining body,
+or a wrapped sentence), and each entry is kept within about 5 lines.
+
 ##  SCENARIOS
 
 -   You want the `CHANGELOG.md` brought up to date with recent commits

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

@@ -2,7 +2,10 @@
 name: ase-repo-commit
 argument-hint: "[--help|-h]"
 description: >
-    Determine commit message for staged Git changes.
+    Determine commit message for staged Git changes. Use when the user
+    asks to "give", "write", "craft", "suggest", or "propose" a "commit
+    message", or wants to know how to "describe" or "phrase" the staged
+    changes for a commit.
 user-invocable: true
 disable-model-invocation: false
 effort: medium

package/plugin/skills/ase-repo-dissect/help.md

@@ -123,4 +123,5 @@ Dissect the changes along an explicitly given axis:
 ##  SEE ALSO
 
 [`ase-task-dissect`](../ase-task-dissect/help.md), [`ase-repo-diff`](../ase-repo-diff/help.md), [`ase-repo-review`](../ase-repo-review/help.md),
-[`ase-repo-changelog`](../ase-repo-changelog/help.md), [`ase-repo-commit`](../ase-repo-commit/help.md).
+[`ase-repo-changelog`](../ase-repo-changelog/help.md), [`ase-repo-commit`](../ase-repo-commit/help.md),
+[`ase-repo-stage`](../ase-repo-stage/help.md).