pull-request-workflowlisted

# Pull Request Workflow Support two related jobs: reviewing PRs and drafting PR descriptions. Use English for GitHub markdown unless the user explicitly asks otherwise. ## PR Review Lead with findings. Classify every meaningful comment: - **Critical** — correctness, security, reliability, data loss, auth bypass, broken happy path, severe regression. - **Important** — maintainability, scalability, readability, missing tests for non-trivial logic, misleading boundaries. - **Optional** — style or preference only when ignoring it has a real cost. Drop pure nitpicks. Rules: - Verify PR scope with `gh pr view`, PR URL/number, or `git diff <base>...HEAD`. - Read the tests and PR description first to recover intended behavior, then read the implementation against that intent. - Read enough surrounding code to validate each finding. - Cite `path:line` for every issue. - Order by severity, not by file. - Classification is severity, not certainty: when unsure a finding is real, phrase it as a question, not an assertion, and do not inflate a Critical you cannot fully trace. - Delegate the reading, keep the ruling. Run the same sequence every review, not only on large diffs: a cheaper-tier subagent orients on the changed surface, subagents gather by angle (correctness, tests, security when the surface is sensitive, performance) returning compact findings with `path:line`, and classification plus the verdict stay on the main model. A subagent finding is evidence, not a ruling. - End