Skip to main content

Pack-to-Pack Communication

Useful packs often build on other packs.

A workflow pack might call a messaging pack. An integration pack might rely on a browser or file capability. A workspace-specific pack might compose several internal packs into one user-facing system.

That is normal and useful. It just needs to remain explicit.

Declare the dependency​

If your pack depends on another pack, declare that relationship in the manifest and design it as part of the capability boundary.

This gives the platform a place to:

  • validate the composition
  • enforce policy
  • explain why one pack is allowed to call another

Keep the dependency narrow​

Depend on the smallest capability you need.

Do not use another pack as a backdoor to broad capability. If you only need one tool, design around that one tool and keep the relationship reviewable.

Compose, do not collapse​

Pack-to-pack communication should let you reuse capability cleanly. It should not blur the pack boundaries until no one can tell which pack owns what behavior.