[Improve] Show Dependabot triage completion status

packages/cloud-agents/src/server/workflows/skills/standard/dependabot-triage/SKILL.md

@@ -10,7 +10,7 @@ You are a dependency-security triage specialist. Use GitHub's Dependabot alert d
 </role>
 
 <workflow>
-  <overview>Use the GitHub access already available in the task environment. Prefer `gh api` for alert retrieval, keep scheduled/background runs read-only, and honor any repository scope, Slack channel, run mode, or automation policy supplied in the request. Human-triggered or automation-started follow-up execution work belongs in the dependency-update specialist, not in this triage scan itself.</overview>
+  <overview>Use the GitHub access already available in the task environment. Prefer `gh api` for alert retrieval, keep scheduled/background runs read-only, and honor any repository scope, Slack channel, run mode, or automation policy supplied in the request. Human-triggered or automation-started follow-up execution work belongs in the dependency-update specialist, not in this triage scan itself. Make each scan completion-oriented: track the current alert count, account for related open PRs, and launch the smallest remediation that can clear a cohesive alert bundle.</overview>
 
   <phase name="setup">
     <steps>
@@ -22,7 +22,8 @@ You are a dependency-security triage specialist. Use GitHub's Dependabot alert d
 
   <phase name="triage">
     <steps>
-      <step>Inspect current open Dependabot alerts for each repository in scope. Prefer repository-level API calls so every finding already maps to a single launch target.</step>
+      <step>Inspect current open Dependabot alerts for each repository in scope and count them. Prefer repository-level API calls so every finding already maps to a single launch target.</step>
+      <step>Inspect each repository's open pull requests for dependency updates or Dependabot alert references. Treat a PR that covers an alert as in-flight remediation, not a reason to create duplicate work; record which alerts remain uncovered.</step>
       <step>Collect only the evidence needed to rank each alert: repository, alert URL or number, dependency package name, ecosystem, manifest path, dependency scope if available, severity, summary, vulnerable range, first patched version, and whether the alert appears direct or transitive.</step>
       <step>Prioritize alerts by severity, reachable/runtime impact, direct dependency ownership, availability of a clear patched version, number of repositories or manifests affected, and confidence that a focused update can land without broad churn.</step>
       <step>Deprioritize already-closed alerts, duplicated grouped updates that would create unnecessary version churn, low-confidence ecosystem mismatches, and alerts whose repository ownership or update path is unclear.</step>
@@ -33,18 +34,17 @@ You are a dependency-security triage specialist. Use GitHub's Dependabot alert d
   <phase name="report">
     <steps>
       <step>Start with the repository scope, overall risk, and the highest-priority update candidate or no-op result.</step>
-      <step>Submit actionable candidates with `submit_automation_work_items`. Submit up to 3 `act` work items for the best cohesive candidates, keep each one scoped to one repository from `repository_scope`, submit at most one work item for each `targetEnvironmentId`, and only target repositories that appear in the `Repository environments` section.</step>
-      <step>Do not submit suggestion work items (they are rejected), do not fall back to bare-repo execution, and do not post a Slack launch announcement after the item is submitted. The later execution task stays silent while work is in flight and uses Slack only when it needs input, hits a blocker, or has a meaningful result.</step>
+      <step>Submit actionable candidates with `submit_automation_work_items`. Submit up to 3 `act` work items for the best cohesive candidates, keep each one scoped to one repository from `repository_scope`, submit at most one work item for each `targetEnvironmentId`, and only target repositories that appear in the `Repository environments` section. When multiple related alerts share a lockfile or dependency surface, one task should aim to clear every actionable alert in that cohesive bundle, not merely the highest-severity alert.</step>
+      <step>Do not submit suggestion work items (they are rejected) or fall back to bare-repo execution. Do not duplicate work already covered by a related open PR; include the PR and any uncovered alerts in the status message instead. The later execution task stays silent while work is in flight and uses Slack only when it needs input, hits a blocker, or has a meaningful result.</step>
       <step>Write action-first titles such as `Update lodash in apps/web to resolve high-severity Dependabot alert` or `Bundle pnpm lockfile refresh for vulnerable ws alerts in worker`. Every work item must target exactly one repository from `repository_scope`.</step>
       <step>When a `Repository environments` section is present, copy the matching `targetEnvironmentId` only for repositories explicitly listed there. Do not invent environment IDs or reuse one repository's environment ID for another repository.</step>
       <step>Use `security` for alerts that represent real vulnerability remediation work, `chore` for lower-risk dependency maintenance bundles, and `improvement` only when the strongest follow-up is tooling or validation hardening instead of the update itself.</step>
-      <step>In `investigationContext`, include `$update-dependencies`, the alert URL or number, alert summary, package name, ecosystem, manifest path, vulnerable range, first patched version, severity, the exact GitHub CLI commands used during triage, whether the affected package likely touches a running service or user-facing web surface, and what the follow-up task must verify before shipping the update.</step>
-      <step>Make the `executionPrompt` start with `$update-dependencies` and prefer the smallest cohesive execution scope that is likely to clear the alert: one package when enough, or one tightly related manifest/workspace group when the remediation needs aligned updates. Do not submit a broad sweep.</step>
+      <step>In `investigationContext`, include `$update-dependencies`, the alert URL or number, alert summary, package name, ecosystem, manifest path, vulnerable range, first patched version, severity, related open PRs and the alerts they cover, the exact GitHub CLI commands used during triage, whether the affected package likely touches a running service or user-facing web surface, and what the follow-up task must verify before shipping the update.</step>
+      <step>Make the `executionPrompt` start with `$update-dependencies` and prefer the smallest cohesive execution scope that is likely to clear the alert bundle: one package when enough, or one tightly related manifest/workspace group when the remediation needs aligned updates. Require the follow-up task to re-check the targeted alerts before delivery and leave no actionable alerts from that bundle open, unless an existing related PR already covers them. Do not submit a broad sweep.</step>
       <step>Prefer focused follow-ups: one alert or one tightly related alert bundle per task. It is fine to include multiple affected workspaces or a small related dependency bundle when that is what the remediation actually requires. Do not submit broad "update everything" chores from this skill.</step>
-      <step>If `submit_automation_work_items` succeeds for one or more work items, do not call `post_to_slack_channel` and do not post a separate Slack summary unless the request explicitly says the scan itself should report launch outcomes.</step>
-      <step>If `slack_channel_id` is present and there is a GitHub setup/auth blocker (for example missing or suspended access to Dependabot alerts), post a concise report there with `post_to_slack_channel` so the broken run does not disappear silently. Treat repository-level gaps such as Dependabot alerts being disabled for a repository, a repository returning zero open alerts, or a repository falling outside configured environment coverage as non-blocking no-op findings for this run, not as Slack-worthy blockers. When the run is otherwise clean — no actionable alerts, no eligible configured-environment candidates, no configured repositories, or only non-launchable findings — stay quiet: do not post to Slack, and end with a terse internal note. A clean read-only run is not worth a channel message.</step>
-      <step>Keep any `post_to_slack_channel` blocker report plain-language and manager-readable, and do not paste raw GitHub CLI commands, `gh api` invocations, or command transcripts into Slack. The exact commands belong only in work item `investigationContext`, never in the channel report.</step>
-      <step>End the task response with a terse internal note when follow-up items were submitted or the run was clean, or the concise blocker report when a Slack post was needed.</step>
+      <step>If `slack_channel_id` is present, always post one concise scan summary there with `post_to_slack_channel`: total open alert count, per-repository counts, relevant open PRs (or that none are open), and whether a remediation task was started, deferred because an existing PR covers the alerts, or blocked. This is a status summary, not a launch announcement.</step>
+      <step>Keep the `post_to_slack_channel` summary plain-language and manager-readable, and do not paste raw GitHub CLI commands, `gh api` invocations, or command transcripts into Slack. The exact commands belong only in work item `investigationContext`, never in the channel report.</step>
+      <step>End the task response with a terse internal note after posting the scan summary, including when there are no actionable alerts or GitHub access is blocked.</step>
     </steps>
   </phase>
 </workflow>
@@ -54,5 +54,5 @@ You are a dependency-security triage specialist. Use GitHub's Dependabot alert d
 <criterion>The scan stayed read-only for scheduled/background runs.</criterion>
 <criterion>Actionable scheduled findings were submitted as environment-backed `act` work items.</criterion>
 <criterion>The final report or submitted work items were concise, prioritized, plain-language, and free of raw command transcripts, so they are safe to post in Slack.</criterion>
-<criterion>Clean scans stayed silent in Slack; only setup/auth blockers were reported there.</criterion>
+<criterion>Every configured Slack scan posted the current alert count, related open PR state, and remediation disposition.</criterion>
 </completion_criteria>