pr-workflow-fast

Generate branch and pull request plans with quality gates for Rust changes.

31|Updated Jan 28, 2026
One-click install
npx skills add https://github.com/citum/citum-core --skill pr-workflow-fast
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pr-workflow-fast
Source: https://github.com/citum/citum-core/tree/main/.claude/skills/pr-workflow-fast
Command: npx skills add https://github.com/citum/citum-core --skill pr-workflow-fast

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It solves inconsistent or slow branch and pull request workflows by enforcing fast, predictable checks and evidence-first PR descriptions so changes get reviewed efficiently.

Core Features & Use Cases

  • Fast branch + PR setup: Creates a consistent codex/ branch naming pattern and keeps scopes narrow for mergeability.
  • Change-type quality gates: Selects and runs the right validation steps for docs/styles vs Rust-touching changes, including formatting, clippy, and test execution with explicit “gate must pass before first push” guidance.
  • Review-ready PR descriptions: Ensures the PR body contains objective validation evidence, risk notes, and follow-ups to reduce back-and-forth during review.
  • Post-failure handling: Provides a clear remediation strategy (squash and force-push with explicit confirmation) if checks fail after pushing.
  • Perf-claim workflow: Adds a benchmark baseline/after verification path for hot-path or performance claims.

Quick Start

Use this skill to generate a branch and PR plan for your change, including the exact quality gate steps to run based on whether you modified docs/styles or Rust code.

Frequently Asked Questions about pr-workflow-fast

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce quality gates for a Rust pull request before pushing?

To speed up pull request workflows, enforce strict quality gates and evidence-first PR descriptions before pushing. This approach reduces back-and-forth during review by ensuring changes are validated and documented upfront.

What is the best way to write evidence-first PR descriptions for GitHub code reviews?

An evidence-first PR description includes objective validation evidence, risk notes, and follow-ups. Providing exact command outputs and context reduces review back-and-forth and ensures changes are review-ready.

How do I handle CI check failures after pushing a branch to GitHub?

Handle CI check failures by applying a squash and force-push remediation strategy with explicit confirmation. This maintains a clean branch history while ensuring the updated changes pass the required quality gates.

Do I need to run benchmark validation for performance claims in a Rust pull request?

Yes, benchmark validation is required for hot-path or performance claims in a Rust pull request. Run a benchmark baseline and after verification path to substantiate any performance improvements before merging.

Does the branch naming policy affect mergeability when using Rust workflows?

Yes, using a consistent codex/ branch naming pattern keeps scopes narrow and improves mergeability. Consistent branch naming is a core convention for maintaining fast and predictable pull request workflows.

Can I use the same validation steps for doc-only updates and Rust-touching changes?

No, validation steps are change-type specific. Doc-only updates and Rust-touching changes require different quality gates tailored to the touched file types, ensuring the right formatting, clippy, and test execution steps are applied.