Add a skill for creating BTrace extensions for target libraries and frameworks

[jbachorik]

Goal

Provide an advanced prompt/skill that can design and scaffold a new BTrace extension for a target library, framework, runtime, or external system.

Unlike #906, which migrates an existing legacy integration, this workflow starts from a target system and derives a maintainable extension architecture.

Inputs

The skill should be able to work from one or more of:

• Maven coordinates and supported version range
• a local or remote source repository
• target JARs and API documentation
• example application code
• desired observations, metrics, or probe operations

Workflow

The skill should:

1. Inspect the target API, dependency graph, classloading behavior, and version compatibility.
2. Identify stable integration points and define the probe-facing use cases.
3. Design the bootstrap-safe extension API using @ServiceDescriptor, Object hand-off, and @ExternalType where appropriate.
4. Separate public API from runtime implementation and prevent target-library types from leaking onto the bootstrap classpath.
5. Determine required BTrace permissions and explain why each is necessary.
6. Implement target interaction through appropriate classloaders, reflection, or cached method handles when direct linkage would be unsafe.
7. Create the required META-INF/services provider declaration.
8. Scaffold the io.btrace.extension Gradle project, metadata, dependencies, shading rules, tests, and documentation.
9. Optionally scaffold example probes and a masked fat-agent configuration for deployment.
10. Verify API purity, artifact contents, provider loading, supported target versions, and a live first trace.

Design requirements

• Prefer stable public target APIs; clearly flag use of internal or version-sensitive APIs.
• Keep target types out of bootstrap-visible extension interfaces unless explicitly modeled as external types.
• Use the defining/application classloader for target-library interaction.
• Support multiple target versions without silently assuming binary compatibility.
• Fail closed when permissions, provider metadata, or classloading boundaries cannot be established safely.
• Explain generated code and leave clear maintenance/version-upgrade guidance.

Acceptance criteria

• Given a representative target framework, produces a compilable API/implementation extension split
• Generates correct service, permission, and provider metadata
• Includes unit tests using realistic target API fixtures
• Includes an integration or example application test demonstrating a first trace
• Produces inspectable API, implementation, and optional fat-agent artifacts
• Documents supported target versions and known compatibility risks
• Can run in analysis-only mode before making repository changes
• Is linked from the BTrace extension-development documentation

Relationship

Related to #906, but intentionally separate:

• [3.0] Add migration prompt/skill for legacy custom system-support packaging #906: migrate an existing legacy custom integration
• this issue: design a new extension from a target library/framework/system