/ase-task-edit

name: ase-task-edit
argument-hint: "[--help|-h] [--plan|-p <option>] [--mode|-m auto|craft|refactor|resolve|specify] [--approach|-a] [--unverified|-u] [--focus|-f <section>[,...]] [--quiet|-q] [--interactive|-i] [--next|-n <option>[,...]] [<id> | <id>: <instruction> | <instruction> | <issue-id>]"
description: >
    Iteratively edit and refine a named plan for a task through a
    conversational loop. A new plan is optionally composed along the
    chosen one of several proposed crafting, refactoring, resolution, or
    specification approaches. Each round, the current plan is shown and the user is
    asked whether to keep refining, mark the plan as done, or proceed to
    the implementation or draft. Use when the user wants to plan a task
    purely through chat-driven refinement, or wants a plan to "craft" a
    new feature, "refactor" the code base, or "resolve" a problem (also
    from a bare analyzer issue id like "P1").
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-dialog.md @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md

<purpose name="ase-task-edit"> Iteratively Edit a Task Plan </purpose>

<expand name="getopt" arg1="ase-task-edit" arg2="--plan|-p=(none|OVERWRITE|REFINE|PRESERVE) --mode|-m=(auto|craft|refactor|resolve|specify) --approach|-a --unverified|-u --focus|-f=(all|SPECIFICATION|SPEC|WHAT|DESIGN|DES|HOW|VERIFICATION|VERIFY|VER|WHEN)... --quiet|-q --interactive|-i --next|-n=(none|DONE|GRILL|DRAFT|IMPLEMENT)... --int-reuse-task --int-source-dir="> $ARGUMENTS </expand>

<objective> Establish and refine the *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. </objective>

@${CLAUDE_SKILL_DIR}/../../meta/ase-format-task.md @${CLAUDE_SKILL_DIR}/../../meta/ase-format-meta.md @${CLAUDE_SKILL_DIR}/../../meta/ase-common-task.md @${CLAUDE_SKILL_DIR}/../../meta/ase-common-approach.md @${CLAUDE_SKILL_DIR}/../../meta/ase-tenets.md

Procedure ---------

<define name="apply-refinement"> Determine the *kind of change* of the refined plan:

• If <getopt-option-mode/> is `craft`, `refactor`, `resolve`, or

`specify`: Set <task-kind/> to `CRAFTING`, `REFACTORING`, `RESOLVING`, or `SPECIFYING` correspondingly, and set <task-kind-changed>true</task-kind-changed>.

• Else if <issue-id/> is not empty (`auto` with a retrieved analyzer

issue): Set <task-kind/> to `RESOLVING`, as the refinement fixes a reported problem, and set <task-kind-changed>true</task-kind-changed>.

• Else (`auto`): Set <task-kind/> to the value of the `Kind:`

frontmatter key of <task-content/> (or, if it is absent or invalid, *infer* it from the plan content, defaulting to `CRAFTING`), and set <task-kind-changed>false</task-kind-changed>.

You *MUST* then first forget all previous internalized tenets and then freshly internalize and strictly honor the **GENERIC TENETS** and the **<task-kind/> TENETS** of the **ASE Tenets** in the following refinement of the plan. Do not output anything.

<if condition="<task-kind/> is equal `SPECIFYING`"> <expand name="task-spec-format"/> </if>

Treat the <instruction/> as a *refinement instruction* for the plan, and update <task-content/> in-place by *applying* the requested <instruction/> to the *plan*.

When refining the plan this way, preserve the overall structure of the plan and only modify what the user actually requested. Do *not* rewrite unrelated sections of the plan.

<if condition="<getopt-option-focus/> is not equal `all`"> Restrict the refinement to the sections in <sections/>: all other sections and the "backmatter" stay *unchanged* and serve as read-only context. Only if the <instruction/> inevitably requires a *foreign change* outside of these sections, apply it nevertheless, set <foreign/> to the comma-separated names of the changed sections (resp. `backmatter`), and only output the following <template/>:

<template> ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ WARNING: changed sections outside of focus: **<foreign/>** </template> </if>

<if condition="<getopt-option-int-source-dir/> is not empty"> The *code basis* of the task is the separate working copy <getopt-option-int-source-dir/> (e.g. a checkout of the branch of its `Source` key): read every project file the <instruction/> requires *exclusively* from there, instead of from the current working copy. </if>

Attachment blocks of the "backmatter" are *never* dropped by a refinement, unless the <instruction/> explicitly asks for it. Their `Data` payloads are *elided* to `[elided: <n/> lines]` markers, which you *MUST* keep *verbatim*, as `ase_task_save` restores them. Only if the <instruction/> requires reading or changing the payload of an attachment, fetch it via the `ase_task_attachment(id: "<ase-task-id/>", type: "<type/>")` tool of the `ase` MCP server (with <type/> being the value of its `Type` key), and replace its marker with the *complete* changed payload as a `|4+` (or `|4-`) literal block scalar according to the plan <format/>. *Remember* every attachment block whose content the applied <instruction/> changed as *touched*, so its `Modified` key is refreshed together with the frontmatter in step 3.1. An attachment the <instruction/> did not change stays *verbatim* -- an implementation draft attachment (`Type` key value `text/x-diff; charset=utf-8; kind="draft"`, from `ase-task-implement --draft`) hence turns *stale* through a "body" change by its `Modified` key falling behind the frontmatter, which step 3.3 reports.

<if condition="<task-kind-changed/> is equal `true`"> Set the `Kind:` frontmatter key of <task-content/> to <task-kind/> -- *creating* the key at its position in the key order of the plan <format/> if it is absent. </if>

Set <task-content-dirty>true</task-content-