원클릭으로
pr
// INVOKE THIS SKILL before creating any PR to ensure compliance with branch naming, changelog requirements, and reviewer assignment.
// INVOKE THIS SKILL before creating any PR to ensure compliance with branch naming, changelog requirements, and reviewer assignment.
| name | pr |
| description | INVOKE THIS SKILL before creating any PR to ensure compliance with branch naming, changelog requirements, and reviewer assignment. |
| Prefix | Use |
|---|---|
add/{feature} | New features |
update/{feature} | Iterating on existing features |
fix/{bug} | Bug fixes |
try/{idea} | Experimental ideas |
Reserved: release/{X.Y.Z} (releases only), trunk (main branch).
Before creating a PR, delegate to the code-review agent to review all changes on the branch. Address any critical issues before proceeding.
Every PR must:
@meAutomattic/fediverse as reviewer# Create PR (includes required assignment/reviewer)
gh pr create --assignee @me --reviewer Automattic/fediverse
Use the exact template from .github/PULL_REQUEST_TEMPLATE.md — do not create custom formatting.
Write changelog messages for end users, not developers. Users read these in the WordPress plugin update screen. Avoid internal jargon (OOM, batching, N+1), class names, or method names. Describe what the user experiences or what changed from their perspective.
✅ Fix automatic cleanup of old activities failing silently on sites with many items.
✅ Add a Site Health check that warns when plugins are causing too many federation updates.
❌ Fix collection purge methods to batch deletions and enforce a hard item cap.
❌ Add Site Health test to detect excessive outbox activity rates.
End all changelog messages with punctuation.
Add manually if forgotten:
composer changelog:add
git add . && git commit -m "Add changelog entry" && git push
See release for complete changelog details.
git checkout trunk && git pull origin trunk
git checkout -b fix/notification-issue
composer lint # PHP standards (composer lint:fix to auto-fix)
npm run lint:js # If JS changed
npm run lint:css # If CSS changed
npm run env-test # Run tests
npm run build # If assets changed
See AGENTS.md for complete commands.
git fetch origin
git rebase origin/trunk
# Resolve conflicts if any
git push --force-with-lease
Hotfixes: Branch fix/critical-issue, minimal changes, add "Hotfix" label, request expedited review.
Experimental: Use try/ prefix, mark as draft, get early feedback, convert to proper branch type once confirmed.
Multi-PR features: Create tracking issue, link all PRs, use consistent naming (add/feature-part-1, etc.), merge in order.
| Label | Use |
|---|---|
Bug | Bug fixes |
Enhancement | New features |
Documentation | Doc updates |
Code Quality | Refactoring, cleanup, etc. |
Skip Changelog | No changelog needed |
Needs Review | Ready for review |
In Progress | Still working |
Hotfix | Urgent fix |
See docs/pull-request.md for complete workflow details.
ActivityPub protocol specification and federation concepts. Use when working with ActivityPub activities, understanding federation mechanics, implementing protocol features, or debugging federation issues.
Use when auditing or updating .gitattributes export-ignore coverage so dev-only files (lint configs, CI, tests, docs, build tooling) don't ship in the WordPress.org plugin zip. Run before a release, after adding a new top-level file or config, or when a tool is renamed (e.g. .eslintrc.js → eslint.config.cjs).
Use when auditing or updating .gitattributes export-ignore coverage so dev-only files (lint configs, CI, tests, docs, build tooling) don't ship in the WordPress.org plugin zip. Run before a release, after adding a new top-level file or config, or when a tool is renamed (e.g. .eslintrc.js → eslint.config.cjs).
PHP coding standards and WordPress patterns for ActivityPub plugin. Use when writing PHP code, creating classes, implementing WordPress hooks, or structuring plugin files.
Development workflows for WordPress ActivityPub plugin including wp-env setup, testing commands, linting, and build processes. Use when setting up development environment, running tests, checking code quality, building assets, or working with wp-env.
Third-party WordPress plugin integration patterns. Use when adding new integrations, debugging compatibility with other plugins, or working with existing integrations.