@rse/ase 1.0.7 → 2.0.1

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

@@ -8,19 +8,23 @@
 `ase-code-edit`
     [`--help`|`-h`]
     [`--mode`|`-m` `auto`|`craft`|`refactor`|`resolve`]
+    [`--approach`|`-a`]
     [`--grill`|`-g`]
     [`--grill-rounds`|`-r` *n*]
+    [`--grill-until`|`-u` `MUST`|`SHOULD`|`MAY`]
+    [`--grill-perspective`|`-p` *perspective*]
+    [`--grill-ground`|`-G`]
     [`--verify`|`-v`]
-    [`--worktree`|`-w`]
+    [`--worktree`|`-w` *name*[`:`*branch*]]
     [`--loop`|`-l`]
     [*query*]
 
 ##  DESCRIPTION
 
 The `ase-code-edit` skill edits the code base *directly* from a *query*,
-in one shot and without any task plan ceremony. It is a *plan-less*
-fusion of `ase-code-craft`, `ase-code-refactor`, `ase-code-resolve`,
-`ase-task-grill`, and `ase-task-implement`.
+in one shot and without any task plan ceremony. It is the *plan-less*
+counterpart of `ase-task-edit`, `ase-task-grill`, and
+`ase-task-implement`, covering crafting, refactoring, and resolving.
 
 Each single-shot run (or each `--loop` iteration) walks through five
 states: *querying* (take the *query* argument or ask for a query via an
@@ -28,11 +32,12 @@ interactive `Edit Query` dialog, and
 split it into its domain-specific WHAT and its implementation-detail HOW
 parts), *discovering* (read the source artifacts related to the query),
 *grilling* (optionally stress-test the query with rounds of questions),
-*implementing* (apply the change set in place, honoring the tenet set
-selected via `--mode`), and *verifying* (optionally verify the
-implementation until it passes). The *querying* state and every
-*grilling* round close with an `EDIT TODO` box showing the established
-`WHAT` and `HOW` information.
+*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
+*querying* state, every *grilling* round, and the approach selection
+close with an `EDIT TODO` box showing the established `WHAT` and `HOW`
+information.
 
 ##  OPTIONS
 
@@ -41,6 +46,15 @@ implementation until it passes). The *querying* state and every
     (CRAFTING), `refactor` (REFACTORING), or `resolve` (RESOLVING).
     The default `auto` infers the tenet set from the query itself.
 
+-   `--approach`|`-a`:
+    Before applying the change set, propose one or more crafting,
+    refactoring, or resolution approaches with pros and cons, recommend
+    one of them, and let the user pick the preferred one via an
+    interactive dialog (or, under the `black` project boxing or in
+    headless mode, automatically pick the recommended one). The chosen
+    approach is merged into the HOW part of the query. Without
+    `--approach`, no approaches are determined at all.
+
 -   `--grill`|`-g`:
     Grill the query before implementing, similar to `ase-task-grill`:
     raise 1-10 questions per round which resolve the open points of the
@@ -48,31 +62,73 @@ implementation until it passes). The *querying* state and every
     (domain-specifics, must be clarified), `INTERFACE` (externally
     observable behavior or UI/API interfaces, must be clarified),
     `ARCHITECTURE` (structure, wiring, placement, or dependencies,
-    should be clarified), or `IMPLEMENTATION` (inner technical details,
-    can be clarified) -- and a 1-2 word `TOPIC` hint. The questions of a
-    round are sorted by descending focus area importance (`DOMAIN`,
-    `INTERFACE`, `ARCHITECTURE`, `IMPLEMENTATION`).
+    should be clarified), `IMPLEMENTATION` (inner technical details,
+    can be clarified), `REGRESSION` (what must not break, should be
+    clarified), or `CONFIRMATION` (what proves the specified behavior,
+    should be clarified) -- and a 1-2 word `TOPIC` hint. The questions
+    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.
     All questions of a round are announced together below a
-    `GRILLING ROUND K/L` line (the announcement line and round numbering
-    are omitted when only a single round is performed) as an
-    `#`/`FOCUS ▶ TOPIC`/`QUESTION` table with one row per
-    question, each row carrying two to four grounded answer alternatives
-    (with the alternative reflecting the current understanding marked as
-    `CURRENT`). They are then asked in *one* batch via a single
+    `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 carrying two to three grounded answer
+    alternatives (with the alternative reflecting the current understanding
+    marked with `⚑`). They are then asked in *one* batch via a single
     interactive dialog titled `GRILLING ROUND K/L` (or plain `GRILLING`
     for a single round), whose question asks for the combined answer to
     all (or a subset) of the listed aspect questions and whose only
     answer options are the fixed `STOP SKILL` (stop the skill) and
     `SKIP GRILLING` (skip the remaining grilling) ones, plus free-text
-    input. The answers are
+    input. The questions are numbered `1`, `2`, etc. and their answer
+    alternatives are lettered `A`, `B`, etc., so the free-text input can
+    cherry-pick answers with short responses matching `\d+[a-zA-Z]`
+    (like `1A 2c`), freely mixed with keyword text. The answers are
     merged back into the WHAT and HOW parts of the query. Without
     `--grill`, no questions are asked at all.
 
 -   `--grill-rounds`|`-r` *n*:
-    The number of grill rounds to apply (default: `1`). Each round
-    starts from scratch from only the current WHAT and HOW parts,
+    The *maximum* number of grill rounds to apply (default: `1`). Each
+    round starts from scratch from only the current WHAT and HOW parts,
     forgetting all information of previous rounds, and closes with an
-    `EDIT TODO` box. Only effective together with `--grill`.
+    `EDIT TODO` box. The grilling stops early -- announced by a
+    `grilling finished early` status line -- once a round, even the
+    first one, finds the open points clear enough according to
+    `--grill-until`. Only effective together with `--grill`.
+
+-   `--grill-until`|`-u` `MUST`|`SHOULD`|`MAY`:
+    Grill until at least all open points of the given severity or
+    higher are clear (default: `MUST`), where the severity follows from
+    the focus area: `MUST` (`DOMAIN`, `INTERFACE`), `SHOULD`
+    (`ARCHITECTURE`, `REGRESSION`, `CONFIRMATION`), and `MAY`
+    (`IMPLEMENTATION`). Independent of this, every open point is rated
+    with an individual impact (`HIGH`, `MEDIUM`, or `LOW`), which
+    decides which points are raised as questions and in which order
+    within a focus area. Only effective together with `--grill`.
+
+-   `--grill-perspective`|`-p` *perspective*:
+    Grill exclusively from the logical *perspective* -- a keyword or
+    short hint like `domain`, `performance`, or `security`. The
+    perspective acts as an exclusive lens: only open points relevant from
+    this perspective are raised as questions, while every question still
+    carries its focus area, severity, and impact. The active perspective
+    is shown in the announcement line, like `GRILLING (security)`.
+    Without a perspective, the grilling is holistic. Only effective together with `--grill`.
+
+-   `--grill-ground`|`-G`:
+    Ground the grilling in facts instead of the world knowledge of the
+    model alone: once before the first round, the artifacts of all kinds
+    (`SPEC`, `CODE`, `DOCS`, `INFR`, and `OTHR`) are scanned for
+    the project facts relevant to the grilled subject (from the given
+    perspective, if any) and the Internet/Web is searched for the
+    established practices, standards, patterns, and pitfalls about it.
+    These facts serve all rounds, both for raising the questions and for
+    preferably deriving their answer alternatives. The grounding is shown
+    in the announcement line, like `GRILLING (security, grounded)`. If
+    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
@@ -81,12 +137,21 @@ implementation until it passes). The *querying* state and every
     until the verification passes. Without `--verify`, strictly no
     verification is performed at all.
 
--   `--worktree`|`-w`:
-    Apply the change sets inside a dedicated Git worktree (as
-    `ase-task-implement --worktree`) instead of the current working
-    copy. One single worktree, named by a two-word id derived from the
-    first query, serves the whole skill run: all `--loop` iterations
-    land in it and it is left uncommitted for review.
+-   `--worktree`|`-w` *name*[`:`*branch*]:
+    Apply the change sets inside the dedicated Git worktree
+    `.ase/worktree/<name>` instead of the current working copy. The
+    worktree is *reused* if it already exists -- then switched to
+    *branch* if given and it has no uncommitted changes --, otherwise
+    it is *created* with the branch *branch* (default: *name*),
+    checked out if it exists or created from `HEAD` otherwise. One
+    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. 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 worktree name or the
+    first query word.
 
 -   `--loop`|`-l`:
     Loop the whole state cycle: after each iteration, ask for the next
@@ -107,6 +172,7 @@ implementation until it passes). The *querying* state and every
 -   You want an analyzer issue like `P1` fixed directly without a plan
 -   You want a quick change with optional grilling and verification
 -   You want several edits chained in a loop, optionally in a worktree
+-   You want the change set to land on a specific Git branch or worktree
 
 ##  EXAMPLES
 
@@ -122,13 +188,34 @@ Grill the query with two rounds first, then implement and verify:
 ❯ /ase-code-edit -g -r 2 -v refactor the config loading into layers
 ```
 
+Let the user pick one of several resolution approaches first, then
+implement:
+
+```text
+❯ /ase-code-edit -a fix race condition in cache invalidation
+```
+
+Grill the query exclusively from the security perspective, grounded in
+the project artifacts and the Internet/Web, then implement:
+
+```text
+❯ /ase-code-edit -g -p security -G add a file upload endpoint to the API
+```
+
 Loop over multiple edits inside a dedicated Git worktree:
 
 ```text
-❯ /ase-code-edit -l -w
+❯ /ase-code-edit -l -w config-layers
+```
+
+Edit inside the dedicated Git worktree `.ase/worktree/verbose` on the
+branch `feature-verbose`:
+
+```text
+❯ /ase-code-edit -w verbose:feature-verbose add a --verbose option to the CLI
 ```
 
 ##  SEE ALSO
 
-[`ase-code-craft`](../ase-code-craft/help.md), [`ase-code-refactor`](../ase-code-refactor/help.md), [`ase-code-resolve`](../ase-code-resolve/help.md),
+[`ase-task-edit`](../ase-task-edit/help.md), [`ase-spec-edit`](../ase-spec-edit/help.md),
 [`ase-task-grill`](../ase-task-grill/help.md), [`ase-task-implement`](../ase-task-implement/help.md).

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

@@ -1,12 +1,15 @@
 ---
 name: ase-code-lint
-argument-hint: "[--help|-h] [--auto|-a] [--severity|-S=(LOW|MEDIUM|HIGH)] [--include|-i=<aspect>[,...]] [--exclude|-e=<aspect>[,...]] <source-reference>"
+argument-hint: "[--help|-h] [--auto|-a] [--severity|-S=(LOW|MEDIUM|HIGH)] [--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.
 user-invocable: true
 disable-model-invocation: false
 effort: high
+allowed-tools:
+    - "Bash(git rev-parse *)"
+    - "Bash(git -C *)"
 ---
 
 @${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
@@ -20,7 +23,7 @@ Lint Source Code
 
 <expand name="getopt"
     arg1="ase-code-lint"
-    arg2="--auto|-a --severity|-S=(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)...">
+    arg2="--auto|-a --severity|-S=(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">
     $ARGUMENTS
 </expand>
 
@@ -38,9 +41,9 @@ related to a set of code quality aspects.
     The project source artifacts are classified as a *black box*, so
     the user does *not* want them inspected or their problems surfaced.
     *Skip* the entire investigation and reporting: do *not* invoke any
-    `Glob` or `Agent` tool and do *not* read any source, only output
-    the following <template/> and then *SKIP* the remaining steps STEP 2
-    and STEP 3:
+    `Bash`, `Glob`, or `Agent` tool and do *not* read any source, only
+    output the following <template/> and then *SKIP* the remaining steps
+    STEP 2 and STEP 3:
 
     <template>
     <ase-tpl-bullet-normal/> **LINT**: *suppressed* (`project.boxing` is `black`)
@@ -83,10 +86,58 @@ related to a set of code quality aspects.
     transcript. The sub-agents perform the silent reading and checking;
     only their final structured return values are consumed here.
 
+    <if condition="<getopt-option-staged/> is equal `true` or <getopt-option-unstaged/> is equal `true`">
+
+    For this, first *silently* restrict the linting to the *changed*
+    files of the Git working copy. Set <changes>staged and
+    unstaged</changes> if both <getopt-option-staged/> and
+    <getopt-option-unstaged/> are equal `true`, set
+    <changes>staged</changes> if only <getopt-option-staged/> is equal
+    `true`, and set <changes>unstaged</changes> otherwise. Determine the
+    *repository root* by running the command `git rev-parse
+    --show-toplevel` (taken exactly as given) and capturing its output
+    into <repo-root/>. Then determine the changed files by running the
+    corresponding commands (taken exactly as given), each listing one
+    path relative to <repo-root/> per line, and collect all listed
+    paths, dropping duplicates:
+
+    <if condition="<getopt-option-staged/> is equal `true`">
+    `git -C "<repo-root/>" -c core.quotepath=off diff --cached --name-only --diff-filter=d`
+    </if>
+
+    <if condition="<getopt-option-unstaged/> is equal `true`">
+    `git -C "<repo-root/>" -c core.quotepath=off diff --name-only --diff-filter=d`
+
+    `git -C "<repo-root/>" -c core.quotepath=off ls-files --others --exclude-standard`
+    </if>
+
+    *Skip* every listed path below the `.ase/` directory (it carries
+    *ASE*'s own state) and every path which is not a source code file
+    (e.g. a binary file), and prefix every remaining path with
+    `<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.
+
+    If <sources/> is empty, only output the following <template/>
+    and then *SKIP* the rest of this STEP 1 and the remaining steps
+    STEP 2 and STEP 3:
+
+    <template>
+    <ase-tpl-bullet-normal/> **LINT**: *no <changes/> source files to lint*
+    </template>
+
+    </if>
+    <else>
+
     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. Then
-    partition <sources/>, preserving order, into at most *eight*
+    directory or wildcard references with the `Glob` tool.
+
+    </else>
+
+    Then partition <sources/>, preserving order, into at most *eight*
     batches of roughly equal size (a single file yields a single
     batch), and invoke the following tool once per batch, emitting
     *all* invocations *in one single message* so they run in
@@ -171,8 +222,8 @@ related to a set of code quality aspects.
     1.  *Mark this skill as the active edit-capable skill* so that the
         ASE `pre-tool-use` hook auto-approves the subsequent `Edit`
         invocations on *any* invocation path (slash command *or* `Skill`
-        tool). Call the `ase_config_set(key: "agent.skill", val:
-        "ase-code-lint", scope: "session:<ase-session-id/>")` tool
+        tool). Call the `ase_state_set(key: "skill", val:
+        "ase-code-lint", session: "<ase-session-id/>")` tool
         from the `ase` MCP server. Do not output anything in this substep.
 
         *Critical safety invariant*: the marker set here grants `Edit`
@@ -478,8 +529,8 @@ related to a set of code quality aspects.
 
     3.  *Clear the active edit-capable skill marker* now that all `Edit`
         invocations are done, so a later unrelated `Edit` is *not*
-        auto-approved. Call the `ase_config_delete(key: "agent.skill",
-        scope: "session:<ase-session-id/>")` tool from the `ase` MCP
+        auto-approved. Call the `ase_state_delete(key: "skill",
+        session: "<ase-session-id/>")` tool from the `ase` MCP
         server. Do not output anything in this substep.
 
     4.  You *MUST* *NOT* output any further additional explanations or
@@ -496,13 +547,13 @@ related to a set of code quality aspects.
 
         <if condition="at least one problem in <problems/> was left uncorrected">
         <ase-tpl-hint level="normal">
-        For problems whose correction demands more than a local edit, use `/ase-code-resolve` to derive and apply a full solution approach.
+        For problems whose correction demands more than a local edit, use `/ase-task-edit` to derive a full solution approach and plan, or `/ase-code-edit -a` to derive and apply it directly.
         </ase-tpl-hint>
         </if>
 
         <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, and `--include`/`--exclude` to narrow the checked aspects.
+        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.
         </ase-tpl-hint>
         </if>
 

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

@@ -11,7 +11,9 @@
     [`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`)]
     [`--include`|`-i`=*aspect*[`,`...]]
     [`--exclude`|`-e`=*aspect*[`,`...]]
-    *source-reference*
+    [`--staged`]
+    [`--unstaged`]
+    [*source-reference*]
 
 ##  DESCRIPTION
 
@@ -76,10 +78,25 @@ the code, and comments contradicting the code.
     code quality aspects. Applied *after* `--include`, so
     `-i A01,A02 -e A02` checks `A01` only.
 
+-   `--staged`:
+    Restrict the linting to the source 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 source
+    files with *any* uncommitted Git changes.
+
+-   `--unstaged`:
+    Restrict the linting to the source files with *unstaged* Git changes
+    plus the *untracked* source files. Deleted files are skipped.
+    Combined with `--staged`, lint the source files with *any*
+    uncommitted Git changes.
+
 ##  ARGUMENTS
 
 -   *source-reference*:
     A file, directory, or other reference to the source code to lint.
+    Optional only under `--staged` or `--unstaged`: with it, only the
+    changed files within it are linted; without it, all changed files
+    of the repository are linted.
 
 ##  SCENARIOS
 
@@ -88,6 +105,7 @@ the code, and comments contradicting the code.
 -   You want all quality corrections applied automatically
 -   You want only specific quality aspects like formatting or spelling checked
 -   You want missing or excessive code documentation flagged
+-   You want only your staged or unstaged changes linted before committing
 
 ##  EXAMPLES
 
@@ -127,7 +145,19 @@ Lint a directory for the documentation aspect only:
 ❯ /ase-code-lint -i A21 src/handlers/
 ```
 
+Lint only the source files with staged Git changes:
+
+```text
+❯ /ase-code-lint --staged
+```
+
+Lint only the unstaged and untracked source files and apply all corrections:
+
+```text
+❯ /ase-code-lint --auto --unstaged
+```
+
 ##  SEE ALSO
 
-[`ase-code-analyze`](../ase-code-analyze/help.md), [`ase-code-resolve`](../ase-code-resolve/help.md), [`ase-code-refactor`](../ase-code-refactor/help.md),
+[`ase-code-analyze`](../ase-code-analyze/help.md), [`ase-code-edit`](../ase-code-edit/help.md), [`ase-task-edit`](../ase-task-edit/help.md),
 [`ase-docs-proofread`](../ase-docs-proofread/help.md).

package/plugin/skills/ase-docs-proofread/SKILL.md

@@ -125,8 +125,8 @@ Analyze documents for spelling, capitalization, punctuation, word break, or gram
     1.  *Mark this skill as the active edit-capable skill* so that the
         ASE `pre-tool-use` hook auto-approves the subsequent `Edit`
         invocations on *any* invocation path (slash command *or* `Skill`
-        tool). Call the `ase_config_set(key: "agent.skill", val:
-        "ase-docs-proofread", scope: "session:<ase-session-id/>")` tool
+        tool). Call the `ase_state_set(key: "skill", val:
+        "ase-docs-proofread", session: "<ase-session-id/>")` tool
         from the `ase` MCP server. Do not output anything in this substep.
 
         *Critical safety invariant*: the marker set here grants `Edit`
@@ -339,8 +339,8 @@ Analyze documents for spelling, capitalization, punctuation, word break, or gram
 
     3.  *Clear the active edit-capable skill marker* now that all `Edit`
         invocations are done, so a later unrelated `Edit` is *not*
-        auto-approved. Call the `ase_config_delete(key: "agent.skill",
-        scope: "session:<ase-session-id/>")` tool from the `ase` MCP
+        auto-approved. Call the `ase_state_delete(key: "skill",
+        session: "<ase-session-id/>")` tool from the `ase` MCP
         server. Do not output anything in this substep.
 
     4.  You *MUST* *NOT* output any further additional explanations or

package/plugin/skills/ase-docs-proofread/help.md

@@ -69,4 +69,4 @@ Proofread an entire documentation directory automatically:
 
 ##  SEE ALSO
 
-[`ase-docs-shorten`](../ase-docs-shorten/help.md), [`ase-docs-refine`](../ase-docs-refine/help.md), [`ase-docs-distill`](../ase-docs-distill/help.md), [`ase-code-lint`](../ase-code-lint/help.md), [`ase-meta-changelog`](../ase-meta-changelog/help.md).
+[`ase-docs-shorten`](../ase-docs-shorten/help.md), [`ase-docs-refine`](../ase-docs-refine/help.md), [`ase-docs-distill`](../ase-docs-distill/help.md), [`ase-code-lint`](../ase-code-lint/help.md), [`ase-repo-changelog`](../ase-repo-changelog/help.md).

package/plugin/skills/ase-docs-refine/SKILL.md

@@ -148,8 +148,8 @@ reduction*, not refinement, and belongs to the `ase-docs-shorten` skill.
     1.  *Mark this skill as the active edit-capable skill* so that the
         ASE `pre-tool-use` hook auto-approves the subsequent `Edit`
         invocations on *any* invocation path (slash command *or* `Skill`
-        tool). Call the `ase_config_set(key: "agent.skill", val:
-        "ase-docs-refine", scope: "session:<ase-session-id/>")` tool
+        tool). Call the `ase_state_set(key: "skill", val:
+        "ase-docs-refine", session: "<ase-session-id/>")` tool
         from the `ase` MCP server. Do not output anything in this substep.
 
         *Critical safety invariant*: the marker set here grants `Edit`
@@ -369,8 +369,8 @@ reduction*, not refinement, and belongs to the `ase-docs-shorten` skill.
 
     3.  *Clear the active edit-capable skill marker* now that all `Edit`
         invocations are done, so a later unrelated `Edit` is *not*
-        auto-approved. Call the `ase_config_delete(key: "agent.skill",
-        scope: "session:<ase-session-id/>")` tool from the `ase` MCP
+        auto-approved. Call the `ase_state_delete(key: "skill",
+        session: "<ase-session-id/>")` tool from the `ase` MCP
         server. Do not output anything in this substep.
 
     4.  You *MUST* *NOT* output any further additional explanations or

package/plugin/skills/ase-docs-shorten/SKILL.md

@@ -215,8 +215,8 @@ than the user asked for.
     1.  *Mark this skill as the active edit-capable skill* so that the
         ASE `pre-tool-use` hook auto-approves the subsequent `Edit`
         invocations on *any* invocation path (slash command *or* `Skill`
-        tool). Call the `ase_config_set(key: "agent.skill", val:
-        "ase-docs-shorten", scope: "session:<ase-session-id/>")` tool
+        tool). Call the `ase_state_set(key: "skill", val:
+        "ase-docs-shorten", session: "<ase-session-id/>")` tool
         from the `ase` MCP server. Do not output anything in this substep.
 
         *Critical safety invariant*: the marker set here grants `Edit`
@@ -454,8 +454,8 @@ than the user asked for.
 
     3.  *Clear the active edit-capable skill marker* now that all `Edit`
         invocations are done, so a later unrelated `Edit` is *not*
-        auto-approved. Call the `ase_config_delete(key: "agent.skill",
-        scope: "session:<ase-session-id/>")` tool from the `ase` MCP
+        auto-approved. Call the `ase_state_delete(key: "skill",
+        session: "<ase-session-id/>")` tool from the `ase` MCP
         server. Do not output anything in this substep.
 
     </step>