/wp-dev-learn

description: Extract learnings from the current session and update wp-dev-skills skill files — captures corrections, new rules, edge cases, and Common Mistakes entries discovered during real usage. Only globally applicable WP developer standards accepted — project-specific rules are redirected. Use `suggest` to see WP dev topics not yet covered by any skill.
argument-hint: "[preview | apply | suggest | skill:<name>]"

WP Dev Skills — Learn from Session

Scan the current conversation for corrections, new rules, and edge cases, then open a PR against `mralaminahamed/wp-dev-skills` for each skill updated. **All changes go through PR — no direct commits, owner or not.**

Action: $ARGUMENTS (defaults to `apply`)

| Mode | Behaviour | |------|-----------| | `apply` | Scan → filter global-only → show table → confirm → branch-per-skill → PR per skill → assign owner | | `preview` | Show what would be proposed (filtered table + candidates), no branches/PRs | | `suggest` | Skip session scan — show only global WP dev topic gaps not covered by any skill | | `skill:<name>` | Scope scan and PRs to one skill only; still show candidates |

---

Acceptance criteria — global standards only

**This plugin ships rules that apply to ALL WordPress developers across ALL projects.**

Rule 0 — never duplicate wordpress-official-agent-skills

Before proposing any skill update or new skill, check whether `wordpress-official-agent-skills` already covers the topic:

find ~/.claude/plugins/cache/wordpress-official-agent-skills -name "SKILL.md" | xargs grep -li "<topic>"

| Test | Accept | Reject | |------|--------|--------| | Already fully covered by `wordpress-official-agent-skills`? | ❌ Reject | — | | Partially covered — this fills a documented gap? | ✅ Accept (document boundary) | — | | Not covered at all by official skills? | ✅ Accept | — |

**If rejected by Rule 0:** note it as "covered by official skills" and suggest referencing `wordpress-official-agent-skills:<skill-name>` instead. `wp-dev-skills` complements official skills — it never replicates them.

Rule 1 — global WP developer standard

Before proposing any learning, apply this filter:

| Test | Accept | Reject | |------|--------|--------| | Would a WP developer on a completely different project benefit from this rule? | ✅ Accept | ❌ Reject | | Is the rule about a WP core API, standard tool, or universal workflow? | ✅ Accept | ❌ Reject | | Does it reference a specific team, repo, project name, or internal tool? | ❌ Reject | — | | Is it a QA process specific to one org's workflow? | ❌ Reject | — | | Is it a code style preference that doesn't reflect WP/WPCS standards? | ❌ Reject | — | | Does it assume a specific plugin architecture that isn't universal? | ❌ Reject | — |

**When a learning is rejected:** do NOT silently drop it. Show it in a **Redirected** section with a suggestion:

## Redirected (not accepted)

| Learning | Reason rejected | Suggestion |
|----------|----------------|------------|
| "Never add bug label — QA assigns it" | Org-specific QA process, not WP standard | Add to project CLAUDE.md |
| "Always use wp_remote_get for HTTP" | Already covered by wordpress-official-agent-skills:wp-rest-api | Reference official skill instead |

Suggestions to offer:

• **Covered by official skills** → reference `wordpress-official-agent-skills:<skill>` — don't duplicate here
• **Org/team-specific** → add to project's `CLAUDE.md` or a private project-scoped plugin
• **Partially covered** → document the gap boundary; reference official skill + extend here only for the uncovered part

---

What counts as a global learning

**Accept:**

• WP core API usage patterns (`wp_remote_get`, `wp_schedule_event`, nonces, capabilities)
• WPCS/PHPCS/PHPStan standards universal across WP plugins
• GitHub flow mechanics that apply to any WP plugin repo (branching, labels that are WP-ecosystem-standard)
• Security patterns required for all WP plugins (sanitize, escape, nonce verify)
• WP.org submission rules
• Patterns documented in WP Handbook or WP Coding Standards

**Reject:**

• Team-internal label assignments ("QA assigns `bug`") — org-specific, not WP standard
• Project-specific scopes, naming conventions, or architecture choices
• Rules tied to specific tools/services not universally used (e.g. "always use Freemius" is org preference, not universal)
• Internal sprint/QA processes

---

Steps

1. Scan conversation

Read the full conversation history. For each candidate learning extract:

• **Signal** — exact quote or paraphrase
• **Rule** — codified "always / never / when X do Y" statement
• **Global?** — apply acceptance criteria above
• **Skill** — which `skills/<name>/SKILL.md` (existing skills below), or `unassigned`
• **Section** — where to add/update
• **Change type** — `add-mistake`, `update-rule`, `add-section`, `refine-guidance`

**Known skills:** `wp-github-flow`, `wp-ci-qa`, `wp-coding-standards`, `wp-plugin-testing`, `wp-plugin-audit`, `wp-plugin-release`, `wp-org-submission`, `wp-woocommerce`, `wp-build-tools`, `wp-database`, `wp-freemius`, `wp-i18n-workflow`, `wp-background-processing`, `wp-multisite`, `wp-email-templates`, `wp-phpstan-stubs`, `wp-admin-browser`, `wp-guided-tour`

Unassigned global learnings → new skill candidates (Step 2b).

2. Preview

2a. Accepted updates (global standards only)

| # | Skill | Section | Change | Rule Summary |
|---|-------|---------|--------|--------------|
| 1 | wp-coding-standards | Common Mistakes | add-mistake | Always escape output with esc_html() — never echo raw |

2b. Redirected (project-specific — not accepted)

| # | Learning | Reason | Suggestion |
|---|----------|--------|------------|
| 1 | "QA assigns bug label" | Org-specific QA process, not WP standard | Add to project CLAUDE.md |

2c. New global skill candidates

Compare unassigned accepted learnings + known WP dev gaps against **both** existing wp-dev-skills AND `wordpr