From waggle
Creates, updates, deletes, and queries tasks in the configured data source. Handles task creation with required confirmations, state transitions, "next task" recommendations, and personal task dashboard. Use this skill for ANY task-related request — creating, updating, deleting, querying, listing, filtering by status/priority/assignee, marking done, blocking, assigning, changing priority, viewing personal dashboards, or asking "what's next". If the user mentions tasks in any way, use this skill. Triggers on: "add task", "create task", "update task", "done", "change status", "list tasks", "what's next", "next task", "block", "assign", "prioritize", "show tasks", "get tasks", "fetch tasks", "my tasks", "assigned to me", "show my tasks", "what are my tasks".
npx claudepluginhub kazukinagata/waggle --plugin waggleThis skill uses the workspace's default tool permissions.
You are managing tasks in the configured data source. Use the provider-specific tools for all data operations.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
You are managing tasks in the configured data source. Use the provider-specific tools for all data operations.
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.
For the full task schema (15 Core + 8 Extended fields) and state transition rules including validation, see references/schema-and-transitions.md in this directory. Always run validation before status changes — never skip it.
When the user asks "what should I do next?" or "next task":
Blocked By contains any non-Done task (unresolved dependencies)For the full task creation flow — assignee resolution, required confirmations, executor choice, questioning flow, pre-creation checklist, and status auto-determination — follow references/task-creation-flow.md in this directory.
Before starting the flow, invoke the loading-custom-instructions skill with key task-creation to populate custom_task_creation_instructions. If the returned value is non-null, the task-creation flow uses it as authoritative guidance for business-logic-dependent defaults (Tags, Priority, Assignee selection, AC/Execution Plan phrasing) on top of the standard questioning. If null, the flow proceeds with the normal defaults. See references/task-creation-flow.md Step 0.
When the user wants to change an Executor=human task to an agent:
For requests like "show me all blocked tasks" or "mark all Done tasks as archived":
After any task status change or subtask creation, check and apply automatic status cascading.
Cascading runs when:
parentTaskparentTask set)parentTask field is set or clearedRule A — All subtasks Done → Parent auto-transitions to Done:
Done, fetch all sibling tasks (tasks sharing the same parentTask)Done, update the parent's Status to Done[Auto] Status set to Done — all subtasks completedRule B — Subtask added to Done parent → Parent reverts to In Progress:
Done, update parent Status to In Progress[Auto] Status reverted to In Progress — new subtask addedRule C — Subtask re-opened → Parent reverts if it was Done:
Done to any other status, check the parent's StatusDone, update parent to In Progress[Auto] Status reverted to In Progress — subtask re-openedAfter updating task T's status:
1. If T.parentTask is null → no cascading, return
2. Fetch parent P = get_task(T.parentTask)
3. If T.status == "Done":
a. Fetch all subtasks S = query_tasks(parentTask == P.id)
b. If ALL tasks in S have status "Done" → update P.status = "Done", log in P.context
4. Else if T.status != "Done" AND P.status == "Done":
→ update P.status = "In Progress", log in P.context
5. Push updated data to view server
These auto-transitions are system-initiated and bypass normal validation (no user confirmation needed).
When the user updates a specific task (status change, field edit, etc.) and the task's Assignee includes current_user.id: if Acknowledged At exists in the schema and is null, set it to the current ISO 8601 timestamp as part of the update. Silent operation — no user prompt.
After creating, updating, or deleting tasks, push fresh data to the view server as described in the active provider's SKILL.md (Pushing Data to View Server section).
When the user asks "my tasks", "assigned to me", "show my tasks", or similar:
Use the active provider SKILL.md's "Querying Tasks" section to fetch tasks filtered by Assignee = current_user.id. The provider determines the optimal query path.
After fetching, check each returned task: if the Acknowledged At field exists in the schema and is null/empty, update the task to set Acknowledged At to the current ISO 8601 timestamp. This is a silent background operation — do not prompt the user. Batch multiple updates if possible.
Group tasks by Status and display in the following order:
For each task, show:
Dispatched At (if set)Group by Executor:
For each task, show the blocking task titles (from Blocked By relation).
List tasks awaiting review.
List titles only (collapsed to keep output concise).
After displaying the task list, suggest next actions:
Next actions:
- Execute tasks: /executing-tasks
- Manage tasks (reassign, change status, etc.): /managing-tasks
- Delegate tasks: /delegating-tasks