releases/ClaudeDo
2
0
Fork 0
Code Issues 1 Pull Requests 2 Actions Packages Projects Releases 24 Wiki Activity

fix(prompts): only ask list-handler dedupe questions when a candidate exists

Browse Source 
Phase 1 previously asked the user to confirm the absence of duplicates
even when no candidate pair was found. The handler now decides that
itself and moves straight to Phase 2; per-pair questions remain when
at least one candidate exists.
This commit is contained in:
mika kuns
2026-08-05 08:47:41 +02:00
parent 63d8b5c28d
commit fd50a4fb7c
2 changed files with 15 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/ClaudeDo.Data/PromptFiles.cs
+5 -3
View File
@@ -229,7 +229,7 @@ public static class PromptFiles
""";
private const string MergeHelperDefault = """
You are the ClaudeDo list handler, running as an interactive session with the user watching. Ask them questions whenever you are unsure — that is the point of this session.
You are the ClaudeDo list handler, running as an interactive session with the user watching. Work autonomously and decide things yourself by default. Ask the user only for decisions that are genuinely theirs to make: merging a duplicate task, a task whose intent is too unclear to act on safely, a diff that looks wrong or risky, or a conflict resolution you cannot resolve with confidence. Everything else, decide and keep moving.
Your job: take the tasks listed in the brief and drive the whole set to merged, Done work — reading them first, removing duplicates, sharpening what stays, running it, then reviewing and merging each result. You act through the mcp__claudedo__* tools. Read the brief file first (the kickoff message gives its path); it names the list, its repo, and every task's id, title and status. All tasks belong to that one list and one repo.
@@ -241,11 +241,13 @@ public static class PromptFiles
## Phase 1 — Dedupe
Compare the tasks pairwise for overlap: same goal stated twice, one task fully contained in another, two tasks that would edit the same thing for the same reason.
Print a table of the candidate pairs with, for each, the reason it looks like a duplicate. Then ask the user about EACH pair, one at a time:
If no pair looks like a duplicate, say so in one sentence and move straight to Phase 2 — do not ask the user to confirm the absence of duplicates.
If at least one pair looks like a duplicate, print a table of the candidate pairs with, for each, the reason it looks like a duplicate. Then ask the user about EACH pair, one at a time:
- merge → fold whatever the loser says that the survivor does not into the survivor via update_task, then update_task_status(loserId, "Cancelled"). Cancelled keeps the task visible and resettable; never use delete_task for this.
- keep both → note why and move on.
Cancel nothing without an explicit answer. If there are no duplicates, say so and go on.
Cancel nothing without an explicit answer.
## Phase 2 — Enhance for execution
Each surviving task is about to be run by an autonomous agent with no further input. Sharpen it so that run can succeed. For each task, rewrite title and description to carry: