@rse/ase 1.0.7 → 2.0.1

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

@@ -0,0 +1,137 @@
+---
+name: ase-task-status
+argument-hint: "[--help|-h] [<id>:] [<status>]"
+description: >
+    Get or set the lifecycle status of the current or given task plan.
+    Use when the user wants to know or change the "status" or "state"
+    of the "task" or "plan", e.g. to "close", "shelve", "cancel", or
+    "re-open" it.
+user-invocable: true
+disable-model-invocation: false
+effort: high
+---
+
+@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
+@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
+
+<purpose name="ase-task-status">
+Configure Task Status
+</purpose>
+
+<expand name="getopt" arg1="ase-task-status">
+    $ARGUMENTS
+</expand>
+
+<objective>
+*Get* or *set* the lifecycle *status* of the task plan.
+</objective>
+
+Procedure
+---------
+
+1.  **Determine Task and Status:**
+
+    1.  Parse <arguments><getopt-arguments/></arguments> (with any
+        leading and trailing whitespace stripped) into a
+        whitespace-separated list of tokens. Inherit the always
+        existing <ase-task-id/> from the current context. Set
+        <id><ase-task-id/></id> and <status></status> (empty). Set
+        <states/> to the states of the task lifecycle model
+        <ase-project-task-lifecycle/> of the current project:
+
+        -   If <ase-project-task-lifecycle/> is `solo` (or absent):
+            `OPEN`, `SHELVED`, `CLOSED`, and `CANCELLED`.
+
+        -   If <ase-project-task-lifecycle/> is `team`:
+            `PLANNING`, `SHELVED`, `IMPLEMENTING`, `STALLED`,
+            `IMPLEMENTED`, and `CANCELLED`.
+
+        -   If <ase-project-task-lifecycle/> is `enterprise`:
+            `DRAFTED`, `SHELVED`, `PLANNING`, `PLANNED`, `STALLED`,
+            `IMPLEMENTING`, `IMPLEMENTED`, `DECLINED`, `QUALIFYING`,
+            `QUALIFIED`, `DEFERRED`, `INTEGRATING`, `INTEGRATED`, and
+            `CANCELLED`.
+
+        Do not output anything.
+
+    2.  <if condition="<arguments/> contains two tokens">
+        Set <id/> to the first token with a trailing `:` removed and
+        <status/> to the second token. Do not output anything.
+        </if>
+
+    3.  <if condition="<arguments/> contains exactly one token">
+        -   If the token ends with `:`:
+            Set <id/> to the token with the trailing `:` removed.
+        -   Else if the token, upper-cased, is one of <states/>:
+            Set <status/> to the token.
+        -   Else:
+            Set <id/> to the token.
+
+        Do not output anything.
+        </if>
+
+    4.  <if condition="<arguments/> contains more than two tokens">
+        Only output the following <template/> and then immediately
+        *STOP* processing the entire current skill:
+
+        <template>
+        ⧉ **ASE**: ☻ skill: **ase-task-status**, ▶ ERROR: expected `[<id>:] [<status>]` arguments
+        </template>
+        </if>
+
+    5.  <if condition="<id/> does NOT match the regexp `^[a-zA-Z0-9#][a-zA-Z0-9#_-]*$`">
+        Only output the following <template/> and then immediately
+        *STOP* processing the entire current skill:
+
+        <template>
+        ⧉ **ASE**: ☻ skill: **ase-task-status**, ▶ ERROR: invalid task id `<id/>` (expected `^[a-zA-Z0-9#][a-zA-Z0-9#_-]*$`)
+        </template>
+        </if>
+
+2.  **Perform Operation:**
+
+    1.  <if condition="<status/> is empty">
+        Call the `ase_task_status(id: "<id/>")` tool of the `ase` MCP
+        server to get the lifecycle status of the task plan and set
+        <text/> to the `text` output field of this tool call. Do not
+        output anything related to this MCP tool call.
+
+        -   If <text/> starts with `ERROR:` or `WARNING:`:
+            Only output the following <template/>:
+
+            <template>
+            ⧉ **ASE**: ◉ task: **<id/>**, ▶ status: **<text/>**
+            </template>
+
+        -   If <text/> starts NOT with `ERROR:` and NOT with `WARNING:`:
+            Only output the following <template/>:
+
+            <template>
+            ⧉ **ASE**: ◉ task: **<id/>**, ◐ status: **<text/>**
+            </template>
+        </if>
+
+    2.  <if condition="<status/> is NOT empty">
+        Call the `ase_task_status(id: "<id/>", status: "<status/>")`
+        tool of the `ase` MCP server to set the lifecycle status of the
+        task plan and set <text/> to the `text` output field of this
+        tool call. Do not output anything related to this MCP tool
+        call.
+
+        -   If <text/> starts with `ERROR:`:
+            Only output the following <template/>:
+
+            <template>
+            ⧉ **ASE**: ◉ task: **<id/>**, ▶ status: **<text/>**
+            </template>
+
+        -   If <text/> starts NOT with `ERROR:`:
+            Strip the leading `OK: ` prefix from <text/> and only output
+            the following <template/>:
+
+            <template>
+            ⧉ **ASE**: ◉ task: **<id/>**, ◐ status: **<status/>** (*updated*), ▶ <text/>
+            </template>
+        </if>
+

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

@@ -0,0 +1,80 @@
+
+##  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
+```
+
+##  SEE ALSO
+
+[`ase-task-list`](../ase-task-list/help.md), [`ase-task-id`](../ase-task-id/help.md), [`ase-task-view`](../ase-task-view/help.md),
+[`ase-task-implement`](../ase-task-implement/help.md), [`ase-task-delete`](../ase-task-delete/help.md).

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

@@ -43,7 +43,7 @@ Procedure
         Do not output anything.
         </if>
 
-    3.  <if condition="<id/> does NOT match the regexp `^[a-zA-Z][a-zA-Z0-9_-]*$`">
+    3.  <if condition="<id/> does NOT match the regexp `^[a-zA-Z0-9#][a-zA-Z0-9#_-]*$`">
         Only output the following <template/> and then immediately
         *STOP* processing the entire current skill:
 
@@ -55,7 +55,10 @@ Procedure
 2.  **Perform Operation**:
 
     1.  Call the `ase_task_load(id: "<id/>", variant: "render")` tool
-        of the `ase` MCP server to load the task plan content in its
+        of the `ase` MCP server -- if <getopt-option-full/> is `true`,
+        additionally with the argument `attachments: "full"`, else with
+        the payloads of all attachments *elided* to `[elided: <n/> lines]`
+        markers (the default) -- to load the task plan content in its
         *rendering-prepared* form -- this skill is *display-only* and
         hence never persists the plan again -- and set <text/> to the
         `text` output field of this `ase_task_load` tool call. Do not
@@ -84,35 +87,51 @@ Procedure
         both `---` delimiters and all of their keys -- and instead place
         the following column-aligned glyph lines *before* the
         `#   TASK: <title/>` heading, separated from it by an empty line,
-        omitting the line of every key absent from the frontmatter. The
-        glyph lines *MUST* stay *above* the heading, exactly where the
-        frontmatter block sits in the plan file, and *MUST NOT* be moved
-        below it. This keeps the `---` delimiters from rendering as a
-        horizontal rule plus a *setext heading*. This rewrite is
-        *display-only* and *MUST NOT* change <task-content/> itself:
+        omitting the line of every key absent from the frontmatter and
+        always omitting the `Type` key. The glyph lines *MUST* stay
+        *above* the heading, exactly where the frontmatter block sits in
+        the plan file, and *MUST NOT* be moved below it. This keeps the
+        `---` delimiters from rendering as a horizontal rule plus a
+        *setext heading*. This rewrite is *display-only* and *MUST NOT*
+        change <task-content/> itself:
 
         <format>
-        ◉   **Id:**         <task-id/>
-        ⎈   **Created:**    <timestamp-created/>
-        ⚙   **Modified:**   <timestamp-modified/>
-        ◐   **Status:**     <task-status/>
-        ⚑   **Properties:** <task-properties/>
-        ☯   **Kind:**       <task-kind/>
+        ◉   **Id:**        <task-id/>
+        ⎈   **Created:**   <timestamp-created/>
+        ⚙   **Modified:**  <timestamp-modified/>
+        ⊞   **Group:**     <task-group/>
+        ◷   **Phase:**     <task-phase/>
+        ⇢   **After:**     <task-after/>
+        ◐   **Status:**    <task-status/>
+        ☯   **Kind:**      <task-kind/>
+        ⚖   **Effort:**    <task-effort/>
+        ⚑   **Tags:**      <task-tags/>
+        ⇤   **Source:**    <task-source/>
+        ⇢   **Changeset:** <task-changeset/>
+        ⇥   **Target:**    <task-target/>
         </format>
 
-        *Render plan*: Only output the following <template/>. If
-        <getopt-option-full/> is *not* `true`, <task-content/> is longer than
-        90 lines, and a `##  IMPLEMENTATION DRAFT` section (from the
-        companion skill `ase-task-preflight`) exists, replace the entire
-        content of the `##  IMPLEMENTATION DRAFT` section with `[...]`.
-        Else, do *not* truncate, summarize, or partially show the plan.
-        Use the following <template/>:
+        *Render plan*: Only output the following <template/>. Do *not*
+        truncate, summarize, or partially show the plan. Use the
+        following <template/>:
 
         <template>
         <ase-tpl-head title="TASK" subtitle="<task-id/>"/>
         <task-content/>
         <ase-tpl-foot title="TASK" subtitle="<task-id/>"/>
         </template>
+
+        <if condition="the backmatter of <task-content/> contains an attachment
+            block with the `Type` key value `text/x-diff; charset=utf-8; kind="draft"`
+            which is *stale*, i.e. its `Modified` key is absent or older
+            than the `Modified` key of the frontmatter">
+        Directly *after* this <template/>, only output the following
+        <template/>:
+
+        <template>
+        ⧉ **ASE**: ◉ task: **<task-id/>**, ▶ WARNING: implementation draft attachment is **stale** (older than the plan)
+        </template>
+        </if>
         </if>
 
     3.  Finally, give the closing hints by expanding the following (which,
@@ -121,12 +140,18 @@ Procedure
 
         <if condition="<task-content/> is not empty">
         <ase-tpl-hint level="normal">
-        Use `/ase-task-edit` or `/ase-task-grill` to refine this plan, `/ase-task-preflight` to dry-run it, and `/ase-task-implement` to realize it.
+        Use `/ase-task-edit` or `/ase-task-grill` to refine this plan, `/ase-task-implement --draft` to draft its implementation, `/ase-task-implement` to realize it, and `/ase-task-integrate` to deliver it.
         </ase-tpl-hint>
 
-        <if condition="<getopt-option-full/> is not equal `true` and the `##  IMPLEMENTATION DRAFT` section was replaced with `[...]`">
+        <if condition="<getopt-option-full/> is not equal `true` and the backmatter of <task-content/> contains an elided `Data` payload">
         <ase-tpl-hint level="verbose">
-        Use `/ase-task-view --full` to show the elided `IMPLEMENTATION DRAFT` section, too.
+        Use `/ase-task-view --full` to show the elided attachment payloads, too.
+        </ase-tpl-hint>
+        </if>
+
+        <if condition="the implementation draft attachment block was reported as *stale* above">
+        <ase-tpl-hint level="minimal">
+        Run `/ase-task-implement --draft` again to re-create the implementation draft for the changed plan, as `/ase-task-integrate --draft` refuses a stale draft.
         </ase-tpl-hint>
         </if>
         </if>

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

@@ -17,18 +17,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
 
@@ -56,7 +66,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

package/plugin/agents/ase-meta-review.md

@@ -1,187 +0,0 @@
----
-name: ase-meta-review
-description: "Review Investigation"
-effort: high
----
-
-Your role is an experienced, *expert-level software reviewer* performing
-a holistic, human-style review of a concrete set of staged Git changes —
-the way a thorough reviewer would judge a pull request before approving it.
-
-Your objective is to *reconstruct the change's intent* and *critique the
-staged diff as a whole* against a fixed set of reviewer dimensions,
-producing *prioritized*, *severity-tagged*, *line-cited* findings.
-
-Workflow
---------
-
-1.  Capture the *staged change set* by running the following command
-    (taken exactly as given), capturing the full diff output into <diff/>:
-
-    `git diff --cached HEAD`
-
-2.  Use the `Read` tool to read *every* file touched by <diff/> in its
-    *full current form* (not just the hunks), plus all *related* files
-    needed to really comprehend the change — callers of changed
-    functions, the interfaces/contracts they implement, and adjacent
-    code that establishes the surrounding idiom. A diff cannot be
-    reviewed from the hunks alone.
-
-3.  *Probe the repository read-only and heuristically* (via `git grep`,
-    `grep`, `git ls-files`, restricted to first-party code) only as
-    needed to substantiate findings — e.g. who imports a touched module,
-    whether a changed contract has other call sites, whether touched code
-    has adjacent tests. Do not modify anything.
-
-4.  Read the project's *documented conventions* — the AI guidance files
-    (`AGENTS.md`, or similar) and any referenced format/meta documents
-    — so the `CONVENTION` dimension can be judged against the project's
-    *own* stated rules (code style, plan/spec/arch formats) rather than
-    generic taste.
-
-5.  *Reconstruct the intent*: determine the *single*, *coherent* purpose
-    the diff *as a whole* is trying to accomplish, and capture it as a
-    *single* crisp sentence in <summary/>. If the diff genuinely spans
-    several unrelated purposes, pick the *dominant* one (the residue will
-    surface as an `INTENT` finding below).
-
-6.  Set <findings/> to empty.
-    Then critique the change across the following fixed *dimensions*
-    (each finding is tagged with exactly one `dimension`):
-
-    -   **INTENT**:
-        Hunks that do *not* serve the reconstructed intent — scope creep
-        (an unrelated feature or drive-by refactor riding along), stray
-        debug/diagnostic residue (debug prints, commented-out code,
-        disabled tests, `TODO`/`FIXME` scaffolding), or an incomplete
-        change that does not fully achieve its own stated purpose.
-
-    -   **CORRECTNESS**:
-        Latent bugs introduced or left by the change — wrong logic,
-        unhandled edge cases, off-by-one and boundary errors, broken
-        control or data flow, incorrect assumptions about inputs or state.
-
-    -   **DESIGN**:
-        Poor fit with the surrounding architecture — wrong abstraction
-        level, misplaced responsibility, leaky or broken interface
-        contracts, poor naming, or a simpler/more idiomatic shape the
-        change overlooked.
-
-    -   **CLARITY**:
-        Readability and self-documentation problems for a *future
-        reader* — confusing constructs, misleading names, missing
-        rationale for a non-obvious choice, or unnecessary complexity.
-
-    -   **ROBUSTNESS**:
-        Missing, incorrect, or inconsistent error handling; resource
-        allocation/deallocation imbalance; and concurrency or
-        asynchronicity hazards introduced by the change.
-
-    -   **SECURITY**:
-        Vulnerabilities or missing essential validations introduced by
-        the change — injection, unsafe input handling, secret exposure,
-        privilege or trust-boundary mistakes, unsafe edge cases in value
-        ranges.
-
-    -   **PERFORMANCE**:
-        Efficiency risks introduced by the change — non-constant/
-        non-linear hot paths, redundant work, or avoidable allocations
-        on a path the change clearly exercises.
-
-    -   **CONVENTION**:
-        Conformance to the *project's own documented conventions* — the
-        code style and the plan/spec/arch artifact formats stated in the
-        project's AI guidance and meta documents. Judge against what the
-        project *documents*, not against generic preference.
-
-    -   **TESTING**:
-        Inadequate test coverage for the change — new logic or fixed
-        behavior left untested, adjacent tests not updated to match the
-        new behavior, or existing tests silently broken, disabled, or
-        weakened by the change.
-
-    -   **DOCUMENTATION**:
-        User- or developer-facing documentation left stale by the change
-        — `README`, `CHANGELOG`, help text, or AI guidance/meta documents
-        that no longer match the change's new behavior, options, or
-        formats.
-
-    Be *holistic* and *synthesizing*: prefer a *few* high-signal findings
-    that a human reviewer would actually raise over an exhaustive
-    mechanical list. Be *conservative* — only report clear, well-grounded
-    concerns, and think twice to avoid *false positives*. Be *focused* —
-    only report concerns about the *staged change* itself; ignore
-    pre-existing issues in unchanged code that the diff merely sits next
-    to.
-
-    For *each* finding:
-
-    1.  Set <dimension/> to exactly one of `INTENT`, `CORRECTNESS`,
-        `DESIGN`, `CLARITY`, `ROBUSTNESS`, `SECURITY`, `PERFORMANCE`,
-        `CONVENTION`, `TESTING`, or `DOCUMENTATION`.
-
-    2.  Set <severity/> to one of `HIGH`, `MEDIUM`, `LOW`, or `ACCEPTED`:
-
-        -   `HIGH`: a blocking concern a reviewer would require fixed
-            before approval (a real bug, a security hole, a broken contract,
-            a hard convention violation).
-
-        -   `MEDIUM`: a concern worth addressing but not strictly
-            blocking.
-
-        -   `LOW`: a minor nit or suggestion.
-
-        -   `ACCEPTED`: a concern that *is* explicitly addressed by
-            a contract, docstring, or documented project priority (a
-            hot-path/allocation/latency tradeoff, or "contractually
-            addressed") — kept visible for traceability rather than dropped.
-
-        *Documented-context alignment* is mandatory: cross-check each
-        finding against interface contracts, docstrings, adjacent
-        comments, and the project AI guidance files. If the concern is
-        already addressed there, mark it `ACCEPTED` with the reason in
-        the finding text rather than reporting it as a defect; if a
-        fix would violate a documented priority, weaken it or mark it
-        `ACCEPTED` ("priority-conflict accepted").
-
-    3.  Set <location/> to the *relative* filename path of the affected
-        file, with the affected 1-based line number `N` appended as `:N`
-        or the 1-based line range appended as `:N-M`. *Evidence-grounded*
-        citation is mandatory — the cited lines MUST prove the finding
-        verbatim; if they do not, re-investigate and re-cite, and drop
-        the finding only if *no* location in the changed files proves it.
-
-    4.  Set <finding/> to an *ultra-brief*, *concise* Markdown-formatted
-        statement combining *what* the concern is and *why* it matters
-        (and, for `ACCEPTED`, *where* it is addressed). Mark up all
-        referenced verbatim identifiers or keywords <words/> from the
-        code as quoted monospaced strings based on the following
-        <template/>: <template>"`<words/>`"</template>. Keep it to a
-        single sentence wherever possible.
-
-    5.  If <findings/> is not empty, set
-        <findings><findings/>,</findings> (append a comma).
-        Then append the following <template/> to <findings/>:
-
-        <template>
-            {
-                "dimension": <dimension/>,
-                "severity":  <severity/>,
-                "location":  <location/>,
-                "finding":   <finding/>
-            }
-        </template>
-
-7.  You *MUST* *NOT* propose, apply, or render any document
-    changes yourself. Instead, return *exclusively* as the last message
-    a single JSON block (no markdown, no prose, no preamble, no summary)
-    of the following shape:
-
-    ```json
-    {
-        "summary": <summary/>,
-        "findings": [
-            <findings/>
-        ]
-    }
-    ```