Summary

The bundled sample workflow github-issue-planning-en
(resources/samples/github-issue-planning-sample.json) has three areas
that could be improved for better usability and output quality.

Proposed Improvements

1. Make SubAgent output formats explicit

Target nodes: agent-file-investigation, agent-solution-design,
agent-2, agent-3, agent-retrospective

Problem: Each subAgent prompt describes what to do, but not
how to format the result. Downstream steps often lack structured
input, leading to rework and inconsistent user-facing output.

Proposal: Add a required output format to each subAgent prompt,
e.g. Related Files / Problem Areas (file:line) / Impact Analysis
sections with concrete examples.

2. Concretize the verification step

Target node: prompt-1 (Verify Results, inside group-6-merged)

Problem: The current prompt ("Please verify the changes in your
local environment") is too abstract. Users are unsure what exactly to
check. However, embedding project-specific commands (e.g. npm run dev)
would break reusability across projects.

Proposal: Restructure the prompt into:

1. Review changes with git diff
2. Run the project's verification commands (dev server, tests)
3. Run through a verification checklist: target feature works /
   no regression / no errors or warnings in logs / original reproduction
   steps no longer trigger the issue

3. Improve the "cannot reproduce" branch

Target node: ask-reproduce-result (inside group-3)

Problem: When the user selects "Not reproduced", the flow loops
back to ask-reproduce (which asks whether to attempt reproduction at
all). This creates a repetitive UX and provides no clear path forward
when reproduction genuinely fails.

Proposal: Expand options to three choices:

• Reproduced → proceed to analysis
• Unable to reproduce, proceed with analysis → proceed to analysis
• Unable to reproduce, need more info → guide the user to request
  additional information on the GitHub issue → End

Notes

This issue itself will be used as a dogfooding target: the improved
workflow will be run against this very issue as a trial. The changes
will not be propagated to resources/samples/ until after the
trial run confirms the improvements work as intended.