@rse/ase 2.0.6 → 2.0.8

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

@@ -14,7 +14,7 @@
     [`--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*]
@@ -34,7 +34,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.
@@ -69,8 +70,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
@@ -130,12 +132,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
@@ -176,16 +183,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 -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 refactor the config loading into layers
+❯ /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

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

@@ -10,6 +10,7 @@ effort: high
 allowed-tools:
     - "Bash(git rev-parse *)"
     - "Bash(git -C *)"
+    - "Bash(find *)"
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
@@ -123,8 +124,9 @@ related to a set of code quality aspects.
     `<repo-root/>/`. If `<getopt-arguments/>` is not empty, keep only
     those files which lie within the source code referenced by it,
     expanding any directory or wildcard references with the `Glob`
-    tool. Set <sources/> to the resulting list of individual source
-    code files, preserving order.
+    tool (or, if the `Glob` tool is not available, with the `find`
+    command via the `Bash` tool). Set <sources/> to the resulting list
+    of individual source code files, preserving order.
 
     If <sources/> is empty, only output the following <template/>
     and then *SKIP* the rest of this STEP 1 and the remaining steps
@@ -139,7 +141,9 @@ related to a set of code quality aspects.
 
     For this, first *silently* resolve `<getopt-arguments/>` to the
     list <sources/> of individual source code files, expanding any
-    directory or wildcard references with the `Glob` tool.
+    directory or wildcard references with the `Glob` tool (or, if the
+    `Glob` tool is not available, with the `find` command via the
+    `Bash` tool).
 
     If <sources/> is empty (no *source-reference* given or none of it
     resolvable), only output the following <template/> and then *STOP*

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
@@ -4453,6 +4595,9 @@ Dissect a specific task plan with a hint:
     [`--mode`|`-m` `auto`|`craft`|`refactor`|`resolve`|`specify`]
     [`--approach`|`-a`]
     [`--unverified`|`-u`]
+    [`--focus`|`-f` *section*[,...]]
+    [`--quiet`|`-q`]
+    [`--interactive`|`-i`]
     [`--next`|`-n` *option*[,...]]
     [*id* | *id*: *instruction* | *instruction* | *issue-id*]
 
@@ -4537,6 +4682,51 @@ stale draft.
     build, tests, linter, type-checker, or program execution) once
     the source files have been modified.
 
+-   `--focus`|`-f` *section*[,...]:
+    Edit and show only the given plan *section*(s). Each *section* is
+    one of `SPECIFICATION` (also `SPEC` or `WHAT`), `DESIGN` (also `DES`
+    or `HOW`), or `VERIFICATION` (also `VERIFY`, `VER`, or `WHEN`),
+    matched case-sensitively, or the sentinel `all` (default). The shown
+    plan consists only of these sections, including their headings, but
+    without the frontmatter and the title.
+
+    The rest of the plan stays the context, and an *instruction* requiring a
+    change outside of the focus is applied nevertheless and reported by
+    a warning. A new plan gets all section headings, but only the focused
+    sections are populated, and `OVERWRITE` re-generates only them. An
+    unknown, empty, or duplicate *section* token aborts the skill. It is
+    forwarded on a hand-off to `ase-task-grill`, but not on a hand-off
+    to another skill.
+
+-   `--quiet`|`-q`:
+    Do not print the resulting plan at the end of a planning round. The
+    status lines, the dialogs, and the warning on a stale implementation
+    draft stay. It is forwarded on a hand-off to `ase-task-grill`, but
+    not on a hand-off to another skill.
+
+-   `--interactive`|`-i`:
+    Show the plan in a band above the prompt (*Anthropic Claude Code CLI* with
+    active ASE function hooks in an interactive terminal only, else the skill
+    aborts), instead of printing it, and ask for the next step without any
+    dialog. The band takes 75% of the terminal height, in the fullscreen mode
+    all the rows the terminal UI leaves it. Under `--focus`, it shows only the
+    focused sections.
+
+    The band follows every change of the plan, also by others, and keeps its
+    scroll position. Its line numbers are those of the plan text in `ase task
+    edit`. It shows the last change as a unified diff with colored backgrounds and
+    line numbers, red for removed and blue for added lines. In the fullscreen
+    mode, scroll it with the mouse wheel, or with *CTRL+x* *TAB* and then
+    *PageUp*/*PageDown*.
+
+    At the prompt, type either a refinement instruction, or one of `DONE`,
+    `GRILL`, `DRAFT`, `IMPLEMENT`, or `CANCEL` (in any case), which closes the
+    band. After a hand-off to `ase-task-grill`, a hand-off back reopens it.
+
+    Type `##` at the end of the prompt (which removes it again) to remove the
+    unified diff and show just the latest state of the plan, until its next
+    change. The band stays open and the input does not reach the agent.
+
 -   `--next`|`-n` *option*[,...]:
     Automatically answer the user dialog for the next step (at the end
     of this skill). *option* is a single token or a *comma-separated
@@ -4608,6 +4798,18 @@ Plan a refactoring under the id `cleanup`:
 ❯ /ase-task-edit -m refactor cleanup: extract HTTP client into its own class
 ```
 
+Refine and show only the `DESIGN` section of the task under id `hello`:
+
+```text
+❯ /ase-task-edit --focus HOW hello: print the text via a dedicated logger.
+```
+
+Refine the task under id `hello` with its plan shown in a band above the prompt:
+
+```text
+❯ /ase-task-edit --interactive hello
+```
+
 </purpose>
 <purpose name="ase-task-estimate">
 
@@ -4781,6 +4983,7 @@ Calibrate the estimation and store the fitted rates:
     [`--ground`|`-G`]
     [`--focus`|`-f` *section*[,...]]
     [`--force`|`-F`]
+    [`--quiet`|`-q`]
     [`--next`|`-n` *option*[,...]]
     [*id*]
 
@@ -4829,7 +5032,7 @@ persisted, its `Tags:` frontmatter key records each grilled section as
 its own tag `grilled:`*section* (lower-case, kept alongside the tags of
 previously grilled sections, e.g. `grilled:specification,
 grilled:design`), and a `PLAN CHANGES` box shows the bullet-points
-changed by the round. Finally, the user is offered a complete
+changed by the round (unless `--quiet` is given). Finally, the user is offered a complete
 re-grilling (with the same grilling options), or a hand-off to editing,
 implementation, or draft.
 
@@ -4891,19 +5094,28 @@ in state `[-]` (cancelled) or `[>]` (deferred) are never questioned.
 
 -   `--focus`|`-f` *section*[,...]:
     Grill only the given plan *section*(s), in the given order. Each
-    *section* is one of `SPECIFICATION` (abbreviated `SPEC`), `DESIGN`
-    (abbreviated `DES`), or `VERIFICATION` (abbreviated `VER`), matched
-    case-insensitively, or the sentinel `all` (default), which expands
-    to `SPECIFICATION,DESIGN,VERIFICATION`. The questions are derived
-    from the themes of the focused sections only, while the entire plan
-    stays the context, and the answers may still update any section.
-    An unknown, empty, or duplicate *section* token aborts the skill.
+    *section* is one of `SPECIFICATION` (also `SPEC` or `WHAT`), `DESIGN`
+    (also `DES` or `HOW`), or `VERIFICATION` (also `VERIFY`, `VER`, or
+    `WHEN`), matched case-sensitively, or the sentinel `all` (default),
+    which expands to `SPECIFICATION,DESIGN,VERIFICATION`. The questions
+    are derived from the themes of the focused sections only, while the
+    entire plan stays the context, and an answer requiring a change
+    outside of the focus is applied nevertheless and reported by a
+    warning. An unknown, empty, or duplicate *section* token aborts the
+    skill. It is forwarded on a re-grilling and on a hand-off to
+    `ase-task-edit`, but not on a hand-off to another skill.
 
 -   `--force`|`-F`:
     Re-grill already grilled sections completely, i.e., ignore their
     `grilled:`*section* tags instead of skipping them resp. re-asking
     only their `[?]` bullet-points.
 
+-   `--quiet`|`-q`:
+    Do not print the `PLAN CHANGES` box of the bullet-points changed by
+    a round. The status lines and the dialogs stay. It is forwarded on a
+    re-grilling and on a hand-off to `ase-task-edit`, but not on a
+    hand-off to another skill.
+
 -   `--next`|`-n` *option*[,...]:
     Automatically answer the user dialog for the next step (at the end
     of this skill). *option* is a single token or a *comma-separated

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>