Make suggested routine template prompts prescriptive about their final output (#13611)

* Make bug hunter routine template prescriptive about its final report

Co-authored-by: Saoud Rizwan <saoudrizwan@users.noreply.github.com>

* Make remaining routine templates prescriptive about their final output

Co-authored-by: Saoud Rizwan <saoudrizwan@users.noreply.github.com>

---------

Co-authored-by: Saoud Rizwan <saoudrizwan@users.noreply.github.com>

apps/examples/desktop-app/webview/components/views/settings/routine-templates.ts

@@ -33,9 +33,18 @@ Explicitly skip style nits, theoretical edge cases with no realistic trigger, an
 - Before opening a PR, check whether an open PR already fixes the same bug. If one exists, note that it is awaiting review with a link instead of duplicating it. If a previous fix was closed without merging, do not re-open one unless the relevant code has materially changed.
 - Only open a PR when you are highly confident the bug is real and the fix is correct. If PRs are not available in this workspace, commit the fix to a branch and describe it in your summary.
 
-## Wrap up
+## Final report
 
-Finish with a short report: what you inspected, and for each fix the bug, its impact, the root cause, and how you validated the change. If nothing clears the bar, a plain "no critical bugs found" summary is the expected outcome most runs.`;
+Your last message is the report the user reads, so write it about the code, not about your session. Do not include process narration: no environment assessment, no list of commands you ran, no "what I attempted" or "investigation summary" sections, and no restating these instructions.
+
+If you fixed bugs, write one short section per bug covering:
+- **Bug**: what is wrong and where, in one line
+- **Impact**: the concrete consequence users would hit
+- **Root cause**: the change that introduced it
+- **Fix**: what you changed, with a link to the PR or branch
+- **Validation**: the test or check that proves the fix works
+
+If nothing clears the bar (the expected outcome most runs), reply with a single line like "No critical bugs found in the N commits since the last run", optionally followed by up to three bullets on areas you inspected closely and why they are sound.`;
 
 const SECURITY_SCAN_PROMPT = `You are a scheduled security reviewer for this repository. Find medium, high, or critical vulnerabilities with a genuine end-to-end attack path, not theoretical weaknesses.
 
@@ -55,9 +64,18 @@ A finding only counts if you can walk the entire chain: who the attacker is, wha
 
 Keep a running log of past findings in a local notes file (for example \`security-findings.local.md\` in the workspace root, excluded from version control). Read it before scanning, do not re-report anything already listed, and append new validated findings after each run.
 
-## Reporting
+## Final report
 
-For each new validated finding, write up the severity, the affected file, the full attack path, and the highest-leverage remediation. Treat findings as sensitive: keep them in the local report, and do not open a PR or publish them elsewhere from this scan. If nothing new clears the bar, say so briefly and stop.`;
+Your last message is the report the user reads, so write it about the findings, not about your session: no environment assessment, no list of commands you ran, and no "investigation summary" sections.
+
+If you validated new findings, write one short section per finding covering:
+- **Severity**: medium, high, or critical
+- **Where**: the affected file and entry point
+- **Attack path**: who the attacker is, what input they control, and how it reaches the vulnerable code
+- **Impact**: what the attacker gains
+- **Remediation**: the highest-leverage fix
+
+Treat findings as sensitive: keep full details in the local notes file, and do not open a PR or publish them elsewhere from this scan. If nothing new clears the bar (the expected outcome most runs), reply with a single line like "No new vulnerabilities found", optionally noting the areas you inspected most closely.`;
 
 const DAILY_DIGEST_PROMPT = `You write a daily engineering digest for this repository.
 
@@ -79,7 +97,7 @@ Review everything that landed in the last 24 hours (commits and merged PRs) and
 
 ## Format
 
-Start with the date range covered, then 3-7 bullets of meaningful changes, then a short "Worth watching" section with 1-3 risks or pending follow-ups.`;
+Your last message is the digest itself, so send it directly: no preamble, no process narration, and no notes about how you gathered the information. Start with the date range covered, then 3-7 bullets of meaningful changes, then a short "Worth watching" section with 1-3 risks or pending follow-ups.`;
 
 const UPDATE_DOCS_PROMPT = `You are a documentation maintainer that runs on a schedule. Keep this repository's docs accurate as the code evolves.
 
@@ -100,9 +118,16 @@ Compare recent code changes against the existing documentation and close the gap
 - Explain intent and usage with concrete examples and constraints, and keep pages structured for scanning.
 - Match the style, tone, and location conventions of the docs already in this repository.
 
-## Output
+## Final report
 
-Open a focused, docs-only PR (or commit the updates to a branch if PRs are unavailable). Summarize which docs you added or updated, the code paths they now cover, and the knowledge gaps you closed. If everything is already accurate, report that and finish.`;
+Open a focused, docs-only PR (or commit the updates to a branch if PRs are unavailable).
+
+Your last message is the report the user reads, so write it about the docs, not about your session: no environment assessment or command-by-command narration. Cover:
+- **Changed**: each doc you added or updated, with a link to the PR or branch
+- **Now covers**: the code paths or behaviors the updates document
+- **Gaps closed**: what was stale, wrong, or missing before
+
+If everything is already accurate, reply with a single line saying so, optionally noting the areas you verified.`;
 
 export const ROUTINE_TEMPLATES: RoutineTemplate[] = [
 	{