pr

Name: pr
Author: woocommerce

Engineering Community

Repo stars 357
Author repo woocommerce-ios

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Create a pull request following WooCommerce iOS conventions. 1. Verify the current branch is not trunk: 2. Check the diff agains…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Description”, “Test Steps”, “Screenshots”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name pr directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Description / Test Steps / Screenshots” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Create a pull request following WooCommerce iOS conventions.

Steps:

Verify the current branch is not trunk:

git branch --show-current

Check the diff against trunk:

git log trunk..HEAD --oneline
git diff trunk...HEAD --stat

Check non-test diff size (should be under 300 lines):

git diff trunk...HEAD --stat -- . ':!*Tests*' ':!*Test*' ':!*.generated.*'

Review the changes to write an accurate description. Read modified files if needed.
- Never include actual Linear issue links (e.g., https://linear.app/...) in PR descriptions — Linear is an internal resource. Only reference the issue ID (e.g., WOOMOB-2485).
Determine if RELEASE-NOTES.txt needs updating. If the change is user-facing, remind about adding a release note entry.
Push the branch:

git push -u origin HEAD

Create the PR. The description must follow the template in .github/PULL_REQUEST_TEMPLATE.md:

gh pr create --base trunk --title "<concise title>" --body "$(cat <<'EOF'
## Description
<description of changes — why and what>

## Test Steps
<how to test>

## Screenshots
N/A

---
- [ ] I have considered if this change warrants user-facing release notes and have added them to `RELEASE-NOTES.txt` if necessary.
EOF
)"

Add labels. After creating the PR, add all labels in a single call using multiple --add-label flags: gh pr edit <number> --add-label "<label1>" --add-label "<label2>". Pick labels from these categories:
- Type (pick one): type: bug, type: crash, type: enhancement, type: task, type: technical debt, type: documentation, type: question
- Feature (pick one if applicable): match the changed area to a feature: * label (e.g., feature: POS, feature: order list, feature: order details, feature: product details, feature: login, feature: dashboard, feature: analytics hub, feature: coupons, feature: shipping labels, feature: order creation, feature: notifications, feature: Blaze, feature: CIAB Mobile Experience, feature: subscriptions, feature: app settings, etc.)
- Priority (pick one if known): priority: low, priority: medium, priority: high, priority: critical
- Category (pick any that apply): category: accessibility, category: design, category: performance, category: tracks, category: unit tests, category: ui tests, category: tooling, category: parity, category: i18n, category: dark mode, category: tablet, etc.
- If the feature is behind a flag, also add status: feature-flagged
- Infer labels from the diff and branch name. If unsure about the feature label, ask the user.
Set milestone. After creating the PR, assign the correct milestone:
- List open milestones: gh api repos/woocommerce/woocommerce-ios/milestones --jq '.[] | "\(.title)\t\(.description)"'
- Each milestone description contains a Code Freeze: date.
- If the PR targets trunk: pick the earliest milestone whose code freeze date has not yet passed (i.e., the next unfrozen milestone).
- If the PR targets a release/X.Y branch: use milestone X.Y (the frozen release milestone).
- Apply with: gh pr edit <number> --milestone "<milestone title>"
Report the PR URL.

If non-test diff exceeds 300 lines, warn that Danger will flag it and suggest splitting.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Engineering
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @woocommerce · no license declared
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，默认拥有全部工具权限。

Output preview pr-woocommerce.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

Create a pull request following WooCommerce iOS conventions.

Steps:

1. Verify the current branch is not `trunk`:
```bash
git branch --show-current
```

2. Check the diff against trunk:
```bash
git log trunk..HEAD --oneline
git diff trunk...HEAD --stat
```

3. Check non-test diff size (should be under 300 lines):
```bash
git diff trunk...HEAD --stat -- . ':!*Tests*' ':!*Test*' ':!*.generated.*'
```

4. Review the changes to write an accurate description. Read modified files if needed.
   - **Never include actual Linear issue links** (e.g., `https://linear.app/...`) in PR descriptions — Linear is an internal resource. Only reference the issue ID (e.g., `WOOMOB-2485`).

5. Determine if RELEASE-NOTES.txt needs updating. If the change is user-facing, remind about adding a release note entry.

6. Push the branch:
```bash
git push -u origin HEAD
```

7. Create the PR. The description must follow the template in `.github/PULL_REQUEST_TEMPLATE.md`:
```bash
gh pr create --base trunk --title "<concise title>" --body "$(cat <<'EOF'
## Description
<description of changes — why and what>

## Test Steps
<how to test>

## Screenshots
N/A

---
- [ ] I have considered if this change warrants user-facing release notes and have added them to `RELEASE-NOTES.txt` if necessary.
EOF
)"
```

8. **Add labels.** After creating the PR, add all labels in a single call using multiple `--add-label` flags: `gh pr edit <number> --add-label "<label1>" --add-label "<label2>"`. Pick labels from these categories:
   - **Type** (pick one): `type: bug`, `type: crash`, `type: enhancement`, `type: task`, `type: technical debt`, `type: documentation`, `type: question`

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Description → Test Steps → Screenshots
terms    -> Never include actual Linear issue links · Add labels. · Type · Feature · Priority · Category · Set milestone. · If the PR targets trunk
files/cmd -> trunk · https://linear.app/... · WOOMOB-2485 · .github/PULLREQUESTTEMPLATE.md · RELEASE-NOTES.txt · --add-label · gh pr edit <number> --add-label "<label1>" --add-label "<label2>" · type: bug
body sha256 -> 71c03b992e07

Decide Fit First

Design Intent

How To Use It

Boundaries And Review

Discussion