Update to Agiflow

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -3,38 +3,41 @@
 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
+# Daily Standup
 
-Give a brief, evidence-based project pulse. Do not modify workspace data.
+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.
 
-## Workflow
+## Guardrails
 
-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.
+- 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.
 
-## Output Format
+## Gather the snapshot
 
-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.
+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.
 
-## Guardrails
+## 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`).
 
-- 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.
+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.