Repository navigation
[FEATURE] Add muse install target for Meta Muse agent skills #3109
Description
Is your feature request related to a problem? Please describe.
Meta's Muse is a personal AI agent whose runtime auto-discovers custom skills at ~/workspace/skills/<name>/SKILL.md (standard Anthropic SKILL.md layout, per the runtime's own skill-authoring docs). APM has no install target for it, so Muse users can't consume APM-managed skills — they have to hand-copy skill files instead of running apm install.
Describe the solution you'd like
An explicit-only muse target (same posture as hermes — no auto-detection heuristics, --target muse only) deploying the skills primitive at user scope to ~/workspace/skills/. It works when: apm install <pkg> --skill <name> --target muse materializes <name>/SKILL.md under ~/workspace/skills/ and the agent picks it up with no further steps. A PR would touch src/apm_cli/core/target_catalog.py (one _capability("muse", ...), explicit_only=True, primitive_profile="muse"), src/apm_cli/integration/targets.py (PrimitiveMapping("skills", "/SKILL.md", "skill_standard")), src/apm_cli/core/target_detection.py (accepted values), docs (reference/cli/targets.md, targets-matrix.md), and a test fixture. Checked the issue tracker first — no existing request for this.
Describe alternatives you've considered
--target agent-skills (converged .agents/skills/) plus a manual symlink/copy into ~/workspace/skills/ — works today, but it's a hand-maintained bridge outside APM's manifest/lockfile model.
Additional context
One caveat: a third-party skill manager claims Muse skills live at ~/.config/muse/skills, but the runtime's own docs say ~/workspace/skills — flagging so maintainers can weigh in on the canonical path before anyone implements. Happy to submit the PR if you're open to the target; per CONTRIBUTING, I'll wait for maintainer scope approval first either way.
Activity
danielmeppiel commentedon Sep 30, 2026
Thanks for the concrete proposal and for waiting for scope approval. Removing the manual skill-copy step fits APM's portable-by-manifest goal.
Advisory recommendation: needs-design, with two specific points to settle:
~/workspace/skills/versus~/.config/muse/skills. Does~refer to the machine running APM or a separate runtime/container home, and is the workspace configurable? Neither path is independently verified here.--targetselects the harness;-gselects user scope. For the smallest user-only slice, I suggest the proposed commandapm install -g <pkg> --skill <name> --target muse, rejecting project-scope use before writes. Also settle whether explicittargets: [muse]in the user manifest counts as opt-in, as manifest selection does for Hermes, rather than requiring the flag on every update.Proposed scope: extend
src/apm_cli/core/target_catalog.pyandsrc/apm_cli/integration/targets.py, reusing the existingskill_standardintegration and target validation. Keep Muse out of auto-detection andall. Hermes is a useful explicit-selection precedent, but its MCP and compiled-instruction support should not be copied into this skills-only target.Done when: an isolated-home fixture deploys the selected
SKILL.mdand resources to the confirmed root; the user manifest/lockfile, reinstall, update and removal stay consistent; unowned skills survive; unsafe traversal/symlink destinations are refused; and dry-run/unsupported scope make no deployment writes. Add a Muse-version discovery smoke check and update the existing install/targets references, target matrix and shippedapm-usage/commands.md.Excluded: MCP, hooks, compiled instructions, runtime setup, arbitrary path overrides and migration between the disputed directories. Needed review is multi-target/user-scope integration plus path-safety and lockfile ownership. A willing core-maintainer review contact is still unconfirmed; this advice does not approve implementation.
For now,
--target agent-skillssupplies the APM-managed.agents/skills/output for your manual bridge. The bridge's Muse discovery remains author-reported, and its copied files are outside APM's managed lifecycle. The highest-value next step is the runtime discovery reference above.Generated by autopilot-issue-triage-worker. This comment is AI-generated and may contain errors.
dsayling commentedon Sep 30, 2026
Thanks for the triage. Answers to the two design questions:
1. Discovery contract. For Muse (the personal agent, not Muse Code), the runtime-owned skill-authoring documentation specifies the skill path as
~/workspace/skills/<name>/.~is the Muse runtime environment's home, not necessarily the machine APM runs on. The~/.config/muse/skillsroots are documented for Muse Code, the CLI agent — a different product; third-party managers claiming that path for the personal agent appear to conflate the two. Residual uncertainty I can't resolve from public docs: whether the Muse desktop app syncs a local~/workspace/skills/into the agent runtime. Until that's confirmed, explicit-only with no auto-detection is the safe posture.2. Scope and opt-in. Agreed: user scope only (
-g), reject project scope before any writes, explicit--target muserequired, never in auto-detection orall, and explicittargets: [muse]in the user manifest counts as opt-in (Hermes precedent). Skills-only — no MCP, hooks, or compiled instructions.danielmeppiel commentedon Oct 1, 2026
Human decision: deferred.
Defer the Muse target while stabilizing existing integrations. Thank you for clarifying that personal Muse and Muse Code are different products and for agreeing the skills-only explicit opt-in scope. That clarification is retained; it need not be repeated. Revisit with confirmed runtime-location/desktop-sync behavior, concrete demand and ongoing maintenance/review capacity.
This is not permanent rejection and does not remove existing supported behavior. No implementation or release is selected for this broader scope now; please do not do additional implementation or rebases for our benefit while it is unselected. Existing contributions and useful evidence are retained.
Recorded by Copilot on behalf of Daniel Meppiel (@danielmeppiel) following the direct product decisions confirmed on 2026-09-30 and explicit authorization to update the issues on 2026-10-01. Daniel separately confirmed that he is the review contact for accepted scopes. This records a human decision, not an autonomous triage recommendation. It does not promise a release, assign implementation, approve a merge, or bypass review.