Menu
Read all unresolved GitHub PR comments from trusted authors and address or resolve them appropriately.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | dyad:pr-fix:comments |
| description | Read all unresolved GitHub PR comments from trusted authors and address or resolve them appropriately. |
Read all unresolved GitHub PR comments from trusted authors and address or resolve them appropriately.
$ARGUMENTS: Optional PR number or URL. If not provided, uses the current branch's PR.You MUST use the TaskCreate and TaskUpdate tools to track your progress. At the start, create tasks for each step below. Mark each task as in_progress when you start it and completed when you finish. This ensures you complete ALL steps.
Only process review comments from these trusted authors. Comments from other authors should be ignored.
Trusted humans (collaborators):
Trusted bots:
Before categorizing review comments, read rules/product-principles.md. Use these principles to make decisions about ambiguous or subjective feedback. When a comment involves a judgment call (e.g., design direction, UX trade-offs, architecture choices), check if the product principles provide clear guidance. If they do, apply them and resolve the comment — do NOT flag it for human review. Only flag comments for human attention when the product principles do not provide enough guidance to make a confident decision.
Citing principles: When replying to threads where product principles informed your decision, explicitly cite the relevant principle by number and name (e.g., "Per Principle #4: Transparent Over Magical, ..."). When flagging for human review, cite which principles you considered and explain why they were insufficient (e.g., "Reviewed Principles #3 and #5 but neither addresses ...").
Determine the PR to work on:
$ARGUMENTS is provided:
123), use it as the PR numberhttps://github.com/owner/repo/pull/123), extract the PR number from the pathgh pr view --json number,url,title,body --jq '.'Fetch all unresolved PR review threads:
Use the GitHub GraphQL API to get all review threads and their resolution status:
gh api graphql -f query='
query($owner: String!, $repo: String!, $pr: Int!) {
repository(owner: $owner, name: $repo) {
pullRequest(number: $pr) {
reviewThreads(first: 100) {
nodes {
id
isResolved
isOutdated
path
line
comments(first: 10) {
nodes {
id
databaseId
body
author { login }
createdAt
}
}
}
}
}
}
}
' -f owner=OWNER -f repo=REPO -F pr=PR_NUMBER
Filter to only:
isResolved: false)IMPORTANT: For threads from authors NOT in the trusted list:
author { login } field)For each unresolved review thread from a trusted author, categorize it:
Read the comment(s) in the thread and determine which category it falls into. For ambiguous or subjective comments, consult rules/product-principles.md to make a decision before falling back to flagging for human review.
rules/product-principles.md. Treat these the same as valid issues — make the change and resolve the thread.Handle each category:
For valid issues:
gh api graphql -f query='
mutation($threadId: ID!) {
resolveReviewThread(input: {threadId: $threadId}) {
thread { isResolved }
}
}
' -f threadId=<THREAD_ID>
For not valid issues:
Reply to the thread explaining why the concern doesn't apply. If a product principle supports your reasoning, cite it explicitly:
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments/<COMMENT_ID>/replies \
-f body="<explanation, citing relevant product principle if applicable, e.g.: Per **Principle #2: Productionizable**, this approach is preferred because...>"
Note: {owner} and {repo} are auto-replaced by gh CLI. Replace <PR_NUMBER> with the PR number and <COMMENT_ID> with the first comment's databaseId from the thread's comments.nodes[0].databaseId field in the GraphQL response (not the thread's id).
Resolve the thread using GraphQL:
gh api graphql -f query='
mutation($threadId: ID!) {
resolveReviewThread(input: {threadId: $threadId}) {
thread { isResolved }
}
}
' -f threadId=<THREAD_ID>
Note: Replace <THREAD_ID> with the thread's id field from the GraphQL response.
For ambiguous issues:
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments/<COMMENT_ID>/replies \
-f body="🚩 **Flagged for human review**: <explanation>. Reviewed **Principle #X: Name** and **Principle #Y: Name** but neither provides clear guidance on <specific ambiguity>."
<PR_NUMBER> with the PR number and <COMMENT_ID> with the first comment's databaseId from the thread's comments.nodes[0].databaseId field in the GraphQL response.After processing all comments, verify and commit changes:
If any code changes were made:
Run /dyad:lint to ensure code passes all checks
Stage and commit the changes:
git add -A
git commit -m "Address PR review comments
- <summary of change 1>
- <summary of change 2>
...
Push the changes:
Run the /dyad:pr-push skill to lint, fix any issues, and push.
Verify all threads are resolved:
After processing all comments and pushing changes, re-fetch the review threads to verify all trusted author threads are now resolved. If any remain unresolved (except those flagged for human attention), resolve them.
Provide a summary to the user:
Report:
Post PR Overview Comment:
After the push is complete, post a top-level PR comment (NOT an inline comment) using gh pr comment with the following structure:
gh pr comment <PR_NUMBER> --body "$(cat <<'EOF'
## 🤖 Claude Code Review Summary
### PR Confidence: X/5
<one sentence rationale for the confidence score>
### Unresolved Threads
| Thread | Rationale | Link |
|--------|-----------|------|
| <brief description> | <why it couldn't be resolved, citing which principles were insufficient> | [View](<permalink>) |
_No unresolved threads_ (if none)
### Resolved Threads
| Issue | Rationale | Link |
|-------|-----------|------|
| <brief description, grouping related/duplicate threads> | <how it was resolved, citing principle if applicable> | [View](<permalink>) |
<details>
<summary>Product Principle Suggestions</summary>
The following suggestions could improve `rules/product-principles.md` to help resolve ambiguous cases in the future:
- **Principle #X: Name**: "<prompt that could be used to improve the rule, phrased as an actionable instruction>"
- ...
_No suggestions_ (if principles were clear enough for all decisions)
</details>
---
🤖 Generated by Claude Code
EOF
)"
Notes:
gh pr comment fails, log a warning but do not fail the skill.CRITICAL: Every trusted author comment MUST be either:
Do NOT leave any trusted author comments in an unhandled state.
Commit any uncommitted changes, run lint checks, fix any issues, and push the current branch.
Root-cause flaky or failing E2E tests from a specific CI run by downloading and analyzing the Playwright HTML report (traces, screenshots, errors). Use this when given a GitHub Actions run URL and asked to investigate failures. Diagnose from report artifacts first, then rebuild and rerun the affected E2E tests locally after making fixes.
Fix failing CI checks and GitHub Actions on a Pull Request.
Automatically gather flaky E2E tests from recent CI runs on the main branch and from recent PRs by wwwillchen/keppo-bot/dyad-assistant, then deflake them.
Promote the latest pre-release to a stable release by creating a release branch, bumping the version, and pushing.
Map a minified error stack trace from a production Dyad build back to original source locations using source maps.