Plugin: implementation · Categories: hardcoded opinion (1), missing externalization (2)
Source: work-readiness sweep (read-only audit vs docs/PLUGIN-PHILOSOPHY.md + docs/MIGRATION-PLAYBOOK.md)
Findings
plugins/implementation/skills/implement/SKILL.md:56 — "stop and create one (git checkout -b <type>/<description>, or /source-control:worktree when that plugin is installed)"plugins/implementation/skills/implement/context/gotchas.md:29 — "git checkout -b <type>/<description> takes 2 seconds."plugins/implementation/skills/implement/evals/evals.json:21 — eval expected_output bakes the same branch form
Why it breaks agnosticism
<type>/<description> is one branch-naming grammar. Target environments using Jira-key branches (SW2-12345-desc, feature/SW2-12345) diverge. Decisive asymmetry: the same skill externalizes the commit-message convention correctly (SKILL.md:86 defers to consumer CLAUDE.md/rules with Conventional Commits as "a common default") but branch grammar is presented as the form with no "check your branch convention" deferral. Violates extensibility seam 3 (consumer CLAUDE.md/rules is the surface for project conventions) and the convention-resolution ladder (read declared value before defaulting).
Fix direction
Mirror the commit-convention treatment already in the same file: defer to the consumer's branch-naming convention (CLAUDE.md/rules) and present <type>/<description> explicitly as "a common default", not the form. Update the eval to match. No hardcode swap.
Plugin:
implementation· Categories: hardcoded opinion (1), missing externalization (2)Source: work-readiness sweep (read-only audit vs docs/PLUGIN-PHILOSOPHY.md + docs/MIGRATION-PLAYBOOK.md)
Findings
plugins/implementation/skills/implement/SKILL.md:56— "stop and create one (git checkout -b <type>/<description>, or/source-control:worktreewhen that plugin is installed)"plugins/implementation/skills/implement/context/gotchas.md:29— "git checkout -b <type>/<description>takes 2 seconds."plugins/implementation/skills/implement/evals/evals.json:21— eval expected_output bakes the same branch formWhy it breaks agnosticism
<type>/<description>is one branch-naming grammar. Target environments using Jira-key branches (SW2-12345-desc,feature/SW2-12345) diverge. Decisive asymmetry: the same skill externalizes the commit-message convention correctly (SKILL.md:86 defers to consumer CLAUDE.md/rules with Conventional Commits as "a common default") but branch grammar is presented as the form with no "check your branch convention" deferral. Violates extensibility seam 3 (consumer CLAUDE.md/rules is the surface for project conventions) and the convention-resolution ladder (read declared value before defaulting).Fix direction
Mirror the commit-convention treatment already in the same file: defer to the consumer's branch-naming convention (CLAUDE.md/rules) and present
<type>/<description>explicitly as "a common default", not the form. Update the eval to match. No hardcode swap.