User Story

As a Claude Code user who wants ApexYard's audit / safety capabilities but isn't ready to fork the full framework, I want self-contained marketplace plugins (apexyard/audit-pack, apexyard/safety-hooks) I can drop into my existing project's .claude/, so that I get the high-leverage governance bits without committing to the fork-based ops-repo model. This also serves as a discovery funnel — plugin users learn the framework exists and may graduate to the full forge later.

Acceptance Criteria

audit-pack plugin

• apexyard/audit-pack defined as a Claude Code marketplace plugin
• Bundles the 9 audit skills: /launch-check (umbrella) + 8 deep-dives — /seo-audit, /accessibility-audit, /compliance-check, /analytics-audit, /monitoring-audit, /docs-audit, /performance-audit, /generative-engine-audit
• Includes the persistence layer _lib-audit-history.sh + audit templates (templates/audits/*.md)
• Self-contained: drops into .claude/ of any project, runs WITHOUT requiring apexyard.projects.yaml registry, /handover, role definitions, or any other framework primitives
• Includes a focused README pitching the framework as a graduation path: "this is one tooth of the apexyard governance comb; the full framework includes 19 role definitions, portfolio registry, AgDR memory, two-marker merge gate at github.com/me2resh/apexyard"

safety-hooks plugin

• apexyard/safety-hooks defined as a separate marketplace plugin
• Bundles: check-secrets.sh, block-main-push.sh, block-git-add-all.sh, pre-push-gate.sh, verify-commit-refs.sh, validate-pr-create.sh, validate-branch-name.sh
• Includes the tracker-agnostic _lib-tracker.sh + _lib-read-config.sh (post-Hooks assume GitHub Issues when working inside a managed-project workspace with a non-GitHub tracker #310 fix) so the plugin works against GitHub / Linear / Jira / Asana / custom
• .claude/settings.json snippet shows the recommended hook wiring
• Same README pitch as audit-pack

Governance + maintenance contract

• AgDR documents the strategic trade-off (sub-packs as funnel vs. dilution of integrated value)
• AgDR codifies the maintenance contract: sub-packs track upstream, NOT separate codebases — they're generated/extracted from the framework, not forked
• Publish path documented: how to regenerate the sub-packs from the upstream framework on each release, how to push to the Claude Code marketplace, version-sync expectations
• CI workflow (or release-time task) that re-bundles the sub-packs from upstream HEAD on each apexyard tag

Performance constraint (per operator memory)

• Sub-packs MUST NOT include framework-distinctive elements that are out-of-scope for plugin distribution — specifically: no portfolio registry, no /handover, no role definitions, no apexyard.projects.yaml references, no _lib-portfolio-paths.sh dependencies. Each sub-pack's value must stand on its own without leaning on framework state that doesn't exist in a non-forked project.
• Sub-packs MUST NOT degrade the integrated framework's performance/effectiveness when run as part of the full apexyard fork. The same files serve both distribution channels; sub-pack extraction is a packaging concern, not a code-fork.

Design Notes

Strategic. Two sub-packs as a funnel — not as a replacement for the full framework. The "ApexYard as a whole" plugin model doesn't fit (the framework IS the ops repo; plugins are additive drop-ins). But the audit pack and safety hooks ARE genuinely self-contained — they work without the portfolio model, without /handover, without the role definitions.

The funnel direction is one-way: plugin → framework. A user discovers apexyard/audit-pack via the Claude Code marketplace, runs it, sees results, reads the README's framework pitch, and considers adopting the full ApexYard fork. The pitch doesn't pressure — it points.

Why not a apexyard/rex (Code Reviewer + merge gate) sub-pack in v1: the two-marker merge gate is tied to the framework's session-state convention (.claude/session/reviews/<pr>-{rex,ceo}.approved). The gate's value depends on the strict per-PR CEO approval pattern, which is harder to package as a drop-in. Defer until the first two sub-packs land and we have a publishing flow.

Why not a apexyard/migrations sub-pack: depends on the migration ticket label + AgDR pattern, which depends on the tracker-aware hooks. Harder to extract cleanly. Defer.

Out of Scope

• Publishing the entire framework as a single mega-plugin (doesn't fit the plugin shape)
• A /c4-arch or other architecture-docs sub-pack — defer until the first two land and we have a publishing flow
• The /rex sub-pack (Code Reviewer + merge gate) — depends on session-state convention; defer
• The /migrations sub-pack — depends on migration ticket label / AgDR pattern; defer
• Translating the marketplace plugins to other AI-agent runtimes (Cursor, Aider, Cline) — out of v1
• Automated marketplace publishing on every framework PR — release-tag-driven only in v1

Glossary