@rse/ase 1.0.7 → 2.0.1

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

@@ -177,7 +177,9 @@ Discover HTTP clients, flagging any without a release in the last 12 months:
     [`--security`|`-s`]
     [`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`)]
     [`--prefix`|`-P` *prefix*]
-    *source-reference*
+    [`--staged`]
+    [`--unstaged`]
+    [*source-reference*]
 
 ##  DESCRIPTION
 
@@ -213,19 +215,29 @@ under *distinct* prefixes coexist instead of overwriting each other.
 Without the option (the default), ids stay unprefixed and the purge
 covers the *entire* `ase-issue-*` space, including any prefixed results.
 
+The `--staged` option restricts the analysis to the source files with
+*staged* Git changes, and the `--unstaged` option restricts it to the
+source files with *unstaged* Git changes plus the *untracked* source
+files. Deleted files are skipped, and the files are analyzed in their
+current working copy state. With a *source-reference*, only the changed
+files within it are analyzed; without one, all changed files of the
+repository are analyzed. If no such file exists, nothing is analyzed.
+Both options can be combined to analyze the source files with *any*
+uncommitted Git changes.
+
 The skill investigates the code base silently, reports each detected
 problem as a `PROBLEM` entry with severity (`LOW`, `MEDIUM`, `HIGH`) and
 inline file/line references (in the performance lens, each entry
 additionally carries an *evidence* and a *trade-off* line), and persists
 results in the `ase` MCP key/value store as `ase-issue-P<n>` entries so
-they can later be resolved via `ase-code-resolve P<n>` or directly
+they can later be planned via `ase-task-edit P<n>` or directly
 fixed via `ase-code-edit P<n>`.
 
 ##  ARGUMENTS
 
 -   *source-reference*:
     A file, directory, function, or other reference to the source code
-    to analyze.
+    to analyze. Optional only under `--staged` or `--unstaged`.
 
 ##  SCENARIOS
 
@@ -234,6 +246,7 @@ fixed via `ase-code-edit P<n>`.
 -   You want performance and efficiency opportunities surfaced
 -   You want a security-focused inspection of your code
 -   You want problems persisted as issue ids like `P1` for later resolving
+-   You want only your staged or unstaged changes analyzed before committing
 
 ##  EXAMPLES
 
@@ -273,250 +286,16 @@ Analyze a directory under its own id namespace, yielding `auth-P1`, `auth-P2`, .
 ❯ /ase-code-analyze --prefix auth src/auth/
 ```
 
-</purpose>
-<purpose name="ase-code-craft">
-
-##  NAME
-
-`ase-code-craft` - Craft Source Code
-
-##  SYNOPSIS
-
-`ase-code-craft`
-    [`--help`|`-h`]
-    [`--auto`|`-a`]
-    [`--dry`|`-d`]
-    [`--direct`|`-D`]
-    [`--interactive`|`-i`]
-    [`--quick`|`-Q`]
-    [`--next`|`-n` *option*[,...]]
-    [*task-id*:] *feature*
-
-##  DESCRIPTION
-
-The `ase-code-craft` skill crafts a *new feature* from scratch by
-investigating the existing code base, internalizing crafting tenets
-(KISS, YAGNI, DRY, SRP, loose coupling, ...), proposing one or more
-*feature approaches* with pros and cons, letting the user pick the
-preferred approach, and composing a corresponding *task plan* aligned
-with the existing architecture.
-
-By default the skill does *not* directly modify source files. It
-persists the plan via `ase_task_save` and then hands off to
-`ase-task-edit`, `ase-task-preflight`, or `ase-task-implement`, as
-selected by `--next`. Only under `--direct` it skips the plan
-entirely and applies the change set to the affected artifacts itself.
-
-##  OPTIONS
-
--   `--auto`|`-a`:
-    Automatically pick the recommended feature approach without
-    asking the user via the interactive dialog.
-
--   `--dry`|`-d`:
-    Compose the plan *without* the `##  VERIFICATION` section. When
-    `ase-task-implement` later applies such a plan, it strictly skips
-    the entire verification phase (no build, tests, linter,
-    type-checker, or program execution) once the source files have
-    been modified.
-
--   `--direct`|`-D`:
-    Craft the feature *immediately* and *in place*: skip the
-    feature approaches, the interactive dialog, and the entire task
-    plan ceremony, and directly apply the complete change set to the
-    affected artifacts, including a corresponding entry in an existing
-    `CHANGELOG.md` file. In this mode `--auto`, `--dry`, `--quick`, and
-    `--next` have no effect, as neither approaches are proposed nor a
-    plan is composed.
-
--   `--interactive`|`-i`:
-    Craft *interactively*: implies `--direct` and, once the initial
-    *feature* has been applied, repeatedly asks for the *next change*
-    with a free-text dialog and immediately applies it in place, too,
-    until the user stops the loop by answering `DONE`.
-
--   `--quick`|`-Q`:
-    Shorthand alias for `-a -d -n IMPLEMENT,DELETE`: automatically pick
-    the recommended feature approach, compose the plan *without* the
-    `##  VERIFICATION` section, immediately hand off to `ase-task-implement`,
-    and finally `ase-task-delete` the now-consumed plan. This gives a
-    single, fast *one-shot* crafting mode.
-
--   `--next`|`-n` *option*[,...]:
-    Automatically choose the next step after composing the plan.
-    *option* is a single token or a *comma-separated chronological
-    list* of tokens; an `IMPLEMENT`, `PREFLIGHT`, or `GRILL` head token
-    is consumed by this skill (bypassing `ase-task-edit`), and any
-    remaining tokens are *forwarded* (via `--next`) to the downstream
-    skill. For all other head tokens, the *entire* list is forwarded
-    to `ase-task-edit`, which consumes its head itself. This lets an
-    entire pipeline be pre-scripted in one shot. Recognized tokens at
-    this skill: `none` (default, hand off to `ase-task-edit`
-    interactively), `DONE` (stop), `EDIT` (hand off to
-    `ase-task-edit`), `GRILL` (hand off to `ase-task-grill`),
-    `PREFLIGHT` (hand off to `ase-task-preflight`),
-    or `IMPLEMENT` (hand off to `ase-task-implement`). Example:
-    `--next PREFLIGHT,IMPLEMENT,DONE` crafts the plan, preflights it,
-    implements it, and exits without further dialog.
-
-##  ARGUMENTS
-
--   [*task-id*:] *feature*:
-    Description of the *feature* to craft. Optionally prefixed with
-    a *task-id* followed by a colon to bind the resulting plan to
-    a specific task id.
-
-##  SCENARIOS
-
--   You want to add a new feature to the code base
--   You want feature approaches with pros and cons before any code changes
--   You want a task plan composed for building something new
--   You want a fast one-shot crafting without any plan ceremony
-
-##  EXAMPLES
-
-Craft a new logging feature:
-
-```text
-❯ /ase-code-craft add structured JSON logging with log levels
-```
-
-Craft a feature under a named task and directly hand off to implementation:
-
-```text
-❯ /ase-code-craft --next IMPLEMENT auth: add JWT authentication middleware
-```
-
-Craft interactively, applying one change after the other in place:
-
-```text
-❯ /ase-code-craft -i add a --verbose option to the CLI
-```
-
-</purpose>
-<purpose name="ase-code-dissect">
-
-##  NAME
-
-`ase-code-dissect` - Dissect a Change Set
-
-##  SYNOPSIS
-
-`ase-code-dissect`
-    [`--help`|`-h`]
-    [`--max-parts`|`-m` *count*]
-    [`--staged`|`-s`]
-    [`--dry`|`-d`]
-    [`--force`|`-f`]
-    [*dissect-hint*]
-
-##  DESCRIPTION
-
-The `ase-code-dissect` skill treats the current Git change set as an
-*epic* and *dissects* it domain-wise and logically into *cohesive
-parts*. Each part is a self-contained unit of change with a single
-coherent purpose, so it can be reviewed and committed *atomically* and
-*independently* of the others.
-
-The change set is captured from the working copy (`git diff`), with
-untracked files folded in *read-only*, or -- under `--staged`/`-s` --
-from the Git index (`git diff --cached HEAD`). The dissection follows a
-strict ruleset: at least *2* and at most *count* parts are derived,
-*every* hunk is assigned to *exactly one* part, mutually dependent hunks
-are kept together, all hunks of one file normally stay in the same part,
-and nothing beyond the actual change set is invented. The cut follows
-the *semantics* of the change, not its technical structure -- a split by
-file, directory, or technical layer is usually *not* the intended one.
-If the change set carries only a single cohesive purpose, it is reported
-as *not dissectable* and nothing is created.
-
-An optional *dissect-hint* steers *how* the change set is split -- which
-changes belong together, along which axis to cut, or how many parts to
-aim at. It is especially useful after a `--dry` run showed an unintended
-dissection. The hint overrides the default grouping, but never the
-ruleset itself.
-
-The derived parts are first reported as a *dissection table* (part
-number, worktree id, scope, and rationale). Then -- unless `--dry` is
-given -- each part's patch is written to a temporary file and applied
-inside a *fresh Git WorkTree* `.ase/worktree/<project-id>-<feature-slug>`,
-whose branch carries the same name and is created from `HEAD`. If a
-`CHANGELOG.md` file exists, a matching entry summarizing that part is
-added *inside* the worktree.
-
-Every part stays *uncommitted*, a failing `git apply` is reported for
-that part while the remaining parts continue, and the *original working
-copy is never mutated*.
-
-Note that the working-copy patch (without `--staged`) is taken relative
-to the Git *index* while the worktrees are created from `HEAD`. So if
-changes are *also* staged, the affected part patches may not apply
-cleanly and are then reported as failed; stage everything and use
-`--staged` in that situation.
-
-##  OPTIONS
-
--   `--max-parts`|`-m` *count*:
-    Upper bound for the number of derived parts (default: `8`). The
-    lower bound is always `2`, because fewer parts are no dissection.
-
--   `--staged`|`-s`:
-    Dissect the *staged* changes (the Git index against `HEAD`) instead
-    of the working copy changes. Untracked files are then *not* folded
-    in, because they are by definition not part of the index.
-
--   `--dry`|`-d`:
-    *Report only* -- print the dissection table but create *no*
-    artifacts at all, so the decision stays fully reversible. Note that
-    this meaning differs from `--dry`/`-d` in `ase-code-craft`, where it
-    instead omits the `##  VERIFICATION` section of the composed plan.
-
--   `--force`|`-f`:
-    Remove and re-create already existing worktrees and branches of the
-    derived names. Without this option, the skill detects colliding
-    targets *before* writing anything, reports them, and stops with
-    status *targets exist*.
-
-##  ARGUMENTS
-
--   *dissect-hint*:
-    A free-text hint telling *how* the change set should be split. If
-    omitted, the parts are derived from the change set alone.
-
-The worktree names are *not* argument-driven: they are always derived
-from the *current* project id and the per-part feature slug.
-
-##  SCENARIOS
-
--   You want a large uncommitted change set split into atomic parts
--   You want each cohesive part of a diff in its own Git worktree
--   You want mixed-up changes untangled before committing them
--   You want a preview of how a change set would be divided
-
-##  EXAMPLES
-
-Dissect the current working copy changes:
-
-```text
-❯ /ase-code-dissect
-```
-
-Preview the dissection of the staged changes into at most four parts:
-
-```text
-❯ /ase-code-dissect --staged --dry --max-parts 4
-```
-
-Re-dissect the changes, re-creating the previously created worktrees:
+Analyze only the source files with staged Git changes:
 
 ```text
-❯ /ase-code-dissect --force
+❯ /ase-code-analyze --staged
 ```
 
-Dissect the changes along an explicitly given axis:
+Analyze only the unstaged and untracked source files below a directory:
 
 ```text
-❯ /ase-code-dissect keep the plugin and tool changes in separate parts
+❯ /ase-code-analyze --unstaged src/handlers/
 ```
 
 </purpose>
@@ -531,19 +310,23 @@ Dissect the changes along an explicitly given axis:
 `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
@@ -551,11 +334,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
 
@@ -564,6 +348,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
@@ -571,31 +364,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
@@ -604,12 +439,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
@@ -630,6 +474,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
 
@@ -645,10 +490,31 @@ 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
 ```
 
 </purpose>
@@ -764,7 +630,9 @@ Get insights into a specific subsystem:
     [`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`)]
     [`--include`|`-i`=*aspect*[`,`...]]
     [`--exclude`|`-e`=*aspect*[`,`...]]
-    *source-reference*
+    [`--staged`]
+    [`--unstaged`]
+    [*source-reference*]
 
 ##  DESCRIPTION
 
@@ -829,10 +697,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
 
@@ -841,6 +724,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
 
@@ -880,224 +764,16 @@ Lint a directory for the documentation aspect only:
 ❯ /ase-code-lint -i A21 src/handlers/
 ```
 
-</purpose>
-<purpose name="ase-code-refactor">
-
-##  NAME
-
-`ase-code-refactor` - Refactor Artifacts
-
-##  SYNOPSIS
-
-`ase-code-refactor`
-    [`--help`|`-h`]
-    [`--auto`|`-a`]
-    [`--dry`|`-d`]
-    [`--direct`|`-D`]
-    [`--quick`|`-Q`]
-    [`--next`|`-n` *option*[,...]]
-    [*task-id*:] *request*
-
-##  DESCRIPTION
-
-The `ase-code-refactor` skill refactors existing artifacts by
-investigating the related code, internalizing refactoring tenets
-(Behavior Preservation, Boy Scout Rule, DRY, SRP, loose coupling,
-clear interfaces, ...), proposing one or more *refactoring approaches*
-with pros and cons, letting the user pick the preferred approach,
-and composing a corresponding *task plan*.
-
-By default the skill does *not* directly modify source files. It
-persists the plan via `ase_task_save` and then hands off to
-`ase-task-edit`, `ase-task-preflight`, or `ase-task-implement`, as
-selected by `--next`. Only under `--direct` it skips the plan
-entirely and applies the change set to the affected artifacts itself.
-
-##  OPTIONS
-
--   `--auto`|`-a`:
-    Automatically pick the recommended refactoring approach without
-    asking the user via the interactive dialog.
-
--   `--dry`|`-d`:
-    Compose the plan *without* the `##  VERIFICATION` section. When
-    `ase-task-implement` later applies such a plan, it strictly skips
-    the entire verification phase (no build, tests, linter,
-    type-checker, or program execution) once the source files have
-    been modified.
-
--   `--direct`|`-D`:
-    Apply the refactoring *immediately* and *in place*: skip the
-    refactoring approaches, the interactive dialog, and the entire task
-    plan ceremony, and directly apply the complete change set to the
-    affected artifacts, including a corresponding entry in an existing
-    `CHANGELOG.md` file. In this mode `--auto`, `--dry`, `--quick`, and
-    `--next` have no effect, as neither approaches are proposed nor a
-    plan is composed.
-
--   `--quick`|`-Q`:
-    Shorthand alias for `-a -d -n IMPLEMENT,DELETE`: automatically pick
-    the recommended refactoring approach, compose the plan *without* the
-    `##  VERIFICATION` section, immediately hand off to `ase-task-implement`,
-    and finally `ase-task-delete` the now-consumed plan. This gives a
-    single, fast *one-shot* refactoring mode.
-
--   `--next`|`-n` *option*[,...]:
-    Automatically choose the next step after composing the plan.
-    *option* is a single token or a *comma-separated chronological
-    list* of tokens; an `IMPLEMENT`, `PREFLIGHT`, or `GRILL` head token
-    is consumed by this skill (bypassing `ase-task-edit`), and any
-    remaining tokens are *forwarded* (via `--next`) to the downstream
-    skill. For all other head tokens, the *entire* list is forwarded
-    to `ase-task-edit`, which consumes its head itself. This lets an
-    entire pipeline be pre-scripted in one shot. Recognized tokens at
-    this skill: `none` (default, hand off to `ase-task-edit`
-    interactively), `DONE` (stop), `EDIT` (hand off to
-    `ase-task-edit`), `GRILL` (hand off to `ase-task-grill`),
-    `PREFLIGHT` (hand off to `ase-task-preflight`),
-    or `IMPLEMENT` (hand off to `ase-task-implement`). Example:
-    `--next PREFLIGHT,IMPLEMENT,DONE` refactors, preflights, implements,
-    and exits without further dialog.
-
-##  ARGUMENTS
-
--   [*task-id*:] *request*:
-    Description of the refactoring *request*. Optionally prefixed
-    with a *task-id* followed by a colon to bind the resulting plan
-    to a specific task id.
-
-##  SCENARIOS
-
--   You want existing code restructured without changing its behavior
--   You want refactoring approaches with pros and cons before any changes
--   You want a task plan composed for a cleanup
--   You want a one-shot refactoring applied directly in place
-
-##  EXAMPLES
-
-Refactor a module into smaller files:
-
-```text
-❯ /ase-code-refactor split src/handlers.ts into per-route modules
-```
-
-Refactor under a named task and directly hand off to implementation:
-
-```text
-❯ /ase-code-refactor --next IMPLEMENT cleanup: extract HTTP client into its own class
-```
-
-</purpose>
-<purpose name="ase-code-resolve">
-
-##  NAME
-
-`ase-code-resolve` - Resolve Problem
-
-##  SYNOPSIS
-
-`ase-code-resolve`
-    [`--help`|`-h`]
-    [`--auto`|`-a`]
-    [`--dry`|`-d`]
-    [`--direct`|`-D`]
-    [`--quick`|`-Q`]
-    [`--next`|`-n` *option*[,...]]
-    [*task-id*:] *problem*
-
-##  DESCRIPTION
-
-The `ase-code-resolve` skill resolves a *bug* or *problem* by
-investigating the related code, internalizing resolution tenets
-(Surgical Changes, No Cleanups, Minimum Flags, Code Adequacy, Origin
-Proximity, ...), proposing one or more *resolution approaches* with
-pros and cons, letting the user pick the preferred approach, and
-composing a corresponding *task plan*.
-
-The *problem* may also be given as a bare issue identifier (e.g. `P1`
-or `T1`) previously produced by `ase-code-analyze` or
-`ase-arch-analyze` and persisted in the `ase` MCP key/value store
-under `ase-issue-<id>`.
-
-By default the skill does *not* directly modify source files. It
-persists the plan via `ase_task_save` and then hands off to
-`ase-task-edit`, `ase-task-preflight`, or `ase-task-implement`, as
-selected by `--next`. Only under `--direct` it skips the plan
-entirely and applies the change set to the affected artifacts itself.
-
-##  OPTIONS
-
--   `--auto`|`-a`:
-    Automatically pick the recommended resolution approach without
-    asking the user via the interactive dialog.
-
--   `--dry`|`-d`:
-    Compose the plan *without* the `##  VERIFICATION` section. When
-    `ase-task-implement` later applies such a plan, it strictly skips
-    the entire verification phase (no build, tests, linter,
-    type-checker, or program execution) once the source files have
-    been modified.
-
--   `--direct`|`-D`:
-    Resolve the problem *immediately* and *in place*: skip the
-    resolution approaches, the interactive dialog, and the entire task
-    plan ceremony, and directly apply the complete change set to the
-    affected artifacts, including a corresponding entry in an existing
-    `CHANGELOG.md` file. In this mode `--auto`, `--dry`, `--quick`, and
-    `--next` have no effect, as neither approaches are proposed nor a
-    plan is composed.
-
--   `--quick`|`-Q`:
-    Shorthand alias for `-a -d -n IMPLEMENT,DELETE`: automatically pick
-    the recommended resolution approach, compose the plan *without* the
-    `##  VERIFICATION` section, immediately hand off to `ase-task-implement`,
-    and finally `ase-task-delete` the now-consumed plan. This gives a
-    single, fast *one-shot* resolution mode.
-
--   `--next`|`-n` *option*[,...]:
-    Automatically choose the next step after composing the plan.
-    *option* is a single token or a *comma-separated chronological
-    list* of tokens; an `IMPLEMENT`, `PREFLIGHT`, or `GRILL` head token
-    is consumed by this skill (bypassing `ase-task-edit`), and any
-    remaining tokens are *forwarded* (via `--next`) to the downstream
-    skill. For all other head tokens, the *entire* list is forwarded
-    to `ase-task-edit`, which consumes its head itself. This lets an
-    entire pipeline be pre-scripted in one shot. Recognized tokens at
-    this skill: `none` (default, hand off to `ase-task-edit`
-    interactively), `DONE` (stop), `EDIT` (hand off to
-    `ase-task-edit`), `GRILL` (hand off to `ase-task-grill`),
-    `PREFLIGHT` (hand off to `ase-task-preflight`),
-    or `IMPLEMENT` (hand off to `ase-task-implement`). Example:
-    `--next IMPLEMENT,DONE` resolves the problem, implements it, and
-    exits without further dialog.
-
-##  ARGUMENTS
-
--   [*task-id*:] *problem*:
-    Description of the *problem* to resolve, or a bare issue
-    identifier like `P1` or `T1` previously produced by an analyzer
-    skill. Optionally prefixed with a *task-id* followed by a colon
-    to bind the resulting plan to a specific task id.
-
-##  SCENARIOS
-
--   You want a bug fixed or a problem resolved in the code
--   You want an issue like `P1` reported by an analyzer resolved
--   You want resolution approaches with pros and cons before any changes
--   You want a task plan composed for a bugfix
-
-##  EXAMPLES
-
-Resolve a free-text problem:
+Lint only the source files with staged Git changes:
 
 ```text
-❯ /ase-code-resolve fix race condition in cache invalidation
+❯ /ase-code-lint --staged
 ```
 
-Resolve a previously analyzed issue and hand off to implementation:
+Lint only the unstaged and untracked source files and apply all corrections:
 
 ```text
-❯ /ase-code-resolve --next IMPLEMENT P1
+❯ /ase-code-lint --auto --unstaged
 ```
 
 </purpose>
@@ -1660,58 +1336,17 @@ and a tighter shortlist:
 ```
 
 </purpose>
-<purpose name="ase-meta-changelog">
+<purpose name="ase-meta-chat">
 
 ##  NAME
 
-`ase-meta-changelog` - Update ChangeLog Entries
+`ase-meta-chat` - Query Foreign LLM for Chat
 
 ##  SYNOPSIS
 
-`ase-meta-changelog`
+`ase-meta-chat`
     [`--help`|`-h`]
-
-##  DESCRIPTION
-
-The `ase-meta-changelog` skill helps to *complete*, *consolidate*, and
-*sort* the entries of the most recent section of a `CHANGELOG.md`
-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>`
-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`, `arch`, `code`,
-`docs`, `infr`, or `othr`. Entries are grouped and sorted by this
-prefix. The date in the section header is also updated to the current
-date.
-
-##  SCENARIOS
-
--   You want the `CHANGELOG.md` brought up to date with recent commits
--   You want changelog entries completed, consolidated, and sorted
--   You want a tidy changelog section before a release
-
-##  EXAMPLES
-
-Update the most recent ChangeLog section:
-
-```text
-❯ /ase-meta-changelog
-```
-
-</purpose>
-<purpose name="ase-meta-chat">
-
-##  NAME
-
-`ase-meta-chat` - Query Foreign LLM for Chat
-
-##  SYNOPSIS
-
-`ase-meta-chat`
-    [`--help`|`-h`]
-    *llm* *query*
+    *llm* *query*
 
 ##  DESCRIPTION
 
@@ -1750,42 +1385,6 @@ Ask Gemini for a brief comparison:
 ❯ /ase-meta-chat gemini Compare gRPC and REST in one paragraph.
 ```
 
-</purpose>
-<purpose name="ase-meta-commit">
-
-##  NAME
-
-`ase-meta-commit` - Git Commit Message
-
-##  SYNOPSIS
-
-`ase-meta-commit`
-    [`--help`|`-h`]
-
-##  DESCRIPTION
-
-The `ase-meta-commit` skill helps to *craft* a *concise commit
-message* for the currently staged Git changes. It inspects the
-output of `git diff --cached` and produces a single-line message of
-the form `<type>: <summary>` where *type* is one of `FEATURE`,
-`IMPROVEMENT`, `BUGFIX`, `UPDATE`, `CLEANUP`, or `REFACTOR`, and
-*summary* is a 60-80 character imperative-mood summary without
-trailing period or Markdown formatting.
-
-##  SCENARIOS
-
--   You want a commit message for the currently staged changes
--   You want a typed one-line summary derived from the staged diff
--   You want to commit but cannot phrase what changed
-
-##  EXAMPLES
-
-Craft a commit message for the currently staged changes:
-
-```text
-❯ /ase-meta-commit
-```
-
 </purpose>
 <purpose name="ase-meta-compat">
 
@@ -1889,13 +1488,14 @@ return the first value that is defined; writes are always confined to
 the strongest (target) scope of the chain.
 
 The recognized keys are grouped under `project.*` (`project.id`,
-`project.name`, `project.boxing`, and the
-`project.artifact.`*kind*`.{basedir,files}` globs) and `agent.*`
-(`agent.persona`, `agent.guidance`, `agent.task`, and `agent.skill`).
+`project.name`, `project.boxing`, `project.task.lifecycle`,
+`project.task.idscheme`, `project.task.default.{source,changeset,target}`,
+and the `project.artifact.`*kind*`.{basedir,files}`
+globs) and `agent.*` (`agent.persona` and `agent.guidance`).
 Some keys are writable on selected scopes only; in particular
-`agent.task` and `agent.skill` are writable on a `session` scope only,
-and the `project.artifact.*` globs are writable on the `user` and
-`project` scopes only.
+the `project.artifact.*` globs are writable on the `user` and
+`project` scopes only. The internal session state, like the active
+task id (see `ase-task-id`), is not part of the configuration.
 
 The three keys steering the behaviour of the agent itself accept fixed
 value sets: `agent.persona` selects the *communication style* and is one
@@ -1908,7 +1508,22 @@ pyramid-structured `journalist`, the brief, factual, and abbreviating
 `project.boxing` selects the artifact transparency and is one of `white`,
 `grey`, or `black`. Setting `agent.persona`, `agent.guidance`, or
 `project.boxing` takes effect immediately, i.e. still within the running
-session.
+session. Additionally, `project.task.lifecycle` selects the task plan
+lifecycle and is one of `solo` (the default), `team`, or `enterprise`; it is
+exported at session start as `<ase-project-task-lifecycle/>`. Finally,
+`project.task.idscheme` selects the scheme of newly generated task ids and is one
+of `slug[:<words>]` (the default, the first *words* (default: 2) words of
+the task title, lower-cased and joined with `-`), `seq[:<template>]` (a
+continuously increasing sequence number, rendered through a sprintf-style
+*template* like `FOO-%03d`, `#%d`, or `%d` (the default)), or `any` (an
+arbitrary unique id chosen by the agent). Additionally,
+`project.task.default.{source,changeset,target}` select the defaults of
+the `Source:`, `Changeset:`, and `Target:` task plan keys (`worktree`,
+`worktree`, and `source` by default), which an absent key reads as, where
+a `branch:<name>` or `attachment:<name>` value can carry the placeholder
+`{id}` of the task id (e.g., `branch:cs-{id}` for a branch per task); they
+are exported at session start as
+`<ase-project-task-default-{source,changeset,target}/>`.
 
 The following *operations* exist:
 
@@ -1944,8 +1559,7 @@ preset-bootstrapping operation that stays a shell concern next to
     the strongest explicitly requested term. If the option is
     omitted, the chain of the *current session* (`session:`*id*) is used,
     so that reads see the full `user` -> `project` -> `session` cascade
-    and writes -- including those to the session-only keys `agent.task`
-    and `agent.skill` -- land on the session layer.
+    and writes land on the session layer.
 
 ##  ARGUMENTS
 
@@ -1959,7 +1573,7 @@ preset-bootstrapping operation that stays a shell concern next to
 ##  SCENARIOS
 
 -   You want the ASE configuration inspected or changed
--   You want the persona, guidance, or boxing switched for a session
+-   You want the persona, guidance, boxing, or task lifecycle switched for a session
 -   You want a configuration value persisted at user or project scope
 -   You want to see which scope supplies each effective value
 
@@ -1995,6 +1609,12 @@ Persist the guidance level for the whole project instead:
 ❯ /ase-meta-config --scope project set agent.guidance minimal
 ```
 
+Persist the task lifecycle for the whole project:
+
+```text
+❯ /ase-meta-config --scope project set project.task.lifecycle team
+```
+
 Remove a value from the user-level configuration:
 
 ```text
@@ -2083,116 +1703,6 @@ Surface at least fifteen anti-theses:
 ❯ /ase-meta-diaboli --count 15 We should rewrite the service in Rust.
 ```
 
-</purpose>
-<purpose name="ase-meta-diff">
-
-##  NAME
-
-`ase-meta-diff` - Summarize Diff
-
-##  SYNOPSIS
-
-`ase-meta-diff`
-    [`--help`|`-h`]
-    [`--coherence`|`-c`]
-    [`--risk`|`-r`]
-    [`--blast`|`-b`]
-
-##  DESCRIPTION
-
-The `ase-meta-diff` skill turns a raw Git diff into a *concise*,
-*human-readable* narrative of what changed and why, *grouped by
-intent* (such as *Feature*, *Improvement*, *Bugfix*, *Update*,
-*Cleanup*, or *Refactor*) rather than by file. It inspects the
-*staged* changes (`git diff --cached HEAD`). The result is a compact
-table, one row per intent group, each naming the affected files
-with their per-file `[+N/-M]` line counts - giving you the essence
-of the changes at a glance.
-
-With `--coherence`, the skill additionally *reconstructs the single
-intended change* the diff is trying to accomplish - phrased as one crisp
-*thesis* sentence - and then walks *every* hunk to *flag those that do
-not serve it*: **scope creep** (an unrelated feature or drive-by refactor
-riding along) and **stray debug** (leftover prints, commented-out code, or
-disabled tests). It emits an overall **COHERENT** / **INCOHERENT** verdict
-plus a table of the flagged hunks with what to do with each - keeping the
-diff to a *single logical and coherent change* before it is committed.
-
-With `--risk`, the skill additionally *scores* the same diff against a
-four-axis **coupling-criticality-coverage-reversibility** rubric and
-emits a *graded risk report* - one table row per axis (each scored *1*-*5*
-with a one-line evidence justification drawn from the actual hunks), an
-overall risk band (**LOW**, **MODERATE**, **HIGH**, or **CRITICAL**),
-and one actionable *mitigation* per high-risk axis. The axes combine
-with *equal weights*, and the rubric is deliberately *not tuned* to any
-specific project: every score is backed by cited evidence so it remains
-*overridable*, and the report is *decision support*, not a merge gate.
-
-With `--blast`, the skill additionally renders a *blast-radius map* - a
-Mermaid `flowchart` of the *touched modules* and their *reverse
-dependencies*, plus a *brief impact summary*. It *extracts the touched
-modules* from the changed files, *scans the repository* for the
-first-party code that *imports* or *references* those modules, builds a
-blast-radius graph (touched modules as origin nodes, dependents fanning
-out along the edges), dispatches the rendering to the `ase-meta-diagram`
-sub-agent, and appends a short bullet list of the per-module impact -
-giving a visual sense of *what a diff endangers* before a deeper review.
-
-##  ARGUMENTS
-
--   `--coherence`, `-c`:
-    In addition to the intent-grouped summary, reconstruct the diff's
-    *single intended change* as one crisp *thesis* sentence and flag
-    *every* hunk that does *not* serve it - *scope creep* or *stray
-    debug* - then emit an overall **COHERENT** / **INCOHERENT** verdict
-    with a table of the flagged hunks.
-
--   `--risk`, `-r`:
-    In addition to the intent-grouped summary, score the diff against
-    the *coupling-criticality-coverage-reversibility* rubric and emit a
-    *graded risk report* with an overall risk band and per-axis
-    *mitigations*. Scores are equal-weighted, evidence-backed, and
-    deliberately untuned to the project.
-
--   `--blast`, `-b`:
-    In addition to the intent-grouped summary, render a *blast-radius
-    map* - a Mermaid `flowchart` of the *touched modules* and their
-    *reverse dependencies* - plus a *brief impact summary* of what
-    depends on the touched code and how far the blast reaches.
-
-##  SCENARIOS
-
--   You want a readable, intent-grouped summary of the staged changes
--   You want a diff checked for scope creep and stray debug leftovers
--   You want a graded risk report of a change before committing
--   You want a blast-radius map of what depends on the touched code
-
-##  EXAMPLES
-
-Summarize the currently staged changes:
-
-```text
-❯ /ase-meta-diff
-```
-
-Summarize the staged changes and append an intent-coherence report:
-
-```text
-❯ /ase-meta-diff --coherence
-```
-
-Summarize the staged changes and append a graded risk report:
-
-```text
-❯ /ase-meta-diff --risk
-```
-
-Summarize the staged changes and append a blast-radius map:
-
-```text
-❯ /ase-meta-diff --blast
-```
-
 </purpose>
 <purpose name="ase-meta-eli5">
 
@@ -2327,7 +1837,7 @@ Evaluate database options with hinted criteria:
 
 `ase-meta-mint`
     [`--help`|`-h`]
-    [`--type`|`-t` `uuid`|`sha1`|`const`|`var`|`class`|`func`|`path`|`name`]
+    [`--type`|`-t` `uuid`|`sha1`|`nanoid`|`const`|`var`|`class`|`func`|`path`|`name`]
     [`--count`|`-c` *count*]
     [*hint*]
 
@@ -2337,7 +1847,7 @@ The `ase-meta-mint` skill *mints* an identifier or a name of a requested
 type out of the free-text *hint* formed by the positional arguments. It
 dispatches on `--type` and emits the generated strings as its result.
 
-The two *hash-derived* types are delegated to the `ase_mint` tool of the
+The three *hash-derived* types are delegated to the `ase_mint` tool of the
 `ase` MCP server, which derives them reproducibly instead of guessing
 them:
 
@@ -2350,6 +1860,11 @@ them:
 -   `sha1`:
     the 40-character hexadecimal *SHA-1* digest of the *hint*.
 
+-   `nanoid`:
+    the 10-character, *NanoId*-style *base62* hash of the *hint* (its
+    *SHA-1* digest, *base62*-encoded and truncated), a short but still
+    reproducible identifier.
+
 The six *linguistic* types are derived by the skill itself: the *hint*
 is distilled into its essential words, which are then assembled
 according to the conventions of the type:
@@ -2383,7 +1898,7 @@ a random *UUID V4* without one.
 
 ##  OPTIONS
 
-`--type`|`-t` `uuid`|`sha1`|`const`|`var`|`class`|`func`|`path`|`name`:
+`--type`|`-t` `uuid`|`sha1`|`nanoid`|`const`|`var`|`class`|`func`|`path`|`name`:
     Select the type of the minted identifier or name (default: `uuid`).
 
 `--count`|`-c` *count*:
@@ -2404,7 +1919,7 @@ a random *UUID V4* without one.
 
 ##  SCENARIOS
 
--   You need a stable, reproducible UUID or SHA-1 digest for a concept
+-   You need a stable, reproducible UUID, SHA-1 digest, or short hash for a concept
 -   You need a well-formed constant, variable, function, or class identifier
 -   You need a path component or slug derived from a description
 -   You need a catchy product name for a new component or tool
@@ -2694,100 +2209,6 @@ to the conceptual neighborhood of the topic:
 ❯ /ase-meta-quotes --ground --proximity --count 12 technical debt
 ```
 
-</purpose>
-<purpose name="ase-meta-review">
-
-##  NAME
-
-`ase-meta-review` - Review Staged Changes
-
-##  SYNOPSIS
-
-`ase-meta-review`
-    [`--help`|`-h`]
-    [`--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`)]
-
-##  DESCRIPTION
-
-The `ase-meta-review` skill performs a *holistic*,
-*human-reviewer-style* critique of the *staged* Git changes and emits a
-single *approve* / *reject* **verdict** backed by *prioritized*,
-*severity-tagged*, *line-cited* **findings**. Rather than scanning the
-code mechanically, it first *reconstructs the change's own intent* and
-then judges the diff *as a whole* against that intent - the way an
-experienced reviewer would on a pull request.
-
-The critique spans a fixed set of reviewer *dimensions*: **intent**
-(does the diff do what it set out to, without scope creep or stray
-residue), **correctness** (latent bugs, edge cases, broken
-control/data flow), **design** (fit with the surrounding architecture,
-naming, abstraction level), **clarity** (readability and
-self-documentation for a future reader), **robustness** (error handling,
-resource and concurrency safety), **security** and **performance** (risks
-introduced by the change), **convention** (conformance to the
-project's documented conventions - code style and the plan/spec
-formats described in `AGENTS.md` and the `ase-format-*` meta documents),
-**testing** (inadequate coverage for the change - new or fixed behavior
-left untested, adjacent tests not updated, or existing tests silently
-broken, disabled, or weakened), and **documentation** (user- or
-developer-facing docs - `README`, `CHANGELOG`, help text, or AI
-guidance/meta documents - left stale by the change).
-
-Each finding carries a *severity* - **HIGH**, **MEDIUM**, **LOW**, or
-**ACCEPTED** (a concern that is contractually addressed or accepted as a
-documented priority conflict) - and is *evidence-grounded*: it cites the
-exact `file:line` location it stems from. The overall verdict is
-**REJECT - DEMANDS CHANGES** when any *HIGH* finding remains, and
-**APPROVE** otherwise. The work is performed by a dedicated `ase-meta-review`
-sub-agent so that the silent reading and read-only repository probing
-never leak into the transcript; only the structured verdict and findings
-are rendered.
-
-The skill *complements* rather than duplicates its neighbors:
-`ase-code-lint` flags *mechanical* code-quality issues, `ase-code-analyze`
-inspects *logic and semantics*, `ase-meta-diff` narrates *what changed*
-(with optional coherence, risk, and blast-radius reports), and
-`ase-meta-diaboli` *adversarially challenges a thesis* - whereas
-`ase-meta-review` renders a *reviewer's judgment* on a concrete diff
-before it is committed.
-
-##  OPTIONS
-
--   `--severity`|`-S`=(`LOW`|`MEDIUM`|`HIGH`):
-    Set the *severity floor* (default `LOW`): findings below the chosen
-    threshold are silently suppressed, ordered `LOW` < `MEDIUM` <
-    `HIGH`. The default `LOW` keeps all findings; `ACCEPTED` findings are
-    never suppressed. Surviving findings are rendered in *descending
-    severity* order `HIGH`, `MEDIUM`, `LOW`, `ACCEPTED`. The floor only
-    affects the rendered findings table, not the overall *verdict*, which
-    is always derived from all findings before the floor is applied.
-
-##  ARGUMENTS
-
-The `ase-meta-review` skill takes no positional arguments; it always
-reviews the currently *staged* Git changes.
-
-##  SCENARIOS
-
--   You want the staged changes reviewed like a human reviewer would
--   You want an approve or reject verdict before committing
--   You want severity-tagged, line-cited findings on a diff
--   You want a holistic judgment instead of a mechanical lint
-
-##  EXAMPLES
-
-Review the currently staged changes before committing:
-
-```text
-❯ /ase-meta-review
-```
-
-Review the staged changes, reporting only `MEDIUM` and `HIGH` findings:
-
-```text
-❯ /ase-meta-review -S MEDIUM
-```
-
 </purpose>
 <purpose name="ase-meta-search">
 
@@ -3080,8 +2501,8 @@ derivation but never restricts it: arbitrary non-ASE actions and
 unlisted transitions stay allowed.
 
 The generated skill is *independent* of the ASE plugin installation path:
-it loads the ASE meta definitions through the `ase meta` command instead
-of plugin-relative includes.
+it loads the ASE meta definitions through the `ase util meta` command
+instead of plugin-relative includes.
 
 The skill is *portable* across the supported agent tools, because
 *Anthropic Claude Code*, *GitHub Copilot*, and *OpenAI Codex* differ in
@@ -3098,7 +2519,7 @@ agent tool:
     ``!`...`` construct before the skill content reaches the model. The
     other agent tools receive it verbatim and would silently leave it
     unexpanded, so they instead get an explicit instruction to run
-    `ase meta ...` themselves before anything else.
+    `ase util meta ...` themselves before anything else.
 
 ##  OPTIONS
 
@@ -3155,23 +2576,717 @@ Generate a user-wide skill and overwrite a previous generation:
 ```
 
 </purpose>
-<purpose name="ase-spec-activate">
+<purpose name="ase-repo-changelog">
 
 ##  NAME
 
-`ase-spec-activate` - Activate Specification Know-How
+`ase-repo-changelog` - Update ChangeLog Entries
 
 ##  SYNOPSIS
 
-`ase-spec-activate`
+`ase-repo-changelog`
     [`--help`|`-h`]
-    [*query*]
 
 ##  DESCRIPTION
 
-The `ase-spec-activate` skill activates the know-how about the
-*SpecBook*-based specification (`SPEC`) of the project in the current
-session: it loads the *SpecBook* format contract, reads the *SpecBook*
+The `ase-repo-changelog` skill helps to *complete*, *consolidate*, and
+*sort* the entries of the most recent section of a `CHANGELOG.md`
+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>`
+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`, `arch`, `code`,
+`docs`, `infr`, or `othr`. Entries are grouped and sorted by this
+prefix. The date in the section header is also updated to the current
+date.
+
+##  SCENARIOS
+
+-   You want the `CHANGELOG.md` brought up to date with recent commits
+-   You want changelog entries completed, consolidated, and sorted
+-   You want a tidy changelog section before a release
+
+##  EXAMPLES
+
+Update the most recent ChangeLog section:
+
+```text
+❯ /ase-repo-changelog
+```
+
+</purpose>
+<purpose name="ase-repo-commit">
+
+##  NAME
+
+`ase-repo-commit` - Git Commit Message
+
+##  SYNOPSIS
+
+`ase-repo-commit`
+    [`--help`|`-h`]
+
+##  DESCRIPTION
+
+The `ase-repo-commit` skill helps to *craft* a *concise commit
+message* for the currently staged Git changes. It inspects the
+output of `git diff --cached` and produces a single-line message of
+the form `<type>: <summary>` where *type* is one of `FEATURE`,
+`IMPROVEMENT`, `BUGFIX`, `UPDATE`, `CLEANUP`, or `REFACTOR`, and
+*summary* is a 60-80 character imperative-mood summary without
+trailing period or Markdown formatting.
+
+##  SCENARIOS
+
+-   You want a commit message for the currently staged changes
+-   You want a typed one-line summary derived from the staged diff
+-   You want to commit but cannot phrase what changed
+
+##  EXAMPLES
+
+Craft a commit message for the currently staged changes:
+
+```text
+❯ /ase-repo-commit
+```
+
+</purpose>
+<purpose name="ase-repo-diff">
+
+##  NAME
+
+`ase-repo-diff` - Summarize Diff
+
+##  SYNOPSIS
+
+`ase-repo-diff`
+    [`--help`|`-h`]
+    [`--coherence`|`-c`]
+    [`--risk`|`-r`]
+    [`--blast`|`-b`]
+
+##  DESCRIPTION
+
+The `ase-repo-diff` skill turns a raw Git diff into a *concise*,
+*human-readable* narrative of what changed and why, *grouped by
+intent* (such as *Feature*, *Improvement*, *Bugfix*, *Update*,
+*Cleanup*, or *Refactor*) rather than by file. It inspects the
+*staged* changes (`git diff --cached HEAD`). The result is a compact
+table, one row per intent group, each naming the affected files
+with their per-file `[+N/-M]` line counts - giving you the essence
+of the changes at a glance.
+
+With `--coherence`, the skill additionally *reconstructs the single
+intended change* the diff is trying to accomplish - phrased as one crisp
+*thesis* sentence - and then walks *every* hunk to *flag those that do
+not serve it*: **scope creep** (an unrelated feature or drive-by refactor
+riding along) and **stray debug** (leftover prints, commented-out code, or
+disabled tests). It emits an overall **COHERENT** / **INCOHERENT** verdict
+plus a table of the flagged hunks with what to do with each - keeping the
+diff to a *single logical and coherent change* before it is committed.
+
+With `--risk`, the skill additionally *scores* the same diff against a
+four-axis **coupling-criticality-coverage-reversibility** rubric and
+emits a *graded risk report* - one table row per axis (each scored *1*-*5*
+with a one-line evidence justification drawn from the actual hunks), an
+overall risk band (**LOW**, **MODERATE**, **HIGH**, or **CRITICAL**),
+and one actionable *mitigation* per high-risk axis. The axes combine
+with *equal weights*, and the rubric is deliberately *not tuned* to any
+specific project: every score is backed by cited evidence so it remains
+*overridable*, and the report is *decision support*, not a merge gate.
+
+With `--blast`, the skill additionally renders a *blast-radius map* - a
+Mermaid `flowchart` of the *touched modules* and their *reverse
+dependencies*, plus a *brief impact summary*. It *extracts the touched
+modules* from the changed files, *scans the repository* for the
+first-party code that *imports* or *references* those modules, builds a
+blast-radius graph (touched modules as origin nodes, dependents fanning
+out along the edges), dispatches the rendering to the `ase-meta-diagram`
+sub-agent, and appends a short bullet list of the per-module impact -
+giving a visual sense of *what a diff endangers* before a deeper review.
+
+##  ARGUMENTS
+
+-   `--coherence`, `-c`:
+    In addition to the intent-grouped summary, reconstruct the diff's
+    *single intended change* as one crisp *thesis* sentence and flag
+    *every* hunk that does *not* serve it - *scope creep* or *stray
+    debug* - then emit an overall **COHERENT** / **INCOHERENT** verdict
+    with a table of the flagged hunks.
+
+-   `--risk`, `-r`:
+    In addition to the intent-grouped summary, score the diff against
+    the *coupling-criticality-coverage-reversibility* rubric and emit a
+    *graded risk report* with an overall risk band and per-axis
+    *mitigations*. Scores are equal-weighted, evidence-backed, and
+    deliberately untuned to the project.
+
+-   `--blast`, `-b`:
+    In addition to the intent-grouped summary, render a *blast-radius
+    map* - a Mermaid `flowchart` of the *touched modules* and their
+    *reverse dependencies* - plus a *brief impact summary* of what
+    depends on the touched code and how far the blast reaches.
+
+##  SCENARIOS
+
+-   You want a readable, intent-grouped summary of the staged changes
+-   You want a diff checked for scope creep and stray debug leftovers
+-   You want a graded risk report of a change before committing
+-   You want a blast-radius map of what depends on the touched code
+
+##  EXAMPLES
+
+Summarize the currently staged changes:
+
+```text
+❯ /ase-repo-diff
+```
+
+Summarize the staged changes and append an intent-coherence report:
+
+```text
+❯ /ase-repo-diff --coherence
+```
+
+Summarize the staged changes and append a graded risk report:
+
+```text
+❯ /ase-repo-diff --risk
+```
+
+Summarize the staged changes and append a blast-radius map:
+
+```text
+❯ /ase-repo-diff --blast
+```
+
+</purpose>
+<purpose name="ase-repo-dissect">
+
+##  NAME
+
+`ase-repo-dissect` - Dissect a Change Set
+
+##  SYNOPSIS
+
+`ase-repo-dissect`
+    [`--help`|`-h`]
+    [`--max-parts`|`-m` *count*]
+    [`--staged`|`-s`]
+    [`--dry`|`-d`]
+    [`--force`|`-f`]
+    [*dissect-hint*]
+
+##  DESCRIPTION
+
+The `ase-repo-dissect` skill treats the current Git change set as an
+*epic* and *dissects* it domain-wise and logically into *cohesive
+parts*. Each part is a self-contained unit of change with a single
+coherent purpose, so it can be reviewed and committed *atomically* and
+*independently* of the others.
+
+The change set is captured from the working copy (`git diff`), with
+untracked files folded in *read-only*, or -- under `--staged`/`-s` --
+from the Git index (`git diff --cached HEAD`). The dissection follows a
+strict ruleset: at least *2* and at most *count* parts are derived,
+*every* hunk is assigned to *exactly one* part, mutually dependent hunks
+are kept together, all hunks of one file normally stay in the same part,
+and nothing beyond the actual change set is invented. The cut follows
+the *semantics* of the change, not its technical structure -- a split by
+file, directory, or technical layer is usually *not* the intended one.
+If the change set carries only a single cohesive purpose, it is reported
+as *not dissectable* and nothing is created.
+
+An optional *dissect-hint* steers *how* the change set is split -- which
+changes belong together, along which axis to cut, or how many parts to
+aim at. It is especially useful after a `--dry` run showed an unintended
+dissection. The hint overrides the default grouping, but never the
+ruleset itself.
+
+The derived parts are first reported as a *dissection table* (part
+number, worktree id, scope, and rationale). Then -- unless `--dry` is
+given -- each part's patch is written to a temporary file and applied
+inside a *fresh Git WorkTree* `.ase/worktree/<project-id>-<feature-slug>`,
+whose branch carries the same name and is created from `HEAD`. If a
+`CHANGELOG.md` file exists, a matching entry summarizing that part is
+added *inside* the worktree.
+
+Every part stays *uncommitted*, a failing `git apply` is reported for
+that part while the remaining parts continue, and the *original working
+copy is never mutated*.
+
+Note that the working-copy patch (without `--staged`) is taken relative
+to the Git *index* while the worktrees are created from `HEAD`. So if
+changes are *also* staged, the affected part patches may not apply
+cleanly and are then reported as failed; stage everything and use
+`--staged` in that situation.
+
+##  OPTIONS
+
+-   `--max-parts`|`-m` *count*:
+    Upper bound for the number of derived parts (default: `8`). The
+    lower bound is always `2`, because fewer parts are no dissection.
+
+-   `--staged`|`-s`:
+    Dissect the *staged* changes (the Git index against `HEAD`) instead
+    of the working copy changes. Untracked files are then *not* folded
+    in, because they are by definition not part of the index.
+
+-   `--dry`|`-d`:
+    *Report only* -- print the dissection table but create *no*
+    artifacts at all, so the decision stays fully reversible.
+
+-   `--force`|`-f`:
+    Remove and re-create already existing worktrees and branches of the
+    derived names. Without this option, the skill detects colliding
+    targets *before* writing anything, reports them, and stops with
+    status *targets exist*.
+
+##  ARGUMENTS
+
+-   *dissect-hint*:
+    A free-text hint telling *how* the change set should be split. If
+    omitted, the parts are derived from the change set alone.
+
+The worktree names are *not* argument-driven: they are always derived
+from the *current* project id and the per-part feature slug.
+
+##  SCENARIOS
+
+-   You want a large uncommitted change set split into atomic parts
+-   You want each cohesive part of a diff in its own Git worktree
+-   You want mixed-up changes untangled before committing them
+-   You want a preview of how a change set would be divided
+
+##  EXAMPLES
+
+Dissect the current working copy changes:
+
+```text
+❯ /ase-repo-dissect
+```
+
+Preview the dissection of the staged changes into at most four parts:
+
+```text
+❯ /ase-repo-dissect --staged --dry --max-parts 4
+```
+
+Re-dissect the changes, re-creating the previously created worktrees:
+
+```text
+❯ /ase-repo-dissect --force
+```
+
+Dissect the changes along an explicitly given axis:
+
+```text
+❯ /ase-repo-dissect keep the plugin and tool changes in separate parts
+```
+
+</purpose>
+<purpose name="ase-repo-merge">
+##  NAME
+
+`ase-repo-merge` - Merge a Branch
+
+##  SYNOPSIS
+
+`ase-repo-merge`
+    [`--help`|`-h`]
+    [`--target`|`-t` *branch*]
+    [`--mode`|`-m` `merge`|`rebase`|`squash`]
+    [`--cleanup`|`-c`]
+    *source-branch*
+
+##  DESCRIPTION
+
+The `ase-repo-merge` skill *merges* a Git *source-branch* into a target
+branch and reports the result as a *merge verdict*: `MERGED`,
+`CONFLICT`, or `FAILED`.
+
+Still *uncommitted* changes in the worktree where the source branch is
+checked out are first *committed* with a derived one-line commit
+message of the form `<type>: <summary>`. The source branch is then
+merged inside the worktree where the target branch is checked out,
+which has to be free of uncommitted changes, in one of three modes: a
+regular *merge* with a merge commit (`git merge --no-ff`), a *rebase*
+of the source branch onto the target branch followed by a
+fast-forward (`git rebase` plus `git merge --ff-only`), or a *squash*
+of all source commits into one commit (`git merge --squash`).
+Merge conflicts are *resolved semantically*, honoring the intents of
+both sides and never losing any change, through the same procedure as
+`ase-repo-resolve`. If a conflict is unresolvable, because both
+intents contradict each other or no confident resolution exists, the
+unresolvable conflicts are reported, the merge is *aborted*, the
+target branch is left untouched, and the verdict is `CONFLICT`. Finally, the skill *checks*
+that the source branch is contained in the target branch. It does
+*not* build or test the merge result, so semantically resolved
+conflicts still deserve a review.
+
+On a `CONFLICT` or `FAILED` verdict, the commit of the previously
+uncommitted source changes is *undone* again, so they are uncommitted
+as before (but no longer partially staged).
+
+If the source branch *equals* the target branch, only its uncommitted
+changes are committed. The skill is also used by `ase agent integrator`
+to drive the *Integration* phase of the `enterprise` task lifecycle
+model headless. As the target branch is by default the checked-out
+branch of the working copy of the project, any uncommitted change
+there lets the merge of every task with its own branch fail, and hence
+the task become `DEFERRED`, while for a task with an in-place change
+set it is committed together with that change set. So, when running
+the integrator, keep the working copy clean and do your own work in
+separate worktrees.
+
+##  OPTIONS
+
+-   `--target`|`-t` *branch*:
+    The target branch of the merge (default: `current`, the checked-out
+    branch of the working copy).
+
+-   `--mode`|`-m` `merge`|`rebase`|`squash`:
+    The merge mode (default: `merge`): `merge` creates a merge commit,
+    `rebase` rebases the source branch (rewriting its commits, in its
+    own worktree if it is checked out) onto the target branch and
+    fast-forwards the target branch, and `squash` combines all changes
+    of the source branch into one new commit on the target branch.
+    Conflicts are resolved per rebased commit under `rebase`.
+
+-   `--cleanup`|`-c`:
+    After a successful merge, remove the worktree of the source branch
+    (if any) and delete the merged source branch.
+
+##  ARGUMENTS
+
+-   *source-branch*:
+    The Git branch to merge.
+
+##  SCENARIOS
+
+-   You want a feature branch landed on the checked-out branch
+-   You want the uncommitted result of a worktree committed and merged
+-   You want merge conflicts resolved instead of hand-editing them
+
+##  EXAMPLES
+
+Merge the branch `feature-x` into the checked-out branch:
+
+```text
+❯ /ase-repo-merge feature-x
+```
+
+Merge the branch `feature-x` into `develop` and remove it afterwards:
+
+```text
+❯ /ase-repo-merge --target develop --cleanup feature-x
+```
+
+Squash the branch `feature-x` into one commit on the checked-out branch:
+
+```text
+❯ /ase-repo-merge --mode squash feature-x
+```
+
+</purpose>
+<purpose name="ase-repo-resolve">
+
+##  NAME
+
+`ase-repo-resolve` - Resolve Merge Conflicts
+
+##  SYNOPSIS
+
+`ase-repo-resolve`
+    [`--help`|`-h`]
+    [`--dir`|`-d` *dir*]
+    [`--safe`|`-s`]
+    [`--interactive`|`-i`]
+    [*path* ...]
+
+##  DESCRIPTION
+
+The `ase-repo-resolve` skill *resolves* the Git merge conflicts of a
+working directory and reports the result as a *resolve verdict*:
+`RESOLVED`, `PARTIAL`, `NONE`, or `FAILED`.
+
+It handles every *unmerged* state of the Git index -- left by an
+in-progress `git merge`, `git rebase`, `git cherry-pick`, `git revert`,
+or by `git stash apply` -- and additionally files carrying conflict
+markers *without* an unmerged index entry, e.g., left by `patch
+--merge`. Reject files (`*.rej`) of `patch` are escalated, but never
+touched.
+
+Every conflict hunk is resolved *semantically*: the intents of both
+sides are determined from the commits, the base version, and the
+surrounding code, and the hunk is resolved so that *both* intents are
+honored. Trivial, independent, and compatible changes are combined,
+while a hunk whose intents *contradict* each other, or for which no
+confident resolution exists, is *kept as-is* including its conflict
+markers and *escalated* to the user. Files with only some unresolvable
+hunks are resolved *partially* and stay unmerged. Non-content conflicts
+(binary, submodule, modify/delete, rename, delete/delete) are resolved
+only if their intent is unambiguous.
+
+The skill is very careful to *never lose* any change: every touched
+file is first backed up into the `ase-resolve` directory inside the Git
+directory, and every resolved hunk is checked to still reflect all
+changes of both sides relative to the base; a hunk failing this check
+is restored with its conflict markers and escalated. The backups are
+removed on a `RESOLVED` verdict and kept otherwise.
+
+Fully resolved unmerged files are staged. On a `RESOLVED` verdict, the
+in-progress operation is *continued* (e.g., `git merge --continue`),
+and, if this stops at the next conflicting commit of a rebase,
+cherry-pick, or revert, those conflicts are resolved, too. The skill
+does *not* build or test the result, so the resolved conflicts still
+deserve a review.
+
+The same resolution procedure is used by `ase-repo-merge` for the
+conflicts of its merge.
+
+##  OPTIONS
+
+-   `--dir`|`-d` *dir*:
+    The Git working directory whose conflicts are resolved (default:
+    `.`, the current working directory).
+
+-   `--safe`|`-s`:
+    Never touch non-content conflicts (binary, submodule,
+    modify/delete, rename, delete/delete), but always escalate them.
+
+-   `--interactive`|`-i`:
+    Instead of directly escalating an unresolvable hunk, show it and
+    let the user choose `OURS`, `THEIRS`, `BOTH`, `KEEP` (escalate), or
+    describe a manual resolution. Ignored when running headless.
+
+##  ARGUMENTS
+
+-   *path* ...:
+    Restrict the resolution to the conflicted files equal to or below
+    the given paths. The in-progress operation is then continued only
+    if no conflicted files remain elsewhere.
+
+##  SCENARIOS
+
+-   You ran into merge conflicts during a merge, rebase, or cherry-pick
+-   You applied a stash or a patch and got conflict markers
+-   You want conflicts resolved without risking the loss of any change
+
+##  EXAMPLES
+
+Resolve all conflicts of the current working directory:
+
+```text
+❯ /ase-repo-resolve
+```
+
+Resolve the conflicts below `src/`, deciding unresolvable hunks
+interactively:
+
+```text
+❯ /ase-repo-resolve --interactive src/
+```
+
+</purpose>
+<purpose name="ase-repo-review">
+
+##  NAME
+
+`ase-repo-review` - Review Changes
+
+##  SYNOPSIS
+
+`ase-repo-review`
+    [`--help`|`-h`]
+    [`--severity`|`-S`=(`AUTO`|`LOW`|`MEDIUM`|`HIGH`)]
+    [`--thorough`|`-t`]
+    [`--staged`]
+    [`--unstaged`]
+    [`--branch`|`-b` *branch*]
+    [`--commit`|`-c` *commit*]
+
+##  DESCRIPTION
+
+The `ase-repo-review` skill performs a *holistic*,
+*human-reviewer-style* critique of the *staged* Git changes (or, with
+`--unstaged`, of the *unstaged* and *untracked* changes, with both
+`--staged` and `--unstaged`, of *all* uncommitted changes, with
+`--branch`, of the changes of a *branch* against its *base*, or, with
+`--commit`, of a *single commit*) and emits a single
+*approve* / *reject* **verdict** backed by *prioritized*,
+*severity-tagged*, *line-cited* **findings**. Rather than scanning the
+code mechanically, it first *reconstructs the change's own intent* and
+then judges the diff *as a whole* against that intent - the way an
+experienced reviewer would on a pull request.
+
+The critique spans a fixed set of reviewer *dimensions*: **intent**
+(does the diff do what it set out to, without scope creep),
+**propagation** (the change fully and consistently carried over to call
+sites, types, schemas, registries, catalogs, and analogous sibling
+places, with matching contracts and terminology, and without orphans left
+behind), **coverage** (all special and edge cases handled, like empty
+values, boundaries, error paths, and all variants), **residue** (debug
+output, commented-out code, scaffolding, temporary files, build output,
+or secrets which do not belong into the change), **correctness**
+(latent bugs, broken control/data flow), **design** (fit with the surrounding architecture,
+naming, abstraction level), **clarity** (readability and
+self-documentation for a future reader), **robustness** (error handling,
+resource and concurrency safety), **security** and **performance** (risks
+introduced by the change), **convention** (conformance to the
+project's documented conventions - code style and the plan/spec
+formats described in `AGENTS.md` and the `ase-format-*` meta documents),
+**testing** (inadequate coverage for the change - new or fixed behavior
+left untested, adjacent tests not updated, or existing tests silently
+broken, disabled, or weakened), and **documentation** (user- or
+developer-facing docs - `README`, `CHANGELOG`, help text, or AI
+guidance/meta documents - left stale by the change).
+
+Each finding carries a *severity* - **HIGH**, **MEDIUM**, **LOW**, or
+**ACCEPTED** (a concern that is contractually addressed or accepted as a
+documented priority conflict) - and is *evidence-grounded*: it cites the
+exact `file:line` location it stems from. The overall verdict is
+**REJECT - DEMANDS CHANGES** when any *HIGH* finding remains, and
+**APPROVE** otherwise. The work is performed by a dedicated `ase-repo-review`
+sub-agent so that the silent reading and read-only repository probing
+never leak into the transcript; only the structured verdict and findings
+are rendered.
+
+The skill *complements* rather than duplicates its neighbors:
+`ase-code-lint` flags *mechanical* code-quality issues, `ase-code-analyze`
+inspects *logic and semantics*, `ase-repo-diff` narrates *what changed*
+(with optional coherence, risk, and blast-radius reports), and
+`ase-meta-diaboli` *adversarially challenges a thesis* - whereas
+`ase-repo-review` renders a *reviewer's judgment* on a concrete diff
+before it is committed or merged.
+
+##  OPTIONS
+
+-   `--severity`|`-S`=(`AUTO`|`LOW`|`MEDIUM`|`HIGH`):
+    Set the *severity floor* (default `AUTO`): findings below the chosen
+    threshold are suppressed, ordered `LOW` < `MEDIUM` < `HIGH`. The
+    default `AUTO` means `MEDIUM` for a project with `grey` boxing and
+    `LOW` (keep all findings) otherwise; an explicitly given floor always
+    wins over the boxing. `ACCEPTED` findings are never suppressed, and
+    the number of suppressed findings is always reported. Surviving
+    findings are rendered in *descending severity* order `HIGH`,
+    `MEDIUM`, `LOW`, `ACCEPTED`. The floor only affects the rendered
+    findings table, not the overall *verdict*, which is always derived
+    from all findings before the floor is applied.
+
+-   `--thorough`|`-t`:
+    Review *exhaustively* instead of reporting only a *few* high-signal
+    findings: report every well-grounded concern, including minor nits,
+    and additionally *plausible* concerns whose impact cannot be fully
+    proven, marked with "*Plausible:*" and rated at most `MEDIUM`.
+
+-   `--staged`:
+    Review the *staged* changes of the working copy. This is the default
+    if neither `--unstaged`, `--branch`, nor `--commit` is given.
+    Combined with `--unstaged`, review *all* uncommitted changes.
+    Combined with `--branch`, additionally review the staged changes of
+    the worktree where the *branch* is checked out.
+
+-   `--unstaged`:
+    Review the *unstaged* changes and the *untracked* files of the
+    working copy (except *ASE*'s own state below `.ase/`) instead of the
+    *staged* changes. Combined with `--staged`, review *all* uncommitted
+    changes. Combined with `--branch`, additionally review the unstaged
+    changes and untracked files of the worktree where the *branch* is
+    checked out.
+
+-   `--branch`|`-b` *branch*:
+    Review the commits of *branch* (any Git revision) since its fork
+    point from its *base*, instead of the *staged* changes. The base is
+    determined automatically as the local branch with the *nearest* fork
+    point (preferring the checked-out branch on a tie) and is reported
+    before the review. The commit messages are checked for mismatches
+    against the diff.
+
+-   `--commit`|`-c` *commit*:
+    Review the single *commit* (any Git revision) against its first
+    parent, instead of the *staged* changes. Its commit message is
+    checked for mismatches against the diff. This option cannot be
+    combined with `--branch`, `--staged`, or `--unstaged`.
+
+##  ARGUMENTS
+
+The `ase-repo-review` skill takes no positional arguments; it reviews the
+currently *staged* Git changes, with `--unstaged` the unstaged and
+untracked changes, with both `--staged` and `--unstaged` all uncommitted
+changes, with `--branch` a branch against its base, or with `--commit` a
+single commit.
+
+##  SCENARIOS
+
+-   You want the staged changes reviewed like a human reviewer would
+-   You want an approve or reject verdict before committing
+-   You want severity-tagged, line-cited findings on a diff
+-   You want a holistic judgment instead of a mechanical lint
+-   You want your not yet staged changes reviewed
+-   You want an exhaustive review of all uncommitted changes
+-   You want a feature branch reviewed before merging it
+-   You want a single, already committed change reviewed
+
+##  EXAMPLES
+
+Review the currently staged changes before committing:
+
+```text
+❯ /ase-repo-review
+```
+
+Review the staged changes, reporting only `MEDIUM` and `HIGH` findings:
+
+```text
+❯ /ase-repo-review -S MEDIUM
+```
+
+Review the unstaged and untracked changes only:
+
+```text
+❯ /ase-repo-review --unstaged
+```
+
+Review all uncommitted changes exhaustively, reporting all findings:
+
+```text
+❯ /ase-repo-review --staged --unstaged -t -S LOW
+```
+
+Review the branch `feature` against its base, including the uncommitted
+changes of its worktree:
+
+```text
+❯ /ase-repo-review -b feature --staged --unstaged
+```
+
+Review the last commit:
+
+```text
+❯ /ase-repo-review -c HEAD
+```
+
+</purpose>
+<purpose name="ase-spec-activate">
+
+##  NAME
+
+`ase-spec-activate` - Activate Specification Know-How
+
+##  SYNOPSIS
+
+`ase-spec-activate`
+    [`--help`|`-h`]
+    [*query*]
+
+##  DESCRIPTION
+
+The `ase-spec-activate` skill activates the know-how about the
+*SpecBook*-based specification (`SPEC`) of the project in the current
+session: it loads the *SpecBook* format contract, reads the *SpecBook*
 schema configuration of the project (the schema files configured via
 `project.artifact.spec.schema`, where the entry `std` -- also the default
 -- names the standard schema bundled with *ASE*), and resolves the list
@@ -3240,10 +3355,14 @@ Activate and directly answer a question about the specification:
 
 `ase-spec-edit`
     [`--help`|`-h`]
+    [`--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*]
 
@@ -3264,11 +3383,12 @@ WHAT and its implementation-detail HOW parts), *discovering* (resolve
 the `SPEC` artifacts, read the *SpecBook* schema configuration of the
 project, and read the specification artifacts related to the query),
 *grilling* (optionally stress-test the query with rounds of questions),
-*implementing* (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 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 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
+approach selection close with an `EDIT TODO` box showing the established
+`WHAT` and `HOW` information.
 
 The change set stays strictly restricted to the `SPEC` artifacts -- the
 artifact kinds `CODE`, `DOCS`, `TASK`, `INFR`, and `OTHR` are never
@@ -3278,6 +3398,15 @@ timestamp refreshed.
 
 ##  OPTIONS
 
+-   `--approach`|`-a`:
+    Before applying the change set, propose one or more specification
+    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
@@ -3285,11 +3414,16 @@ timestamp refreshed.
     (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-3 word `TOPIC` hint. The questions of a
-    round are sorted by descending focus area importance (`DOMAIN`,
-    `INTERFACE`, `ARCHITECTURE`, `IMPLEMENTATION`) and are announced
-    together below a `GRILLING ROUND K/L` line (the round numbering is
+    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-3 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 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
@@ -3298,15 +3432,54 @@ timestamp refreshed.
     whose question asks for the combined answer to all (or a subset) of
     the listed questions and whose only answer options are the fixed
     `SKIP GRILLING` (skip the remaining grilling) and `STOP SKILL` (stop
-    the skill) ones, plus free-text input. The answers are merged back
-    into the WHAT and HOW parts of the query. Without `--grill`, no
-    questions are asked at all.
+    the skill) ones, plus free-text 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 the edited specification by validating it via *SpecBook*
@@ -3315,14 +3488,22 @@ timestamp refreshed.
     the last round are listed as `REMAINING DIAGNOSTICS`. Without
     `--verify`, strictly no validation 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. Under `--verify`,
-    the validation then runs as the `ase spec lint` command inside the
-    worktree.
+-   `--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. Under
+    `--verify`, 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
+    worktree name or the first query word.
 
 -   `--loop`|`-l`:
     Loop the whole state cycle: after each iteration, ask for the next
@@ -3343,6 +3524,7 @@ timestamp refreshed.
 -   You want `SPEC` changes without the task plan ceremony
 -   You want the query stress-tested by grilling before the spec is edited
 -   You want specification edits validated by SpecBook linting
+-   You want the change set to land on a specific Git branch or worktree
 
 ##  EXAMPLES
 
@@ -3358,10 +3540,24 @@ Grill the query with two rounds first, then edit and validate:
 ❯ /ase-spec-edit -g -r 2 -v split the Event entity into Event and EventSeries
 ```
 
+Let the user pick one of several specification approaches first, then
+edit:
+
+```text
+❯ /ase-spec-edit -a model the access permissions of the personas
+```
+
+Grill the query exclusively from the domain perspective, grounded in
+the project artifacts and the Internet/Web, then edit:
+
+```text
+❯ /ase-spec-edit -g -p domain -G add recurring events to the Event model
+```
+
 Loop over multiple specification edits inside a dedicated Git worktree:
 
 ```text
-❯ /ase-spec-edit -l -w
+❯ /ase-spec-edit -l -w event-series
 ```
 
 </purpose>
@@ -3666,6 +3862,123 @@ specification as a unified diff, without applying it:
 ❯ /ase-sync-reconcile -d -t CODE -s SPEC
 ```
 
+</purpose>
+<purpose name="ase-task-assign">
+
+##  NAME
+
+`ase-task-assign` - Assign a Task Plan
+
+##  SYNOPSIS
+
+`ase-task-assign`
+    [`--help`|`-h`]
+    [*id*`:`] *assignee*
+
+##  DESCRIPTION
+
+The `ase-task-assign` skill assigns a *task plan* to an *assignee*, i.e.
+sets its `Assignee:` frontmatter key, via the `ase_task_assign` MCP tool,
+leaving its `Modified:` key alone, as that key tracks changes of the plan
+body only. Additionally, it *accounts* the *AI usage* of the session onto
+the task:
+
+-   Assigning the task to *oneself* (`me` or the current user id) opens
+    the *usage window* of the task, or attaches the session to an already
+    open one (e.g. of a previous session). From then on, all turns of the
+    session are accounted: the AI request time, the cache read, cache
+    write, input, and output tokens, and the costs, as reported by the
+    agent tool via *OpenTelemetry* to the ASE service, plus, in addition,
+    the human time (the whole real time of the window, as the engineer
+    costs money even while waiting for the AI) and its costs at the
+    hourly rate of the assignee in `telemetry.prices.hr` (default: 110 USD).
+
+-   Assigning the task to *anybody else*, or to *nobody* with `none`
+    (removing the `Assignee:` key), *gives it back*: it closes the usage
+    window and, after a grace period of 10 seconds for late telemetry,
+    adds the accumulated usage to the usage attachment of the task
+    (`Type: application/yaml; kind="usage"`), whose YAML data carries the
+    amounts `time: { ai, hr, real }` (minutes), `token: { cread, cwrite,
+    input, output }` (counts), and `cost: { ai, hr }` (USD). Each
+    booking *adds* to the existing amounts, atomically, so concurrent
+    changes of the task (e.g. by the agents of `ase agent`) are never lost.
+
+A usage window also closes and books when its last session *ends*, and
+when the `Assignee:` of the task is changed *elsewhere* (e.g. on the task
+board) while the task is the current task of the session. Conversely,
+changing the `Assignee:` of a task to oneself *elsewhere* (e.g. on the
+task board) opens its usage window, too, and attaches every session of
+the project whose current task it is (also a session switching to it,
+or starting with it, later on), with the window starting *paused*, i.e.,
+accounting from the next AI request of its sessions on. An *unassigned*
+task is even accounted *implicitly*, without any assignment: while it is
+the current task of a session, the session is attached to its usage
+window in the same way, until the session switches to another task, the
+task gets assigned to anybody else, or the session ends (configurable via
+`telemetry.implicit`, default: `true`, never for task `default`), so
+explicitly assigning a task to oneself is needed only for claiming it,
+e.g. against the agents of `ase agent`. Long windows
+additionally book every `telemetry.service.interval` minutes (default: 10).
+Without any AI request for `telemetry.service.idle` minutes (default: 30),
+a usage window *pauses*, and the next AI request (of any kind, not just
+ASE skills) silently *resumes* it, so forgetting a task assigned to
+oneself does not account an idle session endlessly. A usage window without
+any AI request for 7 days is closed and booked.
+
+The accounting is *opt-in*: it requires the configuration key
+`telemetry.enabled` to be `true` (via `ase config set telemetry.enabled
+true`) and the telemetry export of the agent tool to be activated once
+via `ase setup telemetry activate --tool` *tool*, otherwise only the
+assignee is set and a `NOTICE` is reported. If *id*`:` is omitted, the *current* task id
+(inherited from the session context) is used, otherwise, on a successful
+assignment to *oneself*, the current task id of the session is switched
+to *id*.
+
+##  ARGUMENTS
+
+-   *id*`:`:
+    The unique identifier of the task plan, with a trailing colon.
+    If omitted, the current task id is used.
+
+-   *assignee*:
+    The assignee: `me` for oneself, `none` for nobody, or any other
+    name of a human or agent. If the configuration key `project.users`
+    lists the known users, a name which is neither one of them nor the
+    name of an agent present at the agent relay is still assigned, but
+    reported with a `NOTICE`.
+
+##  SCENARIOS
+
+-   You start working on a task and want its AI usage tracked
+-   You hand a task over to a colleague or an agent, booking your usage
+-   You want to know the AI time, tokens, and costs spent on a task
+
+##  EXAMPLES
+
+Take the current task plan and track the AI usage of the session:
+
+```text
+❯ /ase-task-assign me
+```
+
+Take a specific task plan:
+
+```text
+❯ /ase-task-assign hello: me
+```
+
+Give the task plan back to a colleague, booking the AI usage:
+
+```text
+❯ /ase-task-assign alice
+```
+
+Unassign the task plan, booking the AI usage:
+
+```text
+❯ /ase-task-assign hello: none
+```
+
 </purpose>
 <purpose name="ase-task-condense">
 
@@ -3686,13 +3999,15 @@ The `ase-task-condense` skill *compresses* the wording of an existing
 task plan to make it require as little reading as possible, while
 keeping *all semantics fully preserved and unchanged*. It loads the
 current (or given) plan, applies a self-contained, telegrapher-like
-"remove-fluff" ruleset to the *free-text* parts only (the `**WHAT**` /
-`**WHY**` prose and each bullet's specification text), and writes the
-shorter plan back via `ase_task_save`.
-
-The plan *structure* is never altered: all headings, section markers,
-`- **<aspect>**:` bullet labels, code spans, technical terms, file
-paths, numbers, and severities are kept exactly. Only genuinely
+"remove-fluff" ruleset to the *free-text* parts only (the text of each
+`DOM`, `IFC`, `ARC`, `IMP`, `REG`, and `CON` bullet point), and writes
+the shorter plan back via `ase_task_save`.
+
+The plan *structure* is never altered: the frontmatter, all headings,
+the `SPECIFICATION (WHAT)`, `DESIGN (HOW)`, and `VERIFICATION (WHEN)`
+sections, the `- [ ] DOM:`-style bullet prefixes with their checkbox
+states, all attachments, code spans, technical terms, file paths,
+numbers, and severities are kept exactly. Only genuinely
 redundant bullets may be merged, and a shortening that would change
 meaning is always rejected in favor of the longer wording. The condense
 ruleset *overrides* the active session persona, so the plan is compressed
@@ -3703,8 +4018,8 @@ further reduction is possible, the plan is left untouched (including its
 `Modified:` frontmatter timestamp) and reported as *already condensed*.
 
 After condensing, the user is asked whether to stop or hand off to
-`ase-task-edit`, `ase-task-implement`, or `ase-task-preflight`, unless
-`--next` pre-selects this choice.
+`ase-task-edit` or `ase-task-implement` (optionally with `--draft`),
+unless `--next` pre-selects this choice.
 
 ##  OPTIONS
 
@@ -3717,7 +4032,7 @@ After condensing, the user is asked whether to stop or hand off to
     Recognized tokens at this skill: `none` (default, interactive
     answer required), `DONE` (stop), `EDIT` (hand off to
     `ase-task-edit`), `IMPLEMENT` (hand off to `ase-task-implement`),
-    or `PREFLIGHT` (hand off to `ase-task-preflight`). Example:
+    or `DRAFT` (hand off to `ase-task-implement --draft`). Example:
     `--next EDIT,DONE` condenses, hands off to editing, and the editing
     loop will exit immediately.
 
@@ -3820,8 +4135,9 @@ it can be implemented, reviewed, and committed entirely on its own.
 
 The dissection follows a strict ruleset: at least *2* and at most
 *count* parts are derived, *every* bullet point of the epic's
-`##  CHANGES` and `##  VERIFICATION` sections is assigned to *exactly
-one* part, mutually dependent bullet points are kept together, and
+`##  SPECIFICATION (WHAT)`, `##  DESIGN (HOW)`, and
+`##  VERIFICATION (WHEN)` sections is assigned to *exactly one* part,
+mutually dependent bullet points are kept together, and
 nothing beyond the epic's own content is invented. A bullet point which
 itself covers *multiple* domains is *split* into fragments, which are
 then assigned individually -- together they still reproduce the original
@@ -3840,9 +4156,11 @@ never the ruleset itself.
 The derived parts are first reported as a *dissection table* (part
 number, sub-task id, scope, and rationale). Then -- unless `--dry` is
 given -- each part is materialized as its own *complete* sub-task plan
-(with its own `##  CONTEXT`, `##  CHANGES`, and `##  VERIFICATION`
-sections) and persisted under the task id `<task-id>-<feature-slug>`.
-The epic plan itself always stays *untouched*.
+(with its own `##  SPECIFICATION (WHAT)`, `##  DESIGN (HOW)`, and
+`##  VERIFICATION (WHEN)` sections, grouped under the epic via its
+`Group:` frontmatter key) and persisted under the task id
+`<task-id>-<feature-slug>`. The epic plan itself always stays
+*untouched*.
 
 ##  OPTIONS
 
@@ -3852,9 +4170,7 @@ The epic plan itself always stays *untouched*.
 
 -   `--dry`|`-d`:
     *Report only* -- print the dissection table but create *no*
-    artifacts at all, so the decision stays fully reversible. Note that
-    this meaning differs from `--dry`/`-d` in `ase-code-craft`, where it
-    instead omits the `##  VERIFICATION` section of the composed plan.
+    artifacts at all, so the decision stays fully reversible.
 
 -   `--force`|`-f`:
     Overwrite already existing sub-task plans. Without this option, the
@@ -3914,101 +4230,329 @@ Dissect a specific task plan with a hint:
 ```
 
 </purpose>
-<purpose name="ase-task-edit">
+<purpose name="ase-task-edit">
+
+##  NAME
+
+`ase-task-edit` - Iteratively Edit a Task Plan
+
+##  SYNOPSIS
+
+`ase-task-edit`
+    [`--help`|`-h`]
+    [`--plan`|`-p` *option*]
+    [`--mode`|`-m` `auto`|`craft`|`refactor`|`resolve`|`specify`]
+    [`--approach`|`-a`]
+    [`--unverified`|`-u`]
+    [`--next`|`-n` *option*[,...]]
+    [*id* | *id*: *instruction* | *instruction* | *issue-id*]
+
+##  DESCRIPTION
+
+The `ase-task-edit` skill establishes and refines a *task plan* purely
+through a *chat-driven loop*. The user steers each round via an
+interactive dialog that offers continued refinement, finalization, or
+hand-off to implementation or draft. It covers the planning of all
+kinds of change: crafting a new feature, refactoring the code base,
+resolving a problem, and specifying.
+
+A newly generated plan is grounded in the relevant specification
+(`SPEC`), source code (`CODE`), and infrastructure (`INFR`) files of the
+project: it names the actual files and symbols to change, the actual
+build, lint, and test procedures, and a `CHANGELOG.md` entry if such a
+file exists.
+
+Before a new plan is generated, the skill determines its *kind of
+change* (stored in the `Kind:` key of the plan) and internalizes the
+corresponding tenets (for example KISS, YAGNI, and DRY for crafting,
+or Surgical Changes and Origin Proximity for resolving). For a
+resolution, it first reports the `PROBLEM CONTEXT` and `PROBLEM
+DETAILS`. Under `--approach`, it then proposes one or more *approaches*
+with pros and cons, recommends one of them, and lets the user pick the
+preferred one via an interactive dialog, and the new plan is then
+composed along the chosen approach.
+
+If the current task is `default` and a new plan is generated from an
+*instruction*, a new task id is allocated from the instruction
+according to the task id scheme of the project, so the plan does not
+end up under `default`.
+
+Attachments in the plan's backmatter are never removed by a refinement.
+A refinement which changes an attachment refreshes the attachment's
+`Modified:` key; a refinement which changes the plan body refreshes the
+`Modified:` key of the frontmatter (which tracks body changes only, so
+a refinement of frontmatter keys alone leaves it untouched); both use
+the same value. An implementation draft (an attachment block of type
+`text/x-diff; charset=utf-8; kind="draft"`, produced by
+`ase-task-implement --draft`) whose `Modified:` key is absent or older
+than the frontmatter's is *stale*: it is reported with a warning after
+each rendering of the plan, together with a hint that
+`ase-task-implement --draft` has to be run again to re-create the
+draft for the changed plan, as `ase-task-integrate --draft` refuses a
+stale draft.
+
+##  OPTIONS
+
+-   `--plan`|`-p` *option*:
+    Automatically answer the user dialog for the plan refinement
+    with *option*, which can be either `none` (default, interactive
+    answer required), `OVERWRITE` (overwrite an existing plan
+    with *instruction*), `REFINE` (refine the existing plan with
+    *instruction*), or `PRESERVE` (preserve the existing plan by
+    ignoring *instruction* and stopping skill processing).
+
+-   `--mode`|`-m` `auto`|`craft`|`refactor`|`resolve`|`specify`:
+    Select the kind of change of the plan: `craft` (`CRAFTING`),
+    `refactor` (`REFACTORING`), `resolve` (`RESOLVING`), or `specify`
+    (`SPECIFYING`). It selects the tenets internalized when the plan is
+    generated or refined and sets the `Kind:` key of the plan, also on
+    a refinement. The default `auto` infers the kind of a new plan from
+    the *instruction*, uses `RESOLVING` for an *issue-id* (also on a
+    refinement), and otherwise leaves the `Kind:` key of an existing
+    plan as it is and honors its tenets.
+
+-   `--approach`|`-a`:
+    Before a new plan is composed, propose one or more crafting,
+    refactoring, resolution, or specification 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 new
+    plan is then composed along the chosen approach. Without
+    `--approach`, no approaches are determined at all.
+
+-   `--unverified`|`-u`:
+    Generate any *new* plan *without* the `##  VERIFICATION (WHEN)` section.
+    Applies only to freshly generated plans, not to existing plans
+    loaded from disk. When `ase-task-implement` later applies such
+    a plan, it strictly skips the entire verification phase (no
+    build, tests, linter, type-checker, or program execution) once
+    the source files have been modified.
+
+-   `--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
+    chronological list* of tokens; each iteration of the planning
+    loop consumes the *first* token of the list, and on hand-off
+    (`IMPLEMENT` / `DRAFT`) any remaining tokens are *forwarded*
+    (via `--next`) to the downstream skill so an entire pipeline can
+    be pre-scripted in one shot. Recognized tokens at this skill:
+    `none` (default, interactive answer required), `DONE` (no next
+    step), `GRILL` (hand-over to `ase-task-grill`), `DRAFT`
+    (hand-over to `ase-task-implement --draft`), or `IMPLEMENT` (hand-over to
+    `ase-task-implement`). Example: `--next GRILL,DONE` hands the plan
+    off to grilling and forwards `DONE` so grilling exits without asking.
+
+##  ARGUMENTS
+
+-   *id* | *id*: *instruction* | *instruction* | *issue-id*:
+    Edit the task with the unique identifier *id* (default: the current
+    task). Optionally, *instruction* either gives instructions for
+    creating a new task or gives instructions for refining an existing
+    task. Instead, a bare *issue-id* (like `P1`, `T1`, or
+    `<prefix>-P1`), previously reported by `ase-code-analyze` or
+    `ase-arch-analyze`, uses the description of this issue as the
+    *instruction* (also as *id*: *issue-id*), and the issue is removed
+    once the plan is saved. If no such issue exists, *issue-id* is
+    treated as a task *id* resp. as an *instruction*.
+
+##  SCENARIOS
+
+-   You want a task planned through chat-driven refinement
+-   You want a plan created or refined round by round
+-   You want approaches with pros and cons before a plan is composed
+-   You want a plan to craft a feature, refactor code, or resolve a problem
+-   You want an analyzer issue like `P1` turned into a plan
+-   You want plan refinement with hand-off to draft or implementation
+
+##  EXAMPLES
+
+Edit the current task:
+
+```text
+❯ /ase-task-edit
+```
+
+Create a new task under id `hello`:
+
+```text
+❯ /ase-task-delete hello
+❯ /ase-task-edit hello: new "ase hello" CLI command which prints
+  a nice "Hello World!" to the terminal in color blue.
+```
+
+Further refine the task under id `hello`:
+
+```text
+❯ /ase-task-edit hello: change the color to red.
+```
+
+Plan the resolution of the analyzer issue `P1` along an interactively
+chosen approach, and directly hand off to implementation:
+
+```text
+❯ /ase-task-edit --approach --next IMPLEMENT P1
+```
+
+Plan a refactoring under the id `cleanup`:
+
+```text
+❯ /ase-task-edit -m refactor cleanup: extract HTTP client into its own class
+```
+
+</purpose>
+<purpose name="ase-task-estimate">
 
 ##  NAME
 
-`ase-task-edit` - Iteratively Edit a Task Plan
+`ase-task-estimate` - Estimate the Effort of a Task Plan
 
 ##  SYNOPSIS
 
-`ase-task-edit`
+`ase-task-estimate`
     [`--help`|`-h`]
-    [`--plan`|`-p` *option*]
-    [`--dry`|`-d`]
-    [`--next`|`-n` *option*[,...]]
-    [*id* | *id*: *instruction* | *instruction*]
+    [`--force`|`-f`]
+    [`--dry-run`|`-d`]
+    [`--all`|`-a`]
+    [*id* ...]
 
-##  DESCRIPTION
+`ase-task-estimate`
+    `--calibrate`|`-c`
+    [`--save`|`-s`]
 
-The `ase-task-edit` skill establishes and refines a *task plan* purely
-through a *chat-driven loop*. The user steers each round via an
-interactive dialog that offers continued refinement, finalization, or
-hand-off to implementation or preflight.
+##  DESCRIPTION
 
-When a refinement changes the plan text while an `IMPLEMENTATION
-DRAFT` section (produced by `ase-task-preflight`) exists, that section
-became *stale* and is *removed* -- together with the `preflighted`
-value of the `Properties:` frontmatter key -- and a hint is emitted
-that `ase-task-preflight` has to be run again to re-create the draft
-for the changed plan.
+The `ase-task-estimate` skill *estimates* the effort of task plans and
+stores it in their `Effort:` frontmatter key. The effort is the expected
+*human time* of the *entire* lifecycle of a task (including its
+planning), matching the human time `time.hr` booked on the usage
+attachment of the task (see `ase-task-assign`), expressed as one of the
+T-shirt sizes `XS`, `S`, `M`, `L`, or `XL`. The sizes are bands on a
+*logarithmic* scale with the upper bounds `15`, `60`, `240`, and `960`
+human minutes for `XS` to `L` (configuration `project.task.effort.scale`),
+while `XL` is open-ended. A task without an `Effort:` key is *not
+estimated*.
+
+The estimation of a plan combines:
+
+-   an *attention score*: the weighted number of the distinct
+    requirements, behaviors, or changes stated by its checklist items
+    (`DOM` 5.0, `IFC` 4.0, `ARC` 3.0, `IMP` 1.0, `REG` 0.5, `CON` 1.0),
+    converted via `project.task.effort.factor` (default: `1`) human
+    minutes per point,
+
+-   a *volume score*: the code impact of its `ARC` and `IMP` items,
+    predicted read-only from the plan and the code base (never measured
+    from an already existing change set), converted via
+    `project.task.effort.file` (default: `1`) human review minutes per
+    touched file and `project.task.effort.line` (default: `0.025`)
+    human minutes per predicted changed line, which also cover the edge
+    cases and polishing no plan describes, where a newly written line
+    weighs three times a changed one,
+
+-   a *risk surcharge*: 20% more per applying risk out of `dependency`,
+    `ambiguity`, `untested`, `concurrency`, `security`, and
+    `persistence`, but at most 40% in total, where risks applying to
+    virtually every task of the project do not count,
+
+-   an *iteration multiplier*: `project.task.effort.iteration`
+    (default: `2.5`) times the minutes for a task whose main
+    deliverable is an interactive or visual user interface, as such
+    work needs many rounds of post-adjustment,
+
+-   a *plausibility check*: a comparable realization already existing
+    in the code base, whose deviating size lowers the reported
+    *confidence*, and
+
+-   *analogues*: finished tasks with an effort and a usage attachment,
+    whose disagreement lowers the reported *confidence*.
+
+Cancelled (`[-]`) and deferred (`[>]`) items never count. The skill
+reports the size, the confidence, and the main drivers of each
+estimation, and for `XL` additionally warns and suggests splitting the
+task via `ase-task-dissect` -- an `XL` effort never blocks the
+lifecycle.
+
+The effort is *bound* to the plan content it was given for: once the
+plan content changes, the effort becomes *invalid* and is dropped, while
+mere checkbox state changes and whitespace-only edits keep it. Hence,
+an estimation never needs to be cleaned up by hand. Writing the effort
+neither changes the `Modified:` key nor the lifecycle status of a task.
+Empty plans and explicit epic tasks (whose effort is the sum of their
+member tasks) are skipped, and so are tasks already carrying a valid
+effort, unless `--force` is given.
+
+With `--calibrate`, the skill instead re-estimates the successfully
+finished tasks with the *current* rates and compares the results with
+their *actual* human time (only tasks with at least `5` human minutes
+count, as agent-driven tasks book little human time), so a repeated
+calibration converges, and reports the estimated vs. actual band matrix,
+the hit rate, the bias, the best-fitting rates (factor, file, and line
+minutes), and alternatively fitting scale bounds.
+
+The `ase agent estimator` command estimates the tasks automatically in
+the background, and with `--mode request` on request, in any unfinished
+status, via `ase task request <id> estimate <prompt>` or key `R` of the
+task boards.
 
 ##  OPTIONS
 
--   `--plan`|`-p` *option*:
-    Automatically answer the user dialog for the plan refinement
-    with *option*, which can be either `none` (default, interactive
-    answer required), `OVERWRITE` (overwrite an existing plan
-    with *instruction*), `REFINE` (refine the existing plan with
-    *instruction*), or `PRESERVE` (preserve the existing plan by
-    ignoring *instruction* and stopping skill processing).
+-   `--force`|`-f`:
+    Re-estimate tasks which already carry a valid effort.
 
--   `--dry`|`-d`:
-    Generate any *new* plan *without* the `##  VERIFICATION` section.
-    Applies only to freshly generated plans, not to existing plans
-    loaded from disk. When `ase-task-implement` later applies such
-    a plan, it strictly skips the entire verification phase (no
-    build, tests, linter, type-checker, or program execution) once
-    the source files have been modified.
+-   `--dry-run`|`-d`:
+    Estimate and report only, but do not store the effort.
 
--   `--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
-    chronological list* of tokens; each iteration of the planning
-    loop consumes the *first* token of the list, and on hand-off
-    (`IMPLEMENT` / `PREFLIGHT`) any remaining tokens are *forwarded*
-    (via `--next`) to the downstream skill so an entire pipeline can
-    be pre-scripted in one shot. Recognized tokens at this skill:
-    `none` (default, interactive answer required), `DONE` (no next
-    step), `GRILL` (hand-over to `ase-task-grill`), `PREFLIGHT`
-    (hand-over to `ase-task-preflight`), or `IMPLEMENT` (hand-over to
-    `ase-task-implement`). Example: `--next GRILL,DONE` hands the plan
-    off to grilling and forwards `DONE` so grilling exits without asking.
+-   `--all`|`-a`:
+    Estimate all unfinished tasks without a valid effort (with `--force`,
+    all unfinished tasks), instead of the current or given ones.
+
+-   `--calibrate`|`-c`:
+    Report the calibration of the estimation against the finished tasks
+    instead of estimating any task.
+
+-   `--save`|`-s`:
+    Together with `--calibrate`, store the fitted rates as
+    `project.task.effort.factor`, `project.task.effort.file`, and
+    `project.task.effort.line` on the `project` scope. The fitted scale
+    bounds always stay a suggestion only.
 
 ##  ARGUMENTS
 
--   *id* | *id*: *instruction* | *instruction*:
-    Edit the task with the unique identifier *id* (default: `default`).
-    Optionally, *instruction* either gives instructions for creating a
-    new task or gives instructions for refining an existing task.
+-   *id* ...:
+    The unique identifiers of the tasks to estimate. If omitted (and
+    without `--all`), the *current* task is estimated.
 
 ##  SCENARIOS
 
--   You want a task planned through chat-driven refinement
--   You want a plan created or refined round by round
--   You want a plan iterated on before implementing it
--   You want plan refinement with hand-off to preflight or implementation
+-   You want to know how much human time a planned task will need
+-   You want to size all open tasks for planning a sprint or release
+-   You want to check whether a task is too large and should be split
+-   You want to tune the estimation to the actual pace of your team
 
 ##  EXAMPLES
 
-Edit the current task:
+Estimate the current task plan:
 
 ```text
-❯ /ase-task-edit
+❯ /ase-task-estimate
 ```
 
-Create a new task under id `hello`:
+Estimate all unestimated tasks, without storing the results:
 
 ```text
-❯ /ase-task-delete hello
-❯ /ase-task-edit hello: new "ase hello" CLI command which prints
-  a nice "Hello World!" to the terminal in color blue.
+❯ /ase-task-estimate --all --dry-run
 ```
 
-Further refine the task under id `hello`:
+Re-estimate two specific tasks:
 
 ```text
-❯ /ase-task-edit hello: change the color to red.
+❯ /ase-task-estimate --force export-json import-csv
+```
+
+Calibrate the estimation and store the fitted rates:
+
+```text
+❯ /ase-task-estimate --calibrate --save
 ```
 
 </purpose>
@@ -4023,6 +4567,11 @@ Further refine the task under id `hello`:
 `ase-task-grill`
     [`--help`|`-h`]
     [`--rounds`|`-r` *n*]
+    [`--until`|`-u` `MUST`|`SHOULD`|`MAY`]
+    [`--perspective`|`-p` *perspective*]
+    [`--ground`|`-G`]
+    [`--focus`|`-f` *section*[,...]]
+    [`--force`|`-F`]
     [`--next`|`-n` *option*[,...]]
     [*id*]
 
@@ -4037,37 +4586,114 @@ The skill identifies the essential aspects of the plan and raises up to
 carries a `FOCUS-AREA` -- `DOMAIN` (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 `ASPECT`
-hint. The questions are sorted primarily by descending focus area
-importance (`DOMAIN`, `INTERFACE`, `ARCHITECTURE`, `IMPLEMENTATION`)
-and secondarily by the decision tree of their dependencies, so each
+placement, or dependencies, 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-3 word `TOPIC`
+hint. The focus areas are selected by the plan sections under focus
+(`--focus`): `SPECIFICATION` selects `DOMAIN` and `INTERFACE`, `DESIGN`
+selects `ARCHITECTURE` and `IMPLEMENTATION`, and `VERIFICATION` selects
+`REGRESSION` and `CONFIRMATION`. The questions are sorted
+by descending focus area importance, then by descending individual
+impact, and finally by the decision tree of their dependencies, so each
 decision is asked after the decisions it depends on. It honors checks
 for *fuzzy language*, *conflicting terminology*, *conflicting code*,
 *non-concrete scenarios*, *unspecified architecture patterns*, and
 *unspecified dependencies*.
 
-In contrast to the batch grilling of `ase-code-edit --grill`, the
-questions are asked *sequentially*, one at a time: each question is
-announced as an `ASPECT n/N ▶ FOCUS ▷ ASPECT, QUESTION` line and then
-raised via an interactive dialog presenting two to four *grounded*
-answer alternatives labeled `A1`-`A4` (the current plan, marked with
-`⚑`, plus alternatives derived from the code base and world knowledge),
-the fixed `SKIP GRILLING` option (skip the remaining questions and
-rounds, keeping the answers gathered so far), and free-text input.
-Cancelling the dialog stops the skill and leaves the plan untouched.
-Once all aspects are resolved, the plan is updated and persisted, its
-`Properties:` frontmatter key gains the value `grilled`, and the user is
-offered a hand-off to editing, implementation, or preflight.
+As with `ase-code-edit --grill`, all questions of a round are announced
+together below a `GRILLING ROUND K/L` line (plain `GRILLING` for a
+single round) as a `QUESTION`/`ANSWERS` table with one row per
+question, each row carrying two to three *grounded* answer alternatives
+(the one reflecting the current plan marked with `⚑`). They are then
+asked in *one* batch via a single interactive dialog, whose only answer
+option is the fixed `SKIP GRILLING` (skip the remaining grilling, but
+still update the plan with the answers of the previous rounds), plus
+free-text 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. A question not
+addressed by the reply accepts its `⚑` answer, if one exists.
+Cancelling the dialog stops the skill without updating the plan with
+the current round. After every round, the plan is updated and
+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
+re-grilling (with the same grilling options), or a hand-off to editing,
+implementation, or draft.
+
+The *open* questions are recorded in the checkboxes of the plan's
+bullet-points: a bullet-point whose question stayed *unanswered*
+(because the grilling was skipped, or the reply did not address a
+question the plan offers no answer for) is marked `[?]`, an unanswered
+question the plan does not cover yet is added as a new `[?]`
+bullet-point, and an *answered* question resets its bullet-points to
+`[ ]`. When a section is grilled *again* (its `grilled:`*section* tag
+is already present), only its `[?]` bullet-points are re-asked, and a
+section without any `[?]` bullet-point is skipped entirely, unless
+`--force` is given. Bullet-points
+in state `[-]` (cancelled) or `[>]` (deferred) are never questioned.
 
 ##  OPTIONS
 
 -   `--rounds`|`-r` *n*:
-    The number of grill rounds to apply (default: `1`). Each round
-    starts from scratch from only the current plan, as updated by all
-    previous rounds, and re-derives its questions from it, forgetting
-    all questions and answers of previous rounds. With more than one
-    round, each round is announced as `GRILLING ROUND K/L`.
+    The *maximum* number of grill rounds to apply (default: `1`). Each
+    round starts from scratch from only the current plan, as updated and
+    saved by all previous rounds, and re-derives its questions from it,
+    forgetting all questions and answers of previous rounds. With more than one
+    round, each round is announced as `GRILLING ROUND K/L`. 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 `--until`.
+
+-   `--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.
+
+-   `--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.
+
+-   `--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.
+
+-   `--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.
+
+-   `--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.
 
 -   `--next`|`-n` *option*[,...]:
     Automatically answer the user dialog for the next step (at the end
@@ -4077,9 +4703,10 @@ offered a hand-off to editing, implementation, or preflight.
     to the downstream skill on hand-off so an entire pipeline can be
     pre-scripted in one shot. Recognized tokens at this skill: `none`
     (default, interactive answer required), `DONE` (no next step),
-    `EDIT` (hand-over to `ase-task-edit`), `IMPLEMENT` (hand-over to
-    `ase-task-implement`), or `PREFLIGHT` (hand-over to
-    `ase-task-preflight`).
+    `GRILL` (re-grilling via `ase-task-grill --force` with the same
+    grilling options), `EDIT` (hand-over to `ase-task-edit`),
+    `IMPLEMENT` (hand-over to `ase-task-implement`), or `DRAFT`
+    (hand-over to `ase-task-implement --draft`).
 
 ##  ARGUMENTS
 
@@ -4115,6 +4742,26 @@ Grill the current task plan in two rounds:
 ❯ /ase-task-grill --rounds 2
 ```
 
+Grill the current task plan exclusively from the performance
+perspective, grounded in the project artifacts and the Internet/Web:
+
+```text
+❯ /ase-task-grill --perspective performance --ground
+```
+
+Grill only the `DESIGN` and then the `SPECIFICATION` section of the
+current task plan:
+
+```text
+❯ /ase-task-grill --focus DES,SPEC
+```
+
+Re-grill the already grilled current task plan completely:
+
+```text
+❯ /ase-task-grill --force
+```
+
 Grill the current task plan and then hand off to editing:
 
 ```text
@@ -4144,8 +4791,11 @@ task id via the `ase_task_id` MCP tool.
 ##  ARGUMENTS
 
 -   *id*:
-    The new task id to activate. If omitted, the currently active
-    task id is reported.
+    The new task id to activate (characters `A-Z`, `a-z`, `0-9`, `#`,
+    `_`, and `-`). If omitted, the currently active task id is
+    reported. An id not conforming to the task id scheme of the
+    project (`project.task.idscheme`: `slug[:<words>]`, `seq[:<template>]`,
+    or `any`) is accepted, but noticed.
 
 ##  SCENARIOS
 
@@ -4179,50 +4829,103 @@ Switch to a specific task:
 `ase-task-implement`
     [`--help`|`-h`]
     [`--next`|`-n` *option*[,...]]
-    [`--worktree`|`-w`]
+    [`--worktree`|`-w` *name*]
+    [`--source`|`-s` *source*]
+    [`--changeset`|`-c` *changeset*]
+    [`--draft`|`-d`]
+    [`--stateless`|`-S`]
     [*id*]
 
 ##  DESCRIPTION
 
 The `ase-task-implement` skill performs the *final implementation* of
-a task plan by modifying the corresponding *artifacts* with a complete
-*change set*. The plan is loaded and any optional `IMPLEMENTATION DRAFT`
-section produced by `ase-task-preflight` is taken over *1:1* as the
-change set -- the draft is assumed to be user-reviewed, so no fresh
-implementation is created and only parts which actually fail are
-adjusted, guided by the plain plan content. Afterwards the plan's
-`Properties:` frontmatter key gains the value `implemented` (plus
-`verified`, if the verification phase actually ran and succeeded), and
-its `Status:` key becomes `COMPLETED` if the change set was applied
-completely and successfully.
+a task plan by creating a complete *change set* from the plan's
+*source* (the code basis) into the plan's *changeset* (the location of
+the change set). Delivering the change set from there into the plan's
+*target* is the separate concern of `ase-task-integrate`. Afterwards
+the checkboxes of the realized `DOM`/`IFC`/`ARC`/`IMP` bullet-points
+and of the performed and succeeded `REG`/`CON` bullet-points are ticked
+to `[x]` (or `[/]` if only partially realized or succeeded), refreshing
+the plan's `Modified:` key. Bullet-points in state `[-]` (cancelled) or
+`[>]` (deferred) are *skipped*: they are neither realized nor checked,
+do not count against completeness, and keep their checkbox untouched.
+
+The *source* is selected by the plan's `Source:` frontmatter key
+(if absent, the configured default `project.task.default.source`),
+overridable via `--source`:
+
+-   `worktree` (default): the *origin* working copy (the one the skill
+    was started in) with its checked-out branch.
+-   `branch:`*name*: the existing branch *name*. For a `worktree`
+    changeset without `--worktree`, the origin working copy is
+    *switched* to it in place first, but only if it has *no*
+    uncommitted changes, otherwise the skill stops and touches nothing.
+
+A context worktree created by `--worktree` carries its *own* branch
+*name*, which starts at the source (so the source branch itself is never
+checked out there and stays available as the integration target), while
+a reused one keeps its own base, so earlier work in it is continued.
+
+The *changeset* is selected by the plan's `Changeset:` frontmatter
+key (if absent, the configured default `project.task.default.changeset`),
+overridable via `--changeset`:
+
+-   `worktree` (default): the change set stays *uncommitted* in the
+    context worktree.
+-   `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>`.
+-   `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;
+    kind="<name>"` (with its base commit in the `Desc:` key) of the
+    plan only, leaving all artifacts untouched. An already existing
+    attachment of this kind is re-applied first, so re-runs build the
+    change set *cumulatively*. A *stale* one -- older than the plan --
+    stops the skill with an error, and an already *delivered* one --
+    marked `merged` in its `Desc:` key by `ase-task-integrate
+    --no-cleanup` -- is not re-applied, but replaced by a fresh change
+    set. The `--draft` shorthand selects
+    `attachment:draft`, the *implementation draft* of the plan, which
+    can be reviewed via `ase-task-view --full` and delivered via
+    `ase-task-integrate --draft`. An undelivered draft is *ignored* by
+    any other changeset (with a warning), as only `attachment:draft`
+    builds upon it.
+
+For derived changesets (`branch:` and `attachment:`), *uncommitted*
+changes of a `worktree` source are *not* carried over, as they start
+at its `HEAD`.
+
+The skill does *not* maintain the *change set snapshot* of the plan
+(the attachment block of type `text/x-diff; charset=utf-8;
+kind="changeset"`), which only the `implementer` agent of `ase agent`
+attaches after its implementation, but passes an existing one through
+unchanged.
+
+Unless `--stateless` is given, the plan's `Status:` key follows the
+task lifecycle model: for `solo` it stays untouched (as the task is
+closed by `ase-task-integrate`), and for `team` and `enterprise` it
+becomes `IMPLEMENTING` before and `IMPLEMENTED` (if the change set was
+applied completely and successfully) or `STALLED` (otherwise) after
+the implementation.
 
 The *kind of change* stated by the plan's `Kind:` frontmatter key
-(`CRAFTING`, `REFACTORING`, or `RESOLVING`) selects which
+(`SPECIFYING`, `CRAFTING`, `REFACTORING`, or `RESOLVING`) selects which
 *operation-specific tenet set* of the **ASE Tenets** is internalized
 before any artifact is touched, in addition to the always applying
 **GENERIC TENETS**. If a plan carries no such key, the kind is
 *inferred* from the plan content, defaulting to `CRAFTING`.
 
-If the task plan deliberately *omits* the `##  VERIFICATION` section
-(as produced by `ase-code-craft`, `ase-code-refactor`,
-`ase-code-resolve`, or `ase-task-edit` when invoked with `--dry`),
+If the task plan deliberately *omits* the `##  VERIFICATION (WHEN)` section
+(as produced by `ase-task-edit` when invoked with `--unverified`),
 the entire verification phase is strictly skipped: no build, tests,
 linter, type-checker, or program execution is performed once the
 source files have been modified.
 
-With `--worktree`|`-w`, the change set is *not* applied to the current
-working copy: a *fresh Git WorkTree* `.ase/worktree/<id>` and its
-equally named branch are created from `HEAD` *before* any artifact is
-touched, and the entire implementation -- including all verification
-runs -- then happens *inside* that worktree, which is left
-*uncommitted*. The worktree is *not* named by an option value: it
-always carries the unique *task id*, so worktree and branch stay tied
-to the very task plan implemented in them. As the worktree branches off
-`HEAD`, *uncommitted* changes of the current working copy are *not*
-carried over into it.
-
-After implementation, the user is asked whether to preserve or
-delete the task plan, unless `--next` pre-selects this choice.
+After implementation, the user is asked whether to stop, hand off to
+`ase-task-edit`, hand off to `ase-task-integrate`, or delete the task
+plan, unless `--next` pre-selects this choice.
 
 ##  OPTIONS
 
@@ -4230,19 +4933,41 @@ delete the task plan, unless `--next` pre-selects this choice.
     Automatically answer the user dialog for the next step. *option*
     is a single token or a *comma-separated chronological list* of
     tokens; the *first* token is consumed by this skill, and any
-    remaining tokens are intentionally *discarded*, because the
-    downstream `ase-task-delete` skill accepts no `--next` option.
-    Recognized tokens at this skill: `none` (default, interactive
-    answer required), `DONE` (preserve task plan and stop), or
-    `DELETE` (hand off to `ase-task-delete`).
-
--   `--worktree`|`-w`:
-    Apply the change set inside a dedicated *Git WorkTree* instead of
-    the current working copy. The worktree directory `.ase/worktree/<id>`
-    and its equally named branch are derived from the *task id* and
-    created from `HEAD`. If either the directory or the branch already
-    exists, the skill stops and touches nothing. By default, the change
-    set is applied to the current working copy.
+    remaining tokens are *forwarded* (via `--next`) to the downstream
+    skill. Recognized tokens at this skill: `none` (default,
+    interactive answer required), `DONE` (preserve task plan and stop),
+    `EDIT` (hand off to `ase-task-edit`), `INTEGRATE` (hand off to
+    `ase-task-integrate`, forwarding `--worktree`, `--changeset`, and
+    `--stateless`), or `DELETE` (hand off to `ase-task-delete`).
+
+-   `--worktree`|`-w` *name*:
+    Operate in the *context worktree* `.ase/worktree/<name>` instead
+    of the current working copy: it is *reused* if it already exists,
+    otherwise it is *created* with its own branch *name* (checked out if
+    it exists, created at the source commit otherwise, so the source
+    branch itself is never checked out there). The `worktree` value of the
+    changeset refers to it, while the `worktree` value of the source
+    (and of the target of a subsequent integration) keeps referring to
+    the origin working copy, so an integration delivers the change set
+    from the context worktree back into the origin branch. The option
+    is permitted for a `worktree` changeset only, as a `branch:` or
+    `attachment:` changeset would leave the context worktree unused.
+
+-   `--source`|`-s` *source*:
+    Override the plan's `Source:` key (`worktree` or `branch:`*name*)
+    for this run, without changing the plan.
+
+-   `--changeset`|`-c` *changeset*:
+    Override the plan's `Changeset:` key (`worktree`, `branch:`*name*,
+    or `attachment:`*name*) for this run, without changing the plan.
+
+-   `--draft`|`-d`:
+    Shorthand for `--changeset attachment:draft`: create the
+    *implementation draft* of the plan only, leaving all artifacts
+    untouched (a dry-run). Mutually exclusive with `--changeset`.
+
+-   `--stateless`|`-S`:
+    Leave the plan's `Status:` key untouched.
 
 ##  ARGUMENTS
 
@@ -4254,12 +4979,14 @@ delete the task plan, unless `--next` pre-selects this choice.
 
 -   You want a task plan turned into actual changes
 -   You want the planned change set applied and verified
--   You want a reviewed implementation draft applied 1:1
+-   You want the change set committed onto a dedicated branch
+-   You want the change set attached to the plan for review only
+-   You want a dry-run of the implementation as a reviewable draft
 -   You want the implementation isolated in a Git worktree
 
 ##  EXAMPLES
 
-Implement the current task plan:
+Implement the current task plan in the current working copy:
 
 ```text
 ❯ /ase-task-implement
@@ -4271,181 +4998,323 @@ Implement a specific task and delete the plan when done:
 ❯ /ase-task-implement --next DELETE hello
 ```
 
-Implement the task `hello` inside the isolated Git WorkTree
-`.ase/worktree/hello`:
+Draft the implementation of the task `hello` and apply the draft when
+done:
+
+```text
+❯ /ase-task-implement --draft --next INTEGRATE hello
+```
+
+Implement the task `hello` inside the isolated Git worktree
+`.ase/worktree/hello` and integrate it afterwards:
 
 ```text
-❯ /ase-task-implement --worktree hello
+❯ /ase-task-implement --worktree hello --next INTEGRATE,DONE hello
+```
+
+Implement the task `hello` by committing its change set onto the
+branch `feature-hello`:
+
+```text
+❯ /ase-task-implement --changeset branch:feature-hello hello
 ```
 
 </purpose>
-<purpose name="ase-task-list">
+<purpose name="ase-task-integrate">
 
 ##  NAME
 
-`ase-task-list` - List Task Plans
+`ase-task-integrate` - Integrate a Task Change Set
 
 ##  SYNOPSIS
 
-`ase-task-list`
+`ase-task-integrate`
     [`--help`|`-h`]
-    [`--verbose`|`-v`]
-    [`--include`|`-i`=*state*[`,`...]]
-    [`--exclude`|`-e`=*state*[`,`...]]
+    [`--next`|`-n` *option*[,...]]
+    [`--worktree`|`-w` *name*]
+    [`--changeset`|`-c` *changeset*]
+    [`--draft`|`-d`]
+    [`--target`|`-t` *target*]
+    [`--mode`|`-m` `merge`|`rebase`|`squash`]
+    [`--no-cleanup`|`-K`]
+    [`--stateless`|`-S`]
+    [*id*]
 
 ##  DESCRIPTION
 
-The `ase-task-list` skill lists all available *task ids* in the
-current project by calling the `ase_task_list` MCP tool. In the
-default mode, only the task ids are rendered as a single-column
-Markdown table. In verbose mode, the lifecycle status and the
-last-modified timestamp of each task plan are rendered as additional
-columns.
-
-The listing is restricted to an *effective state set*, derived from the
-`Status:` frontmatter key of each task plan (which defaults to `DRAFTED`
-for a plan carrying no such key): with `--include` only, exactly the
-listed states are shown; with `--exclude` only, all states except the
-listed ones; with both, the included ones minus the excluded ones. An
-unknown state, or a combination which cancels out to an empty set,
-aborts the skill with an error. By default,
-`--exclude COMPLETED,CANCELLED` is in effect, so finished and
-abandoned task plans stay out of the way. The eight states are:
-
-```text
-DRAFTED   APPROVED  STARTED  COMPLETED
-REJECTED  DEFERRED  BLOCKED  CANCELLED
-```
+The `ase-task-integrate` skill delivers the *change set* of a task
+plan, as created by `ase-task-implement`, from the plan's *changeset*
+(the location of the change set) into the plan's *target* (the place
+of integration). The integration itself is performed by the skill
+`ase-repo-merge`, which commits still uncommitted changes of the
+change set, merges them into the target branch (through a regular
+merge, a rebase with fast-forward, or a squash merge, as selected via
+`--mode`), resolves merge conflicts semantically, and reports the
+verdict `MERGED`, `CONFLICT`, or `FAILED`.
+
+The *changeset* is selected by the plan's `Changeset:` frontmatter
+key (if absent, the configured default `project.task.default.changeset`),
+overridable via `--changeset`:
+
+-   `worktree` (default): the uncommitted changes and the checked-out
+    branch of the context worktree. If it equals the target branch
+    (only possible without `--worktree`), the integration just commits
+    the uncommitted changes in place.
+-   `branch:`*name*: the existing branch *name*.
+-   `attachment:`*name*: the attachment block of type `text/x-diff;
+    charset=utf-8; kind="<name>"` of the plan, which is applied on a
+    *temporary* branch at the commit it is based on, so drift of the
+    target is resolved by the merge. A *stale* attachment -- one whose
+    `Modified:` key is absent or older than the `Modified:` key of the
+    plan frontmatter -- stops the skill with an error, and so does an
+    already *delivered* one -- one whose `Desc:` key carries the
+    `merged` marker of an earlier `--no-cleanup` integration.
+-   `attachment:draft`: the *implementation draft* of the plan, as
+    created by `ase-task-implement --draft`, selectable via the
+    `--draft` shorthand.
+
+The skill does *not* maintain the *change set snapshot* of the plan
+(the attachment block of type `text/x-diff; charset=utf-8;
+kind="changeset"`), which only the `integrator` agent of `ase agent`
+updates after a successful integration, but passes an existing one
+through unchanged.
+
+The *target* is selected by the plan's `Target:` frontmatter key
+(if absent, the configured default `project.task.default.target`),
+overridable via `--target`:
+
+-   `worktree`: the checked-out branch of the *origin* working copy,
+    i.e. the one the skill was started in (also with `--worktree`).
+-   `branch:`*name*: the existing branch *name*, which has to be
+    checked out in some worktree and to have no uncommitted changes.
+-   `source` (default): whatever the plan's `Source:` key refers to.
+
+The skill stops with an error -- touching nothing -- if the change set
+and the target are the same branch (except for the `worktree` changeset
+of the origin working copy, which just commits in place, see above), or
+if the change set carries neither commits beyond the target nor
+uncommitted changes. Likewise, a merge which leaves the content of the
+target unchanged, as the change set already landed earlier (e.g. on a
+repeated integration), counts as *no* integration: its empty merge
+commit is dropped again and the skill stops with an error. So it never
+reports a success without having delivered anything.
+
+Unless `--stateless` is given, the plan's `Status:` key follows the
+task lifecycle model: for `solo` the plan has to be `OPEN` (otherwise
+the integration is refused) and it becomes `CLOSED` on a successful
+integration and stays `OPEN` otherwise, for `enterprise` it becomes
+`INTEGRATING` before and `INTEGRATED` (on success), `QUALIFIED` (on
+nothing delivered), or `DEFERRED` (otherwise) after the integration,
+and for `team`, which defines no integration states, it stays
+untouched.
+
+After a successful integration, the user is asked whether to preserve
+or delete the task plan, unless `--next` pre-selects this choice.
 
 ##  OPTIONS
 
--   `--verbose`|`-v`:
-    Render an additional `Status` column with the lifecycle state and an
-    additional `Last Modified` column with the `YYYY-MM-DD HH:MM`
-    timestamp of each task plan.
+-   `--next`|`-n` *option*[,...]:
+    Automatically answer the user dialog for the next step. Recognized
+    tokens at this skill: `none` (default, interactive answer
+    required), `DONE` (preserve task plan and stop), or `DELETE` (hand
+    off to `ase-task-delete`).
+
+-   `--worktree`|`-w` *name*:
+    Operate on the *context worktree* `.ase/worktree/<name>` instead
+    of the current working copy, as for `ase-task-implement`. The
+    worktree has to exist already: an integration never creates it, so
+    a mistyped *name* stops the skill with an error. The option is
+    permitted for a `worktree` changeset only, as a `branch:` or
+    `attachment:` changeset would leave the context worktree unused.
+
+-   `--changeset`|`-c` *changeset*:
+    Override the plan's `Changeset:` key (`worktree`, `branch:`*name*,
+    or `attachment:`*name*) for this run, without changing the plan.
+
+-   `--draft`|`-d`:
+    Shorthand for `--changeset attachment:draft`: deliver the
+    *implementation draft* of the plan. Mutually exclusive with
+    `--changeset`.
+
+-   `--target`|`-t` *target*:
+    Override the plan's `Target:` key (`worktree`, `branch:`*name*, or
+    `source`) for this run, without changing the plan.
+
+-   `--mode`|`-m` `merge`|`rebase`|`squash`:
+    The merge mode, passed through to `ase-repo-merge` (default:
+    `merge`): `merge` creates a merge commit, `rebase` rebases the
+    change set branch (rewriting its commits) onto the target branch
+    and fast-forwards the target branch, and `squash` combines all
+    changes of the change set into one new commit on the target branch.
+
+-   `--no-cleanup`|`-K`:
+    After a successful integration, keep the delivered change set
+    instead of removing it: the branch and its worktree, or the
+    attachment block, which is then marked as delivered by appending
+    `, merged <commit>` to its `Desc:` key, so it is never delivered
+    again. Without this option, a delivered branch is removed only if
+    Git considers it merged (always for `--mode squash`) and its
+    worktree has no uncommitted changes. A temporary branch of an
+    attachment is always removed.
+
+-   `--stateless`|`-S`:
+    Leave the plan's `Status:` key untouched.
 
--   `--include`|`-i`=*state*[`,`...]:
-    Restrict the listed task plans to the given comma-separated list of
-    lifecycle states (e.g. `STARTED,BLOCKED`). Without this option, all
-    eight states are listed. The `none` sentinel selects no state at all.
+##  ARGUMENTS
 
--   `--exclude`|`-e`=*state*[`,`...]:
-    Remove the given comma-separated list of lifecycle states from the
-    listed task plans. Applied *after* `--include`, so
-    `-i DRAFTED,STARTED -e STARTED` lists `DRAFTED` only. Defaults to
-    `COMPLETED,CANCELLED`; pass `--exclude none` to suppress the
-    default and list task plans in every state.
+-   *id*:
+    The unique identifier of the task whose change set should be
+    integrated. If omitted, the *current* task id is used.
 
 ##  SCENARIOS
 
--   You want an overview of all task plans
--   You want task ids listed with status and timestamps
--   You want the unfinished or in-progress tasks found
+-   You want the implemented change set committed to the code base
+-   You want a change set branch merged into its target branch
+-   You want a change set attachment delivered into the code base
+-   You want a reviewed implementation draft applied to the code base
+-   You want the task closed once its change set has landed
 
 ##  EXAMPLES
 
-List all unfinished task ids:
+Integrate (commit) the change set of the current task plan:
 
 ```text
-❯ /ase-task-list
+❯ /ase-task-integrate
 ```
 
-List all task ids together with their status and last-modified timestamps:
+Apply the implementation draft of the task `hello` and remove the
+draft attachment afterwards:
 
 ```text
-❯ /ase-task-list --verbose
+❯ /ase-task-integrate --draft hello
 ```
 
-List the task ids of every task plan, including the finished ones:
+Merge the change set branch of the task `hello` into `main` and
+keep the branch afterwards:
 
 ```text
-❯ /ase-task-list --exclude none
+❯ /ase-task-integrate --changeset branch:feature-hello --target branch:main --no-cleanup hello
 ```
 
-List only the task ids of the task plans currently under work:
+Squash the change set branch of the task `hello` into one commit on
+its target:
 
 ```text
-❯ /ase-task-list --include STARTED,BLOCKED
+❯ /ase-task-integrate --changeset branch:feature-hello --mode squash hello
 ```
 
 </purpose>
-<purpose name="ase-task-preflight">
+<purpose name="ase-task-list">
 
 ##  NAME
 
-`ase-task-preflight` - Preflight a Task Plan
+`ase-task-list` - List Task Plans
 
 ##  SYNOPSIS
 
-`ase-task-preflight`
+`ase-task-list`
     [`--help`|`-h`]
-    [`--next`|`-n` *option*[,...]]
-    [*id*]
+    [`--verbose`|`-v`]
+    [`--include`|`-i`=*state*[`,`...]]
+    [`--exclude`|`-e`=*state*[`,`...]]
 
 ##  DESCRIPTION
 
-The `ase-task-preflight` skill performs a *preflight* (dry-run,
-test-drive) of the *implementation* of a task plan by creating a
-draft for a corresponding, complete *artifact change set* in
-*unified diff* format. The draft is appended to the task plan as
-an `IMPLEMENTATION DRAFT` section (replacing any previous draft) and
-the plan's `Properties:` frontmatter key gains the value `preflighted`.
-No source files are modified. The draft is produced under the *same
-tenets* and with the *same rigor* as a final implementation, because
-`ase-task-implement` later takes it over *1:1* after user review --
-only the actual artifact modification and the verification phase
-are deferred.
+The `ase-task-list` skill lists all available *task ids* in the
+current project by calling the `ase_task_list` MCP tool. In the
+default mode, only the task ids are rendered as a single-column
+Markdown table. In verbose mode, the lifecycle status, the effort size
+(see `ase-task-estimate`), and the last-modified timestamp of each task
+plan are rendered as additional columns.
 
-The *kind of change* stated by the plan's `Kind:` frontmatter key
-(`CRAFTING`, `REFACTORING`, or `RESOLVING`) selects which
-*operation-specific tenet set* of the **ASE Tenets** is internalized
-before the draft is produced, in addition to the always applying
-**GENERIC TENETS**. If a plan carries no such key, the kind is
-*inferred* from the plan content, defaulting to `CRAFTING`.
+The listing is restricted to an *effective state set*, derived from the
+`Status:` frontmatter key of each task plan (which defaults to the
+initial state of the task lifecycle model for a plan carrying no such
+key): with `--include` only, exactly the listed states are shown; with
+`--exclude` only, all states except the listed ones; with both, the
+included ones minus the excluded ones. An unknown state, or a
+combination which cancels out to an empty set, aborts the skill with an
+error. The `finished` sentinel stands for the finished states of the
+task lifecycle model. By default, `--exclude finished` is in effect, so
+finished and abandoned task plans stay out of the way. A task plan whose
+`Status:` is not a state of the task lifecycle model at all is never
+filtered out: it is kept in the listing and reported with a warning.
 
-After the preflight, the user is asked whether to stop, hand
-off to `ase-task-edit`, or hand off to `ase-task-implement`,
-unless `--next` pre-selects this choice.
+The states depend on the task lifecycle model configured for the
+project via `project.task.lifecycle`. The `solo` model (default) has
+the 4 states (initial: `OPEN`, finished: `CLOSED` and `CANCELLED`):
+
+```text
+OPEN  SHELVED  CLOSED  CANCELLED
+```
+
+The `team` model has the 6 states (initial: `PLANNING`, finished:
+`IMPLEMENTED` and `CANCELLED`):
+
+```text
+PLANNING  SHELVED  IMPLEMENTING  STALLED  IMPLEMENTED  CANCELLED
+```
+
+The `enterprise` model has the 14 states (initial: `DRAFTED`, finished:
+`INTEGRATED` and `CANCELLED`):
+
+```text
+DRAFTED      SHELVED   PLANNING     PLANNED   STALLED
+IMPLEMENTING IMPLEMENTED DECLINED   QUALIFYING QUALIFIED
+DEFERRED     INTEGRATING INTEGRATED CANCELLED
+```
 
 ##  OPTIONS
 
--   `--next`|`-n` *option*[,...]:
-    Automatically answer the user dialog for the next step. *option*
-    is a single token or a *comma-separated chronological list* of
-    tokens; the *first* token is consumed by this skill, and any
-    remaining tokens are *forwarded* (via `--next`) to the downstream
-    skill so an entire pipeline can be pre-scripted in one shot.
-    Recognized tokens at this skill: `none` (default, interactive
-    answer required), `DONE` (stop), `EDIT` (hand off to
-    `ase-task-edit`), or `IMPLEMENT` (hand off to
-    `ase-task-implement`). Example: `--next IMPLEMENT,DONE` runs the
-    preflight, hands off to implementation, then exits without asking.
+-   `--verbose`|`-v`:
+    Render an additional `Status` column with the lifecycle state, an
+    additional `Effort` column with the T-shirt size (`-` if not
+    estimated), and an additional `Last Modified` column with the
+    `YYYY-MM-DD HH:MM` timestamp of each task plan.
 
-##  ARGUMENTS
+-   `--include`|`-i`=*state*[`,`...]:
+    Restrict the listed task plans to the given comma-separated list of
+    lifecycle states (e.g. `IMPLEMENTING,STALLED`). Without this option,
+    all states are listed. The `none` sentinel selects no state at all,
+    the `finished` sentinel selects the finished states.
 
--   *id*:
-    The unique identifier of the task whose plan should be
-    preflighted. If omitted, the *current* task id is used.
+-   `--exclude`|`-e`=*state*[`,`...]:
+    Remove the given comma-separated list of lifecycle states from the
+    listed task plans. Applied *after* `--include`, so
+    `-i PLANNING,IMPLEMENTING -e IMPLEMENTING` lists `PLANNING` only.
+    Defaults to `finished`; pass `--exclude none` to suppress the
+    default and list task plans in every state.
 
 ##  SCENARIOS
 
--   You want a dry-run of a plan's implementation
--   You want the change set previewed as a unified diff before applying
--   You want an implementation draft to review before committing to it
--   You want a plan test-driven without touching any source files
+-   You want an overview of all task plans
+-   You want task ids listed with status and timestamps
+-   You want the unfinished or in-progress tasks found
 
 ##  EXAMPLES
 
-Preflight the current task plan:
+List all unfinished task ids:
+
+```text
+❯ /ase-task-list
+```
+
+List all task ids together with their status and last-modified timestamps:
+
+```text
+❯ /ase-task-list --verbose
+```
+
+List the task ids of every task plan, including the finished ones:
 
 ```text
-❯ /ase-task-preflight
+❯ /ase-task-list --exclude none
 ```
 
-Preflight a specific task and hand off to implementation when done:
+List only the task ids of the task plans currently under work:
 
 ```text
-❯ /ase-task-preflight --next IMPLEMENT hello
+❯ /ase-task-list --include IMPLEMENTING,STALLED
 ```
 
 </purpose>
@@ -4465,13 +5334,32 @@ Preflight a specific task and hand off to implementation when done:
 ##  DESCRIPTION
 
 The `ase-task-reboot` skill re-creates an existing task plan *from
-scratch* by extracting the original `**WHAT**` and `**WHY**` sections
-(if present) from the current plan, using them as the new instruction,
-preserving the original creation timestamp, and writing fresh plan
-content via `ase_task_save`.
+scratch* by extracting the `DOM` and `IFC` bullet points of the
+`SPECIFICATION (WHAT)` section (if present) from the current plan,
+using them as the new instruction, re-deriving the `DESIGN (HOW)` and
+`VERIFICATION (WHEN)` sections grounded in the relevant specification
+(`SPEC`), source code (`CODE`), and infrastructure (`INFR`) files of the
+project (naming the actual files and symbols to change, the actual build,
+lint, and test procedures, and a `CHANGELOG.md` entry if such a file
+exists), preserving the original creation
+timestamp, the remaining frontmatter keys, and all attachments, and
+writing fresh plan content via `ase_task_save`. As the rebooted plan
+starts its lifecycle anew, its `Status:` key is reset to the default
+state of the task lifecycle model, all `grilled:` tags are dropped
+from its `Tags:` key, and its `Source:`, `Changeset:`, and `Target:`
+keys are dropped, so they read as their configured defaults
+`project.task.default.{source,changeset,target}`.
+
+A plan which does *not* follow the task format (or carries no `DOM` or
+`IFC` bullet point) is rebooted from its entire body instead: all of
+its existing content is *filed* into the `SPECIFICATION (WHAT)`,
+`DESIGN (HOW)`, and `VERIFICATION (WHEN)` sections by classifying
+each statement as a `DOM`, `IFC`, `ARC`, `IMP`, `REG`, or `CON` bullet
+point, with no statement dropped and missing bullet points derived from
+the existing content.
 
 After the reboot, the user is asked whether to stop or hand off to
-`ase-task-edit`, `ase-task-implement`, or `ase-task-preflight`,
+`ase-task-edit` or `ase-task-implement` (optionally with `--draft`),
 unless `--next` pre-selects this choice.
 
 ##  OPTIONS
@@ -4485,7 +5373,7 @@ unless `--next` pre-selects this choice.
     Recognized tokens at this skill: `none` (default, interactive
     answer required), `DONE` (stop), `EDIT` (hand off to
     `ase-task-edit`), `IMPLEMENT` (hand off to `ase-task-implement`),
-    or `PREFLIGHT` (hand off to `ase-task-preflight`). Example:
+    or `DRAFT` (hand off to `ase-task-implement --draft`). Example:
     `--next EDIT,DONE` reboots, hands off to editing, and the editing
     loop will exit immediately.
 
@@ -4498,8 +5386,9 @@ unless `--next` pre-selects this choice.
 ##  SCENARIOS
 
 -   You want a task plan re-created from scratch
--   You want a fresh plan from the original WHAT and WHY
+-   You want a fresh plan from the original specification
 -   You want planning restarted after a plan degraded
+-   You want a free-form or legacy plan filed into the task format
 
 ##  EXAMPLES
 
@@ -4563,6 +5452,184 @@ Rename a specific task:
 ❯ /ase-task-rename old-id new-id
 ```
 
+</purpose>
+<purpose name="ase-task-research">
+
+##  NAME
+
+`ase-task-research` - Research a Topic for a Task Plan
+
+##  SYNOPSIS
+
+`ase-task-research`
+    [`--help`|`-h`]
+    [`--services`|`-s` `all`|`perplexity`|`brave`|`exa`|`websearch`[,...]]
+    [`--refine`|`-r`]
+    [`--dry-run`|`-d`]
+    [*id* | *id*`:` [*topic*] | *topic*]
+
+##  DESCRIPTION
+
+The `ase-task-research` skill *researches* a topic in depth for a task
+plan. It combines a *Web research* -- several focused queries, sent in
+parallel to the Internet/Web search services of `ase-meta-search` --
+with a *grounding* in the *source artifacts* of the project (its
+specification, source code, documentation, and infrastructure).
+
+The result is a *research report* with the parts *Findings* (the Web
+facts, each with its source URL), *Project Grounding* (the relevant
+project facts, each with its project file), *Assessment* (how the
+findings apply to the project, including its gaps and conflicts), and
+*Recommendations* (the concrete consequences for the plan), bounded to
+about 300 lines and at most 10 findings.
+
+The report is *appended* to the single `research` attachment of the
+task (of type `text/markdown; charset=utf-8; kind="research"`), so the
+reports of earlier researches are kept. With `--refine`, the
+recommendations are additionally applied to the plan itself, preserving
+its structure. Without a *topic*, the task plan itself (its title and
+domain items) is researched.
+
+The search queries carry only a self-contained summary of the topic and
+never any project internals like file paths or identifiers, as they are
+sent to foreign search services. The shown report follows the
+configured `project.boxing`, while the attachment always carries the
+full report.
+
+The `ase agent researcher` command researches the tasks automatically
+and always refines the plan by the recommendations: in its mode
+`phase`, it researches and grounds the plans of the `DRAFTED` tasks
+explicitly assigned to it, while in its mode `request`, it researches
+the topics of the requests in any unfinished status, via `ase task
+request <id> research [<topic>]` or key `R` of the task boards.
+
+##  OPTIONS
+
+-   `--services`|`-s` `all`|`perplexity`|`brave`|`exa`|`websearch`[,...]:
+    The comma-separated search services to query (default: `all`).
+
+-   `--refine`|`-r`:
+    Additionally refine the task plan by the recommendations of the
+    research report.
+
+-   `--dry-run`|`-d`:
+    Research and show the report only, but do not change the task.
+
+##  ARGUMENTS
+
+-   *id*:
+    The unique identifier of the task to research for. If omitted, the
+    *current* task is used. A single word without a trailing `:` is
+    always taken as a task identifier.
+
+-   *topic*:
+    The topic to research. If omitted, the task plan itself is
+    researched.
+
+##  SCENARIOS
+
+-   You want to know the established practices and pitfalls of a topic before planning a task
+-   You want to check a task plan against the state of the art
+-   You want to keep the research findings of a task together with its plan
+
+##  EXAMPLES
+
+Research the current task plan itself:
+
+```text
+❯ /ase-task-research
+```
+
+Research a topic for a specific task and refine its plan:
+
+```text
+❯ /ase-task-research --refine export-json: streaming JSON serialization of large data sets
+```
+
+Research a topic with Perplexity only, without changing the task:
+
+```text
+❯ /ase-task-research --services perplexity --dry-run rate limiting of REST APIs
+```
+
+</purpose>
+<purpose name="ase-task-status">
+
+##  NAME
+
+`ase-task-status` - Configure Task Status
+
+##  SYNOPSIS
+
+`ase-task-status`
+    [`--help`|`-h`]
+    [*id*`:`] [*status*]
+
+##  DESCRIPTION
+
+The `ase-task-status` skill gets or sets the *lifecycle status* of a
+*task plan*, i.e. its `Status:` frontmatter key, via the
+`ase_task_status` MCP tool. Without a *status* argument, it reports the
+current status of the plan (defaulting to the initial state of the task
+lifecycle model if the plan carries no `Status:` key). With a *status*
+argument, it sets the status of the plan, leaving its `Modified:` key
+alone, as that key tracks changes of the plan body only.
+
+The *status* is matched case-insensitively against the states of the
+task lifecycle model configured for the project via
+`project.task.lifecycle` (`solo`, `team`, or `enterprise`) and rejected
+if it is no such state. A status not reachable from the current one via
+one or more transitions of the state machine of the model is *rejected*,
+too.
+
+If *id*`:` is omitted, the *current* task id (inherited from the session
+context) is used. A single bare token which is no state of the model is
+also taken as the task id. The current task id of the session is never
+switched.
+
+##  ARGUMENTS
+
+-   *id*`:`:
+    The unique identifier of the task plan, with a trailing colon.
+    If omitted, the current task id is used.
+
+-   *status*:
+    The lifecycle status to set, one of the states of the configured
+    task lifecycle model (case-insensitive). If omitted, the current
+    status is reported.
+
+##  SCENARIOS
+
+-   You want to know the lifecycle status of the current or a given task plan
+-   You want a task plan closed, shelved, cancelled, or re-opened
+-   You want a task plan moved into a certain lifecycle state by hand
+
+##  EXAMPLES
+
+Show the status of the current task plan:
+
+```text
+❯ /ase-task-status
+```
+
+Show the status of a specific task plan:
+
+```text
+❯ /ase-task-status hello:
+```
+
+Close the current task plan (`solo` lifecycle model):
+
+```text
+❯ /ase-task-status closed
+```
+
+Shelve a specific task plan:
+
+```text
+❯ /ase-task-status hello: SHELVED
+```
+
 </purpose>
 <purpose name="ase-task-view">
 
@@ -4584,18 +5651,28 @@ The plan is loaded via the `ase_task_load` MCP tool and shown framed
 between a `( TASK )` header and footer rule. If *id* is omitted, the
 *current* task id (inherited from the session context) is used.
 
-By default, when the plan is longer than 90 lines and contains an
-`IMPLEMENTATION DRAFT` section (produced by `ase-task-preflight`), the
-content of that section is collapsed to `[...]` to keep the view
-compact. The `--full`|`-f` option suppresses this collapsing and renders
-the plan in full, without any truncation or summarization.
+By default, the payload of every attachment in the backmatter (like an
+implementation draft of `ase-task-implement --draft` or the processing
+log of an `ase agent`) is elided to an `[elided: <n> lines]` marker to
+keep the view compact. The `--full`|`-f` option loads the payloads, too,
+and renders the plan in full, without any truncation or summarization.
+
+An implementation draft attachment whose `Modified:` key is absent or
+older than the `Modified:` key of the plan frontmatter is *stale*, as
+the plan changed after the draft was created. Such a draft is reported
+with a warning after the rendering, together with a hint that
+`ase-task-implement --draft` has to be run again, as
+`ase-task-integrate --draft` refuses a stale draft.
+
+The frontmatter keys `Source:`, `Changeset:`, and `Target:` are
+rendered as well, stating where the change set of the plan is
+created from, stored in, and delivered to.
 
 ##  OPTIONS
 
 -   `--full`|`-f`:
-    Render the plan in full, without collapsing the
-    `IMPLEMENTATION DRAFT` section. By default, that section is
-    replaced with `[...]` for plans longer than 90 lines.
+    Render the plan in full, including the payloads of its attachments.
+    By default, each payload is elided to an `[elided: <n> lines]` marker.
 
 ##  ARGUMENTS
 
@@ -4623,7 +5700,7 @@ View a specific task plan:
 ❯ /ase-task-view hello
 ```
 
-View a plan in full, including its `IMPLEMENTATION DRAFT` section:
+View a plan in full, including its implementation draft attachment:
 
 ```text
 ❯ /ase-task-view --full hello