Skill Bundle Composition
Original, project-agnostic instructions. Agent-host effectiveness remains experimental.
When to use
Select canonical public skills and bind private repository context separately without copying instructions, silently installing packages, or broadening tool authority. Use for an actual task in this domain, under the consuming repository’s approved policies.
When not to use
Do not impose this procedure on unrelated or trivial work. Do not migrate tools, install services, perform production effects, publish, or delete resources without the task’s required authorization.
Inputs and tailoring
Resolve the task goal, accepted source/contract baseline, relevant paths, installed versions, actual project-owned commands, effect policy, and required evidence. Read existing configuration before asking for information it already contains. Concrete repository roots, credentials references, command bindings, and private policies belong in the consuming adapter, not this public skill.
Procedure
1. Establish the boundary
Select by actual task outcomes rather than loading every instruction into every agent. Separate foundational guidance from optional domain procedures. A bundle is a discovery selection, not mandatory invocation of all members.
2. Choose the supported contract
Use stable skill IDs and a reviewed pinned checkout. Resolve SKILL.md and supporting files to content hashes and preserve companion tools where needed. The repository resolver is read-only and does not install or execute selected packages.
3. Implement or qualify the path
Bind concrete repository roots, accepted contracts, approved check IDs/argv, identities, limits, and organization policy in a private adapter. Keep credentials, private knowledge, and company-specific paths outside public packages.
4. Exercise failure and integration seams
Keep host/repository policy and execution authorization independent. MCP resources/prompts provide guidance; tools perform bounded actions. Bundle metadata is not a permission grant, shell input, or proof that a child agent loaded a skill.
5. Verify and hand back evidence
Reject unknown/duplicate IDs and unsafe paths, verify selected bytes against the accepted lock, and expose dirty or unknown provenance. Test intended/non-trigger behavior in each host before claiming compatibility; review source updates before changing a private pin.
Output
Return a task-sized implementation or review record containing the accepted invariant, source/environment identity, concrete decisions and changed paths, actual check results, evidence locations, remaining uncertainty, and next action. Distinguish passed, failed, blocked, and not-run checks; package shape is not behavior evidence.
Failure handling
A selection references a missing helper or traversal path: fail resolution and preserve the prior known selection rather than substituting another package. When access or prerequisites are unavailable, preserve existing work and report the smallest missing input. Do not fabricate commands, results, compatibility, or successful external effects.
Example
Two internal adapters select the same durable-workflow instructions and bind different approved queues/checks; they do not maintain separate edited copies of those skill bodies. This is a synthetic example, not a completed production or agent-host run.
Evaluation
Use references/scenarios.json for intended, boundary, and non-trigger evaluation inputs. Keep their status not-run until a separate real host evaluation records actual outcomes.
Technical references
Consult documentation for the installed versions before using version-sensitive APIs. These are underlying-technology references, not copied upstream skill bodies.