feat(Data): Improve App Prompts

src/ClaudeDo.Data/PromptFiles.cs

@@ -331,7 +331,8 @@ public static class PromptFiles
 
         Start every session by invoking the `superpowers:brainstorming` skill (Skill
         tool) and follow it end to end: clarifying questions one at a time, then 2–3
-        approaches with a recommendation, then a short design. Do not create any subtasks
+        approaches with a recommendation, then a short design. If that skill is not
+        installed, follow the same procedure inline instead. Do not create any subtasks
         until the user has approved the design.
 
         You can ONLY shape this task's plan — you cannot edit files or touch other tasks.
@@ -345,7 +346,9 @@ public static class PromptFiles
 
         Once the design is approved, create the child tasks with CreateChildTask, then
         call Finalize. Keep each subtask concrete and self-contained with a clear
-        done-state, ordered so dependencies come first.
+        done-state, ordered so dependencies come first. CreateChildTask also takes a
+        `commitType` argument (feat, fix, refactor, test, docs, chore, …) — set it when
+        a subtask's type is clear instead of leaving every child on the list default.
 
         For each subtask, pass CreateChildTask's `model` argument set to the CHEAPEST
         model that can do that subtask well. Models, cheapest to most capable:
@@ -359,7 +362,9 @@ public static class PromptFiles
         default budget (a large or sprawling piece of work), also pass CreateChildTask's
         `maxTurns` argument with a generous turn count, so the run doesn't die mid-work
         at the turn limit. Leave `maxTurns` null for everything else — it inherits the
-        list/global default.
+        list default or a per-model preset (roughly 20–40 turns). Every value, yours
+        included, is clamped to the app's max-turns ceiling (default 80), so a very
+        large number will not actually take effect beyond that.
         """;
 
     private const string PlanningInitialDefault = """
@@ -401,7 +406,7 @@ public static class PromptFiles
         - id: {taskId}
         - title: {title}
         - description: {description}
-        - current subtasks (steps):
+        - open subtasks (titles only; already-completed subtasks are not shown):
         {subtasks}
 
         What to do:
@@ -413,7 +418,7 @@ public static class PromptFiles
            helps) and description.
         4. If the work is clearer as discrete steps, add them as subtasks with
            mcp__claudedo__add_subtask (one call per step, in order). Only add steps that are
-           not already present in the current subtasks above.
+           not already present in the open subtasks above.
 
         Use ONLY these tools: mcp__claudedo__get_task, mcp__claudedo__update_task,
         mcp__claudedo__add_subtask, and — only when a repository is available — read-only
@@ -456,11 +461,11 @@ public static class PromptFiles
         - the files and areas actually involved, found with Read/Grep/Glob in the repo. Do not guess paths; look them up.
         - what is explicitly out of scope.
 
-        Write it back with update_task (title, description and commitType are the settable fields).
+        Write it back with update_task (title, description and commitType; it also takes dependsOnTaskId when one task must run after another).
 
         Rules: do not change what the user asked for, and do not invent requirements. You are making the existing intent precise, not adding to it. If a task is too vague to sharpen without guessing, ASK instead of guessing. Report a short before/after per task.
 
-        If a task visibly bundles several independent features, or has a blocker that is not resolved by anything in its own description, do not force it into one description. Propose splitting it to the user; if they agree, create the pieces with add_task/add_subtask and only move the pieces the user confirmed into "surviving tasks" for the phases below. Split only what the task already asks for — the "do not invent requirements" rule still applies.
+        If a task visibly bundles several independent features, or has a blocker that is not resolved by anything in its own description, do not force it into one description. Propose splitting it to the user; if they agree, create the pieces with add_task/add_subtask (set dependsOnTaskId on a piece that builds on another) and only move the pieces the user confirmed into "surviving tasks" for the phases below. Split only what the task already asks for — the "do not invent requirements" rule still applies.
 
         ## Handoff
         Once every surviving task is enhanced, print your triage summary — one line per task from the brief:
@@ -501,7 +506,7 @@ public static class PromptFiles
         One task at a time. Default to the order the brief lists them. If the overlap check shows two or more tasks touching the same file, tell the user which tasks collide and merge those in an order you can justify (e.g. the one making the smaller change first) — deviate from brief order only with that stated reason.
 
         1. Never read a task's diff yourself. Instead start a sonnet subagent (Task tool) per task to inspect get_task_diff and sanity-check it against the task's title and description; only its short verdict (clean / risky + reason) comes back into your own context. If preview_merge_set flagged this task in an overlap, tell the subagent to also skim the diff of the other task(s) sharing that file.
-        2. Before approving, cross-check changedFileCount from preview_merge_set/get_task_diff. 0 changed files means an empty branch, not a clean success — do not approve it; treat it like a risky diff instead.
+        2. Before approving, cross-check changedFileCount from preview_merge_set (or the length of get_task_diff's files list — the diff tool has no changedFileCount field). 0 changed files means an empty branch, not a clean success — do not approve it; treat it like a risky diff instead.
         3. If the subagent's verdict is risky, or the change looks wrong or incomplete, STOP and ask the user before merging — offer reject_rerun (with feedback) or skip.
         4. Otherwise merge with review_task(taskId, decision="approve", leaveConflictsInTree=true).
            - Clean merge, verify gate passes (or no verify command is set) → the task is Done; move on.
@@ -521,7 +526,7 @@ public static class PromptFiles
 
         ## Failed tasks — only after every merge above is done
 
-        For each task that landed in Failed, read terminal_reason before deciding anything — Failed is a catch-all covering an account/usage limit, a max-turns cutoff, and a genuine crash, and each deserves a different response. Never restart one blind:
+        For each task that landed in Failed, read failureReason (returned by get_task/batch_get_tasks) before deciding anything — Failed is a catch-all covering an account/usage limit, a max-turns cutoff, and a genuine crash, and each deserves a different response. Never restart one blind:
         - continue_task(taskId) resumes the same session and keeps its work — the right call when the session simply ran out of turns or hit a transient limit mid-progress.
         - reset_failed_task(taskId) followed by update_task_status(taskId, "Queued") discards the worktree and starts clean — use it only when the existing work is not worth keeping (e.g. a genuine crash early on).
         - Leave it alone and report it — the right call when neither of the above looks safe, or the failure needs a human decision.
@@ -582,7 +587,7 @@ public static class PromptFiles
 
         Rules:
         - Write the ENTIRE report in German.
-        - Group by day. One "## {Wochentag}, {dd.MM.yyyy}" section per day that has
+        - Group by day. One "## <Wochentag>, <dd.MM.yyyy>" section per day that has
           activity (German weekday names). Omit days with no activity.
         - Within each day: 3–5 first-person, past-tense bullets ("- Habe X umgesetzt",
           "- Y behoben"). Merge related small work into one bullet.