tododdle-mcp 3.1.0 → 3.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md
CHANGED
|
@@ -87,6 +87,14 @@ Restart Codex, open the Plugins Directory, select **ToDoddle**, and install the
|
|
|
87
87
|
|
|
88
88
|
Installing the plugin does not create or expand ToDoddle credentials, scopes, or project grants. The skill declares the separately configured `tododdle` MCP server as a dependency.
|
|
89
89
|
|
|
90
|
+
### Scheduled ToDoddle Workflows
|
|
91
|
+
|
|
92
|
+
The distributed skill includes opt-in recipes for a morning control tower, ticket review sweep, weekly backlog hygiene, roadmap summary, Agent Connection inbox follow-up, and local release verification. Each recipe defines a suggested cadence, required scopes, mutation level, prompt, duplicate controls, and approval boundaries.
|
|
93
|
+
|
|
94
|
+
Installing the plugin never creates a schedule. Ask Codex to create a named recipe, then confirm the timezone, project, cadence, and allowed mutation level. Test the prompt in a normal chat and review the first runs. Scheduled tasks can use the ToDoddle plugin and its connected MCP tools. Desktop tasks that need local files also require the project to remain available and the app to be running. See the [scheduled tasks documentation](https://learn.chatgpt.com/docs/automations).
|
|
95
|
+
|
|
96
|
+
Use scheduled ToDoddle workflows for user-level checks and reports. Keep required service operations, such as notification delivery, billing reconciliation, webhook retries, and backups, in ToDoddle's server-owned queue or cron system.
|
|
97
|
+
|
|
90
98
|
### Bounded Project Context
|
|
91
99
|
|
|
92
100
|
For substantial planning or implementation, load project context in a small, predictable sequence:
|
package/dist/compatibility.d.ts
CHANGED
|
@@ -1,9 +1,9 @@
|
|
|
1
|
-
export declare const MCP_PACKAGE_VERSION = "3.1.
|
|
1
|
+
export declare const MCP_PACKAGE_VERSION = "3.1.1";
|
|
2
2
|
export declare const MCP_COMPATIBILITY_LEVEL = 3;
|
|
3
3
|
export declare const MCP_VERSION_HEADER = "x-tododdle-mcp-version";
|
|
4
4
|
export declare const MCP_COMPATIBILITY_HEADER = "x-tododdle-mcp-compatibility";
|
|
5
5
|
export declare const MCP_REQUEST_HEADERS: {
|
|
6
|
-
readonly "x-tododdle-mcp-version": "3.1.
|
|
6
|
+
readonly "x-tododdle-mcp-version": "3.1.1";
|
|
7
7
|
readonly "x-tododdle-mcp-compatibility": string;
|
|
8
8
|
};
|
|
9
9
|
export declare function formatMcpUpdateRequiredMessage(message: string, details: unknown): string;
|
package/dist/compatibility.js
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: tododdle-workflow
|
|
3
|
-
description: Use ToDoddle as the work ledger for project boards, lanes, tickets, implementation, status updates, blockers, comments, and
|
|
3
|
+
description: Use ToDoddle as the work ledger for project boards, lanes, tickets, implementation, status updates, blockers, comments, time tracking, and safe recurring checks. Trigger when the user asks to inspect, plan, start, update, complete, report on, or schedule work managed in ToDoddle, or when repository instructions require ToDoddle updates. Do not trigger for casual discussion that does not change or review tracked work.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# ToDoddle Workflow
|
|
@@ -46,6 +46,16 @@ Keep list requests bounded and paginate rather than requesting an entire organiz
|
|
|
46
46
|
|
|
47
47
|
Do not create bookkeeping churn for tiny exploratory actions. Prefer one useful checkpoint over a stream of narration.
|
|
48
48
|
|
|
49
|
+
## Schedule Recurring Checks
|
|
50
|
+
|
|
51
|
+
When a user asks to schedule ToDoddle work, read [scheduled-workflows.md](references/scheduled-workflows.md). Use its ready-to-create recipes and safety rules.
|
|
52
|
+
|
|
53
|
+
- Create a schedule only after the user chooses a recipe, cadence, timezone, project scope, and allowed mutation level. Installing the plugin must never create or enable a schedule.
|
|
54
|
+
- Test the complete prompt in a normal chat before scheduling it. Review the first runs and narrow the prompt if it reads or changes too much.
|
|
55
|
+
- Default to read and report. Permit comments, ticket creation, or status changes only when the user explicitly selects that mutation level.
|
|
56
|
+
- Keep destructive actions, access changes, billing changes, secrets, and completion without verification outside scheduled work.
|
|
57
|
+
- Do not use a user-side scheduled task for required server operations such as notification delivery, billing reconciliation, webhook retries, or backups. Use the application's durable queue or cron system for those jobs.
|
|
58
|
+
|
|
49
59
|
## Upload Files Safely
|
|
50
60
|
|
|
51
61
|
- Use `upload_project_document` or `attach_file_to_ticket` for approved files.
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
# Scheduled ToDoddle Workflows
|
|
2
|
+
|
|
3
|
+
Use these recipes to create opt-in scheduled tasks. Do not activate a schedule during plugin installation.
|
|
4
|
+
|
|
5
|
+
## Set Up a Recipe
|
|
6
|
+
|
|
7
|
+
1. Confirm the user's timezone, cadence, project scope, and allowed mutation level.
|
|
8
|
+
2. Confirm that the ToDoddle Agent Connection grants the required project and scopes.
|
|
9
|
+
3. Replace every angle-bracket placeholder in the selected prompt.
|
|
10
|
+
4. Run the prompt once in a normal chat. Fix missing access or overly broad results.
|
|
11
|
+
5. Create the schedule. Review its first runs before allowing mutations.
|
|
12
|
+
|
|
13
|
+
Use a task in an existing chat when later runs need that chat's context. Use a standalone task when each run should start from the saved prompt. A web task can use the connected ToDoddle plugin but cannot access a local repository. A desktop task that needs local files requires the project to remain available and the app to be running.
|
|
14
|
+
|
|
15
|
+
## Safety Rules
|
|
16
|
+
|
|
17
|
+
- Default to **read and report**.
|
|
18
|
+
- Reuse verified project, board, and lane IDs from the saved prompt. Refresh ticket state on each run.
|
|
19
|
+
- Bound every list request. Follow pagination only as far as the recipe requires. State when a report is partial.
|
|
20
|
+
- Find an existing ticket before creating one. Use a stable idempotency key for any repeated additive action.
|
|
21
|
+
- Write at most one useful summary comment per run. Do not narrate tool calls.
|
|
22
|
+
- Do not delete or archive records, change access, change billing, expose secrets, or mark work complete without current verification.
|
|
23
|
+
- Stop and report a missing scope, project grant, ambiguous project, concurrency conflict, or destructive follow-up.
|
|
24
|
+
|
|
25
|
+
## Recipe: Morning Control Tower
|
|
26
|
+
|
|
27
|
+
**Suggested cadence:** Weekdays at 8:30 AM local time
|
|
28
|
+
**Required scopes:** `projects:read`, `tasks:read`
|
|
29
|
+
**Mutation level:** Read and report
|
|
30
|
+
|
|
31
|
+
```text
|
|
32
|
+
Use $tododdle-workflow for project <project ID>. Reuse the verified project ID. Read the bounded active work queue, overdue work, and unassigned work. Summarize what needs attention today under Blocked, Overdue, Unassigned, In progress, and In review. Include stable ToDoddle links. Do not create, edit, move, complete, or archive tickets. If access is missing or a result is partial, say so clearly.
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
## Recipe: Ticket Review Sweep
|
|
36
|
+
|
|
37
|
+
**Suggested cadence:** Weekdays at 10:00 AM local time
|
|
38
|
+
**Required scopes:** `projects:read`, `tasks:read`
|
|
39
|
+
**Mutation level:** Read and report
|
|
40
|
+
|
|
41
|
+
This recipe covers tickets with the `REVIEW` status. Formal review-request queues require future MCP review tools.
|
|
42
|
+
|
|
43
|
+
```text
|
|
44
|
+
Use $tododdle-workflow for project <project ID>. List active tickets with status REVIEW. Treat a ticket as stale after <number> days without an update. Read full ticket context only for stale or ambiguous results. Report the reviewer or owner action needed and include stable ToDoddle links. Do not approve, complete, reject, or comment on a ticket.
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## Recipe: Weekly Backlog Hygiene
|
|
48
|
+
|
|
49
|
+
**Suggested cadence:** Fridays at 2:00 PM local time
|
|
50
|
+
**Required scopes:** `projects:read`, `tasks:read`
|
|
51
|
+
**Mutation level:** Read and report
|
|
52
|
+
|
|
53
|
+
```text
|
|
54
|
+
Use $tododdle-workflow for project <project ID>. Inspect a bounded active ticket set for likely duplicates, missing priority, missing ownership, stale in-progress work, invalid blocker state, and unclear titles. Do not change tickets. Give a short proposed-action list with stable ToDoddle links. State the page and item limits used and say when the audit is partial.
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
## Recipe: Weekly Roadmap Summary
|
|
58
|
+
|
|
59
|
+
**Suggested cadence:** Fridays at 3:00 PM local time
|
|
60
|
+
**Required scopes:** `projects:read`, `tasks:read`
|
|
61
|
+
**Mutation level:** Read and report
|
|
62
|
+
|
|
63
|
+
```text
|
|
64
|
+
Use $tododdle-workflow for project <project ID>. Summarize meaningful ticket movement since <reporting rule, such as the last 7 days>. Group the result under Completed, Active, In review, Blocked, and New risks. Prefer counts and important changes over a full ticket dump. Include stable ToDoddle links. Do not change project state. State when bounded results make the summary partial.
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
## Recipe: Agent Inbox Follow-up
|
|
68
|
+
|
|
69
|
+
**Suggested cadence:** Every two hours during working hours
|
|
70
|
+
**Required scopes:** The scopes needed to read the replied-to records
|
|
71
|
+
**Mutation level:** Read and report
|
|
72
|
+
|
|
73
|
+
```text
|
|
74
|
+
Use $tododdle-workflow. Read the current Agent Connection inbox for unacknowledged replies. Summarize each reply with its linked ticket or Context item and the next action. Do not acknowledge a reply, change a record, or create a ticket. If there are no replies, report no action.
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
## Recipe: Local Release Verification
|
|
78
|
+
|
|
79
|
+
**Suggested cadence:** After the normal deployment window
|
|
80
|
+
**Required scopes:** `projects:read`, `tasks:read`; add `tasks:write` only for an approved evidence comment
|
|
81
|
+
**Mutation level:** Read and report, or one evidence comment when explicitly enabled
|
|
82
|
+
|
|
83
|
+
Use this recipe only in a desktop task with the correct local repository available.
|
|
84
|
+
|
|
85
|
+
```text
|
|
86
|
+
Use $tododdle-workflow for project <project ID> and ticket <ticket ID>. Refresh the ticket and inspect the local repository. Run only the approved verification checks: <checks>. Do not deploy, push, change billing, change access, or modify production data. Report the result with immutable evidence. If mutation level permits it, add one Markdown HANDOFF comment with Outcome, Verification, and Remaining. Do not complete the ticket automatically.
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
## Do Not Schedule User-Side Server Jobs
|
|
90
|
+
|
|
91
|
+
Do not use these recipes for notification delivery, email digests, subscription reconciliation, webhook retries, backups, or other required service operations. Those jobs must run in ToDoddle's server-owned queue or cron system so they do not depend on a user's computer, chat, or plugin session.
|