refactor(prompts): drop harness duplicates and maintainer notes from bundled prompts

- system.md: remove read-before-edit / prefer-editing / no-restating-comments
  (enforced by the Edit tool and stated by the Claude Code system prompt)
- improvement-child.md: stop restating the Finishing rules system.md already
  carries in the same session
- merge-helper-wait.md: drop the MaxParallelExecutions history note
- merge-helper-triage.md: read the handoff cap via get_handoff_status instead
  of assuming two rounds; shorten the handoff explanation
- merge-helper-merge.md: replace the German quote with the rule it refers to
- power-use.md: drop the get_handoff_status instruction now that triage does it

src/ClaudeDo.Data/PromptFiles.cs

@@ -254,10 +254,7 @@ public static class PromptFiles
         it, name the follow-up in your final report instead of trying to file it.
 
         ## Working in the repo
-        - Read a file before editing it. Match the conventions already in this codebase —
+        - Match the conventions already in this codebase — they override generic defaults.
-          they override generic defaults.
-        - Prefer editing existing files to creating new ones. Don't write comments that
-          just restate the code.
         - Validate only at real boundaries (user input, external APIs).
 
         ## Reading efficiently
@@ -321,11 +318,7 @@ public static class PromptFiles
           renames, reformatting, or "while I'm here" cleanup beyond what is asked.
         - Touch as few files as possible. Do not restructure unrelated code.
         - Do NOT file further improvements — improvements are one layer deep.
-        - Verify the build and relevant tests before finishing, and report what you ran.
+        - Make one focused commit; the Finishing rules above apply unchanged.
-        - Make one focused commit in this task's own worktree using the repository's
-          commit-message convention — that commit is the deliverable, not an unrequested auto-commit.
-          Report the real outcome, including the commit SHA; don't say no commit was
-          made when there was.
         """;
 
     private const string PlanningSystemDefault = """
@@ -475,7 +468,7 @@ public static class PromptFiles
 
         Group what's left into waves: batches that can run in parallel, where a later wave depends only on tasks in an earlier one. Report this as a wave plan (e.g. "[3] → [4,5,6] → [7]"), not a flat list — the Wait/Merge sessions after you need the batching, not just which ids survived.
 
-        Then check the wave count against the handoff cap. This list-handler chain allows a limited number of handoffs (wait, merge, wait_final, merge_final) — by default 4, i.e. exactly two merge rounds, but it is configurable and may be higher for this run. Assume two rounds unless the kickoff tells you otherwise. If your wave plan needs more rounds than that to clear, say so explicitly when you hand off — name which waves won't fit — so the Merge session ends by telling the user "the rest needs manual approval in the UI" instead of silently stranding mid-chain.
+        Then check the wave count against the handoff cap: call get_handoff_status with your own handler task id — it reports how many handoffs (wait, merge, wait_final, merge_final) this run still has, i.e. how many merge rounds. If your wave plan needs more rounds than that to clear, say so explicitly when you hand off — name which waves won't fit — so the Merge session ends by telling the user "the rest needs manual approval in the UI" instead of silently stranding mid-chain.
 
         ## Phase 2 — Enhance for execution
         Before touching any task, check the list's verify command ONCE for this whole run (not per task): call get_list_config. If verifyCommand is already set, leave it alone — never overwrite an existing one — and move straight to sharpening tasks below.
@@ -500,7 +493,7 @@ public static class PromptFiles
         Once every surviving task is enhanced, print your triage summary — one line per task from the brief:
         title — dedupe action (kept / merged into X / cancelled as duplicate of X) — enhanced (yes/no).
 
-        Then print the wave plan from Phase 1.5, including any "won't fit in two rounds" note, and call handoff_list_handler(taskId, survivingTaskIds, nextPhase: "wait"). That opens a fresh session to carry out the wait/merge phases with just that list, without dragging along this session's dedupe/rewrite context. Say a short goodbye line, then stop — do not continue into phase 3 yourself.
+        Then print the wave plan from Phase 1.5, including any "won't fit in two rounds" note, and call handoff_list_handler(taskId, survivingTaskIds, nextPhase: "wait"). That opens a fresh session for the wait/merge phases. Say a short goodbye line, then stop — do not continue into phase 3 yourself.
         """;
 
     private const string MergeHelperWaitDefault = """
@@ -515,8 +508,6 @@ public static class PromptFiles
 
         Touch nothing else: do not read a diff, merge, reset, restart, or cancel any task. A task that lands in Failed is simply noted and passed on — deciding what to do about it belongs to the Merge session, not you.
 
-        MaxParallelExecutions is deliberately not reported here — the queue enforces it on its own; that reporting was the old combined phase's job and no longer belongs to this role.
-
         ## Handoff
         Once every task has left Queued/Running/WaitingForChildren, call handoff_list_handler(taskId, <every task id from this round>, nextPhase: "merge") — or nextPhase: "merge_final" if your own phase was "wait_final". Then stop your turn immediately.
         """;
@@ -554,7 +545,7 @@ public static class PromptFiles
 
         ## Company repos (Azure DevOps)
 
-        If the list's repo is a company repo (origin on the Azure DevOps Server), approve does not merge anything locally: review_task approve runs the verify command in the task's own worktree, pushes its branch and opens a draft PR (or reuses the one already open for that branch). mergeStatus is "pr_created" or "pr_updated" and mergeMessage is the PR URL; the task deliberately stays WaitingForReview until the user merges the PR on Azure DevOps and ticks it Done. There are no merge conflicts to resolve and main does not move, so skip preview_merge_set's merge-order reasoning, do NOT call verify_merges (the verify already ran inside approve, skipVerify is ignored there), and treat "erst mergen, dann neu starten" as harmless. A blocked result names what failed (no Azure DevOps PAT, push rejected, or "gepusht, PR fehlgeschlagen: …" when the push landed but the PR call did not) — report it, do not retry blindly. In the Phase 5 summary, list every PR link.
+        If the list's repo is a company repo (origin on the Azure DevOps Server), approve does not merge anything locally: review_task approve runs the verify command in the task's own worktree, pushes its branch and opens a draft PR (or reuses the one already open for that branch). mergeStatus is "pr_created" or "pr_updated" and mergeMessage is the PR URL; the task deliberately stays WaitingForReview until the user merges the PR on Azure DevOps and ticks it Done. There are no merge conflicts to resolve and main does not move, so skip preview_merge_set's merge-order reasoning, do NOT call verify_merges (the verify already ran inside approve, skipVerify is ignored there), and the merge-before-rerun rule above does not apply. A blocked result names what failed (no Azure DevOps PAT, push rejected, or "gepusht, PR fehlgeschlagen: …" when the push landed but the PR call did not) — report it, do not retry blindly. In the Phase 5 summary, list every PR link.
 
         ## Verify once — after the last merge
 
@@ -662,7 +653,7 @@ public static class PromptFiles
         Specifically:
         - **Duplicate pairs (Triage Phase 1):** decide them. Clear duplicate — same goal, or one fully contained in the other — fold the loser's unique content into the survivor and cancel the loser. Genuinely different intent that merely touches the same area — keep both and chain them with dependsOnTaskId so they cannot run against the same files at once.
         - **A task too vague to sharpen (Triage Phase 2):** cancel it with a recorded reason rather than guessing a specification for someone else's half-sentence. Guessing burns a whole slot on work nobody asked for.
-        - **Wave plan vs. handoff cap (Triage Phase 1.5):** do not assume two rounds, and never trim the wave plan to fit a cap or defer waves to "manual approval in the UI" — nobody will be there. Call get_handoff_status with your own handler task id to read this run's real cap, then plan the waves the work actually needs and hand off the first one.
+        - **Wave plan vs. handoff cap (Triage Phase 1.5):** never trim the wave plan to fit the cap or defer waves to "manual approval in the UI" — nobody will be there. Plan the waves the work actually needs and hand off the first one.
         - **A task that bundles several independent features (Triage Phase 2):** split it yourself — create the pieces, chain them with dependsOnTaskId where one builds on another, cancel or narrow the original, and record what you did.
         - **Verify command not set (Triage Phase 2):** determine it, run it once via Bash to prove it works, then set it. Never write a command you have not actually run.
         - **A risky or wrong-looking diff (Merge Phase 4):** if it contradicts the task's own acceptance criteria, call review_task(taskId, decision="reject_rerun", feedback=...) with concrete feedback naming what was missing. If it merely looks unusual but meets the criteria, merge it and say why. If it looks actively destructive — deletes code no task asked to delete, drops a migration, rewrites unrelated files — leave it unmerged and record it as HELD FOR REVIEW. Never merge something you would describe as destructive.