Three findings from wiring an Agent Script service agent to an apex://
invocable (API v67.0, sf CLI 2.145.6):
1. `sf agent validate authoring-bundle` returns success:true for an action
param with the wrong numeric type. Only the server-side check during the
publish step catches it, so a green validate is not evidence the action
I/O types are correct.
2. Apex Integer and Apex Decimal do not behave the same. An Integer param
as bare `number` is rejected at publish; a Decimal output as bare
`number` publishes and runs correctly. The existing "bare number fails
at publish in action inputs/outputs" note reads as universal, which
sends authors hunting for a complex type a Decimal does not need.
3. Preview started with --api-name writes trace files containing only {}.
Only the --authoring-bundle path produces readable traces. This is not
academic: a service agent cannot always be previewed via
--authoring-bundle, leaving --api-name as the only option and making the
"read the trace after every utterance" rule unsatisfiable. Documented a
discriminating-value fallback for that case.
All additive; no existing guidance removed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
chore: remove stale manifest.json and DOCS_ONLY.md @W-23538245@
manifest.json was a hand-curated skill registry last updated Feb 2026
that nothing consumes. DOCS_ONLY.md incorrectly states the repo contains
no code.
Add stability disclaimer to README
Skills are under active development and don't carry GA-level stability
guarantees. This note sets expectations for developers who fork or sync
the repo that skill names, structure, and availability may change without
notice.
Signed-off-by: Hemant Singh Bisht <hsinghbisht@salesforce.com>
fix: update stale skill name references to match new naming convention
- README.md: update folder structure examples from old names
(generating-apex, generating-custom-object, generating-flow) to new
names (platform-apex-generate, platform-custom-object-generate,
automation-flow-generate)
- samples/AGENT.md (b2e + b2x): update using-ui-bundle-salesforce-data
to experience-ui-bundle-salesforce-data-access
fix: allow nested YAML lists in metadata sub-keys (sync with internal)
The validator incorrectly rejected skills with list-type fields (e.g.
cliTools) nested under metadata sub-keys. This syncs the
parseMetadataBlock() fix from sf-skills-internal that distinguishes
direct-child lists from nested ones.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
