Microsoft Post-Scenario Completion
Apply this guidance whenever a scenario completes (when complete_task returns allTasksComplete: true).
1. Present a completion summary
Show the user a concise summary of what just happened. Structure it as:
✅ **{Scenario name} complete**
**What changed:** {N} tasks completed across {M} projects.
{If failures exist: ⚠️ {F} tasks encountered issues — see details below.}
Keep it to 3–5 lines. This is an orientation, not a report. Do not list every file changed.
2. Highlight failures (if any)
If blockedTasks or failed tasks were present at completion:
- List them with a one-line description of what failed
- Do NOT paper over failures — the user needs to know what requires manual attention
3. Build the "Next Steps" section
The next-steps section combines scenario-specific suggestions (from the scenario's post-completion.md) with generic actions (defined below). You must present them in a single, consistently formatted block.
Step 3a — Load scenario-specific suggestions
If the tool result includes postCompletionInstructionsPath, read that file. It contains:
- Applicability checks the agent MUST perform before including each suggestion (e.g., check whether a package is present, read scenario-instructions.md for recorded decisions). Only include suggestions whose conditions are met.
- Description text for each applicable suggestion.
⚠️ You are the filter. The scenario file lists candidate suggestions — you must verify each one against the actual project state. Never present a suggestion without first confirming it applies. If none of the scenario-specific suggestions apply, skip this part entirely — do not show an empty section.
Use detectedSignals to shortcut applicability checks. When complete_task returns a detectedSignals field, use those pre-computed signals to determine applicability instead of scanning files with the LLM. For example, if signals include NeedsEfCoreUpgrade, you know EF6 is present without reading project files. Only fall back to LLM-based discovery when no relevant signal exists for a given check. Never tell the user you are checking signals or that "no signals are available" — this is an internal optimization invisible to the user.
Step 3b — Append generic actions (always included)
After any scenario-specific suggestions, always append these two items:
- Generate detailed change report
- Discover more opportunities
Step 3c — Format everything using the template below
Present the heading 🚀 Next Steps, then each item as a block separated by ---. Use this exact structure:
🚀 Next Steps
{emoji} **{Title}**
{1–3 sentence description explaining what this does and why it's valuable.}
Would you like me to {action verb phrase}?
---
📊 **Generate detailed change report**
I can generate a comprehensive report summarizing everything that was upgraded, including all files changed, decisions made, and validation results.
Would you like me to generate the detailed change report?
---
🔍 **Discover more modernization opportunities**
Want me to scan your solution for other modernization opportunities?
Formatting rules:
- If the user accepts the report offer, dispatch the ReportGenerator worker — do not write the report yourself and do not load a report skill. Pass the scenario folder, scenario name, and the detected signals. Relay the path it returns.
- If the user accepts the discovery offer, dispatch the ScenarioDiscovery worker and present its cards verbatim
- Each suggestion gets a relevant emoji, bold title, description paragraph, and a CTA question
- Separate items with
--- - Scenario-specific suggestions come first, generic actions last
- The description should help the user understand why they'd want this — not just what it is
4. Wait for user input
After presenting the summary and next steps, stop and wait. Do not automatically start the next scenario. The user drives what happens next.