/ase-code-refactor

name: ase-code-refactor
argument-hint: "[--help|-h] [--auto|-a] [--dry|-d] [--quick|-Q] [--next|-n <option>[,...]] [<task-id>:] <request>"
description: >
    Refactor Code:
    Use when user wants to "refactor" or "change" the code base.
user-invocable: true
disable-model-invocation: false
effort: xhigh
allowed-tools:
    - "Skill"
    - "Agent"

@${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-code-refactor"> Refactor Source Code </purpose>

<expand name="getopt" arg1="ase-code-refactor" arg2="--auto|-a --dry|-d --quick|-Q --next|-n=(none|DONE|EDIT|GRILL|PREFLIGHT|IMPLEMENT)..."> $ARGUMENTS </expand>

<if condition="<getopt-option-quick/> is equal `true`"> The `--quick`/`-Q` flag is a *shorthand alias*: set <getopt-option-auto/> to `true`, <getopt-option-dry/> to `true`, and <getopt-option-next/> to `IMPLEMENT,DELETE`. Do not output anything. </if>

<objective> *Refactor* existing artifacts the following way: <request><getopt-arguments/></request> </objective>

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

Procedure ---------

You *MUST* *NOT* call `Edit`, `Write`, `NotebookEdit`, or any filesystem-modifying tool during this entire skill. The *only* permitted way to persist artifacts is via `ase_task_save(...)`.

<flow>

1. <step id="STEP 1: Reason About Refactoring">

1. <if condition=" <request/> matches the regexp `^[a-zA-Z][a-zA-Z0-9_-]*$` "> Set <ase-task-id><request/></ase-task-id> (set task id to request) and <request></request> (set request empty), call the `ase_task_id(id: "<ase-task-id/>", session: "<ase-session-id/>")` tool from the `ase` MCP server to switch the task, and then only output the following <template/>:

<template> ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ▶ status: **task given** </template> </if>

2. <if condition=" <request/> has the format `<id/>: <text/>` AND <id/> matches the regexp `^[a-zA-Z][a-zA-Z0-9_-]*$` "> Set <request><text/></request> and <ase-task-id><id/></ase-task-id> and call the `ase_task_id(id: "<ase-task-id/>", session: "<ase-session-id/>")` tool from the `ase` MCP server to implicitly switch the task. Do not output anything. </if>

3. <if condition="<request/> is empty"> Ask the user interactively, without a special tool, for the initial request with a single question:

`**No refactoring details known yet. What is the refactoring you want to request?**`

Then set <request/> to the response of the user. </if>

4. <if condition=" <ase-task-id/> is equal `default` and <request/> is not empty "> Set <ase-task-id/> to a unique task id, derived from <request/>, which consists of two lower-case words concatenated with a `-` character. Then call the `ase_task_id(id: "<ase-task-id/>", session: "<ase-session-id/>")` tool from the `ase` MCP server to implicitly switch the task. Do not output anything. </if>

5. Report the task and request with the following <template/>:

<template> ⧉ **ASE**: ◉ task: **<ase-task-id/>** ⧉ **ASE**: ⇌ request: **<request/>** </template>

6. Figure out what the artifact refactoring <request/> is about.

7. Ask the user for clarification if the goal of this refactoring is too unclear.

8. Do not output anything else in this step, unless you asked the user.

</step>

2. <step id="STEP 2: Investigate Code Base">

1. Check the existing source files for all code which is related to the refactoring <request/>.

2. Check the architecture of the existing code base to understand the overall structures and dynamics.

3. Do not output anything in this STEP 2.

</step>

3. <step id="STEP 3: Internalize Refactoring Tenets">

1. <task-kind>REFACTORING</task-kind>

2. <expand name="code-tenets" arg1="<task-kind/>"></expand>

3. Do not output anything in this STEP 3.

</step>

4. <step id="STEP 4: Choose Refactoring Approaches">

You *MUST* perform the following sub-steps *internally* and *without any output* until and including the recommendation decision. Only sub-steps 4-7 below are allowed to produce output; sub-steps 4-6 only if <getopt-option-auto/> is equal `false` *and* <ase-project-boxing/> is *not* equal `black`.

If <getopt-option-auto/> is equal `true` or <ase-project-boxing/> is equal `black`, *skip* the reporting sub-steps 4-6 entirely (they perform no output at all) to speed up processing.

1. *Propose* a corresponding *refactoring approach*, optionally including some *alternative* refactoring approaches. Do *not* output anything in this sub-step.

2. *Reflect* on and *critique* the proposed approaches by deriving, per approach, a small set of concrete *pros* and *cons*. Do *not* output anything in this sub-step.

3. Based on the reflection, *decide* which approach to recommend and annotate it with an <annotation/> of ` ⚝ **RECOMMENDATION** ⚝`. All other approaches receive an empty <annotation/>. Do *not* output anything in this sub-step.

4. Indicate start of reporting by showing the following <template/>:

<template> <ase-tpl-head title="APPROACHES"/> </template>

5. Now report each approach with the following <template/>, inlining its pros/cons derived in sub-step 2, and do not output anything else in this step:

<template> ● **APPROACH A<n/>**<annotation/>: