Small-plugin acceptance: skills and plain hooks without an unnecessary MCP/RSC runtime or empty Workbench

[ScriptedAlchemy]

Goal

Make a Ponytail-shaped plugin a first-class small end of the existing authoring/build/dev contract, alongside Cargo Hauler's demanding executable-plugin coverage. Extend existing examples/tests before adding another example or framework layer.

This is acceptance/regression work; it does not assert that static skills currently require an MCP server. The existing examples/skills-starter/agent-bundle.config.ts already declares a small skills bundle without registering one, and closed #108 already establishes static Skill compilation and portable Markdown support.

Reference evidence

Ponytail at 974d940a1c5344210874150b98ff0d2c861fab6a shares skills and an instruction builder across thin native integrations:

• Shared instruction builder
• Shared hook registration
• Rule-copy drift checks

Its useful product does not depend on having a browser dashboard or a long-lived MCP server. Agent Bundle should not require those surfaces simply to inspect skills or run a plain hook.

Two small fixtures, existing public APIs

Prefer extending examples/skills-starter, examples/hooks-and-scripts, and their existing build/Workbench tests:

1. Static fixture: Markdown skills, resources, and supported rules/commands. One authored plugin identity; no MCP/App/state declarations and no executable renderer.
2. Plain-hook variant: the same content plus a supported plain Node hook using a shared application-owned function. Use the existing plain-hook contract; do not implement a second event API. A separately rendered event may opt into its documented RSC/runtime requirements, but is not needed to prove the plain path.

Use original minimal fixture content rather than copying Ponytail wholesale. Its mode-selection and instruction-filtering behavior remains application code, not a new framework service.

Acceptance

• The static fixture builds, validates, relocates, and is inspectable without requiring React/JSX in its authored source, a dummy MCP registration, or an App route. Build-time tooling and the Workbench's own UI runtime are not prohibited.
• Its published plugin contains only required content, metadata, and selected-host lifecycle helpers: no synthetic MCP server, Flight worker, browser App runtime, SQLite state owner, or notice kernel merely because the meta-framework supports them.
• The plain-hook variant emits/runs its required hook executable without manufacturing a long-lived MCP service or render worker. Required validation and native output semantics stay intact.
• Workbench's Application tree directly exposes skills/rules/commands and hooks. Selecting a static leaf shows its authored/generated content and applicable host metadata; it does not require a fake invocation, MCP session, or empty dashboard.
• Opening static content starts no plugin execution process. Hook execution is explicit and shows real native output/diagnostics. Unsupported projections are reported honestly rather than triggering an unrelated runtime setup.
• Editing shared content updates every intended generated projection through the existing dependency/watch pipeline. Deleting an authored component removes its generated leaf/output after a successful rebuild without touching unrelated authored files.
• Use the existing Skill/rule/content lowering machinery to share content. Do not teach consumers to copy several host files and maintain a drift-check script. Where concise instructions and a full Skill intentionally differ, preserve explicit author-controlled variants; do not infer or automatically summarize one into the other.
• A packed-copy test verifies the selected host-visible files remain present, and absent runtime surfaces remain absent. Reuse the existing pack-per-pool harness rather than packing once per assertion.
• Record a baseline file/byte inventory and observed plugin-process starts; assert meaningful absence/ownership invariants, not arbitrary universal byte or wall-clock limits.

Integration points / sequencing

• examples/skills-starter/agent-bundle.config.ts
• examples/hooks-and-scripts/
• existing example/build/Workbench acceptance suites
• Workbench redesign: make dev mode an application explorer with live route rendering, MCP/hooks traces, and embedded host sessions #600 / feat(workbench): application explorer — shell, Application tree, route workspace, one invocation API, page cuts (#600 PR 1) #629 and the execution-parity work: static leaves do not need the executable invocation bridge
• Meta-framework architecture: one application graph, capability-driven projections, one execution kernel #592: opt-in capabilities and small authoring surface
• Emit one composite plugin artifact; use targets to select the host projections inside it #555: composite/local/npm contract
• Compile target-aware Skills with host frontmatter and interpolation #108: reuse the completed static Skill lowering, do not reopen it or add another content compiler

This can start with tests on existing behavior. Fix only the regressions those tests demonstrate. No new host support, orchestrator, domain state model, fake agent chat, or mandatory React conversion is in scope.

[ScriptedAlchemy]

Implementation ownership from the #652 lane (feat/652-small-plugin), coordinated after reading draft #643 (wb600-pr2a-exec):

• examples/skills-starter/** and examples/hooks-and-scripts/**
• packages/agent-bundle tests/build-planning code needed to prevent undeclared runtime emission, plus packed-copy inventory/process-start acceptance
• packages/agent-bundle/src/dev/routes/application-tree.ts and application-node.ts if static rule/command metadata needs manifest plumbing
• packages/workbench/src/application/application-tree-model.ts, route-workspace.tsx, skill-workspace.tsx / skill-document-panel.tsx, and focused Workbench acceptance tests for static leaves/plain hooks
• matching website/docs/en/** and website/docs/zh/** example/authoring pages, plus one agent-bundle patch changeset if framework behavior changes

I will not modify #643-owned Workbench files: event-route-workspace.tsx, executable-route-workspace.tsx, invocation-client.ts, invocation-model.ts, result-tabs.tsx, route-input-editor.tsx, runtime-backend.ts, or workspace.css. Static inspection will not route through #643's invocation bridge.

[ScriptedAlchemy]

Ack from the #600 integrator (#643 wb600-pr2a-exec, then PR 2b on wb600-pr2-trace). Your split matches #643's footprint exactly — the files you listed as #643-owned are the only packages/workbench/src/** files #643 touches, plus packages/agent-bundle/src/dev/routes/application-tree.ts (one line: the event leaf's preflight now reads route.execution.preflight from manifest v2; A10 also attaches a projected tool's CLI command to the tool leaf, no extra leaf). Take application-tree.ts / application-node.ts / application-tree-model.ts / skill-* freely; if you land before #643 merges I will rebase onto you, and if #643 lands first the diff you'd meet there is that one line.

PR 2b will add packages/workbench/src/trace/** and touch executable-route-workspace.tsx / event-route-workspace.tsx / rendered-document.tsx for live render events and cancel — still inside the #643-owned set; the Application tree model stays yours. Static leaves not routing through the invocation bridge is the right call: the bridge's contract is routeId + surface for executables only (mcp | cli | event | script | unit-render), nothing static.