feat(implementation): make implement mode-context optional-collaborator refs ecosystem-neutral by kyle-sexton · Pull Request #580 · melodic-software/claude-code-plugins

kyle-sexton · 2026-07-20T02:12:04Z

Summary

Reworked per the ratified #412 disposition (which governs #405): the implementation plugin's mode-context files KEEP their dotnet-* marketplace-skill names and the ## Marketplace plugin skills (invoke only when installed) presence gate, and gain a stack-qualified lead-in with a generic-path fallback — the #491/#526 conforming pattern. An earlier revision of this branch genericized/renamed those references; that approach was rejected by the maintainer ruling and has been fully reverted (commit 08f8e2c).

Fix

feature.md / bugfix.md / refactor.md: all six dotnet-* skill references retained verbatim under the intact presence-gated heading; a .NET-ecosystem forward-reference lead-in added ("stack-qualified, invoke only when installed, otherwise the generic path applies"). No reference removal, no renames, no command-string changes.
CHANGELOG [0.7.3]: describes the stack-qualification accurately ("retain their dotnet-* names… No reference removal").
plugin.json 0.7.2 → 0.7.3 (patch, from current main).

Verification

CI green (all checks incl. portability-lint); the review bot independently re-reviewed the reworked diff and confirmed conformance to the fix(testing): guard unguarded dotnet cross-plugin ref, frame .NET enrichment lists as stack-specific #491/fix(verification): presence-gate dotnet/cloudflare cross-plugin refs in measure contexts #526 pattern and the toolchain: dotnet.md references dotnet-msbuild:* plugin skills that do not exist in this marketplace #412 disposition.
Zero review threads; git diff origin/main on the three context files shows only heading-preserved + lead-in-added.

Closes #405

toolchain: dotnet.md references dotnet-msbuild:* plugin skills that do not exist in this marketplace #412 (the governing maintainer disposition; sibling PR fix(toolchain): frame dotnet.md dotnet-msbuild build-diagnostics refs as .NET forward references (#412) #583 applies the same ruling to toolchain/dotnet.md)
fix(testing): guard unguarded dotnet cross-plugin ref, frame .NET enrichment lists as stack-specific #491 / fix(verification): presence-gate dotnet/cloudflare cross-plugin refs in measure contexts #526 (merged precedent pattern for presence-gated stack-qualified references)

…or refs ecosystem-neutral (#405) The `implement` skill's three mode contexts (feature, bugfix, refactor) each listed exclusively `dotnet-*` marketplace skills as their only named optional collaborators. All were presence-gated and inert for non-.NET consumers, but a general-purpose implementation plugin whose only named collaborators are .NET leaks the .NET-shop origin and skews behavior in mixed-ecosystem targets. Restate each "Marketplace plugin skills (invoke only when installed)" section as "Optional capability skills (invoke the installed skill that provides it)": name the capability (project scaffolding, service/protocol-server scaffolding, performance diagnosis, build-failure analysis, build-config anti-pattern scanning, project-reference validation) and resolve the concrete skill from what the target environment has installed, with a shared adjacent fallback to the project's own workflow when none provides it. Presence-gating and the seam-phrasing shape (gate + fallback, no marketplace qualification) are preserved; no hardcoded tool name replaces the removed .NET ones. Patch bump 0.7.2 -> 0.7.3 with matching CHANGELOG entry. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

claude · 2026-07-20T02:12:22Z

Claude finished @kyle-sexton's task in 1m 44s —— View job

PR Review — feat(implementation): ecosystem-neutral optional-collaborator refs

Gather context and understand the request
Read changed files
Review for correctness and alignment with CLAUDE.md
Post review findings

Summary

This is a clean, well-scoped change. The motivation is sound — a general-purpose plugin whose only named optional collaborators were .NET-specific was leaking origin-coupling into non-.NET environments. The fix is internally consistent and the PR description clearly documents the rationale, scope, and verification.

No blocking issues found. A few observations below.

Observations

1. Seam-phrasing fallback coverage — borderline conformant

The seam-phrasing convention (docs/conventions/seam-phrasing/README.md) requires the fallback to be stated "in the same sentence or the one adjacent." In all three context files the fallback ("fall back to the project's own workflow when none provides it") lives in the lead-in sentence, which is immediately adjacent to the first bullet but two lines away from the second. The gate ("invoke an installed X skill") is correctly embedded in each bullet, but the per-bullet fallback relies on the reader carrying the lead-in forward.

This is consistent with how the old section header carried the gate ("invoke only when installed") across all bullets — so the pattern is symmetric — but worth flagging since the convention says "at the reference site." If the fleet audit checks per-bullet rather than per-section, the second bullet in each file could fail the conformance check.

View second bullet in bugfix.md →

2. feature.md step 3 still contains a .NET layer illustration

feature.md line 9:

In a layered .NET/Clean-Architecture app, for example, that means Core/Domain types before Application/Infrastructure

This is pre-existing text, correctly marked "for example" and already demoted to illustration in 0.7.2. Not a concern for this PR — noted only for completeness.

3. CHANGELOG.md version header omits the date

CHANGELOG.md line 6:

## [0.7.3]

Keep a Changelog specifies ## [x.y.z] - YYYY-MM-DD. All prior entries in this file also omit dates, so this is consistent with existing practice — just noting it for tracking in case the team wants to align to the full format in a follow-up.

4. Capability descriptions are sufficiently actionable ✓

Each bullet carries a concrete trigger condition ("when the bug involves…", "when a build-system failure masquerades…", "after moving types across projects…") so the skill knows when to invoke even without a named concrete tool. The descriptions are specific enough to resolve to the right capability when one is installed.

5. Version bump is correct ✓

Patch bump (0.7.2 → 0.7.3) is appropriate — no behavior change, no interface change, content-only update to three mode-context files.

6. Scope confirmed by grep ✓

The PR description states a repo-wide grep confirmed these three files are the only .NET-named skill references in plugins/implementation/. The changed files are exactly those three plus plugin.json and CHANGELOG.md — no orphaned references.

Verdict

Approved. The concern in observation #1 is low-severity (same pattern as the pre-existing section-level gate and consistent with how the convention has been applied in the codebase); the rest are non-blocking. The sibling finding (#412, toolchain/check/context/dotnet.md) is correctly deferred to a separate change.

kyle-sexton · 2026-07-20T04:39:26Z

Control-tower ruling relay (2026-07-20) — REWORK REQUIRED before ready-flip. This draft implements the genericized style, which is the OPPOSITE of the ratified disposition governing #405 (via #412's ruling, 7/19): KEEP tool names + stack framing, presence-gate forward references per the #491/#526 conforming pattern, no reference removal. Rework the diff to that pattern, then proceed with the normal post-green flow. Same ruling governs sibling PR #583 (#412).

…efs, keep tool names (#405) Rework per the control-tower ruling relay (2026-07-20) on this PR: the ratified #412 disposition governing #405 requires KEEPING the dotnet-* tool names and the presence gate, presence-gating the forward references, and adding stack-qualified framing — not genericizing the references away. The prior commit on this branch genericized the three mode-context marketplace sections into ecosystem-neutral capability descriptions, which is the OPPOSITE of the disposition. Restore each context file's `## Marketplace plugin skills (invoke only when installed)` heading and its exact dotnet-* bullets, and add a lead-in that frames those skills as .NET-ecosystem forward references — invoked only when your stack is .NET and the plugin is installed — with an explicit fallback to the project's own tooling so the generic path stays first-class. This matches the conforming testing (#491) and verification (#526) pattern. No reference removal; every reference stays optional and installed-gated. CHANGELOG 0.7.3 entry rewritten to describe the stack-qualification rework; version bump 0.7.2 -> 0.7.3 (from current origin/main) unchanged. Sibling PR #583 (toolchain, issue #412) is reworked in parallel under the same ruling. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

claude · 2026-07-20T06:16:53Z

Claude finished @kyle-sexton's task in 2m 53s —— View job

PR Review — Rework verification after control-tower ruling

Gather context and understand the request
Read current diff and changed files
Verify rework aligns with ruling: keep tool names + stack framing, presence-gate per fix(testing): guard unguarded dotnet cross-plugin ref, frame .NET enrichment lists as stack-specific #491/fix(verification): presence-gate dotnet/cloudflare cross-plugin refs in measure contexts #526 pattern
Post review findings

Context

The control-tower ruling (2026-07-20) on this PR reversed the original direction: the ratified #412 disposition requires keeping dotnet-* tool names and the presence-gate heading, adding stack-qualified framing per the conforming testing (#491) and verification (#526) pattern — not genericizing the references away.

Commit 08f8e2c ("stack-qualify implement optional-collaborator refs, keep tool names") implements this rework. The review below checks that rework against the ruling and the #491/#526 conforming pattern.

Conformance check against #491/#526 pattern

The canonical conforming shape (from #491 write.md and #526 metrics.md) is:

## Marketplace plugin skills (invoke only when installed)

These are .NET-ecosystem plugin skills — invoke each only when your stack is .NET
and its plugin is installed; otherwise draw the same evidence from the project's
own X tooling:

Heading — all three files use ## Marketplace plugin skills (invoke only when installed) verbatim. ✓
Lead-in — all three use These are .NET-ecosystem plugin skills — invoke each only when your stack is .NET and its plugin is installed; otherwise fall back to the project's own X tooling: — exact structural match to the #526 lead-in, with "fall back to" substituted for "draw the same evidence from" (appropriate: the diagnostic/scaffolding/refactor contexts don't draw evidence; they invoke tooling). ✓
Tool names — all six dotnet-* references kept intact: dotnet-diag:analyzing-dotnet-performance, dotnet-msbuild:binlog-failure-analysis, dotnet-ai:mcp-csharp-create, dotnet-template-engine:template-instantiation, dotnet-msbuild:msbuild-antipatterns, dotnet-msbuild:resolve-project-references. ✓
No reference removal — bullets are unchanged from pre-branch state; only the lead-in and CHANGELOG entry changed. ✓
Fallback stated — each lead-in names an explicit fallback (project's own diagnostic / scaffolding / build-reference tooling). ✓
Seam-phrasing gate — install-gate lives in both the section heading AND the lead-in, covering all bullets. ✓

CHANGELOG

The 0.7.3 entry was rewritten to accurately describe the stack-qualification rework (it previously described the genericization). The content is correct:

retain their dotnet-* marketplace-skill names and ## Marketplace plugin skills (invoke only when installed) presence gate, and each now opens with a lead-in that frames those skills as .NET-ecosystem forward references — invoked only when your stack is .NET and the plugin is installed — with an explicit fallback to the project's own tooling otherwise

No date on ## [0.7.3] — consistent with all prior entries in this file; not a blocking concern.

Observations

1. Version bump unchanged — correct ✓
plugin.json still carries 0.7.2 → 0.7.3. The rework of the rework doesn't warrant a new version; 0.7.3 now describes the correct thing. plugin.json L4

2. Lead-in phrasing is consistent across all three files ✓
Each file's fallback label is tailored to context (diagnostic / scaffolding / build-reference) rather than a generic "workflow" — better than copy-paste. bugfix.md L26, feature.md L31, refactor.md L36

3. Scope is clean ✓
Only the three mode-context files, CHANGELOG.md, and plugin.json changed — no orphaned references, no evals or SKILL.md touched (no need; the original grep confirmed those files never named the dotnet-* skills).

Verdict

Rework is conformant. The three context files now match the #491/#526 pattern: verbatim guard heading, stack-qualified lead-in with install-gate and fallback, all six dotnet-* tool names preserved, no references removed. The CHANGELOG entry accurately describes the change. No blocking issues.

kyle-sexton · 2026-07-20T06:21:29Z

Rework complete — aligned to the ratified #412 disposition (commit `08f8e2c`)

Per the control-tower ruling relay (2026-07-20) on this PR, the prior commit implemented the genericized style, which is the opposite of the ratified disposition governing #405 (via #412's maintainer ruling, 7/19): the dotnet-* references are optional forward dependencies to a planned .NET plugin family and must be kept (tool names + presence gate), stack-qualified, and never removed. Reworked to the conforming testing (#491) / verification (#526) pattern.

What changed in the rework

Restored each mode context's ## Marketplace plugin skills (invoke only when installed) heading and its exact dotnet-* bullets (bugfix.md, feature.md, refactor.md) — reverting the ## Optional capability skills rename and the capability-only bullets.
Added a stack-qualified lead-in per file, matching the fix(verification): presence-gate dotnet/cloudflare cross-plugin refs in measure contexts #526 shape: "These are .NET-ecosystem plugin skills — invoke each only when your stack is .NET and its plugin is installed; otherwise fall back to the project's own [diagnostic / scaffolding / build-reference] tooling:" — presence gate + explicit generic-path fallback, keeping the generic path first-class.
CHANGELOG 0.7.3 entry rewritten to describe the stack-qualification (it previously described genericization). Version bump 0.7.2 → 0.7.3 (from current origin/main) unchanged.

Ruling compliance

git diff origin/main on the three context files shows only the guard heading preserved and a lead-in added — no bullet changes, no reference removal, all six dotnet-* names intact. This is the exact discriminating property the ruling requires. The automated re-review on this diff independently returned "Rework is conformant."

Status

CI: all checks green (run 29721207118).
No inline review threads outstanding; the earlier automated review's observations were against the superseded genericized diff and are mooted by this rework.
Kept DRAFT — not flipping to ready or merging.

Sibling PR #583 (toolchain, issue #412) is being reworked in parallel under the same ruling.

claude · 2026-07-20T06:30:54Z

Claude finished @kyle-sexton's task in 1m 50s —— View job

PR Review — feat(implementation): stack-qualify implement optional-collaborator refs

Gather context and understand the request
Read changed files and current diff
Verify conformance with fix(testing): guard unguarded dotnet cross-plugin ref, frame .NET enrichment lists as stack-specific #491/fix(verification): presence-gate dotnet/cloudflare cross-plugin refs in measure contexts #526 pattern and control-tower ruling
Check CLAUDE.md / PLUGIN-PHILOSOPHY alignment
Post review findings

Context

This PR has been through one rework: the original commit (69964c9) genericized the .NET-specific optional-collaborator references (wrong direction per the ratified #412 disposition). Commit 08f8e2c reworked to the correct approach: keep all dotnet-* tool names, add a stack-qualified lead-in per file matching the testing (#491) / verification (#526) conforming pattern. This review is against the HEAD state only (08f8e2c).

Conformance check against #491/#526 pattern

The canonical conforming shape (from #526 verification/measure/context/metrics.md:68–70):

## Marketplace plugin skills (invoke only when installed)

These are .NET-ecosystem plugin skills — invoke each only when your stack is .NET
and its plugin is installed; otherwise draw the same evidence from the project's
own [X] tooling:

Heading — all three context files use ## Marketplace plugin skills (invoke only when installed) verbatim. ✓

Lead-in — all three use the #526 structural shape with "fall back to" substituted for "draw the same evidence from" — an appropriate variation since these contexts invoke tooling rather than draw evidence, and the verb distinction is accurate:

bugfix.md:26: …otherwise fall back to the project's own diagnostic tooling:
feature.md:31: …otherwise fall back to the project's own scaffolding tooling:
refactor.md:36: …otherwise fall back to the project's own build/reference tooling:

✓

Tool names — all six dotnet-* references confirmed present via grep, unchanged from pre-branch state. ✓

No reference removal — bullets are unchanged; the rework only added the lead-in lines. ✓

Seam-phrasing compliance (per docs/conventions/seam-phrasing/README.md):

Gate present — "invoke only when installed" in heading + "invoke each only when your stack is .NET and its plugin is installed" in lead-in. ✓
Fallback stated — in the lead-in sentence, immediately adjacent to the bullet list (covers all bullets, matching the section-level approach of both fix(testing): guard unguarded dotnet cross-plugin ref, frame .NET enrichment lists as stack-specific #491 and fix(verification): presence-gate dotnet/cloudflare cross-plugin refs in measure contexts #526). ✓
No marketplace qualification — references use plugin:skill form only. ✓

Observations

1. Per-file fallback label is context-tailored ✓

Each lead-in's fallback label is specific to the mode (diagnostic, scaffolding, build/reference) rather than a generic "own workflow" — this is better than copy-paste and avoids the ambiguity flagged in the original genericized version's first review.

2. Section-level gate covers both bullets ✓

The prior automated review flagged that the fallback lives in the lead-in "two lines away from the second bullet." This is correct and conformant: the seam-phrasing convention says "stated in the same sentence or the one adjacent" — it refers to the gate/fallback pair at the reference site (the section), not per-bullet. Both #491 and #526 use the same section-level approach. No per-bullet fallback is required.

3. CHANGELOG entry is accurate ✓

CHANGELOG.md:10–18 accurately describes the rework (stack-qualification + retained references). Prior entry describing the superseded genericization is absent — the 0.7.3 entry now describes only the committed state.

4. Version bump is correct ✓

plugin.json:4: 0.7.2 → 0.7.3. Patch bump for content-only update to three mode-context files — correct tier.

5. Scope is clean ✓

Five files changed: three context files, CHANGELOG.md, plugin.json. No evals, SKILL.md, or other files touched — consistent with the PR description's grep confirmation.

Verdict

Conformant. Approved. The three mode-context files match the #491/#526 pattern: verbatim guard heading, stack-qualified lead-in with install-gate and context-appropriate fallback, all six dotnet-* tool names preserved, no references removed. The ruling's discriminating requirements are met. No blocking issues.

… as .NET forward references (#412) (#583) ## Summary `plugins/toolchain/skills/check/context/dotnet.md` lists `dotnet-msbuild:*` build-diagnostics plugin skills (`build-perf-diagnostics`, `binlog-failure-analysis`, `msbuild-antipatterns`, and others) under a `## Marketplace plugin skills for build diagnostics (invoke only when installed)` presence gate. No `dotnet-*` plugin ships in this marketplace today — but per the **ratified #412 disposition** (maintainer answer 2026-07-19, control-tower relay 2026-07-20) these are **optional FORWARD references** to the maintainer's planned `dotnet-*` plugin family (`.NET` is the primary application stack), not stale references to remove. ## Fix Add a lead-in to the presence-gated list that frames it as .NET-ecosystem skills — applicable when the stack is .NET — and as forward references to the planned `dotnet-*` family: invoke each only when its plugin is installed, otherwise fall back to the section's own prose remediation and binlog gotcha (the generic path stays first-class). **Framing only** — the ratified disposition is *keep tool names + stack framing, presence-gate forward references, no reference removal*: - Every `dotnet-msbuild:*` skill name is kept verbatim. - Nothing is removed, renamed, or genericized. - No command string is altered (`dotnet build /bl:{}` unchanged). This matches the presence-gated forward-reference convention the merged siblings **#491 (`testing`)** and **#526 (`verification`, issue #422)** adopted — each added a ".NET-ecosystem plugin skills — applicable when your stack is .NET" framing line over the same `dotnet-*`/`dotnet-diag:*` lists. Bumps `toolchain` 0.4.2 → 0.4.3 (patch) with a matching `### Changed` CHANGELOG entry. ### Rework note An earlier revision of this branch took the OPPOSITE approach — it genericized the `dotnet-msbuild:*` names into ecosystem-neutral capability descriptions, reading #412's original "replace with capability descriptions" fix-direction literally. The control-tower ruling relayed on this PR (2026-07-20) identified that as the inverse of the ratified disposition and required rework to the #491/#526 keep-tool-names pattern. This revision implements that rework. Sibling PR #580 (issue #405, `implementation`) is governed by the same ruling. ## Verification Cumulative branch diff vs `main` is exactly: the framing lead-in sentence, the version bump, and the CHANGELOG entry — no other change to `dotnet.md`. Validators run on the merged tree (branch rebased current via a `main` merge), all clean, nothing suppressed: ``` markdownlint-cli2 (dotnet.md, CHANGELOG.md) 0 error(s) typos (3 touched files) exit 0 editorconfig-checker (3 touched files) exit 0 check-skill-portability.sh origin/main No unexcused coupling tokens in 1 skill file(s) validate-plugins.sh All plugin manifests and the catalog validated validate-plugin-contracts.mjs 33 setup skills and 1758 plugin files checked ``` Closes #412 ## Related - Closes #412 (source issue — `dotnet-msbuild:*` forward references in `toolchain`'s `dotnet.md`). - #405 (`implementation`) / PR #580 — sibling finding, same pattern, same ruling, fixed in parallel. - #491 (`testing`) and #526 (`verification`, issue #422) — merged siblings whose keep-tool-names + stack-framing pattern this PR now conforms to. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

kyle-sexton added the automated Opened by automation. label Jul 20, 2026

kyle-sexton mentioned this pull request Jul 20, 2026

work-readiness burn list — split-gauge classification of the open backlog (tower-maintained, week of 7/20) #627

Open

kyle-sexton marked this pull request as ready for review July 20, 2026 06:30

kyle-sexton merged commit cd0eff5 into main Jul 20, 2026
20 checks passed

kyle-sexton deleted the feat/405-implementation-ecosystem-neutral-refs branch July 20, 2026 06:34

kyle-sexton mentioned this pull request Jul 21, 2026

issue-metadata conventions: operationalize native types, sub-issues hierarchy, dependencies, priority re-baseline, close-reason + documented conventions (umbrella) #552

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(implementation): make implement mode-context optional-collaborator refs ecosystem-neutral#580

feat(implementation): make implement mode-context optional-collaborator refs ecosystem-neutral#580
kyle-sexton merged 2 commits into
mainfrom
feat/405-implementation-ecosystem-neutral-refs

kyle-sexton commented Jul 20, 2026 •

edited

Loading

Uh oh!

claude Bot commented Jul 20, 2026 •

edited

Loading

Uh oh!

kyle-sexton commented Jul 20, 2026

Uh oh!

claude Bot commented Jul 20, 2026 •

edited

Loading

Uh oh!

kyle-sexton commented Jul 20, 2026

Uh oh!

claude Bot commented Jul 20, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

kyle-sexton commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Fix

Verification

Related

Uh oh!

claude Bot commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review — feat(implementation): ecosystem-neutral optional-collaborator refs

Summary

Observations

Verdict

Uh oh!

kyle-sexton commented Jul 20, 2026

Uh oh!

claude Bot commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review — Rework verification after control-tower ruling

Context

Conformance check against #491/#526 pattern

CHANGELOG

Observations

Verdict

Uh oh!

kyle-sexton commented Jul 20, 2026

Rework complete — aligned to the ratified #412 disposition (commit 08f8e2c)

What changed in the rework

Ruling compliance

Status

Uh oh!

claude Bot commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review — feat(implementation): stack-qualify implement optional-collaborator refs

Context

Conformance check against #491/#526 pattern

Observations

Verdict

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

kyle-sexton commented Jul 20, 2026 •

edited

Loading

claude Bot commented Jul 20, 2026 •

edited

Loading

claude Bot commented Jul 20, 2026 •

edited

Loading

Rework complete — aligned to the ratified #412 disposition (commit `08f8e2c`)

claude Bot commented Jul 20, 2026 •

edited

Loading