Title: [FEATURE] Support mapping instruction frontmatter to Cursor `alwaysApply: true`

[KomTak001]

Summary

When deploying instructions to Cursor with apm install --target cursor, APM maps applyTo to globs in .cursor/rules/*.mdc. As far as we can tell, there is currently no way to express Cursor’s Always Apply mode (alwaysApply: true) from APM source instructions.

We’d find it helpful if workspace-wide guardrails (e.g. Git workflow conventions, approval-before-mutation policies) could be authored once in APM and deployed without manual post-install edits that are lost on the next apm install.

Use case

We distribute reusable rule packages for policies such as:

• Verifying the current branch before git commit / git push
• Asking for user approval before mutating operations

These rules are not tied to a specific file type. In Cursor, we’d like them to behave like Always Apply rules rather than file-scoped or “apply intelligently” rules.

From our testing, the options we have today feel like partial fits:

1. applyTo: "**" — APM compiles this to globs: "**". In Cursor this maps to Apply to Specific Files (auto-attached when matching files are in context), which seems different from Always Apply.
2. Omit applyTo — APM deploys description only. In Cursor this maps to Apply Intelligently (the agent decides relevance). This works reasonably well for commit/push tasks, but does not feel guaranteed.

We may be missing something, but we haven’t found a way to get reliable Always Apply behavior from APM source alone.

What we observed (APM 0.19.0)

APM instruction frontmatter	apm install --target cursor output (.mdc frontmatter)	Cursor rule mode (as we understand it)
applyTo: "**"	globs: "**" + description	Apply to Specific Files
applyTo omitted	description only (no globs, no alwaysApply)	Apply Intelligently

Example when applyTo is omitted:

---
description: Verify branch before git commit/push
---

Example when applyTo: "**" is set:

---
description: ...
globs: "**"
---

This aligns with the transform described in Instructions and agents:

cursor | .cursor/rules/.mdc | applyTo → globs:

We did not see a documented mapping to alwaysApply.

What we’re hoping for

It would be great if authors could declare “always-on” instructions in source and have APM compile/deploy them to Cursor with something like:

---
description: ...
alwaysApply: true
---

Ideally, deployed .mdc files would not need hand-editing after each apm install.

Note on other targets

We noticed Windsurf has a related concept when applyTo is missing:

windsurf | .windsurf/rules/.md | missing applyTo → trigger: always_on

Cursor has alwaysApply: true, but we couldn’t find an equivalent mapping for Cursor in the current docs. Cross-target consistency for “workspace-wide guardrail” intent might be worth considering.

Possible approach (open to maintainer input)

One idea: add an explicit instruction frontmatter field, for example:

---
description: Verify branch before git commit/push
alwaysApply: true
---

A sketch of how Cursor output might work:

Source	Cursor .mdc output	Notes
alwaysApply: true	alwaysApply: true (+ optional description)	Always Apply
applyTo: "<glob>"	globs: "<glob>"	Auto Attached (current behavior)
neither alwaysApply nor applyTo	description only	Apply Intelligently (current behavior)

If both alwaysApply and applyTo were set, mutual exclusion (or a clear precedence rule) might help avoid ambiguity. Clarifying in docs that applyTo: "**" is not the same as Always Apply on Cursor could also help future authors.

Workaround we’re using for now

1. Omit applyTo and write a specific description (Apply Intelligently).
2. After apm install, manually add alwaysApply: true to the relevant .mdc file — with the caveat that this is overwritten on reinstall/update.

Environment

• APM CLI: 0.19.0
• Target: cursor

Example package layout (illustrative):

rules/workspace-guardrails/
├── apm.yml
└── .apm/instructions/
    ├── git-branch-policy.instructions.md
    └── approval-gate.instructions.md

Minimal repro:

cd path/to/rules/workspace-guardrails
apm compile --validate
mkdir -p /tmp/apm-cursor-test && cd /tmp/apm-cursor-test
apm install path/to/rules/workspace-guardrails --target cursor
head -6 .cursor/rules/git-branch-policy.mdc
head -6 .cursor/rules/approval-gate.mdc

References

• APM docs — instruction transform table: https://microsoft.github.io/apm/producer/author-primitives/instructions-and-agents/
• Cursor docs — rule types (alwaysApply, globs, description): https://cursor.com/docs/rules

Why it matters to us

For teams sharing guardrail packages through APM, “always-on” Cursor rules are hard to keep in sync as source-of-truth today. A first-class mapping would make those packages easier to maintain and less dependent on post-install patches.

[github-actions]

Triage Panel Verdict

Decision: Accept (with design note)

Thank you @KomTak001 for this well-researched feature request with clear use cases.

Panel Review

DevX UX Expert: The gap is real and well-documented: applyTo: "**" maps to "Apply to Specific Files" in Cursor (file-scoped auto-attach), not "Always Apply". Users authoring workspace-wide guardrail rules (branch policies, approval gates) need "Always Apply" semantics but have no source-level way to express it -- they resort to post-install manual edits that are overwritten on reinstall. The Windsurf analog (trigger: always_on when applyTo is absent) shows this is a recognized cross-editor concept.

Supply Chain Security Expert: No supply-chain concerns. Adding an alwaysApply frontmatter field and mapping it to a Cursor .mdc field is a safe schema extension.

APM CEO (Arbiter): Accept. The use case is clear, the implementation sketch is sensible, and the cross-target consistency angle (Cursor alwaysApply / Windsurf trigger: always_on) is worth tracking as a unified "always-on" primitive. The mutual-exclusion question between alwaysApply and applyTo needs a design decision (precedence rule or validation error). This needs a brief design note in the frontmatter schema before implementation, but the feature direction is accepted.

Design note: Before implementing, define the schema contract: if both alwaysApply: true and applyTo are set, should APM (a) treat alwaysApply as taking precedence and ignore applyTo for Cursor output, or (b) emit a validation error? Document the resolution in the instruction frontmatter schema reference.

Classification

Dimension	Value
Type	type/feature
Area	area/cli
Theme	theme/portability
Priority	priority/low -- workaround available (post-install manual edit)

Suggested Next Action

1. Design decision: resolve the alwaysApply + applyTo mutual-exclusion rule.
2. Update the instruction frontmatter schema to add alwaysApply: bool (optional, default false).
3. In the Cursor integration: when alwaysApply: true, emit alwaysApply: true in the .mdc frontmatter (omit globs).
4. Update the instruction transform table in the docs (producer/author-primitives/instructions-and-agents/).
5. Consider whether a unified "always-on" intent field (cross-target) is the right long-term approach, or whether alwaysApply stays Cursor-specific.
6. Add tests: alwaysApply: true in source -> .mdc contains alwaysApply: true and no globs.

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · sonnet46 2.7M · ◷