Work together GUILDUO
Manage Guilduo Quests: planning, trees and completion
A Quest is easier to hand over when its completion criteria and next action are explicit. Check scheduling, lifecycle, assignment and Handoff as separate states.
Choose the right Quest kind
For the example To Do, add Review the revised message and verify it is saved as the criterion, and Read the current message as the next action. Rewards cannot be Quest Tree parents or children.
| Kind | Use | Example |
|---|---|---|
| To Do | A task completed once | Fix the help message before publication |
| Daily | A scheduled recurring routine | Review the work plan each morning |
| Habit | A repeated behavior | Record a reading session |
| Reward | A reward purchased with Gems | A break as a personal reward |
Use Backlog and scheduling
The JSON above is a create_quest input example. This tool creates work, so use it only with authorization to create a Quest. Adding dryRun to a tool that does not accept it does not make a preview.
- Use planningState: backlog for a To Do without an execution date.
- Use scheduled with on_date and a scheduledDate for work on a specific day.
- Use until_due and dueDate for work that should remain visible through its deadline.
- After saving, reread the appropriate Today, Week, Future or Backlog view. A schedule change is distinct from completion or archiving.
{
"kind": "todo",
"title": "Review the help message",
"planningState": "backlog",
"completionCriteria": "Compare old and new text and verify the saved result",
"nextAction": "Read the current message"
}Separate Quest Trees from dependencies
A Quest Tree organizes a larger goal into parents and children. For example, Publish the docs can contain Write the connection guide and Review the copy. Read the existing tree with get_quest_tree before changing it.
Dependencies describe ordering conditions. If Review the copy follows Write the connection guide, treat that relationship separately from the tree.
Only habit, daily and todo can form trees. Cycles and self-parenting are rejected; maximum depth is eight levels. Use includeArchived when reviewing stored children.
Understand completion, archiving and rewards
- A one-off To Do moves to Archive on completion. Leaving Today does not mean it was deleted.
- Dailies, Habits and recurring To Dos return to active while keeping completion history. Separate the next occurrence from past completion.
- Completing a child does not complete its parent. An accepted Handoff or Human answer does not automatically complete the source Quest.
- Completion rewards are granted once per Quest occurrence. Battle commands after earning MP are separate actions.
- Archive unneeded work and restore it to active if needed. Preserve history instead of using deletion as routine cleanup.
Find missing work and diagnose update failures
- Check All, Backlog and Archive as well as Today. Review kind, date and tag filters.
- Check for an account mismatch or a read-only reconnection state.
- Follow nextCursor in MCP results. Do not treat the first page as the complete list.
- On a conflict, read the latest Quest, refresh expectedUpdatedAt for assignment or review requests, and preview again.
Sources for this article
Edited from the public GitHub documentation. Read the original sources for specification details.
Content reviewed: · Public source revision: 5125178