A Class C candidate under
ADR 0028.
The ADR gates the proposal; it does not mandate the split. A decline with recorded reasoning
closes this issue.
The shape
source-control carries 7 skills and five hooks across three events:
| Event |
Hook |
Matcher |
PreToolUse |
pr-body-linkage-gate.sh |
Bash |
PreToolUse |
worktree-add-containment-gate.sh |
Bash |
PreToolUse |
pr-linkage-mcp-gate.sh |
^mcp__github__(create|update)_pull_request… |
PostToolUse |
worktree-add-claim-gate.sh |
Bash |
WorktreeCreate |
worktree-create-gate.sh |
— |
What to decide
This one has the clearest internal seam of the five candidates: the hooks fall into two unrelated
groups — PR-body linkage (2 hooks, on both the CLI and MCP paths) and worktree containment/claiming
(3 hooks). Before asking whether to split hooks from skills, ask whether the plugin is already two
plugins.
Then the coupling test that decides it: the PR gates enforce
pr_body_required_sections, which /source-control:pull-request also READS when drafting. That is
the documented two-reads pattern — the skill drafts to the convention, the gate enforces it. Two
surfaces of one convention is an argument for keeping them together, and it is the same shape that
makes claude-ops (#3723) questionable.
The worktree gates may be a different answer from the PR gates. A split does not have to be
all-or-nothing.
The bar a split has to clear
Per the ADR. Note additionally that pr-linkage-mcp-gate.sh is matched on an MCP tool rather than
Bash, so a consumer who never uses the GitHub MCP server pays nothing for it — which weakens the
"always-on cost" half of the split argument for that hook specifically.
Constraints
- Every
<name>_enabled userConfig boolean stays either way.
pr_body_required_sections is owned at marketplace level
(docs/conventions/pr-body-convention/), not by this plugin. A split must not move it or fork it.
Related
A Class C candidate under
ADR 0028.
The ADR gates the proposal; it does not mandate the split. A decline with recorded reasoning
closes this issue.
The shape
source-controlcarries 7 skills and five hooks across three events:PreToolUsepr-body-linkage-gate.shBashPreToolUseworktree-add-containment-gate.shBashPreToolUsepr-linkage-mcp-gate.sh^mcp__github__(create|update)_pull_request…PostToolUseworktree-add-claim-gate.shBashWorktreeCreateworktree-create-gate.shWhat to decide
This one has the clearest internal seam of the five candidates: the hooks fall into two unrelated
groups — PR-body linkage (2 hooks, on both the CLI and MCP paths) and worktree containment/claiming
(3 hooks). Before asking whether to split hooks from skills, ask whether the plugin is already two
plugins.
Then the coupling test that decides it: the PR gates enforce
pr_body_required_sections, which/source-control:pull-requestalso READS when drafting. That isthe documented two-reads pattern — the skill drafts to the convention, the gate enforces it. Two
surfaces of one convention is an argument for keeping them together, and it is the same shape that
makes
claude-ops(#3723) questionable.The worktree gates may be a different answer from the PR gates. A split does not have to be
all-or-nothing.
The bar a split has to clear
Per the ADR. Note additionally that
pr-linkage-mcp-gate.shis matched on an MCP tool rather thanBash, so a consumer who never uses the GitHub MCP server pays nothing for it — which weakens the"always-on cost" half of the split argument for that hook specifically.
Constraints
<name>_enableduserConfig boolean stays either way.pr_body_required_sectionsis owned at marketplace level(
docs/conventions/pr-body-convention/), not by this plugin. A split must not move it or fork it.Related