wp-github-flow

Name: wp-github-flow
Author: mralaminahamed

25stars3forks

How to install wp-github-flow?

mralaminahamed/wp-dev-skills/wp-github-flow

$npx -y skills add mralaminahamed/wp-dev-skills --skill wp-github-flow

Installs into the current project.

Summary

Use when shipping work through GitHub — fixing a GitHub issue by URL/number, or committing and PR-ing uncommitted working-tree changes. Covers resolving ISSUE_REPO vs CODE_REPO, grouping changes into scoped conventional commits (type(scope): summary), branching from fresh origin/

Files · 1

View on GitHub

SKILL.md

1	# GitHub Contribution Flow
2
3	> Model note: Issue-driven mode (root-cause tracing + fix) requires `sonnet` or `opus`. Changes-driven mode (group + commit existing edits) is mechanical and works well on `haiku`.
4
5	## Overview
6
7	Two entry modes that converge on the same shipping flow (branch → scoped commits → push → PR):
8
9	- Issue-driven — fetch issue → trace root cause → fix → ship. Wraps `superpowers:systematic-debugging`. Root cause MUST be confirmed before any fix is written.
10	- Changes-driven — read the working tree → group changes by conventional-commit scope → one commit per scope → ship. No issue required.
11
12	Both end at §6 Branch, Commit, PR, which is shared.
13
14	## When to use
15
16	Issue-driven:
17	- User says "analyze/debug/fix/investigate issue #NNN"
18	- User pastes a GitHub issue URL and asks to debug it
19	- User says "find the root cause of this bug" with an issue reference
20
21	Changes-driven:
22	- "commit my changes", "commit these scope by scope", "commit by scope"
23	- "create a branch and PR", "open a PR for these changes"
24	- "read all changes from X and commit + create PR"
25	- Any request whose end goal is commits/branch/PR from existing working-tree edits
26
27	Not for: Plugin version releases or WP.org SVN deploy — use `wp-plugin-release` and `wp-org-submission`. QA failure triage on an already-open PR — use `wp-ci-qa`.
28
29	## Required Sub-Skill
30
31	Issue-driven only: Invoke `superpowers:systematic-debugging` before any fix. Do NOT skip Phase 1 (root cause investigation). Changes-driven mode skips this — the edits already exist.
32
33	## References
34
35	- `references/gh-reference.md` — `gh` CLI commands, branch naming rules, label discovery, PR template sections, common CI failures
36	- `references/project-entry-points.md` — project layout template: repos, plugin dirs, entry-point files, and key conventions; copy and fill in for your project
37	- `references/conventional-commits.md` — type/scope table, WP-specific scope list, summary rules, multi-commit PR rules, footer conventions, rebase reword
38
39	## Repo ≠ where the issue lives
40
41	The repo that hosts the issue is often NOT the repo that holds the code / receives the PR. Resolve two names up front and keep them distinct:
42
43	- `ISSUE_REPO` — where `gh issue view` / `gh issue edit` run.
44	- `CODE_REPO` — where the affected code lives; where you branch, push, and `gh pr create --repo "$CODE_REPO"`.
45
46	When they differ, the PR's close footer must be cross-repo: `Closes ISSUE_OWNER/ISSUE_REPO#N` (a bare `Closes #N` only closes an issue in the same repo).
47
48	Real example: issues live in `my-org/my-plugin`, but the buggy code + PR live in `my-org/my-plugin-pro` → PR opens on `my-plugin-pro`, body says `Closes my-org/my-plugin#247`.
49
50	---
51
52	## Changes-Driven Workflow
53
54	Use this when the user wants to ship existing uncommitted edits. Skip to §6's mechanics but commit scope by scope rather than one lump.
55
56	### A. Read every change
57
58	```bash
59	git status
60	git diff # unstaged
61	git diff --staged # staged
62	```
63
64	Read the full diff, not just the file list — a single file can contain edits belonging to different scopes, and the commit message's "why" depends on what actually changed.
65
66	### B. Group changes by scope
67
68	Map each change to one conventional-commit scope. Scopes are project-defined — read the repo's CLAUDE.md for the list, don't assume.
69	- ShopFlow: `api, cart, checkout, orders, products, customers, payments, shipping, taxes, coupons, inventory, admin, dashboard, blocks, spa, database, templates, email, reports, build, i18n`.
70
71	Group by what the change is about, not just which directory it lives in. Examples from real sessions:
72	- `pages/Coupons/index.jsx` + `pages/Coupons/CouponList/index.jsx` → both `coupons`
73	- `pages/AbandonedCart/index.

People who liked this also viewed

6 picks

Type

wp-github-flow

25stars3forks

View on GitHub

How to install wp-github-flow?

mralaminahamed/wp-dev-skills/wp-github-flow

$npx -y skills add mralaminahamed/wp-dev-skills --skill wp-github-flow

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# GitHub Contribution Flow
2
3	> Model note: Issue-driven mode (root-cause tracing + fix) requires `sonnet` or `opus`. Changes-driven mode (group + commit existing edits) is mechanical and works well on `haiku`.
4
5	## Overview
6
7	Two entry modes that converge on the same shipping flow (branch → scoped commits → push → PR):
8
9	- Issue-driven — fetch issue → trace root cause → fix → ship. Wraps `superpowers:systematic-debugging`. Root cause MUST be confirmed before any fix is written.
10	- Changes-driven — read the working tree → group changes by conventional-commit scope → one commit per scope → ship. No issue required.
11
12	Both end at §6 Branch, Commit, PR, which is shared.
13
14	## When to use
15
16	Issue-driven:
17	- User says "analyze/debug/fix/investigate issue #NNN"
18	- User pastes a GitHub issue URL and asks to debug it
19	- User says "find the root cause of this bug" with an issue reference
20
21	Changes-driven:
22	- "commit my changes", "commit these scope by scope", "commit by scope"
23	- "create a branch and PR", "open a PR for these changes"
24	- "read all changes from X and commit + create PR"
25	- Any request whose end goal is commits/branch/PR from existing working-tree edits
26
27	Not for: Plugin version releases or WP.org SVN deploy — use `wp-plugin-release` and `wp-org-submission`. QA failure triage on an already-open PR — use `wp-ci-qa`.
28
29	## Required Sub-Skill
30
31	Issue-driven only: Invoke `superpowers:systematic-debugging` before any fix. Do NOT skip Phase 1 (root cause investigation). Changes-driven mode skips this — the edits already exist.
32
33	## References
34
35	- `references/gh-reference.md` — `gh` CLI commands, branch naming rules, label discovery, PR template sections, common CI failures
36	- `references/project-entry-points.md` — project layout template: repos, plugin dirs, entry-point files, and key conventions; copy and fill in for your project
37	- `references/conventional-commits.md` — type/scope table, WP-specific scope list, summary rules, multi-commit PR rules, footer conventions, rebase reword
38
39	## Repo ≠ where the issue lives
40
41	The repo that hosts the issue is often NOT the repo that holds the code / receives the PR. Resolve two names up front and keep them distinct:
42
43	- `ISSUE_REPO` — where `gh issue view` / `gh issue edit` run.
44	- `CODE_REPO` — where the affected code lives; where you branch, push, and `gh pr create --repo "$CODE_REPO"`.
45
46	When they differ, the PR's close footer must be cross-repo: `Closes ISSUE_OWNER/ISSUE_REPO#N` (a bare `Closes #N` only closes an issue in the same repo).
47
48	Real example: issues live in `my-org/my-plugin`, but the buggy code + PR live in `my-org/my-plugin-pro` → PR opens on `my-plugin-pro`, body says `Closes my-org/my-plugin#247`.
49
50	---
51
52	## Changes-Driven Workflow
53
54	Use this when the user wants to ship existing uncommitted edits. Skip to §6's mechanics but commit scope by scope rather than one lump.
55
56	### A. Read every change
57
58	```bash
59	git status
60	git diff # unstaged
61	git diff --staged # staged
62	```
63
64	Read the full diff, not just the file list — a single file can contain edits belonging to different scopes, and the commit message's "why" depends on what actually changed.
65
66	### B. Group changes by scope
67
68	Map each change to one conventional-commit scope. Scopes are project-defined — read the repo's CLAUDE.md for the list, don't assume.
69	- ShopFlow: `api, cart, checkout, orders, products, customers, payments, shipping, taxes, coupons, inventory, admin, dashboard, blocks, spa, database, templates, email, reports, build, i18n`.
70
71	Group by what the change is about, not just which directory it lives in. Examples from real sessions:
72	- `pages/Coupons/index.jsx` + `pages/Coupons/CouponList/index.jsx` → both `coupons`
73	- `pages/AbandonedCart/index.

People who liked this also viewed

6 picks

Type