Update to Agiflow

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -3,36 +3,73 @@
 description: Turn a product goal or feature request into a clear Agiflow project plan with small, testable tasks in Planning status. Use when starting a project, decomposing a feature, clarifying requirements, or converting an idea into an actionable backlog.
 ---
 
-# Agiflow Project Plan
+# Project Plan
 
-Create a focused near-term plan. Plan tasks first and leave work-unit creation to backlog grooming.
+Turn a goal into a small set of well-scoped tasks in the project's Planning status. Planning tasks are not ready for execution; `backlog-grooming` promotes them to Todo.
 
-## Workflow
+## Guardrails
 
-1. Call `get_current_scope` and resolve the target project with `list_projects` when needed.
-2. Call `get_project_detail`, `list_project_statuses`, and `list_tasks` to understand goals, configured statuses, and existing work.
-3. Ask only the questions needed to resolve the intended outcome, users, scope, constraints, and definition of done.
-4. Check for duplicate or overlapping tasks before proposing new ones.
-5. Decompose the outcome into small vertical slices that can be completed and verified independently.
-6. For each proposed task, include:
-   - Clear title
-   - Outcome-focused description
-   - At least two testable acceptance criteria
-   - Explicit in-scope and out-of-scope boundaries
-   - Priority and useful categorization tags
-   - Dependencies or sequencing notes when relevant
-7. Present the complete task plan and request approval before writing.
-8. After approval, use `batch_create_tasks` for multiple tasks or `create_task` for one task. Use the exact Planning status name returned by `list_project_statuses`.
-9. Call `list_tasks` to verify the created tasks and report any per-item errors.
-
-## Planning Rules
-
-- Do not create work units in this workflow.
-- Do not promote tasks to Todo.
-- Prefer the smallest plan that delivers useful progress.
-- Split tasks that combine unrelated outcomes or cannot be verified independently.
-- Preserve existing work and avoid duplicates.
+- Create tasks only in the Planning status. Never create them in Todo.
+- Do not create work units here. Grouping belongs to `backlog-grooming`.
+- Ask follow-up questions about vague scope before creating anything.
+- Present the plan and get explicit confirmation before calling any create tool.
+- Favor the simplest version that delivers user-visible progress. Plan the next two to four weeks, not months.
 
-## Response
+## 1. Research first
 
-Report created task titles, priorities, dependencies, and any tasks that still need user decisions. Recommend `refine-task` for ambiguous tasks or `backlog-grooming` when the Planning backlog is ready.
+1. Resolve the project with `list_projects` and read it with `get_project_detail`. If the user needs a new project, confirm the name and details, then use `create_project`.
+2. Call `list_project_statuses` to find the exact Planning status name.
+3. Check for duplicates and related work with `list_tasks` and `list_work_units`.
+4. Call `list_members` to see who could be assigned.
+
+Note whether the project is new (focus on foundations and setup) or existing (focus on integration with current work and avoiding overlap).
+
+## 2. Clarify requirements
+
+Extract and confirm:
+
+- **Who benefits and what they need**
+- **In scope and explicitly out of scope**
+- **Constraints**: deadlines, security, compatibility, performance
+- **Dependencies**: other features, external services, data
+- **How each outcome will be verified**
+
+If requirements are already clear, move on. If unknowns block confident planning, propose a time-boxed investigation task first.
+
+## 3. Decompose
+
+For fewer than five obvious tasks, skip to step 4. Otherwise:
+
+- Cut **vertical slices**: each delivers something demonstrable, not "all database work first".
+- For each slice state: what it is (one sentence), what it needs, what it produces, and "done when" (WHEN action, THEN observable result).
+- Identify the order (what must come first) and the smallest MVP subset.
+
+Present the decomposition and wait for confirmation. Do not create tasks yet.
+
+## 4. Create tasks in Planning
+
+After confirmation, use `batch_create_tasks` (or `create_task` for one) with:
+
+- **status**: the project's Planning status
+- **title**: verb-led and specific ("Add", "Fix", "Update")
+- **description**: context, constraints, and how it fits the goal; mention prerequisite tasks by title
+- **acceptanceCriteria**: two to five concrete, verifiable conditions
+- **priority**: low, medium, or high based on impact
+- **tags**: consistent categories such as `feature:billing`, `bug:checkout`, `spike:search`
+- **assignee**: optional; can be set during grooming
+
+Keep tasks small enough to finish in a short session. Include verification tasks where a criterion needs dedicated testing. Create prerequisite tasks first.
+
+## 5. Verify and summarize
+
+1. Call `list_tasks` filtered to the Planning status to confirm every task was created as intended.
+2. Summarize: number of tasks created, grouping by tag, suggested order, MVP versus full scope, open questions or risks.
+3. Recommend next steps: `refine-task` for any task that needs more depth, then `backlog-grooming` to prioritize, group, and promote.
+
+## Common mistakes
+
+- Creating tasks in Todo instead of Planning
+- Creating work units during planning
+- Horizontal slices ("all APIs first")
+- Twenty tiny tasks when five would do, or two giant ones
+- Acceptance criteria such as "works correctly"