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

# Backlog Grooming

Review Planning tasks, confirm which are ready, prioritize them, group them into work units, and promote ready tasks to Todo. Grooming is the gate between Planning and Todo.

## Guardrails

- Only operate on tasks in the Planning status.
- Do not promote tasks with fewer than two acceptance criteria or a vague description. Suggest `refine-task` instead.
- Get the user's confirmation on readiness, priority order, and groupings before creating work units or updating tasks.
- Keep independent tasks out of work units that depend on unfinished work.

## 1. Load the backlog

1. Resolve the project (`list_projects`, `get_project_detail`) and its status names with `list_project_statuses`.
2. `list_tasks` filtered to the Planning status. Apply any tag filter the user gives (for example `feature:auth`).
3. `list_work_units` for existing organization and in-flight work.
4. `list_members` for available assignees.

If nothing is in Planning, say so and suggest `project-plan`.

## 2. Assess readiness

| Check | Required | If missing |
| --- | --- | --- |
| Two or more acceptance criteria | Yes | Needs refinement |
| Description has enough context | Yes | Needs refinement |
| Priority set | Yes | Set during grooming |
| Tags applied | Recommended | Set during grooming |
| Assignee | Optional | Set during grooming |

Sort tasks into **Ready**, **Needs refinement** (with reasons), and **Blocked** (with the blocker). Present this report. Do not promote anything that needs refinement.

## 3. Prioritize

For ready tasks, weigh:

- **Value**: user-facing work before internal tooling before cleanup
- **Risk**: uncertain work earlier, to fail fast
- **Dependencies**: prerequisites before dependents
- **Effort versus impact**: quick wins first when otherwise equal

Present a ranked list (rank, title, tags, priority) with dependency notes and quick wins. Wait for confirmation.

## 4. Group into work units

Create a work unit when three to eight related tasks deliver one capability and share the same prerequisites. Leave one or two tasks standalone. Split groups larger than eight. Do not mix tasks that can start now with tasks waiting on other unfinished work; split them.

Check existing work units in progress or review for overlap before proposing new ones.

After confirmation, call `batch_create_work_units` with, for each unit: title, type (`feature`, `epic`, or `initiative`), description of what it delivers, priority, estimated effort, and the task IDs it contains.

## 5. Promote to Todo

For each approved task, in priority order:

- `update_task` with the project's Todo status and an assignee if agreed.
- Use `reorder_tasks` (or position values) so prerequisites sit above dependents.

Tasks that still need human decisions, access, or refinement stay in Planning.

## 6. Verify and summarize

1. `list_tasks` filtered to Todo, and `list_work_units`, to confirm the result.
2. Summarize: tasks promoted, work units created (with task counts), tasks left in Planning and why, execution order across work units, assignments.
3. Recommend next steps: `refine-task` for tasks left behind, `daily-standup` to follow progress.

## Common mistakes

- Promoting tasks without acceptance criteria
- Work units with more than eight tasks, or unrelated tasks grouped together
- Skipping confirmation on priority order
- Ignoring dependency order when ordering Todo

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

# Daily Standup

Give a brief, read-only account of what needs attention, what is in progress, and the next useful action. Agiflow is the shared work record; this skill reports on it and does not change it.

## Guardrails

- Read only. Do not create comments, change statuses, reassign tasks, or delete anything during a standup.
- Label the scope (organization or project) and the snapshot time. Keep the user's reporting window when one is given. Never claim "since last check" without a known earlier boundary.
- A task's `updatedAt` is not its completion time or blocked-since time. Do not infer history from current status or a recent edit.
- A review status or a checked acceptance criterion is not proof of completion. Report evidence states as returned.
- A failed read is not an empty result. Say which reads failed or which pages were not loaded. Never say "all clear" when data is missing.

## Gather the snapshot

1. Resolve scope. If the user names a project, find it with `list_projects`. Otherwise use the current organization; `get_current_scope` confirms what the connection is bound to.
2. Call `list_tasks` with `view: "attention"` (and the project when one is resolved) for the shared prioritized queue. Keep the returned ordering; do not invent a separate urgency score. Use `total` for counts, not the visible page length, and continue with `nextOffset` when needed.
3. Read current work: `list_tasks` with `statusFilter: "active"` for a project, or `list_active_tasks_by_org` for an organization.
4. For the few most important items, call `get_task` with `view: "handoff"`. Attribute comments to their author and time instead of treating them as verified facts.
5. Use `get_organization_summary` or `get_work_unit_progress` only when a count or progress figure is needed to explain an item.

## Describe what the evidence supports

- For attention items, state the returned reason: blocked, in review, overdue, reported, rejected, or stale.
- Evidence states: `reported` means a result exists without approval; `verified` means approved evidence is current; `stale` means the task or criteria changed after the result.
- If the user asks for a historical report (for example "what finished this week") and dated history is not available, give a clearly labeled current snapshot and say the requested change count is unavailable. Do not invent baselines, completion counts, or delivery dates.

## Present the standup

Keep it short:

- **Scope and time**: organization or project name, snapshot time.
- **Needs attention**: the most important items with task identifiers, reasons, and dashboard links when returned.
- **In progress**: current work grouped by project or work unit.
- **Suggested next actions**: one or two, marked as recommendations.

Separate recorded facts from recommendations. A recommendation does not authorize a change; if the user wants to act on one, switch to the matching workflow (for example `triage` or `refine-task`).

When the attention queue read succeeded and is empty, say no tasks match the attention rules in this scope. Do not equate that with all project work being complete.

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. Read the workspace, interpret what it says about the user's situation, and recommend one next workflow. Do not just relay data.

This skill is read only. It recommends; the chosen workflow performs any changes after the user agrees.

## 1. Understand the situation

Ask only what you cannot infer from the workspace:

1. **Where are you?** New idea, existing backlog, stalled project, or mid-execution?
2. **What is unclear?** Requirements, priorities, approach, or capacity?
3. **What does "done" look like?** Can the outcome be described concretely?

## 2. Read the workspace

- `get_current_scope` to confirm the connected organization or project.
- `get_organization_summary` for project and task counts and recent activity.
- `list_projects` to choose a project, then `get_project_detail` for its goals.
- `list_project_statuses` to learn the project's status names (Planning, Todo, In Progress, Review, Done, or custom names).
- `list_work_units` and `list_tasks` to see how work is organized.
- `list_members` to see who can be assigned.

Interpret what you find. Forty tasks and no work units means work was planned but never organized. Work units with every task still in Todo means planning happened but execution has not started.

## 3. Recommend a workflow

Agiflow work moves through: **plan → refine → groom → execute → review**.

| What you observe | What it means | Recommend |
| --- | --- | --- |
| Empty project, just an idea | Requirements unknown | `project-plan` |
| Many tasks in Planning, none in Todo | Planned but not groomed | `backlog-grooming` |
| Planning tasks are vague or lack acceptance criteria | Not ready to groom | `refine-task`, then `backlog-grooming` |
| Todo tasks but no work units | Groomed but not grouped | `backlog-grooming` |
| Some work done, some blocked or stalled | Execution stalled | `triage` |
| Everything in progress, nothing done | No focus | `triage` |
| Starting the day, need orientation | Status unknown | `daily-standup` |

Workflow summaries:

- **project-plan**: turn a goal into small, testable tasks in Planning status.
- **refine-task**: make one task an unambiguous, testable specification.
- **backlog-grooming**: check readiness, prioritize, group into work units, and promote ready tasks to Todo.
- **triage**: diagnose stalled, blocked, or overloaded work and propose specific fixes.
- **daily-standup**: read-only pulse of attention items and current work.

## 4. Present the recommendation

Give a short read of the workspace (two or three observations with numbers), one recommended workflow with the reason, and an optional second choice. Ask whether to start it.

## Principles

1. Plan the next two to four weeks, not the whole journey.
2. Sequence risky and uncertain work first.
3. A task without acceptance criteria is a wish, not a plan.
4. Small batches: three to eight tasks per work unit.
5. When in doubt, refine.

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

# Project Plan

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.

## Guardrails

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

## 1. Research first

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"

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

# Refine Task

Make one existing task clear enough that whoever picks it up (a person or an AI agent) can finish it without asking questions.

## Guardrails

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

## 1. Select and load the task

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

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

When ready, recommend `backlog-grooming` to prioritize and promote the task.

## Common mistakes

- Expanding scope during refinement
- Words like "properly", "correctly", "efficiently"
- Criteria that need subjective judgment
- No out-of-scope section

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

# Triage

Find out why a project is stuck and recommend specific actions. Diagnose first, then let the user decide what to change.

## Guardrails

- Diagnose before prescribing.
- Report by severity: blockers, then warnings, then notes.
- Recommend one specific action per problem (reassign, split, refine, cancel, re-prioritize), not vague advice.
- Make no changes until the user approves specific actions.
- Before cancelling a task, record the reason with `create_task_comment`.

## 1. Load project state

1. `list_active_tasks_by_org` for all active work, or `list_tasks` with `statusFilter: "active"` for one project.
2. `list_tasks` with `view: "attention"` for the shared queue of blocked, overdue, in-review, rejected, and stale items.
3. `list_work_units` and `get_work_unit_progress` for work-unit health.
4. `list_members` for capacity.
5. `get_project_detail` and `list_project_statuses` when a project is named.
6. For stalled or blocked items, read `list_task_comments` and `get_task` to learn why.

## 2. Identify problems

- **Stalled**: in progress with no recent movement; work units whose tasks have not moved; assigned but inactive work.
- **Blocked**: blocked work units or tasks, blocker comments with no follow-up, work waiting on unfinished prerequisites.
- **Quality gaps**: tasks without acceptance criteria or with vague descriptions; unassigned high-priority tasks; work units with more than eight tasks.
- **Imbalance**: one assignee with many in-progress tasks; everything in progress and nothing done; high-priority work waiting while low-priority work is active.

Do not infer how long something has waited from `updatedAt` alone; say when timing is unknown.

## 3. Classify severity

| Severity | Meaning | Action |
| --- | --- | --- |
| **BLOCKER** | Stops progress on the critical path | Resolve now |
| **WARNING** | Creates risk or waste | Resolve soon |
| **NOTE** | Improvement opportunity | When convenient |

## 4. Recommend actions

| Problem | Action | Tools |
| --- | --- | --- |
| Task too large and stalled | Split into smaller tasks | `batch_create_tasks`, then `update_task` on the original |
| Unclear scope or no acceptance criteria | Refine | Suggest `refine-task` |
| Blocked by missing work | Create the unblocking task | `create_task` |
| Assignee overloaded | Reassign | `update_task` |
| No focus | Finish one work unit first | `update_task` priorities |
| Wrong priorities | Re-prioritize | `update_task`, `reorder_tasks` |
| Obsolete or descoped | Cancel with a documented reason | `create_task_comment`, then `update_task` |
| Todo task needs re-scoping | Move back to Planning | `update_task` |
| Urgent incoming bug | Create in Planning with a `bug:` tag and high priority | `create_task`, then suggest `backlog-grooming` |

## 5. Present the report

```
## Triage Report
Scope: [organization or project]   Date: [today]

Summary: active [N], in progress [N], blocked [N]; [N] blockers, [N] warnings, [N] notes

Blockers
1. [task or work unit id]: [problem]
   Recommendation: [action]. Impact if ignored: [effect]

Warnings
1. [id]: [problem]. Recommendation: [action]

Notes
1. [observation]: [suggestion]

Health: Healthy / Needs attention / At risk
Next steps: 1. ... 2. ... 3. ...
```

## 6. Act only with approval

Ask which actions to take. Apply only the approved ones, then re-read the affected tasks or `list_active_tasks_by_org` to confirm the result.

## Common mistakes

- Reporting status without finding causes
- Vague suggestions ("improve descriptions")
- Changing data without approval
- Ignoring blocked items or skipping their comments