fix(sdk): warn for silently dropped skill, command, and hook options - #8
Merged
Merged
Conversation
|
@arielarevalo is attempting to deploy a commit to the agent-plugin-sdk Team on Vercel. A member of the Team first needs to authorize it. |
Emitters now record an unsupported-option warning for declared optional fields their native format cannot carry, instead of dropping them silently. Same contract as the Codex subagent warnings (jal-co#6). Output files are unchanged.
arielarevalo
force-pushed
the
fix/unsupported-option-warnings
branch
from
September 1, 2026 18:08
6b24bdc to
8793c7d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Emitters now record an
unsupported-optionwarning for each declared optional field they drop because their native format has no field for it. This coversallowedTools,disableModelInvocation,license, andmetadataon skills,allowedTools,argumentHint, and passthroughfrontmatteron commands, and thepowershellhook command variant on Claude, Codex, and Gemini. Output files are unchanged. The build still degrades, andwarnings[]now reports the loss.Why
src/warnings.ts:6-9states the contract: the build "emits a structuredBuildWarninginstead of throwing or silently dropping it". The commands docs page already promised this behavior: "the command body still emits and the build reports a warning for the unsupported option". #6 applied the pattern to one case, the Codex subagentfrontmatter, and #5 lists two of the cases here under "Related". This change applies the same pattern to the remaining option-level drops.How
Each dropped field warns through the repo's two existing idioms. Options that repeat across harnesses get one helper each in
src/harnesses/shared.ts, in the same shape aswarnAsyncandwarnEventinsrc/harnesses/hooks.ts, and each emit site guards explicitly, in the same style as the subagent warnings in the Codex emitter (#6). The Pi, Cursor, and Windsurf emitters now accept thectxparameter thatHarness.emitalready declares, which is why nothing there could warn before.warnPowershellsits beside the existingwarnAsync. The type doc comments and the skills, commands, and hooks docs pages now state per harness what is emitted and what warns. The hooks docs example also usedunix:where the type declaresbash:, fixed in passing.Four adjacent silent drops stay untouched on purpose, because each needs a decision rather than a warning. Claude Code natively accepts skill
license,metadata, anddisable-model-invocationin SKILL.md, so the right fix there is emission. Copilot prompt files have a nativetoolslist, same reasoning. Codex skillmetadatamay belong inagents/openai.yaml. Cursor drops the required commanddescription, and a warning there would fire on every Cursor build. I can file or fix those separately.Warning pattern
The hand-written shape is deliberate, to respect the existing idioms above and the documented split in
src/emit.ts: feature gating is central, and option warnings come from the emitter throughctx.warn. The alternative is to centralize: extend the per-featuresupportsmap to option level and letemitForderive these warnings. That would also surface per-option support insupportMatrix(). Value-level cases such as thepowershellvariant and event mapping do not fit a boolean matrix, so some hand-written warnings would remain either way. If you prefer the central direction, I can open a separate issue for it, and this PR keeps the current pattern in the meantime.Testing
pnpm turbo typecheck test lint buildpasses. A new table test,test/unsupported-option-warnings.test.ts, builds one plugin with every optional field set and asserts the exact per-harnessfeature.optionwarning set. It also asserts that files still emit minus the fields, that Copilot emitspowershellnatively aswindows, that empty values warn nothing, and that a plugin with no optional fields builds warning-free on all eight harnesses.