Verify Pr

Verify PR Skill

Use this skill when an engineer asks to "check my PR", "is this ready for review", "verify PR",

or before requesting reviewers. It provides a structured assessment that the engineer acts on.

Repository Context

LogicAppsUX is a pnpm + turbo monorepo with this structure:

• libs/ — shared libraries (designer, designer-ui, data-mapper-v2, logic-apps-shared, etc.)
• apps/ — applications (vs-code-designer, vs-code-react, Standalone, iframe-app)
• e2e/ — end-to-end tests
• .squad/ — agent squad configuration, playbooks, knowledge

Build and test commands use turbo:

• pnpm turbo run build — full build
• pnpm turbo run test:lib — unit tests
• pnpm turbo run lint — linting

What This Skill Checks

1. Title Format

The PR title must start with one of: feat:, fix:, chore:, refactor:, perf:, docs:, test: — with an optional scope in parentheses.

Good: feat(designer): add conditional action branching

Good: fix(data-mapper): resolve schema loading for nested arrays

Good: chore(ci): update pnpm lock workflow

Good: fix: resolve token picker overflow in dark theme

Bad: Update API endpoint (too vague, no prefix)

Bad: [WIP] working on stuff (no prefix, not descriptive)

2. Description Template

The PR body must include these sections with real content (not just placeholders):

| Section | Required? | What to check |

|---------|-----------|---------------|

| Commit Type | Yes | At least one [x] selected (feat, fix, refactor, perf, docs, test, chore) |

| Risk Level | Yes | Exactly one [x] selected. Must match risk:* label. |

| What & Why | Yes | >50 chars of actual content explaining the change |

| Impact of Change | Yes | At least one of Users/Developers/System has content |

| Test Plan | For code PRs | At least one testing approach selected. If unit/e2e checked, verify tests exist in the diff. |

| Screenshots/Videos | For UI changes | Required when PR changes libs/designer-ui/src/ or libs/designer/src/ (non-test files) |

| Contributors | Optional | Nudge if blank — remind to credit PMs/designers |

3. Risk Label

• PR must have exactly one label matching risk:low, risk:medium, or risk:high
• The label must match what's selected in the Risk Level section
• Estimate what the risk SHOULD be based on the diff:
• High: security/auth changes, breaking API changes, credential handling, libs/logic-apps-shared core utilities that many packages depend on
• Medium: libs/logic-apps-shared (shared across monorepo), apps/vs-code-designer (extension distribution), state management changes, new dependencies, CI/infra, multi-package changes
• Low: docs, tests only, single-component UI fixes, config changes, generated files, libs/designer-ui cosmetic changes
• If declared risk is lower than estimated, flag it clearly

4. Review Threads

For each unresolved review thread:

• Read the comment carefully — understand what the reviewer is actually asking
• Classify it:
• Blocking bug — reviewer found a real issue that must be fixed
• Design question — reviewer wants clarification on approach
• Suggestion — reviewer proposes an improvement, not required
• Nit — style/naming preference, non-blocking
• Outdated — the code has changed since the comment was made
• Explain to the engineer what the reviewer wants and why
• Suggest a response — but let the engineer decide:
• For bugs: "This needs a fix — here's what to change: ..."
• For questions: "The reviewer is asking about X. You could respond with: ..."
• For suggestions: "This is optional. The tradeoff is ... You can accept or explain why not."
• For outdated: "This was about old code. Verify it's fixed, then resolve."

Do NOT auto-fix or auto-resolve. The engineer should understand each comment and make an informed decision.

5. CI Status

Check all CI check runs:

• List any failures with the job name and a brief explanation of what likely failed
• For passing checks, just confirm "all green"
• If PR desc check failed, explain which sections need updating
• Cross-reference with ci-sentinel: If CI failures are complex or flaky, recommend invoking @ci-sentinel for deeper diagnosis with log analysis

6. Coverage Report

• Check if the pr-coverage.yml workflow has posted its comment (look for the coverage report comment)
• If coverage decreased, flag it and identify which changed files lack test coverage
• If coverage report is not yet posted, note it as pending
• Do NOT duplicate what pr-coverage already reports — just reference it as part of readiness

7. Merge Readiness

After checking everything, give a clear verdict:

## PR Readiness: [READY / NOT READY / NEEDS ATTENTION]

Title: fix(designer): resolve token picker overflow
Description: all sections filled
Risk: medium (declared) matches medium (estimated — touches libs/designer/)
Label: risk:medium present
CI: 14/14 checks green
Coverage: pr-coverage reports 87% on changed files (above threshold)
Review threads: 3 unresolved (1 blocking, 1 question, 1 nit)
Screenshots: provided (before/after token picker)

### Unresolved Threads

#### Thread 1 — Blocking (libs/designer-ui/src/tokenPicker/index.tsx:147)
**Reviewer says:** "This overflow fix might clip the dropdown in narrow panels. Have you tested in the VS Code webview?"
**What this means:** The reviewer is concerned about a different host environment where the panel may be narrower.
**Suggested action:** Test in the VS Code extension (Standalone host may be wider). If confirmed working, reply with a screenshot from VS Code.

#### Thread 2 — Question (libs/designer/src/core/state/tokens/tokenSlice.ts:22)
**Reviewer says:** "Why not use the existing selectTokensByNodeId selector?"
**What this means:** The reviewer wants to understand the design choice.
**Suggested response:** "selectTokensByNodeId returns all token types. This PR needs only expression tokens for the overflow fix, so a new selector avoids re-renders from unrelated token updates."

#### Thread 3 — Nit (libs/designer-ui/src/tokenPicker/styles.ts:88)
**Reviewer says:** "Consider using tokens.spacingHorizontalM instead of 12px"
**What this means:** Minor style preference to use Fluent design tokens instead of hardcoded pixels.
**Suggested action:** Accept — using tokens is the project convention. Or respond "Kept as px because this needs to match a fixed-size icon."

Cross-References with Existing Agents

• ci-sentinel: For complex CI failures, recommend the engineer invoke ci-sentinel for log-level diagnosis
• customer-repro-tester: For bug-fix PRs, check if there's a linked customer issue. If so, recommend asking customer-repro-tester to validate the fix against the original repro steps
• pr-orchestrator: This skill feeds INTO pr-orchestrator's lifecycle — verify-pr checks readiness, pr-orchestrator manages the full PR flow
• release-scribe: If the PR body needs rewriting, reference release-scribe's conventions

How to Invoke

Engineers can use this skill in Copilot Chat:

• "Load verify-pr and check my PR"
• "Is PR #4521 ready for review?"
• "What do I need to fix before merging?"

The skill works with the current branch's PR automatically, or with a specific PR number.

Continuous Monitoring

Once invoked, the skill should keep monitoring until the PR is fully green:

• Run the initial verification (title, body, labels, threads, CI, coverage)
• Report findings to the engineer
• After the engineer makes changes (commits, edits description, responds to threads):
• Re-check what's changed
• Report updated status: "2 of 3 issues resolved. Remaining: ..."
• Repeat until ALL of these are true:
• Title matches prefix format
• Description passes all template sections
• Risk label present and matches body + estimated risk
• All review threads resolved (or classified as non-blocking with response)
• CI checks all green
• pr-coverage report posted and above threshold
• Screenshots present (if UI changes detected in libs/designer-ui or libs/designer)
• Then report: "PR is ready for review/merge. All checks pass."

The monitoring loop should feel like a helpful co-pilot sitting next to the engineer, not a nagging bot. After each check:

• Only report what CHANGED since last check
• Celebrate progress ("Risk level fixed — 2 items remaining")
• If the engineer asks to stop monitoring: stop immediately

Important

• Never auto-fix code — explain what needs to change and let the engineer decide
• Never auto-resolve threads — help the engineer understand what to respond
• Always explain WHY a comment was made, not just WHAT to do
• Distinguish blocking from non-blocking — engineers should know what MUST be fixed vs what's optional
• Check the diff — verify review comments are still relevant to the current code
• Respect pr-coverage — don't duplicate its analysis; reference its comment as authoritative for coverage data