/ase-task-grill

name: ase-task-grill
argument-hint: "[--help|-h] [--next|-n <option>[,...]] [<id>]"
description: >
    Interview the user relentlessly about the task plan until reaching a
    shared understanding, resolving each branch of the question decision
    tree. Use when the user wants to stress-test a plan, get grilled on
    their plan, or mentions "grill me" or "grill plan".
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-grill"> Iteratively Grill a Task Plan </purpose>

<expand name="getopt" arg1="ase-task-grill" arg2="--next|-n=(none|DONE|EDIT|IMPLEMENT|PREFLIGHT)... --int-reuse-task"> $ARGUMENTS </expand>

<objective> Interview the user relentlessly about every essential aspect of the task plan until reaching a shared understanding. </objective>

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

Procedure ---------

<define name="handoff-args"> Set <args>--int-reuse-task</args>. <if condition="<getopt-option-next/> is not equal `none`"> Set <args><args/> --next <getopt-option-next/></args> </if> </define>

1. **Determine Task:**

1. Set <id><getopt-arguments/></id> initially. 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:

1. <if condition=" <id/> matches the regexp `^[a-zA-Z][a-zA-Z0-9_-]*$` "> Set <ase-task-id><id/></ase-task-id> (set task id) and 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. <elseif condition="<id/> is NOT empty"> The argument is neither empty nor a valid task id. As this skill only accepts an optional `[<id>]` argument and *never* a free-text instruction, only output the following <template/> and then immediately *STOP* processing the entire current skill:

<template> ⧉ **ASE**: ☻ skill: **ase-task-grill**, ▶ ERROR: expected single `[<id>]` argument </template> </elseif>

2. **Determine Task Plan:**

1. Determine the current task plan content:

<if condition=" <getopt-option-int-reuse-task/> is equal `true` *and* a `ase_task_save(id: '<ase-task-id/>', ...)` tool call exists earlier in the current session "> Set <text/> to the `text` *output* field of the most recent `ase_task_save(id: '<ase-task-id/>', ...)` tool call -- this is the rendering-prepared plan content and *MUST NOT* be confused with the `text` *argument* passed into that call -- *without* calling `ase_task_load` again. Set <status>plan reused</status>. Do not output anything. </if> <else> Call the `ase_task_load(id: "<ase-task-id/>")` tool of the `ase` MCP server to load the current task plan content and set <text/> to the `text` output field of this `ase_task_load` tool call. Do not output anything related to this MCP tool call. Set <status>plan loaded</status>. </else>

• If <text/> starts with `ERROR:` or `WARNING:`:

Output the following <template/> and then immediately *STOP* processing the entire current skill:

<template> ⧉ **ASE**: ☻ skill: **ase-task-grill**, ▶ **<text/>** </template>

• If <text/> starts NOT with `ERROR:` and NOT with `WARNING:`:

Set <plan><text/></plan> (set plan to text). Calculate the number of words <words/> of <plan/>. Then output the following <template/>:

<template> ⧉ **ASE**: ◉ task: **<ase-task-id/>**, ✪ plan: **<words/>** words, ▶ status: **<status/>** </template>

2. <if condition="<plan/> is 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. </if>

3. **Iterate Over Task Plan Aspects:**

Interactively interview the user *relentlessly* about every *essential aspect* of the task plan in <plan/> *until* reaching a shared understanding and no decisions/questions are left open.

This especially means, you *MUST* clarify as many aspects as necessary to ensure that for at least the most important decisions, during a subsequent implementation, no essential freedom of choices exist any longer.

For this process, determine the <n/> essential aspects <aspect-N/> (a one or two word long short identifier like `Foo` or `Bar-Baz`) and the corresponding decision/question <question-N/> where a shared understanding is required.

Honor also the following checks for identifying the problematic aspects:

• **Fuzzy Language**:

When the user uses vague or overloaded terms instead of a precise or canonical term.

• **Conflicting Terminology**:

When the user uses a term that conflicts with the existing terminology in the code base.

• **Conflicting Code**:

When the user states how something works, check whether the current code state really agrees.

• **Non-Concrete Scenarios**:

When domain relationships are being discus