Commit f1d1a07d065 for woocommerce
commit f1d1a07d065c51d344bf72cec69014901718eedc
Author: Michael Pretty <prettyboymp@users.noreply.github.com>
Date: Wed May 20 12:05:06 2026 -0400
Remove human-stall instructions from autoloaded skills (#65202)
The woocommerce-git-commit and woocommerce-git-draft-pr skills
contained directives to wait for user approval and to ask follow-up
questions mid-procedure. Autoloaded skills get pulled into any agent
session that matches their trigger keywords — including non-interactive
runs like AI Coder revisions — where waiting for a human means the run
bails with no commits and the working-tree fix is discarded
(see PAY-669).
Replace the wait/ask imperatives with infer-from-context fallbacks and
convert ambiguous "ask user" branch/dirty-tree checks into hard stops.
The preview blocks remain as informational output, which is harmless
for autonomous runs and still useful to interactive users.
diff --git a/.ai/skills/woocommerce-git-commit/SKILL.md b/.ai/skills/woocommerce-git-commit/SKILL.md
index 885ba12d910..f0f365a59d2 100644
--- a/.ai/skills/woocommerce-git-commit/SKILL.md
+++ b/.ai/skills/woocommerce-git-commit/SKILL.md
@@ -35,7 +35,7 @@ Two files changed for the same reason = one commit. Don't over-split.
### 3. Draft Commit Message(s)
-Use the current session context to understand what work was done and why. If motivation is still unclear after reviewing the diff and conversation, ask the user in a single question.
+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:
@@ -53,9 +53,9 @@ Do NOT include issue/PR refs — GitHub adds those on squash-merge.
If $ARGUMENTS is provided, use it as guidance for the commit message.
-### 4. Preview and Confirm
+### 4. Preview
-Show the user each proposed commit:
+State each proposed commit before executing:
```text
Commit 1: Fix double margin-top in flex layout
@@ -66,8 +66,6 @@ Commit 2: Add changelog entries for email editor fix
files: plugins/woocommerce/changelog/fix-email-margin
```
-Wait for user approval or corrections before executing.
-
### 5. Execute
For each confirmed commit:
diff --git a/.ai/skills/woocommerce-git-draft-pr/SKILL.md b/.ai/skills/woocommerce-git-draft-pr/SKILL.md
index 8f4bbe68ec7..1eaa4f66979 100644
--- a/.ai/skills/woocommerce-git-draft-pr/SKILL.md
+++ b/.ai/skills/woocommerce-git-draft-pr/SKILL.md
@@ -20,7 +20,7 @@ Create a concise, reviewer-friendly draft PR from the current branch.
### 1. Preflight and Analyze
-Verify from dynamic context: not on trunk (ask which branch if so), commits exist ahead of trunk (stop if none), no uncommitted changes (ask user to commit/stash if dirty).
+Verify from dynamic context: not on trunk (stop if so), commits exist ahead of trunk (stop if none), no uncommitted changes (stop if dirty).
**Base branch**: use `release/*` if the branch was created from one, otherwise `trunk`.
@@ -32,13 +32,13 @@ From the dynamic context above (read full diffs only if the stat summary is ambi
- **UI changes?** Changes in `client/`, `templates/`, CSS/SCSS, JSX/TSX
- **Plugin-affecting?** Code shipped to users = yes. CI/CD, workflows, tooling, docs = no. This drives changelog, milestone, and PR body complexity — non-plugin PRs use a simplified body (see Step 3).
-### 2. Gather Context from User
+### 2. Gather Context
-Extract issue/PR refs from commits and branch name. Ask the user (combine into one prompt):
+Extract issue/PR refs from commits and branch name:
-- If no issue ref: "Is there a GitHub issue?" (Linear is internal — only reference GitHub issues in PRs)
-- If bug fix, no origin PR found: "Which PR introduced this bug?"
-- If motivation unclear from code: "What's the context?"
+- **Issue ref**: use what's in commits/branch if present; otherwise omit `Closes #` (Linear refs are internal — only reference GitHub issues in PRs).
+- **Bug-fix origin PR**: if a bug fix and no PR ref is in the diff/commits, search history (`git log -S` on touched lines) to find the introducing PR; omit `Bug introduced in PR #XXXX.` if not found.
+- **Motivation**: infer from diff and commit messages. Use the strongest summary you can; don't block on missing context.
### 3. Generate PR Title + Body
@@ -68,16 +68,16 @@ Use the full template:
- **Submission Review Guidelines**: Keep as-is from template.
- **Changes proposed**: 2-3 sentences. Lead with WHY, then WHAT. No filler ("This PR addresses..."). Include `Closes #1234.` if applicable. For bugs: `Bug introduced in PR #XXXX.` (omit this line entirely if not a bug fix).
- **Screenshots**: Remove section if no UI changes. For UI changes, use Chrome DevTools MCP to capture screenshots if available; otherwise remind user to add them before marking ready.
-- **Testing instructions**: Concrete numbered steps with expected outcomes. Ask user to verify before finalizing. Each step must be actionable — don't reference links that won't exist yet.
-- **Testing done**: Ask user what testing they've performed.
+- **Testing instructions**: Concrete numbered steps with expected outcomes derived from the diff. Each step must be actionable — don't reference links that won't exist yet.
+- **Testing done**: Fill with what's verifiable from the session (commits, test runs, lint runs). If nothing is verifiable, write "Author to fill in before marking ready."
- **Milestone**: Check auto-assign `[x]` if plugin-affecting.
- **Changelog**: If changelogs already in diff → "does not require" (created manually). Otherwise → "Automatically create" `[x]` with Significance, Type, and a user-facing Message.
Strip all HTML comments (`<!-- -->`) and unfilled placeholder lines (e.g., `Closes # .`, `Bug introduced in PR # .`) from output.
-### 4. Preview and Confirm
+### 4. Preview
-Show the user the generated title and body. Apply any corrections before proceeding.
+State the generated title and body before executing.
### 5. Push and Create