[Feature] Plugin scope: train a producer repo's skills from sessions in consumer repos

[MitchellkellerLG]

Summary

A repo that ships its skills as a plugin (Claude Code / Codex plugin marketplace) has its instruction surface loaded in other repos: the SKILL.md files live in the producer repo, but every session that exercises them runs in a consumer repo. Neither --scope project nor --scope user fits that shape today.

What I tried (backpass 0.1.19, Windows 11, node 22)

Producer: gtm-orchestrator, plugin.json ships 37 skills from .claude/skills/. Consumers: 7 client repos that install the plugin from a marketplace. Consumer transcripts reference the skills by their plugin-cache path, e.g. ~/.codex/plugins/cache/gtm-orchestrator/gtm-orchestrator/2.0.1/.claude/skills/campaign-copywriting/SKILL.md, so the evidence is there.

1. --scope project --target campaign-copywriting in a consumer repo with skillsDir pointed at the producer checkout: rejected by assertSkillsDirInsideRepo (skills.js ~L361, lexical + realpath check, so a junction/symlink does not pass either).
2. Copying .backpass/evidence/*.json from a consumer into the producer's .backpass/evidence/: evidence key embeds the memory-surface hash (state.js evidenceKey), so it is marked stale and re-analyzed against the producer's own AGENTS.md, which the consumer session never loaded.
3. --scope user has the right pieces (external skillsDirs via allowExternal, cross-project fold with --project <glob>, minGapProjects), but it writes to the user memory file, and on Windows it is blocked by [Bug] Windows: --scope user fails with "could not secure state directory ... as mode 700 (got 666)" #115.

Ask

A way to train a producer repo's skills from consumer sessions. Two shapes that would work, either is fine:

• --scope plugin (or a plugin block in .backpassrc.json): memory surface = the producer's skill descriptions (plus optional memory file), transcripts = sessions in the listed consumer projects (--project globs, like user scope), writes = the producer's SKILL.md files. Essentially user-scope folding pointed at a project's skills dir.
• Or, smaller: let --scope project accept an external skillsDir when the config opts in explicitly (e.g. "skillsDirs": [{"path": "...", "external": true}]), plus --project <glob> in project scope to pull consumer sessions.

Nice to have: record which skill a transcript actually loaded (the plugin-cache path is already in the transcript) so --target <skill> can sample only sessions that exercised that skill, and gap items can carry a skill attribution alongside domain.

Related: #115 (user scope on Windows).

[kunchenguid]

Speaking as Kun's firstmate: feature request is in scope — labeled ready-for-pr. No open PR yet.

The ask is an explicit choice of surface (new --scope plugin, or project-scope with an opted-in external skillsDir plus --project globs), writing into the producer repo's named skills from consumer-session transcripts. That matches how user scope already folds cross-project sessions while still naming the weights. It does not silently widen writes from a default project run, and it does not touch the two-session / per-edit review bar. Related Windows user-scope blocker #115 is separate and already ready-for-pr.

VISION per-rule:

• Purpose / owns the backward pass: aligns (still transcripts → named producer skills; human names the surface).
• Evidence is the only currency: aligns (no change to quote/two-session bar; cross-project pooling is already accepted at user scope).
• The human owns the weights: aligns (explicit scope or config opt-in; review gate unchanged).
• Nothing the model says is taken on faith: aligns (measurement/staging unchanged by this ask).
• The budget is the constraint: aligns (still a gradient step on the named skills surface).
• It reads what you already have: aligns (local consumer transcripts; pooling across projects is scale, not kind; association stays opt-in via listed projects).
• Failure is loud and named: aligns (no quieter degraded path requested).
• Scope / resist list: aligns (explicit scope choice; does not write user-level from a project-scoped run; does not widen writes without naming the target).

contract-class: opt-in (new scope or explicit external-skillsDir config; not a new unconfigured default).