T-66RD-agent-pants-additions-plugin-level-assets-resource-excludes
State: closed/done · Impact: medium · Complexity: large
sdlc’s plugin ships more than prose skills — a built CLI (sdlc.js, a
wasm artifact, a launcher) that every skill’s shell-outs depend on,
plus a tests//fixtures tree that must never ship. agent-pants today
has no concept of plugin-level binary assets or resource excludes, and
no per-skill shim for locating the CLI relative to the rendered skill
file.
sdlc’s pre-cutover plugin export path (sdlc harness export, itself
retired in a later Phase 3 task) has its own bespoke logic for bundling
the CLI and excluding dev-only files. agent-pants’s vault-note build
has neither concept.
Proposed
Section titled “Proposed”Three additions to agent-pants: (1) plugin-level assets — a way to
declare cli/sdlc.js, the wasm artifact, and the launcher as files
copied into the built plugin verbatim, not authored as vault notes; (2)
resource excludes — an agent-pants.yaml list (or fixed convention) so
tests/ and fixtures never make it into a build; (3) a skill-relative
scripts/sdlc shim emitted per skill, which walks up from its own
location to find cli/sdlc, falling back to PATH — with Claude able to
render ${CLAUDE_PLUGIN_ROOT} where that is the more direct route.
Conventions for all three are served by sdlc conventions show <name>.
Approach
Section titled “Approach”- Add a plugin-level
assets:key to the agent-pants project-file schema, and have the build step copy each listed file/glob into the built plugin’s root unmodified. - Add a resource-excludes mechanism (a project-file key or a fixed exclude convention) so
tests/and fixture directories never land inmarketplace.out. - Add the per-skill
scripts/sdlcshim generator: for every skill in the build, emit a small shim script that resolves the CLI by walking up parent directories looking forcli/sdlc, falling back tosdlcon PATH. - Write the
sdlc conventions show <name>entries documenting all three (asset declaration, exclude convention, shim contract) so a skill author knows how to invoke the CLI without hand-rolling the walk-up logic. - Build sdlc’s plugin end to end with the nested config and confirm the CLI, wasm and launcher land
in the output and
tests/does not.
| Area | Note |
|---|---|
agent-pants crate/CLI | Assets/excludes/shim generation — outside solutions/ontological |
solutions/ontological/conventions/ | New sdlc conventions show entries |
solutions/ontological/agent-pants.yaml | Declares the assets/excludes for sdlc’s build |
Acceptance criteria
Section titled “Acceptance criteria”- AC-1: A built sdlc plugin contains cli/sdlc.js, the wasm artifact, and the launcher, copied
verbatim (not vault-note-rendered). Done for what actually exists on disk: the launcher
(
cli/sdlc) lands verbatim at.claude-plugin/packs/sdlc/cli/sdlc. Neithersdlc.jsnor a wasm artifact exists as a checked-in file yet — theassets:mechanism is generic and will carry both the moment they do; nothing further to wire. - AC-2: A built sdlc plugin contains no tests/ directory or fixture files.
- AC-3: Every emitted skill in the built plugin has a scripts/sdlc shim that resolves to the plugin’s own cli/sdlc when run from inside the built tree.
- AC-4:
sdlc conventions show assets,sdlc conventions show excludes, andsdlc conventions show shim(or however the three are named) each print non-empty guidance.
Out of scope
Section titled “Out of scope”- Runtime resolution logic inside the CLI itself beyond the shim’s walk-up (existing CLI-launch behavior).
- Any change to what the wasm artifact contains.
Dependencies
Section titled “Dependencies”- The nested agent-pants.yaml the assets/excludes are declared in.