@rse/ase 1.0.7 → 2.0.1

package/plugin/skills/ase-meta-review/SKILL.md

@@ -1,210 +0,0 @@
----
-name: ase-meta-review
-argument-hint: "[--help|-h] [--severity|-S=(LOW|MEDIUM|HIGH)]"
-description: >
-    Perform a holistic, human-reviewer-style critique of the currently
-    staged Git changes and emit an approve/reject verdict with
-    prioritized, severity-tagged, line-cited findings. Use when the user
-    wants the staged diff "reviewed", "critiqued", or "code-reviewed"
-    before committing.
-user-invocable: true
-disable-model-invocation: false
-effort: high
-allowed-tools:
-    - "Bash(git diff *)"
-    - "Agent"
----
-
-@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
-
-<purpose name="ase-meta-review">
-Review Staged Changes
-</purpose>
-
-<expand name="getopt"
-    arg1="ase-meta-review"
-    arg2="--severity|-S=(LOW|MEDIUM|HIGH)">
-    $ARGUMENTS
-</expand>
-
-<objective>
-Review the currently staged Git changes the way an *experienced human
-reviewer* would - judging them *holistically* against the change's *own
-intent* and against *correctness*, *design fit*, *clarity*, *robustness*,
-and *project-convention conformance* - and emit a single *approve /
-request-changes verdict* backed by *prioritized*, *severity-tagged*,
-*line-cited* findings. This is a *synthesizing critique*, not a mechanical
-scan: it complements `ase-code-lint` (mechanical quality), `ase-code-analyze`
-(logic/semantics), and `ase-meta-diff` (intent narrative and risk).
-</objective>
-
-Procedure
----------
-
-<flow>
-
-1.  <step id="STEP 1: Determine Change Set">
-
-    1.  Determine *whether there are staged changes at all* by running the
-        corresponding command (taken exactly as given) and capturing its
-        output - the bare *list of staged file names* - into <diff/>. This
-        is a lightweight gate; the full diff is fetched by the sub-agent
-        in STEP 2, so capturing only the file-name list here is sufficient:
-
-        `git diff --cached --name-only HEAD`
-
-    2.  <if condition="<diff/> is empty">
-        Only output the following <template/> and then *STOP* immediately:
-
-        <template>
-        ⧉ **ASE**: ✪ skill: **ase-meta-review**, ▶ status: **no changes to review**
-        </template>
-        </if>
-
-    </step>
-
-2.  <step id="STEP 2: Review Investigation">
-
-    <if condition="<ase-project-boxing/> is equal `black`">
-
-    The project source artifacts are classified as a *black box*, so
-    the user does *not* want the staged changes scrutinized or their
-    findings surfaced. *Skip* the entire review investigation: do
-    *not* invoke the `Agent` tool and do *not* read any change, set
-    <findings/> to the *empty* list, set <verdict/> to `SKIPPED (boxing:
-    black)`, set <summary/> to a *one-line* neutral restatement of the
-    change intent derived solely from STEP 1, and proceed *directly* to
-    STEP 3.
-
-    </if>
-
-    First, use the following <template/> to give a hint on this step:
-
-    <template>
-    <ase-tpl-bullet-secondary/> **REVIEW INVESTIGATION**
-    </template>
-
-    Dispatch the review investigation to a *sub-agent* via the `Agent`
-    tool so that *no* investigation details leak into the user-visible
-    transcript. The sub-agent performs the silent reading, the read-only
-    repository probing, and the critique; only its final structured return
-    value is consumed here.
-
-    For this, invoke *exactly once* the tool:
-
-    ```text
-        Agent(
-            description:       "Review Investigation",
-            subagent_type:     "ase:ase-meta-review",
-            prompt:            "Review the staged changes.",
-            run_in_background: false
-        )
-    ```
-
-    Parse the single result message of the `Agent` tool as a JSON object,
-    set <summary/> to its `summary` field (a single crisp sentence
-    reconstructing the change's intent), and set <findings/> to its
-    `findings` field (a list).
-
-    Then *derive* the overall <verdict/> from <findings/>: set
-    <verdict/> to `REJECT - DEMANDS CHANGES` if *any* finding in
-    <findings/> has a `severity` field of `HIGH`; otherwise set
-    <verdict/> to `APPROVE`. The verdict is derived *before* the
-    severity floor below, so the floor only affects which findings are
-    *rendered*, never the verdict.
-
-    Then determine the *effective severity floor* <floor/>: define the
-    ordinal rank `LOW`=1, `MEDIUM`=2, `HIGH`=3, start from
-    <floor><getopt-option-severity/></floor> (default `LOW`), and - if
-    <ase-project-boxing/> is equal `grey` - raise <floor/> to `MEDIUM`
-    whenever its current rank is below `rank(MEDIUM)` (grey boxing
-    surfaces only *material* findings of severity `MEDIUM` and above).
-    The floor affects only which findings are *rendered*, never the
-    <verdict/> derived above.
-
-    Then *apply the effective severity floor* <floor/>: *Keep* a finding
-    in <findings/> if and only if its `severity` field is `ACCEPTED` *or*
-    `rank(severity)` is greater than or equal to `rank(<floor/>)`;
-    *silently drop* all other findings. With the default floor `LOW`, all
-    findings are kept. `ACCEPTED` findings are *never* dropped.
-
-    You *MUST* *NOT* output anything else in this STEP 2.
-
-    </step>
-
-3.  <step id="STEP 3: Verdict and Findings">
-
-    1.  Use the following <template/> to output the overall review in
-        <verdict/> and the reconstructed intent <summary/>:
-
-        <template>
-
-        <ase-tpl-bullet-signal/> **REVIEW VERDICT**: **<verdict/>**
-
-        <ase-tpl-bullet-normal/> **CHANGE INTENT**: <summary/>
-
-        </template>
-
-        You *MUST* *NOT* output anything else in this STEP 3.1.
-
-    2.  <if condition="<findings/> is empty">
-        Only output the following <template/> - with <note/> set to `the
-        change was not reviewed` if <verdict/> starts with `SKIPPED` and
-        to `the change is clean` otherwise - and then *SKIP* the
-        remainder of this STEP 3 (an empty finding list never yields the
-        `REJECT` verdict, so the closing hint of substep 4 would expand
-        into nothing anyway):
-
-        <template>
-
-        <ase-tpl-bullet-normal/> **NO FINDINGS**: <note/>, nothing to flag.
-
-        </template>
-        </if>
-
-    3.  <if condition="<findings/> is NOT empty">
-        Sort the findings by <severity/> from highest to lowest in the
-        fixed order `HIGH`, `MEDIUM`, `LOW`, `ACCEPTED`. Within the same
-        severity, keep the order returned by the sub-agent.
-
-        Then render a *three-column table* with one row per finding by
-        using the following output <template/>. For each finding, repeat
-        the third line, set <severity/> to its `severity` field, set
-        <dimension/> to its `dimension` field, set <location/> to its
-        `location` field, and set <finding/> to its `finding` field.
-
-        In the <location/> column, mark up the `file:line` reference
-        as code (with backticks) and prepend it with `▢ ` - keep the
-        sub-agent's own `:N` / `:N-M` line citation intact and do *not*
-        append any further line-count decoration.
-
-        Because the <finding/> text is free-form Markdown, *before*
-        emitting any row you *MUST* escape every literal `|` pipe
-        character inside <location/> and <finding/> as `\|` so it cannot
-        break the table column structure.
-
-        <template>
-        | Severity        | Dimension    | Finding                 |
-        | --------------- | ------------ | ----------------------- |
-        | **<severity/>** | <dimension/> | <location/>: <finding/> |
-        </template>
-
-        Keep the overall report *concise* and *brief*.
-        Do *not* output any further explanation.
-        </if>
-
-    4.  Finally, give the closing hint by expanding the following
-        (which, depending on the configured <ase-guidance-level/>, may
-        expand into nothing and hence emit no output at all):
-
-        <if condition="<verdict/> starts with `REJECT`">
-        <ase-tpl-hint level="normal">
-        Use `/ase-code-resolve` to derive and apply a solution approach for the findings which demand changes.
-        </ase-tpl-hint>
-        </if>
-
-    </step>
-
-</flow>

package/plugin/skills/ase-meta-review/help.md

@@ -1,96 +0,0 @@
-
-##  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
-```
-
-##  SEE ALSO
-
-[`ase-meta-diff`](../ase-meta-diff/help.md), [`ase-meta-commit`](../ase-meta-commit/help.md), [`ase-code-lint`](../ase-code-lint/help.md), [`ase-code-analyze`](../ase-code-analyze/help.md),
-[`ase-meta-diaboli`](../ase-meta-diaboli/help.md).

package/plugin/skills/ase-task-preflight/SKILL.md

@@ -1,166 +0,0 @@
----
-name: ase-task-preflight
-argument-hint: "[--help|-h] [--next|-n <option>[,...]] [<id>]"
-description: >
-    Preflight the implementation of current or given task plan.
-    Use when the user calls to "preflight", "dry-run" or "test-drive"
-    the "task", "plan", "spec", or "specification".
-user-invocable: true
-disable-model-invocation: false
-effort: xhigh
----
-
-@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
-
-<purpose name="ase-task-preflight">
-Preflight a Task Plan
-</purpose>
-
-<expand name="getopt"
-    arg1="ase-task-preflight"
-    arg2="--next|-n=(none|DONE|EDIT|IMPLEMENT)... --int-reuse-task">
-    $ARGUMENTS
-</expand>
-
-<objective>
-*Preflight* the implementation of a task plan by creating a draft
-for a corresponding, *complete source code change set*.
-</objective>
-
-@${CLAUDE_SKILL_DIR}/../../meta/ase-format-task.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-common-task.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-tenets.md
-@${CLAUDE_SKILL_DIR}/../../meta/ase-common-code.md
-
-Procedure
----------
-
-1.  **Determine Task:**
-
-    1.  Set <instruction><getopt-arguments/></instruction> initially, with any
-        leading and trailing whitespace stripped.
-        Inherit the always existing <ase-task-id/> from the current context.
-        Inherit the always existing <ase-session-id/> from the current context.
-        Do not output anything.
-
-    2.  React on task id:
-
-        <expand name="task-react-id" arg1="ase-task-preflight"></expand>
-
-2.  **Determine Operation:**
-
-    1.  Determine the current task plan content:
-
-        <expand name="task-load-content"></expand>
-
-    2.  If the <task-content/> is still empty, complain and tell the user to
-        use the `ase-code-resolve`, `ase-code-refactor`, `ase-code-craft`,
-        or `ase-task-edit` skills first to create a task plan. Then
-        immediately stop processing this skill.
-
-    3.  Internalize the tenets stated by the plan:
-
-        <expand name="code-tenets-from-plan"></expand>
-
-3.  **Create Implementation Draft:**
-
-    1.  Perform a *preflight* of the *implementation* of <task-content/> by creating a
-        draft for a corresponding, *complete artifact change set*
-        which *would* fully implement the task plan <task-content/>. Store
-        this artifact change set in *unified diff* format in <unified-diff/>.
-
-        Create this draft with the *same rigor* as the final
-        implementation of the companion skill `ase-task-implement`,
-        because that skill later takes the draft over *1:1* -- the user
-        is assumed to review the draft in between. Hence *read* the
-        current content of *every* artifact the draft touches before
-        drafting its hunks, so all context lines match the artifacts
-        *exactly* and the diff would apply *cleanly*, and honor the
-        task plan and the internalized tenets just as the final
-        implementation would. Only the actual modification of the
-        artifacts and the verification phase are deferred to
-        `ase-task-implement`.
-
-    2.  Append this artifact change set <unified-diff/> to the end
-        of the <task-content/> with the following <template/>. If a section
-        named `##  IMPLEMENTATION DRAFT` already exists from a
-        previous run of this skill, *replace* this entire existing
-        section.
-
-        Set <fence/> to a run of backtick characters *one longer* than
-        the longest backtick run occurring anywhere inside
-        <unified-diff/>, but to at least three, so a diff which itself
-        carries fenced code blocks (e.g. one over Markdown artifacts)
-        cannot terminate the block prematurely.
-
-        <template>
-
-        ##  IMPLEMENTATION DRAFT
-
-        <fence/>text
-        <unified-diff/>
-        <fence/>
-
-        </template>
-
-    3.  Update <timestamp-modified/> with the current time in
-        ISO-style format, which has to be determined by calling the
-        `ase_timestamp(format: "yyyy-LL-dd HH:mm")` tool of the `ase`
-        MCP server and using the `text` field of its response. Update
-        the `Modified: ...` frontmatter key of <task-content/> with the
-        new <timestamp-modified/> value, *creating* the whole key at its
-        position in the key order of the plan <format/> if the plan does
-        not carry it yet.
-        Do not output anything.
-
-        Additionally *add* the value `preflighted` to the `Properties:`
-        frontmatter key of <task-content/> if it is still absent, keeping
-        all already present values and *creating* the whole key (with the
-        single value `preflighted`) if the plan carries none. Do not
-        output anything.
-
-    4.  Finally, call the `ase_task_save(id: "<ase-task-id/>",
-        text: "<task-content/>")` tool of the `ase` MCP server to save the updated
-        task plan content. This `ase_task_save` MCP tool call is the
-        *only* permitted way to persist the plan -- *NEVER* write the
-        plan file via `Write`/`Edit` or by executing a shell command.
-        Do not output anything related to this MCP tool call
-        except the following <template/>:
-
-        <template>
-        ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **plan updated**
-        </template>
-
-4.  **Decide Next Step:**
-
-    1.  *Determine next step*:
-
-        <expand name="task-next-select"
-            arg1="ase-task-preflight"
-            arg2="DONE|EDIT|IMPLEMENT">
-            Next Step: How would you like to proceed with the plan?
-            DONE: Stop processing.
-            EDIT: Hand processing off to editing.
-            IMPLEMENT: Hand processing off to implementation.
-        </expand>
-
-    2.  Check the tool <result/> and dispatch accordingly:
-
-        -   If <result/> is `DONE` or `CANCEL`:
-            Only output the following <template/> and then *STOP*.
-
-            <template>
-            ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **plan updated -- done**
-            </template>
-
-        -   If <result/> is `EDIT`:
-            <expand name="task-next-handoff" arg1="ase-task-edit"
-                arg2="plan updated -- hand-off to edit"></expand>
-
-        -   If <result/> is `IMPLEMENT`:
-            <expand name="task-next-handoff" arg1="ase-task-implement"
-                arg2="plan updated -- hand-off to implementation"></expand>
-

package/plugin/skills/ase-task-preflight/help.md

@@ -1,82 +0,0 @@
-
-##  NAME
-
-`ase-task-preflight` - Preflight a Task Plan
-
-##  SYNOPSIS
-
-`ase-task-preflight`
-    [`--help`|`-h`]
-    [`--next`|`-n` *option*[,...]]
-    [*id*]
-
-##  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 *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`.
-
-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.
-
-##  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.
-
-##  ARGUMENTS
-
--   *id*:
-    The unique identifier of the task whose plan should be
-    preflighted. If omitted, the *current* task id is used.
-
-##  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
-
-##  EXAMPLES
-
-Preflight the current task plan:
-
-```text
-❯ /ase-task-preflight
-```
-
-Preflight a specific task and hand off to implementation when done:
-
-```text
-❯ /ase-task-preflight --next IMPLEMENT hello
-```
-
-##  SEE ALSO
-
-[`ase-task-edit`](../ase-task-edit/help.md), [`ase-task-implement`](../ase-task-implement/help.md), [`ase-task-reboot`](../ase-task-reboot/help.md),
-[`ase-task-view`](../ase-task-view/help.md).