Agiflow

View saved version →

---
name: backlog-grooming
description: Review Agiflow Planning tasks for readiness, prioritize approved work, group related tasks into work units, and promote ready tasks to Todo. Use when grooming a backlog, organizing planned tasks, creating work units, or deciding what should be executed next.
---

# Agiflow Backlog Grooming

Treat grooming as the quality gate between Planning and Todo.

## Workflow

1. Resolve the target project and call `list_project_statuses` to discover its exact status names.
2. Call `list_tasks` for Planning tasks, `list_work_units` for existing active work units, and `list_members` for assignment context.
3. Call `get_task` for tasks whose readiness, dependencies, or acceptance criteria are unclear.
4. Classify every Planning task as:
   - Ready
   - Needs refinement
   - Blocked by a dependency
   - Duplicate or obsolete
5. Require a clear outcome, sufficient context, and at least two testable acceptance criteria before promotion.
6. Propose a priority order and explain the tradeoffs.
7. Group three to eight cohesive tasks into a work unit only when they deliver one shared capability. Leave one or two related tasks standalone and split groups larger than eight.
8. Review existing work units for shared dependencies and sequencing conflicts.
9. Present the proposed promotions, work units, assignments, and dependency order. Request approval before writing.
10. After approval:
    - Use `batch_create_work_units` for approved groups.
    - Use `update_task` to move only ready, ungated tasks to the exact Todo status and set their ordering.
11. Verify with `list_tasks` and `list_work_units`.

## Guardrails

- Never promote a vague task or a task missing testable acceptance criteria.
- Never promote a downstream task whose required upstream work is incomplete.
- Do not force unrelated work into one work unit.
- Do not modify records before the user approves the proposed grooming plan.
- Recommend `refine-task` for tasks that fail readiness checks.

## Response

Report promoted tasks, created work units, items left in Planning, dependency gates, and the recommended execution order.

View saved version →

---
name: daily-standup
description: Produce a concise read-only Agiflow status summary covering completed work, work in progress, blockers, and recommended next priorities. Use for daily standups, morning checks, stakeholder updates, or a quick project pulse.
---

# Agiflow Daily Standup

Give a brief, evidence-based project pulse. Do not modify workspace data.

## Workflow

1. Call `get_current_scope` and resolve the requested project when needed.
2. Call `list_active_tasks_by_org` for current active work.
3. Call `list_work_units` for active and blocked work units.
4. Call `get_project_detail` when the summary is project-specific.
5. Call `list_members` to resolve assignee context.
6. Call `get_task`, `get_work_unit_progress`, or `list_task_comments` only when needed to confirm progress or a blocker.
7. Summarize:
   - Done or moved to Review since the latest available update
   - Current work in progress
   - Blocked or stalled items
   - Highest-priority next actions

## Priority Logic

1. Resolve blockers that prevent other work.
2. Finish existing work in progress before starting more work.
3. Select the highest-priority ready item.
4. Recommend refinement when a task is not ready.

## Output Format

Use short sections titled Done, In Progress, Blocked, and Next Up. Include task or work-unit identifiers when available. State clearly when no recent changes or blockers are found.

## Guardrails

- Remain read-only. Do not call mutation tools.
- Do not claim an item changed recently unless the returned data supports that conclusion.
- Distinguish confirmed blockers from possible signs of stalled work.
- Keep the summary scannable and end with one clear recommendation.

View saved version →

---
name: getting-started
description: Assess an authenticated Agiflow workspace and recommend the right next project-management workflow. Use when a user is new to Agiflow, asks what to do next, needs orientation, or is unsure whether to plan, refine, groom, triage, or review daily status.
---

# Getting Started with Agiflow

Act as a project-management coach. Diagnose the workspace before recommending action.

## Workflow

1. Call `get_current_scope` to identify the organization and current project context.
2. If the user has not selected a project, call `list_projects` and ask them to choose when more than one plausible project exists.
3. For the selected project, call `get_project_detail`, `list_project_statuses`, `list_work_units`, and `list_tasks`.
4. Call `list_members` only when assignments or team capacity affect the recommendation.
5. Interpret the state instead of only repeating counts.
6. Recommend one primary next workflow and explain why it fits.

## Decision Guide

- Empty project or unstructured requirements: use `project-plan`.
- Vague Planning task or unclear completion criteria: use `refine-task`.
- Ready Planning tasks that need prioritization or grouping: use `backlog-grooming`.
- Stalled, blocked, overloaded, or unhealthy work: use `triage`.
- Quick read-only progress check: use `daily-standup`.

## Response

Summarize:

- Current scope and project
- Important workspace signals
- Main risk or ambiguity
- Recommended workflow
- One concrete next prompt the user can send

## Guardrails

- Do not create or modify records during orientation.
- Do not assume status names. Read them with `list_project_statuses`.
- Ask a focused question when the desired outcome or project is unclear.
- Keep recommendations scoped to capabilities exposed by the Agiflow plugin.

View saved version →

---
name: project-plan
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

Create a focused near-term plan. Plan tasks first and leave work-unit creation to backlog grooming.

## Workflow

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.

## Response

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.

View saved version →

---
name: refine-task
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

Make the selected task ready for confident execution while preserving its original intent.

## Workflow

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.

## Quality Test

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.

## Guardrails

- 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.

## Response

Summarize what changed, which ambiguities were resolved, and whether the task is ready for `backlog-grooming`.

View saved version →

---
name: triage
description: Diagnose stalled, blocked, overloaded, or unhealthy Agiflow projects and recommend specific corrective actions. Use for project health checks, blocked work, conflicting priorities, obsolete tasks, overloaded assignees, or an unmanageable backlog.
---

# Agiflow Triage

Diagnose before prescribing. Read the workspace first and separate evidence from inference.

## Workflow

1. Call `get_current_scope` and resolve the target project when one is specified.
2. Call `list_active_tasks_by_org`, `list_work_units`, and `list_members`.
3. For relevant items, call `get_task`, `get_work_unit`, `get_work_unit_progress`, and `list_task_comments` to inspect details and documented blockers.
4. Identify:
   - Stalled tasks or work units
   - Explicit blockers and unresolved dependencies
   - Missing or vague acceptance criteria
   - High-priority unassigned work
   - Excessive work in progress
   - Obsolete or duplicate tasks
   - Priority inversions
5. Classify each finding as Blocker, Warning, or Note.
6. Recommend one specific action for each finding and explain the expected impact.
7. Present the report and ask which actions the user approves.
8. Execute only approved actions with the appropriate tools, such as `update_task`, `create_task`, `batch_create_tasks`, or `create_task_comment`.
9. Re-read affected records to verify the result.

## Mutation Rules

- Do not change anything during diagnosis.
- Document the reason with `create_task_comment` before cancelling or materially re-scoping a task.
- Use `update_task` only after approval for reassignment, priority, status, or scope changes.
- Create new tasks only when the user approves the proposed corrective work.
- Do not use deletion as a default cleanup action.

## Response

Provide a concise health summary, evidence for each finding, severity, recommended action, and the three highest-priority next steps.