Skip to content

Document skill load metadata#35

Merged
Stephen Belanger (Qard) merged 1 commit into
mainfrom
skill-load-metadata-spec
Jul 3, 2026
Merged

Document skill load metadata#35
Stephen Belanger (Qard) merged 1 commit into
mainfrom
skill-load-metadata-spec

Conversation

@Qard

@Qard Stephen Belanger (Qard) commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Summary

  • add a feature spec for skill attribution metadata
  • separate observed skill loads on normalized skill tool spans from explicit parsed requests on message/turn spans
  • define singular skill_* metadata for observed tool spans and plural loaded_* metadata for explicit multi-skill message parsing
  • define optional metadata.skill_load_trigger on skill tool spans: missing defaults to implicit, explicit is emitted only when the load is known to come from explicit user skill syntax
  • clarify that loaded skill content belongs in the normal tool span output, not metadata

Validation

  • scripts/test.sh

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just make a coding agent plugin spec, and make this a section as part of that?

@Qard Stephen Belanger (Qard) force-pushed the skill-load-metadata-spec branch 2 times, most recently from c2feb76 to a2e886e Compare July 2, 2026 18:45
Stephen Belanger (Qard) added a commit to braintrustdata/braintrust-claude-plugin that referenced this pull request Jul 3, 2026
## Summary
- normalize Claude Skill tool calls as observed skill-load tool spans
- attach singular skill metadata including skill name and original tool
name
- omit the optional skill_load_trigger field for phase 1, so these loads
default to implicit under the spec
- add post-tool hook coverage for the normalized span payload

## Spec
- braintrustdata/braintrust-spec#35

## Validation
- ./run_tests.sh test_post_tool_use
@Qard

Copy link
Copy Markdown
Contributor Author

Abhijeet Prasad (@AbhiPrasad) It's not specific to coding agents though. Any agent which uses skills should be able to capture the use of those skills, and we instrument a bunch of such agent harness frameworks in our SDKs, so I think it makes sense here.

Actually, I'm not convinced there's many coding agent specific things we'd need that should not apply to SDKs to justify having a separate spec, at least not at this stage. We can always re-evaluate later, but at the moment I don't think a split makes sense.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay that's fair, let's keep it separate for now then.

@Qard Stephen Belanger (Qard) merged commit 7fd4f12 into main Jul 3, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants