// Commit uncommitted changes with well-crafted messages following WooCommerce repo conventions. Use when the user says "commit", "commit changes", "commit this", "git commit", or "save my work".
Create a high-quality draft PR for the current branch. Use when the user says "create a PR", "draft PR", "open a PR", "make a PR", "push and create PR", or "submit PR".
Set up, start, stop, restart, verify, and troubleshoot the WooCommerce Core local development environment with wp-env and asset build watchers. Use when Codex is asked to run WooCommerce locally, prepare wp-env, watch WooCommerce builds, choose between full and targeted build/watch commands, diagnose localhost:8888, or explain local environment setup commands.
Identify performance issues in WooCommerce PHP code. Use when writing or reviewing code that loads collections of post-based objects (products, orders), renders product lists with images, reads multiple options in a loop or method, or writes SQL queries involving joins, aggregates, meta lookups, or range queries.
Run tests, linting, and quality checks for WooCommerce development. Use when running tests, fixing code style, or following the development workflow.
Add or modify WooCommerce backend PHP code following project conventions. Use when creating new classes, methods, hooks, or modifying existing backend code. **MUST be invoked before writing any PHP unit tests.**
Add or modify routes in the WooCommerce Store API (`/wc/store/v1/*`). Use when creating new Store API endpoints, modifying existing ones, or designing the schemas blocks and external integrations consume. Covers authentication, REST URL design, schema/response alignment, variation handling, idempotency, and common pitfalls.
| name | woocommerce-git-commit |
| description | Commit uncommitted changes with well-crafted messages following WooCommerce repo conventions. Use when the user says "commit", "commit changes", "commit this", "git commit", or "save my work". |
Commit uncommitted work with clear, conventional messages. Groups unrelated changes into separate commits when appropriate.
git branch --show-currentgit status --shortgit diff --statgit diff --cached --statFrom the dynamic context above, determine what changed:
Default to a single commit unless changes are clearly unrelated. Split only when:
Two files changed for the same reason = one commit. Don't over-split.
Use the current session context to understand what work was done and why. If motivation is still unclear after reviewing the diff and conversation, infer the best reasonable description from the diff and commit conventions.
Format — verb-first imperative, under 72 chars:
Fix get_item_downloads() not always returning an arrayAdd cache priming to AJAX downloadable searchUpdate email editor reset action label for consistencyRefactor order count cache refresh logicRemove deprecated payment gateway fallbackVerbs: Fix, Add, Update, Refactor, Remove, Restore, Bump, Prepare, Simplify, Improve, Replace
For changelog-only commits: Add changelog entries for [description]
Do NOT include issue/PR refs — GitHub adds those on squash-merge.
If $ARGUMENTS is provided, use it as guidance for the commit message.
State each proposed commit before executing:
Commit 1: Fix double margin-top in flex layout
files: src/Blocks/EmailEditor/Layout.php
src/Blocks/EmailEditor/styles.css
Commit 2: Add changelog entries for email editor fix
files: plugins/woocommerce/changelog/fix-email-margin
For each confirmed commit:
git add <specific files>
git commit -m "<message>"
Always stage specific files — never git add -A or git add ..
After all commits, show git log --oneline -n <number of new commits> to confirm.
git add -A or git add .woocommerce-dev-cycle skill handles that. Linting should be run before invoking this skill, not after.