Problem
After #878 retired unconditional install, install still plants harness-specific skills into each harness's skills dir and generates Rovo Dev's prompts.yml. That is install's last artifact-deployment responsibility and a second deployment channel running parallel to sync. The declarative sync path should own both, but it has no concept of harness targeting: a declared skill is resolved from content/skills/{slug}/ and deployed to every detected harness.
Context
Harness-specific skills today: review-permissions (claude); brainstorming and systematic-debugging (rovodev). For Claude these come from plugins; for other harnesses they are extracted into the library. A likely future harness (Codex) would need the same skills, so the real shape is one skill serving several non-Claude harnesses.
The sync pipeline is keyed by slug — one slug resolves to exactly one source directory — so the same skill cannot live in two harness-specific directories.
For prompts.yml, #877 introduced a sentinel-delimited managed-region merge primitive and adopted it for the project domain; the home domain and install still overwrite the whole file. Preview of prompts.yml under --dry-run was deferred from #877.
The home tier declares the all collection, so flattened harness skills join @library automatically and need no separate declaration to survive the move off unconditional install.
Proposed solution
Express harness affinity as a declarative property of the skill: a harnesses: frontmatter field listing target harness ids, absent meaning all harnesses, validated against the known set. This keeps affinity an intrinsic, single-source property of the skill (like a rulebook's delivery:) and lets one skill serve several harnesses without duplication.
Chosen over two alternatives: path-based targeting under _harnesses/{harnessId}/, which cannot express one skill across multiple harnesses without breaking the slug-keyed model; and a per-consumer harness map in codeassembly.yaml, since affinity is intrinsic to the skill, not a per-project choice.
Flatten harness-specific skills into the general content/skills/{slug}/ catalog; the field, not the directory, restricts deployment. sync and sync --global deploy a skill to the intersection of its declared harnesses and the harnesses being synced, with the restriction honored uniformly so validation never trips on a non-target harness and a dropped harness is retracted. Flattened skills join @library, so the all collection delivers them, each routed to its harness.
install stops planting skills and stops generating prompts.yml. Both sync domains generate prompts.yml through the #877 managed-region merge, making sync the sole producer and preserving foreign entries.
Acceptance criteria
Must have
Should have
Problem
After #878 retired unconditional install,
installstill plants harness-specific skills into each harness's skills dir and generates Rovo Dev'sprompts.yml. That is install's last artifact-deployment responsibility and a second deployment channel running parallel tosync. The declarativesyncpath should own both, but it has no concept of harness targeting: a declared skill is resolved fromcontent/skills/{slug}/and deployed to every detected harness.Context
Harness-specific skills today:
review-permissions(claude);brainstormingandsystematic-debugging(rovodev). For Claude these come from plugins; for other harnesses they are extracted into the library. A likely future harness (Codex) would need the same skills, so the real shape is one skill serving several non-Claude harnesses.The sync pipeline is keyed by slug — one slug resolves to exactly one source directory — so the same skill cannot live in two harness-specific directories.
For
prompts.yml, #877 introduced a sentinel-delimited managed-region merge primitive and adopted it for the project domain; the home domain andinstallstill overwrite the whole file. Preview ofprompts.ymlunder--dry-runwas deferred from #877.The home tier declares the
allcollection, so flattened harness skills join@libraryautomatically and need no separate declaration to survive the move off unconditional install.Proposed solution
Express harness affinity as a declarative property of the skill: a
harnesses:frontmatter field listing target harness ids, absent meaning all harnesses, validated against the known set. This keeps affinity an intrinsic, single-source property of the skill (like a rulebook'sdelivery:) and lets one skill serve several harnesses without duplication.Chosen over two alternatives: path-based targeting under
_harnesses/{harnessId}/, which cannot express one skill across multiple harnesses without breaking the slug-keyed model; and a per-consumer harness map incodeassembly.yaml, since affinity is intrinsic to the skill, not a per-project choice.Flatten harness-specific skills into the general
content/skills/{slug}/catalog; the field, not the directory, restricts deployment.syncandsync --globaldeploy a skill to the intersection of its declared harnesses and the harnesses being synced, with the restriction honored uniformly so validation never trips on a non-target harness and a dropped harness is retracted. Flattened skills join@library, so theallcollection delivers them, each routed to its harness.installstops planting skills and stops generatingprompts.yml. Both sync domains generateprompts.ymlthrough the #877 managed-region merge, makingsyncthe sole producer and preserving foreign entries.Acceptance criteria
Must have
harnesses:frontmatter field (absent = all harnesses);syncandsync --globaldeploy it only into its target harnesses' skills dirs.content/skills/{slug}/catalog, with no_harnesses/skill sub-tree; targeting derives from the field, not the location.installplants no skill into any skills dir and no longer generatesprompts.yml; the declarative path is the sole producer ofprompts.yml.prompts.ymlin both domains is produced through the Project-scoped Rovo Dev skills don't appear in the available-skills list #877 managed-region merge primitive, preserving foreign entries (no whole-file overwrite).library listsurfaces harness-specific skills and shows each skill's harness affinity.Should have
sync --dry-runpreviewsprompts.ymlwrites and removals in both domains.SKILL.mdomits the build-onlyharnesses:directive.harnesses:field and harness-targeted declarative deployment.