playbooks

home / skills / dyad-sh / dyad / pr-push

pr-push skill

/.claude/skills/pr-push

This skill commits uncommitted changes, runs linting, fixes issues, and pushes the current feature branch to GitHub autonomously.

npx playbooks add skill dyad-sh/dyad --skill pr-push

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
8.0 KB
---
name: dyad:pr-push
description: Commit any uncommitted changes, run lint checks, fix any issues, and push the current branch.
---

# PR Push

Commit any uncommitted changes, run lint checks, fix any issues, and push the current branch.

**IMPORTANT:** This skill MUST complete all steps autonomously. Do NOT ask for user confirmation at any step. Do NOT stop partway through. You MUST push to GitHub by the end of this skill.

## 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.

## Instructions

1. **Ensure you are NOT on main branch:**

   Run `git branch --show-current` to check the current branch.

   **CRITICAL:** You MUST NEVER push directly to the main branch. If you are on `main` or `master`:
   - Generate a descriptive branch name based on the uncommitted changes (e.g., `fix-login-validation`, `add-user-settings-page`)
   - Create and switch to the new branch: `git checkout -b <branch-name>`
   - Report that you created a new branch

   If you are already on a feature branch, proceed to the next step.

2. **Check for uncommitted changes:**

   Run `git status` to check for any uncommitted changes (staged, unstaged, or untracked files).

   If there are uncommitted changes:
   - **When in doubt, `git add` the files.** Assume changed/untracked files are related to the current work unless they are egregiously unrelated (e.g., completely different feature area with no connection to the current changes).
   - Only exclude files that are clearly secrets or artifacts that should never be committed (e.g., `.env`, `.env.*`, `credentials.*`, `*.secret`, `*.key`, `*.pem`, `.DS_Store`, `node_modules/`, `*.log`).
   - **Do NOT stage `package-lock.json` unless `package.json` has also been modified.** Changes to `package-lock.json` without a corresponding `package.json` change are spurious diffs (e.g., from running `npm install` locally) and should be excluded. If `package-lock.json` is dirty but `package.json` is not, run `git checkout -- package-lock.json` to discard the changes.
   - Stage and commit all relevant files with a descriptive commit message summarizing the changes.
   - Keep track of any files you ignored so you can report them at the end.

   If there are no uncommitted changes, proceed to the next step.

3. **Run lint checks:**

   Run these commands to ensure the code passes all pre-commit checks:

   ```
   npm run fmt && npm run lint:fix && npm run ts
   ```

   If there are errors that could not be auto-fixed, read the affected files and fix them manually, then re-run the checks until they pass.

   **IMPORTANT:** Do NOT stop after lint passes. You MUST continue to step 4.

4. **Run tests:**

   Run the test suite to ensure nothing is broken:

   ```
   npm test
   ```

   If any tests fail, fix them before proceeding. Do NOT skip failing tests.

   **IMPORTANT:** Do NOT stop after tests pass. You MUST continue to step 5.

5. **If lint made changes, amend the last commit:**

   If the lint checks made any changes, stage and amend them into the last commit:

   ```
   git add -A
   git commit --amend --no-edit
   ```

   **IMPORTANT:** Do NOT stop here. You MUST continue to step 6.

6. **Push the branch (REQUIRED):**

   You MUST push the branch to GitHub. Do NOT skip this step or ask for confirmation.

   **CRITICAL:** You MUST NEVER run `git pull --rebase` (or any `git pull`) from the fork repo. If you need to pull/rebase, ONLY pull from the upstream repo (`dyad-sh/dyad`). Pulling from a fork can overwrite local changes or introduce unexpected commits from the fork's history.

   First, determine the correct remote to push to:

   a. Check if the branch already tracks a remote:

   ```
   git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
   ```

   If this succeeds (e.g., returns `origin/my-branch` or `someuser/my-branch`), the branch already has an upstream. Just push:

   ```
   git push --force-with-lease
   ```

   b. If there is NO upstream, check if a PR already exists and determine which remote it was opened from:

   First, get the PR's head repository as `owner/repo`:

   ```
   gh pr view --json headRepository --jq .headRepository.nameWithOwner
   ```

   **Error handling:** If `gh pr view` exits with a non-zero status, check whether the error indicates "no PR found" (expected — proceed to step c) or another failure (auth, network, ambiguous branch — report the error and stop rather than silently falling back).

   If a PR exists, find which local remote corresponds to that `owner/repo`. List all remotes and extract the `owner/repo` portion from each URL:

   ```
   git remote -v
   ```

   For each remote URL, extract the `owner/repo` by stripping the protocol/hostname prefix and `.git` suffix. This handles all URL formats:
   - SSH: `[email protected]:owner/repo.git` → `owner/repo`
   - HTTPS: `https://github.com/owner/repo.git` → `owner/repo`
   - Token-authenticated: `https://x-access-token:[email protected]/owner/repo.git` → `owner/repo`

   Match the PR's `owner/repo` against each remote's extracted `owner/repo`. If multiple remotes match (e.g., both SSH and HTTPS URLs for the same repo), prefer the first match. If no remote matches (e.g., the fork is not configured locally), proceed to step c.

   Push to the matched remote:

   ```
   git push --force-with-lease -u <matched-remote> HEAD
   ```

   c. If no PR exists (or no matching remote was found) and there is no upstream, fall back to `origin`. If pushing to `origin` fails due to permission errors, try pushing to `upstream` instead (per the project's git workflow in CLAUDE.md). Report which remote was used.

   ```
   git push --force-with-lease -u origin HEAD
   ```

   Note: `--force-with-lease` is used because the commit may have been amended. It's safer than `--force` as it will fail if someone else has pushed to the branch.

7. **Create or update the PR (REQUIRED):**

   **CRITICAL:** Do NOT tell the user to visit a URL to create a PR. You MUST create it automatically.

   First, check if a PR already exists for this branch:

   ```
   gh pr view --json number,url
   ```

   If a PR already exists, skip PR creation (the push already updated it).

   If NO PR exists, create one using `gh pr create`:

   ```
   gh pr create --title "<descriptive title>" --body "$(cat <<'EOF'
   ## Summary
   <1-3 bullet points summarizing the changes>

   ## Test plan
   <How to test these changes>

   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   EOF
   )"
   ```

   Use the commit messages and changed files to write a good title and summary.

8. **Remove review-issue label:**

   After pushing, remove the `needs-human:review-issue` label if it exists (this label indicates the issue needed human review before work started, which is now complete):

   ```
   gh pr edit --remove-label "needs-human:review-issue" 2>/dev/null || true
   ```

9. **Remember learnings (after initial push):**

   Run the `/remember-learnings` skill to capture any errors, snags, or insights from this session into `AGENTS.md` or `rules/` files.

   If any files were modified by the skill (check with `git status`):
   - Stage the modified files: `git add AGENTS.md rules/`
   - Create a new commit for the learnings:
     ```
     git commit -m "docs: record session learnings"
     ```
   - Push the learnings commit:
     ```
     git push
     ```

   **IMPORTANT:** Do NOT amend the previous commit. Create a separate commit for learnings so the main work is already pushed before this step.

10. **Summarize the results:**

- Report if a new feature branch was created (and its name)
- Report any uncommitted changes that were committed in step 2
- Report any files that were IGNORED and not committed (if any), explaining why they were skipped
- Report any lint fixes that were applied
- Confirm tests passed
- Confirm the branch has been pushed
- Report any learnings added to `AGENTS.md` or `rules/` (and whether a follow-up push was made)
- **Include the PR URL** (either newly created or existing)

Overview

This skill automates committing any local changes, running lint and tests, applying fixes, and pushing the current feature branch to GitHub. It completes all steps autonomously without asking for confirmation and ensures a pull request is created or updated. It also records session learnings and reports the final PR URL and a concise summary of actions.

How this skill works

The skill inspects the current git branch, stages and commits uncommitted changes (excluding secrets and unwanted artifacts), runs formatter/linter and TypeScript checks, and fixes issues either automatically or by editing files. It runs the test suite, amends commits if lint made changes, determines the correct remote, pushes with --force-with-lease, and creates or updates a GitHub PR using the gh CLI. Finally, it removes a specific review label if present and records learnings in repo docs.

When to use it

  • You have local work that needs to be committed, linted, tested, and pushed without manual steps.
  • You want an automated, auditable PR creation or update from a feature branch.
  • You need consistent pre-push checks (fmt, lint:fix, TypeScript, tests) applied before pushing.
  • You want session learnings recorded automatically after a push.

Best practices

  • Never run this skill from main/master; it will create a descriptive feature branch if needed.
  • Keep secrets and build artifacts out of commits (.env, node_modules/, *.key, *.pem, .DS_Store, logs).
  • Avoid spurious package-lock.json commits unless package.json changed.
  • Ensure gh CLI is authenticated and remotes are configured (origin/upstream) for predictable pushes.
  • Prefer small, focused commits so lint fixes can be amended cleanly into the last commit.

Example use cases

  • Finish a local bugfix: commit changed files, auto-fix lint, run tests, and push with a PR created.
  • Polish a new feature branch after manual edits and ensure all checks pass before pushing.
  • Recover from local formatting fixes by amending the last commit and force-pushing safely.
  • Capture session notes and troubleshooting tips into AGENTS.md or rules/ after a successful push.

FAQ

Will this skill ever push to main or master?

No. If run on main/master it creates a descriptive feature branch and switches to it before committing or pushing.

What does it do with files that should never be committed?

It automatically excludes common secrets and artifacts (.env*, node_modules/, *.key, .DS_Store, logs). It reports any ignored files in the final summary.

How does the skill choose which remote to push to?

It prefers an existing upstream if set. If none, it checks for an existing PR headRepository to match a local remote, otherwise falls back to origin and, on permission errors, attempts upstream per repo workflow.