simple-pr
- Repo stars 15,240
- License MIT
- Author repo tantivy
Simple PR
Follow these steps to create a simple PR from staged changes:
Step 1: Check workspace state
Run: git status
Verify that all changes have been staged (no unstaged changes). If there are unstaged changes, abort and ask the user to stage their changes first with git add.
Also verify that we are on the main branch. If not, abort and ask the user to switch to main first.
Step 2: Ensure main is up to date
Run: git pull origin main
This ensures we're working from the latest code.
Step 3: Review staged changes
Run: git diff --cached
Review the staged changes to understand what the PR will contain.
Step 4: Generate commit message
Based on the staged changes, generate a concise commit message (1-2 sentences) that describes the "why" rather than the "what".
Display the proposed commit message to the user and ask for confirmation before proceeding.
Step 5: Create a new branch
Get the git username: git config user.name | tr ' ' '-' | tr '[:upper:]' '[:lower:]'
Create a short, descriptive branch name based on the changes (e.g., fix-typo-in-readme, add-retry-logic, update-deps).
Create and checkout the branch: git checkout -b {username}/{short-descriptive-name}
Step 6: Commit changes
Commit with the message from step 3:
git commit -m "{commit-message}"
Step 7: Push and open a PR
Push the branch and open a PR:
git push -u origin {branch-name}
gh pr create --title "{commit-message-title}" --body "{longer-description-if-needed}"
Report the PR URL to the user when complete.
- Fluxly category
- Engineering
- Author-declared agents
- No explicit declaration found; this is not inferred or tested compatibility
- Static check
- 94 / 100 · heuristic scan, not runtime safety proof
- Author / version / license
- @quickwit-oss · MIT
- Fluxly token estimate
- Lean
- Fluxly setup estimate
- Plug-and-play
- External API key
- No requirement detected
- Detected OS requirements
- Unspecified
- Runtime requirements
- Unspecified
- Detected file/system behavior
-
- Read-only
- Write / modify
- Detected network behavior
- Local-only
- Install commands
- None (reference only)
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
The current SKILL.md does not define a fixed output example. Run: git status Verify that all changes have been staged (no unstaged changes). If there are unstaged changes, abort and ask the user to stage their changes first with git add. Also verify that we are on the main branch. If not, abort and ask the user to…
Run: git pull origin main This ensures we're working from the latest code.
Run: git diff --cached Review the staged changes to understand what the PR will contain.
Based on the staged changes, generate a concise commit message (1-2 sentences) that describes the "why" rather than the "what". Display the proposed commit message to the user and ask for confirmation before proceeding.
Get the git username: git config user.name | tr ' ' '-' | tr '[:upper:]' '[:lower:]' Create a short, descriptive branch name based on the changes (e.g., fix-typo-in-readme, add-retry-logic, update-deps). Create and checkout the branch: git checkout -b…
Commit with the message from step 3:
# Simple PR
Follow these steps to create a simple PR from staged changes:
## Step 1: Check workspace state
Run: `git status`
Verify that all changes have been staged (no unstaged changes). If there are unstaged changes, abort and ask the user to stage their changes first with `git add`.
Also verify that we are on the `main` branch. If not, abort and ask the user to switch to main first.
## Step 2: Ensure main is up to date
Run: `git pull origin main`
This ensures we're working from the latest code.
## Step 3: Review staged changes
Run: `git diff --cached`
Review the staged changes to understand what the PR will contain.
## Step 4: Generate commit message
Based on the staged changes, generate a concise commit message (1-2 sentences) that describes the "why" rather than the "what".
Display the proposed commit message to the user and ask for confirmation before proceeding.
## Step 5: Create a new branch
Get the git username: `git config user.name | tr ' ' '-' | tr '[:upper:]' '[:lower:]'`
Create a short, descriptive branch name based on the changes (e.g., `fix-typo-in-readme`, `add-retry-logic`, `update-deps`).
Create and checkout the branch: `git checkout -b {username}/{short-descriptive-name}`
## Step 6: Commit changes
Commit with the message from step 3:
```
git commit -m "{commit-message}"
```
## Step 7: Push and open a PR
Push the branch and open a PR:
```
git push -u origin {branch-name}
gh pr create --title "{commit-message-title}" --body "{longer-description-if-needed}"
```
Report the PR URL to the user when complete. Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.
sections -> Step 1: Check workspace state → Step 2: Ensure main is up to date → Step 3: Review staged changes → Step 4: Generate commit message → Step 5: Create a new branch → Step 6: Commit changes
terms -> Verify that all changes have been staged (no unstaged changes). · Also verify that we are on the main branch. · This ensures we're working from the latest code. · Review the staged changes to understand what the PR will contain. · Based on the staged changes, generate a concise commit message (1-2 sentences) that describes the "why" rather than the "what". · Display the proposed commit message to the user and ask for confirmation before proceeding. · Create a short, descriptive branch name based on the changes (e.g., fix-typo-in-readme, add-retry-logic, update-deps). · Report the PR URL to the user when complete.
files/cmd -> git status · git add · main · git pull origin main · git diff --cached · git config user.name | tr ' ' '-' | tr '[:upper:]' '[:lower:]' · fix-typo-in-readme · add-retry-logic
body sha256 -> dfd8f06e36a6
Decide Fit First
Design Intent
How To Use It
Boundaries And Review