home / skills / athola / claude-night-market / pr-prep

This skill helps you prepare PRs by staging changes, generating summaries, and documenting tests and drafts for efficient submissions.

npx playbooks add skill athola/claude-night-market --skill pr-prep

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

Files (4)
SKILL.md
5.3 KB
---
name: pr-prep
description: 'Use this skill for PR preparation. Use when preparing PRs for submission,
  running quality gates, drafting PR descriptions and templates. Do not use when reviewing
  existing PRs - use pr-review instead. DO NOT use when: just generating commit messages
  - use commit-messages.'
category: artifact-generation
tags:
- git
- pr
- pull-request
- quality-gates
- testing
tools:
- Bash
- Write
- TodoWrite
complexity: medium
estimated_tokens: 1000
progressive_loading: true
modules:
- quality-gates.md
- pr-template.md
dependencies:
- sanctum:shared
- sanctum:git-workspace-review
- imbue:evidence-logging
- imbue:structured-output
- scribe:slop-detector
- scribe:doc-generator
hooks:
  PreToolUse:
  - matcher: Bash
    command: "# Log quality gate execution\nif echo \"$CLAUDE_TOOL_INPUT\" | grep\
      \ -qE \"(make|npm|cargo|pytest|ruff|eslint|clippy) (test|lint|fmt|build|check)\"\
      ; then\n  cmd=$(echo \"$CLAUDE_TOOL_INPUT\" | jq -r '.command // empty' 2>/dev/null\
      \ || echo 'N/A')\n  echo \"[skill:pr-prep] Quality gate: $cmd at $(date)\" >>\
      \ ${CLAUDE_CODE_TMPDIR:-/tmp}/skill-audit.log\nfi\n"
    once: false
  PostToolUse:
  - matcher: Write
    command: "# Track PR template generation\nfile=$(echo \"$CLAUDE_TOOL_INPUT\" |\
      \ jq -r '.file_path // empty' 2>/dev/null)\nif echo \"$file\" | grep -qE \"\
      (pr[-_]description|PR[-_]TEMPLATE|pull[-_]request)\"; then\n  echo \"[skill:pr-prep]\
      \ PR template written: $file at $(date)\" >> ${CLAUDE_CODE_TMPDIR:-/tmp}/skill-audit.log\n\
      fi\n"
  Stop:
  - command: 'echo "[skill:pr-prep] === Workflow completed at $(date) ===" >> ${CLAUDE_CODE_TMPDIR:-/tmp}/skill-audit.log

      '
---
# Pull Request Preparation Workflow

## Usage

Use this skill to stage changes and generate a PR summary. Run `Skill(sanctum:git-workspace-review)` first to capture the repository state and diffs.

## Required Progress Tracking

Create `TodoWrite` items for these steps before starting:
1. `pr-prep:workspace-reviewed`
2. `pr-prep:quality-gates`
3. `pr-prep:changes-summarized`
4. `pr-prep:testing-documented`
5. `pr-prep:pr-drafted`
6. `pr-prep:content-verified`

Mark each item as complete as the section is finished.

## Step 1: Review Workspace (`workspace-reviewed`)

Confirm that `Skill(sanctum:git-workspace-review)` is complete. If changes were staged after the initial review, re-execute the skill to refresh the context.

## Step 2: Run Quality Gates (`quality-gates`)

Execute formatting, linting, and tests using project-specific commands (e.g., `make fmt`, `make lint`, `make test`). Resolve all failures before proceeding. If a task cannot be executed locally, document the reason and the alternative validation performed. Language-specific commands and failure handling are detailed in `modules/quality-gates.md`.

## Step 3: Summarize Changes (`changes-summarized`)

Use the notes from the workspace review and the output of `git diff --stat origin/main...HEAD` to understand the scope. Identify key points in the diffs and group them into 2-4 paragraphs highlighting the technical changes and their rationale. Note breaking changes, migrations, or documentation updates.

## Step 4: Document Testing (`testing-documented`)

List each test command executed and its result. Include manual verification steps where relevant. If tests were skipped, document the reason and the mitigation plan.

## Step 5: Draft the PR (`pr-drafted`)

Populate the standard template with Summary, Changes, Testing, and Checklist sections. Include issue references, screenshots, or follow-up TODO items. Template structure and examples are available in `modules/pr-template.md`.

## Step 6: Verify Content Quality (`content-verified`)

Apply `Skill(scribe:slop-detector)` principles to the draft. Verify that the PR description avoids tier-1 slop words (delve, comprehensive, leverage, utilize, robust, seamless) and formulaic phrases like "I'd be happy to" or "It should be noted." Ensure there is no AI attribution in the text and that all claims are grounded with evidence such as commands, numbers, or filenames. Use active voice and maintain a balanced structure with prose for context.

### Vocabulary Substitutions

- Replace **leverage** or **utilize** with **use**.
- Replace **comprehensive** with **thorough** or **complete**.
- Replace **robust** with **solid** or **reliable**.
- Replace **facilitate** with **help** or **enable**.
- Replace **streamline** with **simplify**.

### Remediation

If the description contains slop, apply `Skill(scribe:doc-generator)` principles to ground claims with specifics, remove marketing language, and use direct statements.

## Output Instructions

Write the final PR description to the specified path, then display the file path and its contents for confirmation.

## Notes

Do not include tool or AI attribution in the PR text. If changes are required mid-process, re-run quality gates. This skill covers preparation; pushing changes and opening the PR occurs outside this workflow.

## Supporting Modules

- [TodoWrite patterns](modules/todowrite-patterns.md) - naming conventions for sanctum TodoWrite items

## Troubleshooting

If project-specific commands like `make` or `npm` are unavailable, verify the environment setup against the `README`. For permission errors, check write access to build directories. If a step fails without clear output, retry the command with verbose flags to inspect the logs.

Overview

This skill prepares a pull request for submission by running quality gates, summarizing changes, documenting tests, and drafting a clean PR description. It enforces a checklist-style workflow so the PR is ready for opening without added review tasks. Use it before pushing or creating the PR.

How this skill works

The skill starts with a captured workspace review and reruns it if new changes appear. It runs formatting, linting, and tests (or documents why they could not run), extracts diff stats to summarize changes, records test results and manual verification, then generates a PR draft that follows tight wording rules and a standard template. It ends by validating the draft against slop-detection rules and producing the final PR text for placement.

When to use it

  • Preparing a PR for submission to origin/main or another target branch
  • After staging and committing changes but before opening the PR
  • When you need a concise, test-backed PR summary and checklist
  • When you want author-side quality gates run and documented
  • Not for reviewing existing PRs or only generating commit messages

Best practices

  • Run the workspace review capture first and re-run if you stage new changes
  • Execute project-specific format, lint, and test commands and fix all failures before drafting
  • Use git diff --stat origin/main...HEAD to scope and group changes into 2–4 focused paragraphs
  • Record each test command and outcome; document manual verification steps and mitigation for skipped tests
  • Apply the provided word substitutions and remove marketing or AI-attribution language; ground claims with commands, filenames, or numbers

Example use cases

  • Prepare a feature branch PR: run quality gates, summarize code and migration steps, draft PR description with testing notes
  • Submit a bugfix PR: isolate changed files, list failing tests fixed, include reproduction steps and screenshots
  • Document a refactor: highlight API changes, breaking notes, and required consumer migrations
  • Prepare a release PR: summarize package/version bumps, changelog entries, and CI validation results

FAQ

What if tests fail in CI but pass locally?

Record local results, include CI failure logs or links, document environment differences, and add a mitigation plan or follow-up TODO before opening the PR.

Can I skip running lint or format locally?

Only if you document why the task could not run and include an alternative validation step; unresolved lint/format failures should be fixed before drafting the PR.

How should I handle breaking changes in the PR?

Call out breaking changes explicitly in the Changes section, list migration steps, update docs or changelog, and note any required version bumps.