Update to Agiflow

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -3,39 +3,84 @@
 description: Refine an existing Agiflow task into an unambiguous, testable specification without expanding its intended outcome. Use when a task is vague, lacks acceptance criteria, has unclear scope or dependencies, or is not ready for backlog grooming.
 ---
 
-# Agiflow Refine Task
+# Refine Task
 
-Make the selected task ready for confident execution while preserving its original intent.
+Make one existing task clear enough that whoever picks it up (a person or an AI agent) can finish it without asking questions.
 
-## Workflow
+## Guardrails
 
-1. Resolve the task with `get_current_scope`, `list_projects`, `list_tasks`, or `get_task` as needed.
-2. Call `get_task` for full details and `list_task_comments` when prior decisions may affect scope.
-3. Call `list_project_statuses` and `list_members` only when status or assignment context is relevant.
-4. Evaluate the task for:
-   - Clear user or business outcome
-   - Concrete scope boundaries
-   - Objective acceptance criteria
-   - Known dependencies and blockers
-   - Appropriate priority and assignee
-   - Enough context to complete without guessing
-5. Ask focused clarification questions for unresolved decisions. Do not invent requirements.
-6. Draft the refined title, description, acceptance criteria, scope boundaries, and dependency notes.
-7. Show the proposed changes and request approval.
-8. After approval, call `update_task` with only the fields that need to change.
-9. Call `get_task` again to verify the saved result.
+- Refine the existing intent. Do not expand or shrink the outcome, and do not add criteria that belong to another task.
+- Make required context explicit instead of implied.
+- Acceptance criteria must be concrete and verifiable.
+- Show the proposed changes and get confirmation before calling `update_task` or `create_task_comment`.
+- Do not change the task's status during refinement.
 
-## Quality Test
+## 1. Select and load the task
 
-Acceptance criteria must be specific, measurable, achievable within the task, relevant to its outcome, and directly verifiable. Replace phrases such as "works correctly" or "handles errors" with observable behavior.
+- If the user gave a task identifier (for example `SHOP-12`), call `get_task` with it.
+- Otherwise call `list_tasks` for tasks not yet started (Planning or Todo; confirm names with `list_project_statuses`), show the ones with thin descriptions or few acceptance criteria, and ask the user to pick one.
+- Read comments with `list_task_comments` and, if the task belongs to a work unit, read it with `get_work_unit` for broader scope.
 
-## Guardrails
+## 2. Find the gaps
+
+Check:
+
+- Is the goal clear, and is the reason it matters stated?
+- Are acceptance criteria specific and measurable?
+- Is scope bounded (what is in and what is out)?
+- Are dependencies on other tasks and known constraints stated?
+- Could someone complete it without asking a question?
+
+Ask the user only for information that cannot be found in the task, its comments, or its project.
+
+## 3. Draft the refined description
+
+Use this structure:
+
+```markdown
+## Overview
+One or two sentences: the goal and why it matters.
+
+## Context
+Related tasks, references, constraints (security, compatibility, deadlines), and dependencies.
+
+## Implementation Notes
+Specific guidance on the expected approach, when known.
+
+## Out of Scope
+What should not be done in this task.
+```
+
+## 4. Rewrite acceptance criteria
+
+Apply the SMART test: specific, measurable, achievable in this task, relevant, testable.
+
+| Vague | Specific |
+| --- | --- |
+| Handle errors properly | Invalid input returns a clear validation message naming the field |
+| Make it fast | Page loads in under 2 seconds on the dashboard with 500 tasks |
+| Add tests | Tests cover the success path, a validation error, and an empty input |
+
+For each criterion, consider the success path, the failure path, and edge cases.
+
+## 5. Apply with confirmation
+
+Present the refined description and criteria side by side with the original. After the user approves:
+
+1. `update_task` with the new `description` and `acceptanceCriteria` (each item unchecked).
+2. `create_task_comment` summarizing what changed, the context added, and a readiness verdict.
+
+## 6. Readiness verdict
+
+- **Ready**: clear goal, SMART criteria, explicit scope, dependencies stated.
+- **Needs more info**: usable, with caveats listed in the comment.
+- **Not ready**: a required item is missing. Record the gap in the comment and tell the user what is needed.
 
-- Do not add new product requirements during refinement.
-- Do not move the task from Planning to Todo. Backlog grooming owns that transition.
-- Do not delete the task.
-- Preserve useful existing context and comments.
+When ready, recommend `backlog-grooming` to prioritize and promote the task.
 
-## Response
+## Common mistakes
 
-Summarize what changed, which ambiguities were resolved, and whether the task is ready for `backlog-grooming`.
+- Expanding scope during refinement
+- Words like "properly", "correctly", "efficiently"
+- Criteria that need subjective judgment
+- No out-of-scope section