PR Fix

Address all outstanding issues on a GitHub Pull Request by handling both review comments and failing CI checks.

Arguments

• $ARGUMENTS: Optional PR number or URL. If not provided, uses the current branch's PR.

Task Tracking

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.

Product Principles

When making decisions about review comments, consult rules/product-principles.md. Use these principles to resolve ambiguous or subjective feedback autonomously. Only flag issues for human attention when the product principles do not provide enough guidance to make a decision.

Instructions

This is a meta-skill that orchestrates two sub-skills to comprehensively fix PR issues.

1. Run /dyad:pr-fix:comments to handle all unresolved review comments:

   • Address valid code review concerns
   • Resolve invalid concerns with explanations
   • Use product principles to resolve ambiguous feedback autonomously
   • Only flag issues for human attention when product principles are insufficient to decide

2. Run /dyad:pr-fix:ci to handle failing CI checks from the latest PR run:

   • Fix failing tests (unit and E2E)
   • Update snapshots if needed
   • Ensure all checks pass

3. Run /dyad:pr-push to commit and push all changes:

   • This step is REQUIRED. Do NOT skip it or stop before it completes.
   • It will commit changes, run lint/tests, and push to GitHub.
   • Wait for it to finish and verify the push succeeded.

4. Post Summary Comment: After both sub-skills complete, post a comment on the PR with a consolidated summary using gh pr comment. The comment should include:

   • A header indicating success (✅) or failure (❌)
   • Review comments addressed, resolved, or flagged
   • CI checks that were fixed
   • Any remaining issues requiring human attention
   • Use <details> tags to collapse verbose details (e.g., full error messages, lengthy explanations)
   • If there were any errors, include specific error messages in the collapsed details

   Error handling: If gh pr comment fails (e.g., due to network issues, rate limits, or permissions), log a warning but do not fail the entire skill if the underlying fixes were successful. The comment is informational and should not block a successful run.

   Example formats:

   Success:

   ## ✅ Claude Code completed successfully
   
   ### Summary
   - Fixed 2 review comments
   - Resolved 1 CI failure (lint error in `src/foo.ts`)
   
   <details>
   <summary>Details</summary>
   
   ... detailed information here ...
   
   </details>
   
   ---
   [Workflow run](https://github.com/dyad-sh/dyad/actions/runs/12345678)
   

   Failure:

   ## ❌ Claude Code failed
   
   ### Summary
   - Attempted to fix 2 review comments
   - Failed to resolve 1 CI failure (lint error in `src/foo.ts`)
   
   <details>
   <summary>Error Details</summary>
   
   **Error:** `lint` command failed with exit code 1.
   
   

   ... linter output ...

   
   </details>
   
   ---
   [Workflow run](https://github.com/dyad-sh/dyad/actions/runs/12345678)
   

   Note: Include a link to the workflow run at the end. If the GITHUB_REPOSITORY and GITHUB_RUN_ID environment variables are available, use them to construct the URL: https://github.com/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID. If these environment variables are not set, omit the workflow run link.