running-daily-tasks

name	running-daily-tasks
description	Unified daily routine: ingests messages into tasks, then guides user through task refinement and dispatch. Works in both Terminal CLI and Claude Desktop. Use this skill whenever the user wants to start their day, run a morning routine, or process their daily task workflow — even if they just ask "what should I do today?". Triggers on: "daily tasks", "daily routine", "run daily tasks", "morning routine", "start my day", "what should I do today", "daily run".
user-invocable	true

Waggle — Daily Routine

Unified daily routine that ingests messages into tasks, then guides the user through task refinement and dispatch. Works in Terminal CLI, Claude Desktop, and Cowork environments.

---

Output Discipline

This skill runs as a multi-step pipeline, but the user only needs its outcomes. Do not narrate step transitions ("Now I'll...", "X done, next Y") and do not relay protocol internals — provider detection, config/schema checks, cache state, validation plumbing, view-server pushes. Surfacing them buries what actually matters.

Emit user-facing text only when it changes something for the user:

• a prompt or confirmation that needs their input
• an error or a warning
• an intermediate result that changes the outcome (e.g., a non-PASS quality verdict and the gaps behind it — it explains why a task lands at a different status than expected)
• the final result summary

Step 0: Session Bootstrap

Invoke the bootstrap-session skill to establish the active provider and current user. Skip if active_provider and current_user are already set in this conversation.

---

Step 1: Message Intake

Execute the ingesting-messages skill.

If the user specified a lookback period (e.g., "past 3 days", "48 hours"), pass that instruction when invoking the skill so that ingesting-messages uses it as its lookback_period.

Record the result as intake_result. If the skill was skipped (e.g., no messaging MCP detected), set intake_result = "skipped (no messaging MCP)".

---

Step 2: Task Refinement (Backlog → Ready)

Promote the current user's Backlog tasks to Ready by filling quality gates.

1. Query the provider for tasks where Status = Backlog AND Assignee includes current_user.
   • Auto-Acknowledge: After fetching, for each task where Acknowledged At exists in the schema and is null, update it to the current ISO 8601 timestamp (silent, no user prompt).
2. If no tasks are found, set refinement_result = "skipped (no Backlog tasks)" and proceed to Step 2.5.
3. Present all tasks with options:

   Backlog tasks to refine:
   [Auto-plan all N tasks] [Review all one by one] [Skip]
   

   User chooses how to proceed — no artificial threshold on count.
   • Auto-plan all: Invoke the planning-tasks skill in pipeline mode with the task IDs. The task-planning-agent plans each task, choosing per task between codebase exploration and domain-template planning based on the task content. On completion, present summary: "Auto-planned N/M. K need more context."
   • Review all one by one: For each task, use the multi-round brainstorming protocol (see planning-tasks SKILL.md). Invoke the validating-fields skill for Ready before promoting.
   • Skip: Defer to next daily run.
4. For each task where planning completes successfully, run validation and promote to Ready if valid.
5. Record refinement_result — e.g., "3 auto-planned, 2 reviewed, 1 deferred".

---

Step 2.5: Blocked Task Review

Review Blocked tasks and surface actionable items.

1. Query using the provider's filter recipe for Blocked tasks owned by user (see provider SKILL.md): Status=Blocked AND (Assignee=current_user OR (Issuer=current_user AND Assignee empty))
   • Auto-Acknowledge: After fetching, for each task where Assignee includes current_user and Acknowledged At exists in the schema and is null, update it to the current ISO 8601 timestamp (silent, no user prompt).
2. If 0 results: set blocked_review_result = "skipped (no Blocked tasks)" and proceed to Step 3.
3. Separate into two groups:
   • Group A — Unblocked: ALL Blocked By tasks are Done
   • Group B — Still blocked: some Blocked By tasks remain non-Done

Group A — Unblocked tasks (action required)

For each unblocked task:

1. Read the blocker task's Agent Output (contains the hearing response or execution result).
2. Synthesize: "Blocker resolved. '{blocker_title}' result: {agent_output_summary}"
3. If main task AC starts with [DRAFT or fails semantic validation:
   • AC MUST be replaced before transitioning (not optional).
   • Propose updated AC based on the blocker's Agent Output.
   • Ask: "Move to Ready with this updated AC? [Yes / Edit first / Skip]"
4. Run validate-task-fields.sh for Ready. Transition if valid.
5. Re-evaluate Executor: "Should this be executed by AI? [cli / cowork / keep human]"

Group B — Still blocked tasks (batch summary)

Present as a single summary table (no interactive prompts per task):

Still blocked (N tasks):
| Title | Blocked By | Blocked Days | Blocker Assignee |
| ...   | ...        | X days       | {name}           |

For tasks blocked >7 days ONLY: offer batch support options: "M tasks blocked >7 days. [Ping all blocker assignee] [Escalate all to Urgent] [Skip]"

• Ping: Add a comment on each blocker task noting the stagnation.
• Escalate: Change blocker tasks' Priority to Urgent.

If any task has Error Message non-empty, append to summary.

Record blocked_review_result — e.g., "2 unblocked → Ready, 3 still blocked (1 escalated)".

---

Step 2.6: Ready Quality Health Check (v2.8.0+)

Catch tasks that reached Ready (or beyond) without going through the v2.8.0 quality gates — typically Notion UI direct edits, legacy tasks created before the upgrade, or bypassed paths.

1. Query all Ready / In Progress / In Review tasks owned by the user, skipping only those tagged worthiness:calendar-like or worthiness:info-only (already classified as non-task).

   Do not narrow this query by verdict. It is tempting to select only tasks whose Quality Verdict is empty or non-PASS, and that is what the pre-v4.0.0 version did — but it makes the two cases this sweep exists for invisible:

   • a task whose spec was hand-edited in the provider UI while keeping a matching-looking PASS, and
   • a task holding a legacy v1 PASS.

   Neither is detectable from a provider query. Deciding the first requires reading several fields, stripping the machine-written Context blocks, normalizing, and computing SHA-256 — none of which a query language does. Filtering on the verdict string would exclude exactly the tasks that look healthy and are not.

2. Hand the whole set to the reviewing-quality skill in live, cache-aware mode (batch). That skill owns the normalization and the hash, so it — not this one, and not the provider query — decides which tasks are current. Passing everything is cheap: a task with a current v2 PASS returns from cache with no LLM call, so the cost scales with the number of stale tasks, not with the size of the board. The skill fans out 5 Reviewer agents per chunk and writes the new verdicts itself.

   This is also the deliberate reason not to recompute the hash here. One implementation of it exists; a second one, kept in step by hand, would drift, and a drifted hash reports fresh tasks as stale and stale tasks as fresh rather than failing loudly.

3. If the batch reports every task as a current cache hit: set quality_health_result = "skipped (all Ready+ tasks have a current v2 PASS verdict)" and proceed to Step 3.

4. After the batch returns, sort by verdict and present the 5 oldest non-PASS tasks (avoid choice overload):

   Ready+ tasks with quality concerns (showing 5 oldest of N):
   1. [Ready] "API endpoint scaffolding" — REJECT (Goal clarity, Verifiability)
   2. [Ready] "Update README" — NEEDS_REFINEMENT (Reproducibility)
   ...
   

5. Ask the user:

   • [a] Batch refine via /planning-tasks — invokes planning-tasks in batch mode on the listed tasks.
   • [b] Skip — leave the verdicts as-is. The tasks still dispatch normally because the verdict is advisory at executing-tasks (cache-only).

---

Step 3: Task Dispatch

Execute the executing-tasks skill (normal mode). The skill will verify all tasks have complete Execution Plans, Acceptance Criteria, and other required fields before dispatch. The user will be prompted to fill any gaps and choose the execution method.

Record the result as dispatch_result.

---

Step 3.5: Ready Human Task Prompt

Surface stagnating Ready tasks with executor=human for action.

1. Query using the provider's filter recipe for Ready human tasks owned by user (see provider SKILL.md): Status=Ready AND Executor=human AND (Assignee=current_user OR (Issuer=current_user AND Assignee empty))
   • Auto-Acknowledge: After fetching, for each task where Assignee includes current_user and Acknowledged At exists in the schema and is null, update it to the current ISO 8601 timestamp (silent, no user prompt).
2. If 0 results: set human_ready_result = "skipped (no Ready human tasks)" and proceed to Step 4.
3. Run validate-task-fields.sh on each task. Note which have validation warnings (empty AC, empty Plan).
4. For each task (oldest first, max 5, note "and N more..." if truncated):
   • Calculate age in days since creation. If ≥3 days: flag as stagnating.
   • Analyze Title/Description for AI suitability.
   • Present with options:

     Ready human tasks requiring attention:
     1. [High] "Task title" (7d old) ⚠ missing AC
        → [Start now] [Fix AC/Plan] [Reassign to AI] [Delegate] [Defer to Backlog]
     

   • If task has validation warnings (empty AC/Plan): highlight [Fix AC/Plan] as recommended action.
   • [Fix AC/Plan]: Invoke planning-tasks on this task (spawns appropriate planning agent).
   • [Reassign to AI]: If non-code task detected, add info note: "Note: this is a {category} task. AI can assist with research, drafting, and structured planning." Proceed with user's choice.
   • [Start now]: Move to In Progress (run validation first).
   • [Delegate]: Invoke delegating-tasks skill.
   • [Defer to Backlog]: Move to Backlog.
5. Record human_ready_result.

---

Step 4: Summary

Output the following report:

[Daily Tasks Complete]
Message Intake:           {intake_result}
Task Refinement:          {refinement_result}
Blocked Task Review:      {blocked_review_result}
Ready Quality Check:      {quality_health_result}
Task Dispatch:            {dispatch_result}
Ready Human Tasks:        {human_ready_result}

Always respond in the user's language.