feat(toolchain): dotnet opt-in gate on .editorconfig, visible skip status

[kyle-sexton]

Summary

Adds an opt-in key to the dotnet ecosystem entry — the one lint-bearing ecosystem (of 8: dotnet, python, typescript, bash, markdown, powershell, yaml, cross-cutting) that lacked one. dotnet format's own docs state preferences are read from .editorconfig "if present, otherwise a default set of preferences will be used"; verified empirically (dotnet SDK 10.0.302) that a project with no .editorconfig still fails dotnet format --verify-no-changes against Roslyn's built-in conventions. Without a gate, this imposes formatting opinions on a repo that never configured any — the same class of violation ruff-format/typos-format already avoid at the hook layer.

• check/SKILL.md now honors opt-in for the lint phase — it never did before, so dotnet's check-cmd ran unconditionally whenever .cs/.csproj/etc. changed. Build and test are unaffected; only the lint phase is gated.
• Both check/SKILL.md and lint/SKILL.md make an opt-in-unmet skip visible (skip (opt-in unmet: ...)) instead of lint/SKILL.md's prior behavior of silently dropping the ecosystem from output entirely — this applied to every opt-in-bearing ecosystem, not just dotnet.
• Multi-tool ecosystems (bash's shellcheck-always/shfmt-conditional split; cross-cutting's per-tool config list) get explicit handling so an unconditionally-applicable sub-tool is never suppressed just because a sibling sub-tool's condition is unmet.
• plugins/toolchain version 0.5.2 → 0.6.0 (minor — new capability, not a fix to previously-intended behavior).

Review history

An independent fresh-context review caught two IMPORTANT findings before this PR, both fixed and empirically re-verified:

1. The opt-in condition originally required a C#-specific .editorconfig section ([*.cs]), but a universal [*] section demonstrably governs dotnet format's output on .cs files too (empirically confirmed: [*] indent_style=tab alone triggers real WHITESPACE violations). Widened the condition to [*] or a C#-glob section.
2. The initial "opt-in-unmet skip suppresses the whole ecosystem row" rule was correct for single-condition ecosystems (dotnet, python) but wrong for multi-tool ones (bash, cross-cutting) where one sub-tool's condition can hold unconditionally — fixed both skill files to gate only the actually-unmet sub-tool(s).

plugins/toolchain has no automated test harness (documentation-driven: skills read YAML config, the executing agent runs the resolved shell commands — there's no script to unit-test), so verification here is empirical testing of the underlying dotnet format behavior plus careful prose review, not a CI-gated test suite.

Test plan

• check-jsonschema against ecosystem.schema.json — both dotnet.yaml files (bundled default + example fixture) validate.
• dotnet format --verify-no-changes behavior empirically verified (dotnet SDK 10.0.302): no .editorconfig → built-in defaults apply; .editorconfig with only unrelated globs ([*.md]) → zero effect; .editorconfig with [*] → real effect (matches a [*.cs] section).
• scripts/check-changed-skills.sh origin/main — both edited skills PASS, 0 errors.
• scripts/generate-catalog.mjs --check, scripts/check-changelog-parity.sh --check — pass.
• typos (full repo, matches CI), markdownlint-cli2 on all touched files — clean.
• Independent fresh-context code review — 2 IMPORTANT findings, both fixed and re-verified above.

Related

• Closes feat(toolchain): dotnet batch guard — runtime analyzer/editorconfig detection #835 (epic Epic: lint/static-analysis gap closure #830, sub-item 5 of docs/topics/lint-static-analysis-gaps/PLAN.md, contract landed via docs: add lint/static-analysis gaps brief #829).

🤖 Generated with Claude Code

[claude]

Claude finished @kyle-sexton's task in 3m 24s —— View job

---

PR Review: feat(toolchain): dotnet opt-in gate on .editorconfig, visible skip status

• Gather context and understand the request
• Read changed files and analyze the diff
• Review SKILL.md changes (check + lint)
• Review ecosystem YAML changes (dotnet.yaml)
• Review plugin.json version bump and CHANGELOG
• Post comprehensive review feedback

---

Overall

Solid, well-motivated change. The rationale is sound (verified empirically), the single-vs-multi-tool opt-in distinction is clearly articulated, and the visible-skip-vs-silent-drop fix is an unambiguous improvement. Two findings below — one behavioral nuance that's worth calling out explicitly, one schema staleness gap — plus a few minor prose observations.

---

Finding 1 — Multi-tool opt-in: shfmt runs even when .editorconfig is absent (behavior worth acknowledging)

check/SKILL.md line ~116, lint/SKILL.md line ~89

The multi-tool rule says: when shellcheck's condition holds unconditionally, "still run check-cmd and report its real output." Bash's check-cmd is:

check-cmd: "shellcheck -x -S warning <files> && shfmt -d <files>"

Because the entire check-cmd string is run, shfmt -d <files> will execute even when bash.yaml's opt-in says "shfmt only when .editorconfig declares shell style" and no shell .editorconfig is present. In check-mode this is read-only (-d = diff, no file changes), so the blast radius is low — the user sees formatting diffs for their shell files even though they never configured any. In fix-mode (shfmt -w <files>), it would rewrite files with shfmt's defaults, which is a stronger imposition than the original opt-in intended.

This is a real trade-off and the PR chose the right pragmatic pick (option 3 — splitting commands into separate schema keys — would be a bigger schema refactor). But the current skill prose doesn't acknowledge it: a future author reading "shfmt only when .editorconfig declares shell style" alongside the new multi-tool rule might expect shfmt to be suppressable, then be surprised it isn't. A single-sentence acknowledgment in the Gotchas section of check/SKILL.md would close that gap:

Multi-tool check-cmd atomicity — when a multi-tool ecosystem's check-cmd bundles both a gated and an unconditional sub-tool in one shell string, both run when the unconditional sub-tool's condition holds. The opt-in gate cannot suppress individual commands within a single check-cmd string; split commands into separate ecosystem keys to gate them independently.

View in context →

---

Finding 2 — ecosystem.schema.json: opt-in description is now semantically stale (out-of-scope file, worth flagging)

docs/conventions/ecosystem-commands/ecosystem.schema.json (not changed in this PR) currently says:

"opt-in": {
  "description": "The config file or condition whose presence signals the repo uses this toolchain (e.g. 'biome.json'). Informational for resolvers deciding applicability."
}

After this PR, opt-in is actively evaluated by skills — not merely informational. The single-vs-multi-tool parsing, the skip (opt-in unmet: ...) reporting, and the distinction between single-clause and semicolon-delimited multi-clause values are all derived from the opt-in string's prose shape. The schema description saying "Informational for resolvers" now misleads a future author who reads it as "safe to ignore in resolving behavior."

A follow-up update to the schema description (could be squashed here or logged as a task) would prevent that confusion. Suggested replacement:

"A human-readable condition evaluated by resolvers to decide whether to run this ecosystem's lint phase. Either a single condition for the whole check-cmd (e.g. dotnet, python), or a semicolon-delimited multi-clause string where each clause names a sub-tool and its own condition (e.g. bash). Resolvers report skip (opt-in unmet: ...) when the condition isn't met, rather than silently omitting the ecosystem."

---

Minor observations (no action required)

lint/SKILL.md step 3 → "see step 2/3 below" reference is ambiguous

The phrase "see step 2/3 below" in detection sub-step 3 is intended to point at the top-level ### 2. Run linters and ### 3. Present results sections, but the shared numbering could confuse a reader into looking back at the same sub-list. "see sections 2 and 3 below" would be clearer.

View →

Skip message: ≤10 words produces non-deterministic output

skip (opt-in unmet: <condition, ≤10 words>) asks the agent to summarize a 30-word opt-in string into ≤10 words on the fly. Different agent invocations may produce different summaries. This is intentional for an AI-driven system, but if consistent output matters (for check-jsonschema or diff-based auditing of skill output), consider adding a short opt-in-label key to the schema in a follow-up — a fixed 5–10 word summary that the agent lifts verbatim.

Version bump 0.5.2 → 0.6.0 is correct: new visible behavior (opt-in gate, changed output format) warrants a minor bump, not a patch.

CHANGELOG.md — well-structured, covers all three change categories (Added ×2, Fixed ×1).

reference/ecosystems/dotnet.yaml opt-in comment header — unusually thorough for a YAML comment (13 lines), but it carries empirical verification notes that would otherwise be invisible. The tradeoff is justified.

---

Summary

Approve with the two items above as suggested follow-ups:

1. Add an explicit prose note in check/SKILL.md Gotchas acknowledging that multi-tool check-cmd atomicity means a gated sub-tool (shfmt) still runs when a sibling's unconditional condition holds.
2. Update ecosystem.schema.json's opt-in description to reflect active evaluation semantics (separate commit / separate PR is fine).

Neither blocks merge — the behavior is correct and the conceptual model is sound.

[claude]

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

---

Security Review — PR #890

Tasks

• Load tools
• Fetch PR diff
• Read changed files
• Analyze for security vulnerabilities
• Post findings

---

Scope

Seven files changed across four categories: YAML config (dotnet.yaml ×2), skill instruction markdown (check/SKILL.md, lint/SKILL.md, check/context/dotnet.md), plugin manifest (plugin.json), and changelog. No GitHub Actions workflows, no new scripts, no new dependencies.

Findings

No security issues found.

Here is what I examined and why each area is clean:

Command injection — The opt-in field value is never passed to a shell. It is read by the AI agent as natural-language instruction to evaluate a filesystem condition (.editorconfig presence), and as display text in the skip (opt-in unmet: ...) status string. Neither path reaches a shell exec. The actual shell commands (check-cmd, fix-cmd) are unchanged; this PR only adds a gate that conditionally suppresses one of them.

Path traversal — The .editorconfig walk is bounded explicitly to the repo root (already established by git rev-parse --show-toplevel in the pre-existing skill preamble). No new file access outside that scope is introduced.

Prompt injection via consumer-supplied opt-in text — The opt-in field is consumer-configurable and interpreted by the AI agent. A crafted value could in principle try to influence the agent's behavior. However: (a) the consumer is the repo owner — the same trusted party already able to set a malicious check-cmd or fix-cmd, which are far more direct execution vectors; (b) the bundled default is a safe static string; (c) no third-party can influence this value without write access to the consumer's .claude/ecosystems/ directory. The opt-in field expands the interpretation surface only within the same trust boundary that already exists for every other consumer-configurable key.

Information disclosure — The condition text from opt-in appears in agent output. No credentials, tokens, or sensitive system paths are part of any opt-in value (bundled or example). The opt-in values are purely descriptive condition strings.

Authorization change — The opt-in gate restricts lint execution (dotnet format only runs when .editorconfig is present). Build and test phases are explicitly unaffected. This is a narrowing of behavior, not a widening.

Supply chain / dependencies — Version bump 0.5.2 → 0.6.0 in plugin.json. No new external dependencies, no new action pins, no new uses: or ${{ }} expressions.

GitHub Actions patterns — No workflow files changed.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 82e44f328c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[kyle-sexton]

Both review findings addressed in 9e78fb6:

Claude Code review Finding 1 / Codex P2 (same root cause — check-cmd atomicity): correct catch. My "still run check-cmd, report real output" instruction didn't actually work — check-cmd is one opaque shell string, so a gated sub-tool bundled with an unconditional one (bash's shfmt alongside shellcheck) still ran regardless. Narrowed the claim: the binary opt-in gate now applies cleanly only to single-condition ecosystems (dotnet, python, the actual scope of #835). Multi-tool ecosystems (bash, cross-cutting) keep their unchanged prior behavior — not solved here, since splitting a bundled check-cmd into separately-gateable keys is a schema change out of this PR's scope. Documented the limitation explicitly in check/SKILL.md's Gotchas rather than claiming a fix that doesn't hold.

Claude Code review Finding 2 (schema opt-in description staleness): fixed — updated ecosystem.schema.json's opt-in description to reflect active evaluation semantics. Description-only change, no structural schema edit, so no ecosystem-commands contract version bump.

Minor observations (step 2/3 reference, ≤10-word non-determinism): the step reference is now "sections 2 and 3" per the suggestion. The ≤10-word summary non-determinism is accepted as-is (agent-interpreted prose is the established pattern for this whole field across every ecosystem) — a structured opt-in-label key would be a separate schema addition, not folded in here.

[claude]

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

---

Security Review — PR #890

Tasks

• Load tools
• Fetch PR diff / read changed files
• Analyze for security vulnerabilities
• Post findings

---

Scope

Eight files across: skill instruction markdown (check/SKILL.md, lint/SKILL.md, check/context/dotnet.md), YAML config (reference/ecosystems/dotnet.yaml, examples/dotnet.yaml), schema (ecosystem.schema.json), plugin manifest (plugin.json), and changelog. No GitHub Actions workflows, no new scripts, no new dependencies. Reviewed against HEAD SHA 9e78fb6 (the follow-up narrowing commit is included).

Findings

No security issues found.

Here is what I examined and why each area is clean:

Command injection — The opt-in field added to dotnet.yaml is never passed to a shell. Per check/SKILL.md line 112–116, the agent reads it as natural-language prose to decide whether to gate check-cmd, and the condition summary appears as display text in skip (opt-in unmet: ...). Neither path executes the string. The actual shell commands (check-cmd, fix-cmd, build-cmd, test-cmd) are unchanged from prior behavior; the PR only adds a prose-evaluated gate that conditionally suppresses check-cmd in the lint phase.

Prompt injection via consumer-supplied opt-in text — The opt-in field is consumer-configurable and now actively interpreted by the agent (rather than being informational). A crafted value could try to influence agent behavior through the prompt. However, this does not expand the existing trust boundary: a consumer who can write .claude/ecosystems/dotnet.yaml can already supply arbitrary shell strings in check-cmd, fix-cmd, build-cmd, and test-cmd, which are far more direct execution vectors. The opt-in field's active-evaluation role is a narrower surface than what already exists.

Path traversal — The opt-in condition describes a filesystem walk ("anywhere from the changed file up to the repo root"). This walk is bounded by $REPO_ROOT established via git rev-parse --show-toplevel (SKILL.md line 49/50, carried over from existing skill preamble). The boundary is unchanged; this PR adds no new filesystem access scope.

Authorization change — The opt-in gate restricts dotnet format execution: it only runs when a governing .editorconfig is present. This is a narrowing of behavior, not a widening. Build and test phases are explicitly unaffected (check/SKILL.md line 112: "Build and test always run regardless of opt-in").

Follow-up commit 9e78fb6 specific — This commit removes the claim that the opt-in gate can suppress individual sub-tools in a multi-tool check-cmd (the gate correctly now only applies to single-condition ecosystems like dotnet and python). It also updates the schema description for opt-in. Both changes are documentation-only with respect to shell execution behavior. No new injection surface, no behavioral widening.

GitHub Actions / supply chain — No workflow files changed. No new external dependencies, action pins, or ${{ }} expressions introduced.

Information disclosure — The opt-in string appears in agent output when the condition is unmet. None of the bundled or example opt-in values contain credentials, tokens, or sensitive paths — they are purely descriptive condition strings.

[claude]

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

---

PR Review — Post-Fix Pass (commit 9e78fb6)

• Gather context and understand the request
• Read changed files from the PR diff
• Review fix for Finding 1 (check-cmd atomicity narrowed to single-condition ecosystems)
• Review fix for Finding 2 (ecosystem.schema.json opt-in description update)
• Review remaining files for correctness
• Post final review

---

Overall

Both findings from the initial review are addressed correctly. The skill prose is now internally consistent and the schema description is accurate. One real defect remains: the fix commit updated the skill files but left the CHANGELOG.md's [0.6.0] Added bullet describing behavior that the fix explicitly walked back.

---

Finding — CHANGELOG [0.6.0] multi-tool description is now incorrect

plugins/toolchain/CHANGELOG.md, lines 24–29

The commit 9e78fb6 corrected the skill files but did not update the 0.6.0 CHANGELOG entry. The Added bullet still reads:

Multi-tool ecosystems (bash's shellcheck-always/shfmt-conditional split, cross-cutting's per-tool config list) are only whole-row-skipped when every sub-tool's condition is unmet — an unconditionally-applicable sub-tool (e.g. shellcheck) still runs and reports even when a sibling sub-tool in the same ecosystem is gated.

This describes the intended behavior from the original commit (82e44f3), which both reviewers identified as not actually achievable (check-cmd is an opaque shell string; the partial-skip cannot suppress individual sub-tools). The fix commit acknowledged this and restored prior behavior for multi-tool ecosystems — but the CHANGELOG still claims the partial-skip works as designed.

After 9e78fb6, the true state is: multi-tool ecosystems (bash, cross-cutting) are unchanged by this PR — they simply keep running check-cmd as before. The paragraph above should be replaced with something like:

Multi-tool ecosystems (bash, cross-cutting) whose check-cmd bundles multiple sub-tools into one opaque shell string are not changed by this release — they continue running check-cmd as before. Per-sub-tool gating within a single opaque command string is not addressable without a schema change; the atomicity limitation is documented in check/SKILL.md's Gotchas.

The CHANGELOG is the consumer-facing release summary — shipping it with an incorrect claim about what the release does is a real defect, not a nit. Fix this →

---

Rest of the PR: LGTM

Finding 1 fix (check/SKILL.md) — the rewrite is precise. The binary gate is scoped clearly to single-condition ecosystems; the multi-tool paragraph now correctly says "this gate does NOT apply — check-cmd is a single opaque string… Run check-cmd as before (unchanged from prior behavior)." The new Gotcha bullet names the atomicity limitation explicitly and notes the schema-change prerequisite. No overclaim remains.

Finding 2 fix (ecosystem.schema.json) — the updated opt-in description covers both value shapes (single-condition and multi-clause semicolon-delimited), documents the resolver's active evaluation duty, and replaces the stale "informational" characterization. Accurate.

lint/SKILL.md — consistent with check/SKILL.md after the fix. The "sections 2 and 3 below" wording is clearer than the prior "step 2/3." The single-condition vs. multi-tool distinction is now stated the same way in both skills.

dotnet.yaml (bundled default + example) — the opt-in condition is well-calibrated: gated on [*] or a C#-glob section rather than bare file presence, with a rationale comment that explains why a .editorconfig with only [*.md] doesn't count. Both the bundled default and the example fixture carry the same value.

check/context/dotnet.md — the lint section correctly flags the gate and cross-references the YAML rationale. Appropriate.

Version bump 0.5.2 → 0.6.0 — correct; new externally visible behavior (opt-in gate, changed output format) warrants a minor bump.

---

Summary

One item to fix before merge: update the CHANGELOG [0.6.0] multi-tool paragraph to match what the fix commit actually does (multi-tool ecosystems unchanged, prior behavior retained). Everything else is correct and the overall approach is sound.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9e78fb6a55

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

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

---

PR Review — Post-Fix Pass (commit 3eb0257)

• Gather context and load tools
• Read PR diff and changed files
• Review latest commit (root=true EditorConfig boundary fix)
• Check CHANGELOG accuracy (prior finding resolved in 3eb0257)
• Review all changed files for correctness
• Post final review

---

Overall

Three finding-driven fix commits later, this PR is clean and ready to merge. All findings from the initial review (×2), the post-fix review (×1), and the Codex P2 review (×1) are correctly addressed. The PR now does what it says, the CHANGELOG accurately describes what changed, and the opt-in walk boundary honors real EditorConfig discovery semantics.

---

Commit 3eb0257 — Correct

The root = true boundary fix addresses the real gap Codex caught: EditorConfig discovery stops at a root = true marker, so a section in a file above that marker is never seen by dotnet format for files in the nested subtree. Before this fix, the opt-in walk went "up to the repo root" unconditionally and could falsely satisfy the condition from a parent section that dotnet format itself would ignore — producing a phantom opt-in and letting the gate pass when it should have skipped.

The fix is correct in three ways:

dotnet.yaml opt-in string (line 34) — now reads "walked from the changed file up to the repo root or a root = true marker (whichever comes first)." This correctly mirrors EditorConfig discovery semantics; the agent stops the walk at whichever boundary comes first, so a parent section beyond a root = true marker is never consulted.

Header comment (lines 20–27) — explains the rationale with the empirical verification (dotnet SDK 10.0.302, verified that root = true genuinely terminates discovery) and cross-references bash-format.sh's shell_editorconfig_opt_in() as prior art for the same discipline. The precedent link is accurate.

examples/dotnet.yaml (line 9) — synced to match the bundled default's opt-in value. The two files are consistent.

CHANGELOG [0.6.0] (lines 10–18) — the first Added bullet is updated to include the root=true boundary in the description, and the prior commit's inaccurate multi-tool paragraph is gone. All three bullets are now accurate: (a) dotnet opt-in with correct walk semantics, (b) binary gate scoped to single-condition ecosystems only with explicit note that multi-tool ecosystems are unchanged, (c) visible skip for single-condition ecosystems (not mis-claiming coverage of multi-tool).

---

All Prior Findings — Confirmed Resolved

Finding	Source	Commit	Status
check-cmd atomicity: gate can't suppress individual sub-tools in a bundled string	Claude Code, Codex P2	9e78fb6	✓ Narrowed to single-condition ecosystems; Gotchas documents the limitation
ecosystem.schema.json opt-in description: "informational" is stale	Claude Code	9e78fb6	✓ Updated to describe active evaluation, both value shapes, visible skip
CHANGELOG multi-tool paragraph: describes behavior the fix walked back	Claude Code	3eb0257	✓ Replaced with accurate "unchanged from prior behavior" language
EditorConfig root=true boundary: outer section beyond a marker shouldn't satisfy gate	Codex P2	3eb0257	✓ Walk now stops at the first root=true marker or repo root

---

Rest of the PR — LGTM

check/SKILL.md — the binary gate (lines 112–118) is precisely bounded: explicitly "single-condition" ecosystems (dotnet, python), explicit "does NOT apply" for multi-tool, and Gotcha bullet names the atomicity limitation with the schema-change prerequisite. No overclaiming.

lint/SKILL.md — consistent with check/SKILL.md. Detection step 3 (line 89) and run step 2 (line 95) both correctly state the same single-condition / multi-tool distinction. The "sections 2 and 3 below" reference from the earlier nit is already "sections 2 and 3."

ecosystem.schema.json — opt-in description (line 48) now covers both value shapes, documents the active evaluation contract and visible-skip obligation. Accurate.

check/context/dotnet.md — lint section (lines 36–42) correctly flags the opt-in gate and cross-references dotnet.yaml for rationale. No duplication.

plugin.json — version 0.6.0 is correct. New visible behavior (opt-in gate, changed output format) warrants a minor bump.

---

One Minor Observation (no action required)

opt-in string: inclusivity of root = true file is implied but not explicit

The opt-in value says "walked from the changed file up to the repo root or a root = true marker." A strict reading of "up to X" could be interpreted as exclusive of X (stopping before checking that file's sections). The header comment clarifies the intended behavior ("stops at a root = true marker even when that file has no C#-relevant section" implies the file IS checked before stopping), and because the agent resolves the bundled YAML (including header comments) the behavior in practice is unambiguous. But if the opt-in string is ever used in a context where only the value is visible, "up to and including the root = true marker" would be strictly unambiguous. Not blocking — the comment + value together are clear.

---

Summary

Approve. All four finding categories are correctly addressed, the CHANGELOG is accurate, the opt-in walk semantics honor real EditorConfig discovery behavior, and the scope is correctly bounded to single-condition ecosystems. The PR is ready to merge.

[claude]

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

---

Security Review — PR #890 (HEAD: 3eb0257)

Tasks

• Load tools
• Fetch PR diff (including latest commit 3eb0257)
• Read changed files
• Analyze for security vulnerabilities
• Post findings

---

Scope

Eight files across three commits. The third commit (3eb0257) is the one not covered by the two prior security reviews. Files: YAML config (reference/ecosystems/dotnet.yaml, examples/dotnet.yaml), skill instruction markdown (check/SKILL.md, lint/SKILL.md, check/context/dotnet.md), schema (ecosystem.schema.json), plugin manifest (plugin.json), changelog. No GitHub Actions workflows, no new scripts, no new package dependencies.

Findings

No security issues found.

Here is what I examined and why each area is clean.

---

Commit 3eb0257 specific — .editorconfig walk boundary and prompt injection surface

This commit is the first to explicitly instruct the agent to read .editorconfig files for the presence of a root = true marker. That is a new file-read vector: a crafted .editorconfig could theoretically inject content into the agent's context window when the agent evaluates the opt-in condition.

In practice, this is within the same trust boundary that already exists for every other consumer-configurable key. The consumer who controls the .editorconfig already controls check-cmd, fix-cmd, build-cmd, and test-cmd — opaque shell strings the agent executes directly, which are a far more capable injection surface. A hostile actor who can place a crafted .editorconfig in the repository already has write access and can reach the agent via much more direct vectors. The opt-in walk adds no new trust surface; it adds a new file read within the already-trusted consumer's own repository.

The walk itself is bounded correctly — the skill instructs the agent to stop at the repo root ($REPO_ROOT resolved via git rev-parse --show-toplevel) or at a root = true marker, whichever comes first. This mirrors the boundary already applied in bash-format.sh's shell_editorconfig_opt_in(). No unconstrained path traversal.

Command injection — The opt-in field value is read as prose and never passed to a shell. The agent uses it to decide whether to suppress check-cmd; the condition text appears only as display text in skip (opt-in unmet: ...) output. No execution path touches this string.

Authorization change — The opt-in gate restricts dotnet format execution. Build and test phases are explicitly unaffected (check/SKILL.md: "Build and test always run regardless of opt-in"). This is behavioral narrowing, not widening.

Information disclosure — The opt-in string appears in agent output when the condition is unmet. The bundled default and example values contain only descriptive prose; no credentials, tokens, or sensitive paths.

GitHub Actions / supply chain — No workflow files changed. Version bump 0.5.2 → 0.6.0 in plugin.json; no new external dependencies, action pins, or ${{ }} expressions introduced.

---

Summary

Three independent security passes on this PR (two prior, this one covering HEAD). All three find the same result: the changes are a behavioral narrowing of lint execution, the new opt-in evaluation and .editorconfig read operate within the existing consumer trust boundary, and no new injection surface, authorization gap, or information-disclosure risk is introduced.

[kyle-sexton]

Both new findings from the post-fix review pass addressed in 3eb0257:

Codex — EditorConfig root=true boundary: correct, empirically confirmed. The opt-in walk now stops at whichever comes first — the repo root or a root = true marker — matching this repo's own bash-format.sh precedent for the identical discipline.

Claude Code review — stale CHANGELOG entry: correct, the [0.6.0] entry still described the multi-tool partial-skip behavior the prior commit (9e78fb6) walked back. Corrected to describe what actually ships: single-condition ecosystems get the new binary gate; multi-tool ecosystems are unchanged (documented limitation, not a fix).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3eb02573b3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Apply opt-in skip reporting beyond dotnet/python

When /toolchain:lint sees a changed Markdown/PowerShell/YAML file whose configured opt-in is unmet, this new rule only defines the visible skip (opt-in unmet: ...) behavior for dotnet and python. Those ecosystems also have single-condition opt-ins in the bundled defaults, so this leaves the old silent omission path in place for them despite the updated results-table contract saying unmet opt-ins should be reported. Please treat every single-condition opt-in ecosystem, not just dotnet/python, as a visible skip.

Useful? React with 👍 / 👎.