simple-pr
- Repo stars 15,240
- License MIT
- Author updated Live
- Author repo tantivy
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @quickwit-oss · MIT
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: simple-pr
description: Create a simple PR from staged changes with an auto-generated commit message Follow these steps…
category: engineering
runtime: no special runtime
---
# simple-pr output preview
## PART A: Task fit
- Use case: Create a simple PR from staged changes with an auto-generated commit message Follow these steps to create a simple PR from staged changes: 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. runs entirely locally. Works with Claude ….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Step 1: Check workspace state / Step 2: Ensure main is up to date / Step 3: Review staged changes” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Create a simple PR from staged changes with an auto-generated commit message Follow these steps to create a simple PR from staged changes: 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. runs entirely locally. Works with Claude …”.
- **02** When the source has headings, the agent prioritizes “Step 1: Check workspace state / Step 2: Ensure main is up to date / Step 3: Review staged changes” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Step 1: Check workspace state / Step 2: Ensure main is up to date / Step 3: Review staged changes”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: simple-pr
description: Create a simple PR from staged changes with an auto-generated commit message Follow these steps…
category: engineering
source: quickwit-oss/tantivy
---
# simple-pr
## When to use
- Create a simple PR from staged changes with an auto-generated commit message Follow these steps to create a simple PR…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Step 1: Check workspace state / Step 2: Ensure main is up to date / Step 3: Review staged changes” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "simple-pr" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Step 1: Check workspace state / Step 2: Ensure main is up to date / Step 3: Review staged changes
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}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.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review