Cursor plan header metadata vs GH issue as plan format discrepancy

[JPDuchesne]

Cursor plan header metadata vs GH issue as plan format discrepancy

Problem

Cursor plan files (.plan.md) carry a YAML frontmatter block that Cursor's
plan UI owns — typically name, overview, todos, and isProject:

---
name: Organic diapedesis deformation
overview: Improve the squeeze visual…
todos:
 - id: squeeze-angle
 content: Add squeezeAngle to Membrane…
 status: completed
isProject: false
---

That frontmatter is local editor state: a plan picker label, a short overview,
and a checklist Cursor ticks as it works. It is not plan prose.

Today dev plan link / push treat everything after the <!-- ai-flow -->
sync header as the issue body
(https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/header.rb,
https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/accessor.rb).
Plan.to_issue_body / from_issue_body are verbatim — they do not strip YAML
frontmatter. So linking a Cursor-native draft publishes the frontmatter onto
GitHub, where it renders as noisy leading --- / key soup above the real
markdown. Conversely, plans born on GitHub (dev plan new / a clean pull)
have no frontmatter until Cursor invents one locally — so the two sides already
disagree about what "the body" is.

Decision

Do not keep Cursor YAML frontmatter on GitHub. The issue body is the
canonical markdown plan only (starting at the # title / prose). Frontmatter
stays a local-only envelope around that body.

Rationale:

• GitHub already has its own title; name / overview duplicate it poorly.
• todos are Cursor session progress, not shared plan content — publishing them
  invites stale checklists and review noise.
• The sync contract already says the issue body is what reviewers edit via
  /ask / /edit; frontmatter has no role there.

The <!-- ai-flow --> HTML comment remains local-only as today (never part of
the issue body). It is orthogonal to YAML frontmatter: sync metadata vs Cursor
UI metadata.

Layers of a linked local plan file

<!-- ai-flow
issue: owner/repo#n
synced_at: …
-->
---
name: …
overview: …
todos: […]
isProject: false
---

# Plan title

…markdown body…

Layer	Lives on disk	Lives on GitHub	Owned by
<!-- ai-flow --> header	yes	no	dev plan sync guard
YAML frontmatter (---…---)	yes (optional)	no	Cursor plan UI
Markdown body	yes	yes (canonical)	humans + ai-flow review

How this plays with pull / push / link

All sync comparisons, merge bases, and issue PATCHes operate on the markdown
body only — never on frontmatter.

dev plan push / link <file> (local → remote)

1. Header.split → ai-flow header + remainder (unchanged).
2. Split remainder into optional YAML frontmatter + markdown body (new).
3. Publish / create the issue with Plan.to_issue_body(markdown_body) only.
4. Merge base stores that same markdown body.
5. Rewrite the local file as: ai-flow header + (preserved frontmatter, if any) +
   markdown body. Frontmatter is not deleted locally; it is simply not shipped.

Title extraction (extract_title) already keys off the first # … line; it
must run on the markdown body after frontmatter is peeled off so a name: key
cannot be mistaken for content.

dev plan pull (remote → local)

1. Fetch issue body → that string is the markdown body (no frontmatter on GH).
2. If a local file exists, peel and preserve its YAML frontmatter across the
   rewrite; only replace the markdown body (and refresh the ai-flow header /
   merge base as today).
3. If there is no local frontmatter (fresh pull, or a plan that never had one),
   write header + markdown body only — do not synthesize fake todos. Cursor
   may add frontmatter the next time it opens the file; that is fine and stays
   local.

Conflict / status semantics

• ahead / behind / diverged compare markdown bodies against the merge base.
• Editing only frontmatter (ticking a todo, renaming in Cursor) must not
  mark the plan dirty for sync and must not trigger a meaningful push
  (body unchanged → existing "already in sync" path).
• Three-way merge (pull --merge) merges markdown bodies only; frontmatter is
  carried through from the local side untouched.

Edge cases

• Draft already linked with frontmatter on GH (today's bug residue): first
  push after the fix rewrites the issue body to markdown-only (stripping the
  published frontmatter). That is an intentional one-time cleanup, not a
  conflict — remote "change" is us removing noise we incorrectly published.
• Malformed / non-Cursor leading ---: only peel a block that looks like
  Cursor plan frontmatter (opening --- on its own line near the top,
  closing ---, YAML mapping). Ordinary markdown horizontal rules deeper in
  the body are left alone.
• ai-flow header vs frontmatter order: canonical on-disk order is ai-flow
  header, then optional frontmatter, then markdown. If a hand-edited file has
  frontmatter above the ai-flow header, normalize on the next pull/push
  write.

Implementation sketch

• Teach
  https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/header.rb
  (or a sibling splitter next to it) to peel/rejoin YAML frontmatter from the
  post-header remainder, mirroring how Header.split already peels the HTML
  comment.
• Thread that through
  https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/accessor.rb
  link / push / pull / write_linked_plan / record_sync / status so
  every path that reads or writes "the body" means markdown-only for remote and
  merge-base purposes.
• Keep
  https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan.rb
  to_issue_body / from_issue_body as LF normalization only — callers pass
  markdown, not the full file.
• Tests in
  https://github.com/d3mlabs/dev/blob/HEAD/test/dev/plan/accessor_test.rb
  (and a focused splitter test): link/push strip frontmatter from the issue;
  pull preserves local frontmatter; frontmatter-only edits stay clean; merge
  does not clobber frontmatter.
• Document the three-layer file shape in
  https://github.com/d3mlabs/dev/blob/HEAD/share/cursor-skills/ai-flow/SKILL.md
  so agents do not hand-edit frontmatter into issue-facing prose.

Non-goals

• Syncing Cursor todos to GitHub checklists (or the reverse).
• Changing the <!-- ai-flow --> header format or conflict-guard rules.
• Requiring frontmatter on every local plan — absence remains valid.

Subtasks

• Plan file: peel/rejoin Cursor YAML frontmatter #40 — Plan file: peel/rejoin Cursor YAML frontmatter
• Plan sync: issue body is markdown-only (strip/preserve frontmatter) #41 — Plan sync: issue body is markdown-only (strip/preserve frontmatter)
• ai-flow skill: document three-layer linked plan file shape #42 — ai-flow skill: document three-layer linked plan file shape

[JPDuchesne]

/edit expand the body issue:

• A cursor plan linked to a GH issue with dev plan link <file> keeps its cursor plan frontmatter, which is noise on GH. Let's reconcile and fix. Do we need to keep the frontmatter at all on GH? How does that play with dev plan pull / dev plan push?

✅ /edit — Expanded the plan with the frontmatter-vs-issue discrepancy, decided GH keeps markdown only (no Cursor YAML), and specified how link/pull/push/status treat the three local layers.

---

Plan updated — view the edited section

Word diff

Cursor plan header metadata vs GH issue as plan format discrepancy

## Problem

Cursor plan files (.plan.md) carry a YAML frontmatter block that Cursor's
plan UI owns — typically name, overview, todos, and isProject:

That frontmatter is local editor state: a plan picker label, a short overview,
and a checklist Cursor ticks as it works. It is not plan prose.

Today dev plan link / push treat everything after the <!-- ai-flow -->
sync header as the issue body
(https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/header.rb,
https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/accessor.rb).
Plan.to_issue_body / from_issue_body are verbatim — they do not strip YAML
frontmatter. So linking a Cursor-native draft publishes the frontmatter onto
GitHub, where it renders as noisy leading --- / key soup above the real
markdown. Conversely, plans born on GitHub (dev plan new / a clean pull)
have no frontmatter until Cursor invents one locally — so the two sides already
disagree about what "the body" is.

## Decision

Do not keep Cursor YAML frontmatter on GitHub. The issue body is the
canonical markdown plan only (starting at the # title / prose). Frontmatter
stays a local-only envelope around that body.

Rationale:

- GitHub already has its own title; name / overview duplicate it poorly.
- todos are Cursor session progress, not shared plan content — publishing them
invites stale checklists and review noise.
- The sync contract already says the issue body is what reviewers edit via
/ask / /edit; frontmatter has no role there.

The <!-- ai-flow --> HTML comment remains local-only as today (never part of
the issue body). It is orthogonal to YAML frontmatter: sync metadata vs Cursor
UI metadata.

## Layers of a linked local plan file

| Layer | Lives on disk | Lives on GitHub | Owned by |
|---|---|---|---|
| <!-- ai-flow --> header | yes | no | dev plan sync guard |
| YAML frontmatter (---…---) | yes (optional) | no | Cursor plan UI |
| Markdown body | yes | yes (canonical) | humans + ai-flow review |

## How this plays with pull / push / link

All sync comparisons, merge bases, and issue PATCHes operate on the markdown
body only — never on frontmatter.

### dev plan push / link <file> (local → remote)

1. Header.split → ai-flow header + remainder (unchanged).
2. Split remainder into optional YAML frontmatter + markdown body (new).
3. Publish / create the issue with Plan.to_issue_body(markdown_body) only.
4. Merge base stores that same markdown body.
5. Rewrite the local file as: ai-flow header + (preserved frontmatter, if any) +
markdown body. Frontmatter is not deleted locally; it is simply not shipped.

Title extraction (extract_title) already keys off the first # … line; it
must run on the markdown body after frontmatter is peeled off so a name: key
cannot be mistaken for content.

### dev plan pull (remote → local)

1. Fetch issue body → that string is the markdown body (no frontmatter on GH).
2. If a local file exists, peel and preserve its YAML frontmatter across the
rewrite; only replace the markdown body (and refresh the ai-flow header /
merge base as today).
3. If there is no local frontmatter (fresh pull, or a plan that never had one),
write header + markdown body only — do not synthesize fake todos. Cursor
may add frontmatter the next time it opens the file; that is fine and stays
local.

### Conflict / status semantics

- ahead / behind / diverged compare markdown bodies against the merge base.
- Editing only frontmatter (ticking a todo, renaming in Cursor) must not
mark the plan dirty for sync and must not trigger a meaningful push
(body unchanged → existing "already in sync" path).
- Three-way merge (pull --merge) merges markdown bodies only; frontmatter is
carried through from the local side untouched.

### Edge cases

- Draft already linked with frontmatter on GH (today's bug residue): first
push after the fix rewrites the issue body to markdown-only (stripping the
published frontmatter). That is an intentional one-time cleanup, not a
conflict — remote "change" is us removing noise we incorrectly published.
- Malformed / non-Cursor leading ---: only peel a block that looks like
Cursor plan frontmatter (opening --- on its own line near the top,
closing ---, YAML mapping). Ordinary markdown horizontal rules deeper in
the body are left alone.
- ai-flow header vs frontmatter order: canonical on-disk order is ai-flow
header, then optional frontmatter, then markdown. If a hand-edited file has
frontmatter above the ai-flow header, normalize on the next pull/push
write.

## Implementation sketch

- Teach
https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/header.rb
(or a sibling splitter next to it) to peel/rejoin YAML frontmatter from the
post-header remainder, mirroring how Header.split already peels the HTML
comment.
- Thread that through
https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/accessor.rb
link / push / pull / write_linked_plan / record_sync / status so
every path that reads or writes "the body" means markdown-only for remote and
merge-base purposes.
- Keep
https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan.rb
to_issue_body / from_issue_body as LF normalization only — callers pass
markdown, not the full file.
- Tests in
https://github.com/d3mlabs/dev/blob/HEAD/test/dev/plan/accessor_test.rb
(and a focused splitter test): link/push strip frontmatter from the issue;
pull preserves local frontmatter; frontmatter-only edits stay clean; merge
does not clobber frontmatter.
- Document the three-layer file shape in
https://github.com/d3mlabs/dev/blob/HEAD/share/cursor-skills/ai-flow/SKILL.md
so agents do not hand-edit frontmatter into issue-facing prose.

## Non-goals

- Syncing Cursor todos to GitHub checklists (or the reverse).
- Changing the <!-- ai-flow --> header format or conflict-guard rules.
- Requiring frontmatter on every local plan — absence remains valid.

Source diff

@@ -1 +1,159 @@
 # Cursor plan header metadata vs GH issue as plan format discrepancy
+
+## Problem
+
+Cursor plan files (`.plan.md`) carry a YAML frontmatter block that Cursor's
+plan UI owns — typically `name`, `overview`, `todos`, and `isProject`:
+
+```yaml
+---
+name: Organic diapedesis deformation
+overview: Improve the squeeze visual…
+todos:
+ - id: squeeze-angle
+ content: Add squeezeAngle to Membrane…
+ status: completed
+isProject: false
+---
+```
+
+That frontmatter is local editor state: a plan picker label, a short overview,
+and a checklist Cursor ticks as it works. It is not plan prose.
+
+Today `dev plan link` / `push` treat everything after the `<!-- ai-flow -->`
+sync header as the issue body
+([https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/header.rb](https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/header.rb),
+[https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/accessor.rb](https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/accessor.rb)).
+`Plan.to_issue_body` / `from_issue_body` are verbatim — they do not strip YAML
+frontmatter. So linking a Cursor-native draft publishes the frontmatter onto
+GitHub, where it renders as noisy leading `---` / key soup above the real
+markdown. Conversely, plans born on GitHub (`dev plan new` / a clean `pull`)
+have no frontmatter until Cursor invents one locally — so the two sides already
+disagree about what "the body" is.
+
+## Decision
+
+**Do not keep Cursor YAML frontmatter on GitHub.** The issue body is the
+canonical markdown plan only (starting at the `#` title / prose). Frontmatter
+stays a local-only envelope around that body.
+
+Rationale:
+
+- GitHub already has its own title; `name` / `overview` duplicate it poorly.
+- `todos` are Cursor session progress, not shared plan content — publishing them
+ invites stale checklists and review noise.
+- The sync contract already says the issue body is what reviewers edit via
+ `/ask` / `/edit`; frontmatter has no role there.
+
+The `<!-- ai-flow -->` HTML comment remains local-only as today (never part of
+the issue body). It is orthogonal to YAML frontmatter: sync metadata vs Cursor
+UI metadata.
+
+## Layers of a linked local plan file
+
+```
+<!-- ai-flow
+issue: owner/repo#n
+synced_at: …
+-->
+---
+name: …
+overview: …
+todos: […]
+isProject: false
+---
+
+# Plan title
+
+…markdown body…
+```
+
+| Layer | Lives on disk | Lives on GitHub | Owned by |
+|---|---|---|---|
+| `<!-- ai-flow -->` header | yes | no | `dev plan` sync guard |
+| YAML frontmatter (`---`…`---`) | yes (optional) | **no** | Cursor plan UI |
+| Markdown body | yes | **yes (canonical)** | humans + ai-flow review |
+
+## How this plays with `pull` / `push` / `link`
+
+All sync comparisons, merge bases, and issue PATCHes operate on the **markdown
+body only** — never on frontmatter.
+
+### `dev plan push` / `link <file>` (local → remote)
+
+1. `Header.split` → ai-flow header + remainder (unchanged).
+2. Split remainder into optional YAML frontmatter + markdown body (new).
+3. Publish / create the issue with `Plan.to_issue_body(markdown_body)` only.
+4. Merge base stores that same markdown body.
+5. Rewrite the local file as: ai-flow header + (preserved frontmatter, if any) +
+ markdown body. Frontmatter is not deleted locally; it is simply not shipped.
+
+Title extraction (`extract_title`) already keys off the first `# …` line; it
+must run on the markdown body after frontmatter is peeled off so a `name:` key
+cannot be mistaken for content.
+
+### `dev plan pull` (remote → local)
+
+1. Fetch issue body → that string **is** the markdown body (no frontmatter on GH).
+2. If a local file exists, peel and **preserve** its YAML frontmatter across the
+ rewrite; only replace the markdown body (and refresh the ai-flow header /
+ merge base as today).
+3. If there is no local frontmatter (fresh pull, or a plan that never had one),
+ write header + markdown body only — do not synthesize fake `todos`. Cursor
+ may add frontmatter the next time it opens the file; that is fine and stays
+ local.
+
+### Conflict / status semantics
+
+- `ahead` / `behind` / `diverged` compare markdown bodies against the merge base.
+- Editing only frontmatter (ticking a todo, renaming in Cursor) must **not**
+ mark the plan dirty for sync and must **not** trigger a meaningful push
+ (body unchanged → existing "already in sync" path).
+- Three-way merge (`pull --merge`) merges markdown bodies only; frontmatter is
+ carried through from the local side untouched.
+
+### Edge cases
+
+- **Draft already linked with frontmatter on GH** (today's bug residue): first
+ push after the fix rewrites the issue body to markdown-only (stripping the
+ published frontmatter). That is an intentional one-time cleanup, not a
+ conflict — remote "change" is us removing noise we incorrectly published.
+- **Malformed / non-Cursor leading `---`**: only peel a block that looks like
+ Cursor plan frontmatter (opening `---` on its own line near the top,
+ closing `---`, YAML mapping). Ordinary markdown horizontal rules deeper in
+ the body are left alone.
+- **ai-flow header vs frontmatter order**: canonical on-disk order is ai-flow
+ header, then optional frontmatter, then markdown. If a hand-edited file has
+ frontmatter above the ai-flow header, normalize on the next `pull`/`push`
+ write.
+
+## Implementation sketch
+
+- Teach
+ [https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/header.rb](https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/header.rb)
+ (or a sibling splitter next to it) to peel/rejoin YAML frontmatter from the
+ post-header remainder, mirroring how `Header.split` already peels the HTML
+ comment.
+- Thread that through
+ [https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/accessor.rb](https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/accessor.rb)
+ `link` / `push` / `pull` / `write_linked_plan` / `record_sync` / `status` so
+ every path that reads or writes "the body" means markdown-only for remote and
+ merge-base purposes.
+- Keep
+ [https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan.rb](https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan.rb)
+ `to_issue_body` / `from_issue_body` as LF normalization only — callers pass
+ markdown, not the full file.
+- Tests in
+ [https://github.com/d3mlabs/dev/blob/HEAD/test/dev/plan/accessor_test.rb](https://github.com/d3mlabs/dev/blob/HEAD/test/dev/plan/accessor_test.rb)
+ (and a focused splitter test): link/push strip frontmatter from the issue;
+ pull preserves local frontmatter; frontmatter-only edits stay `clean`; merge
+ does not clobber frontmatter.
+- Document the three-layer file shape in
+ [https://github.com/d3mlabs/dev/blob/HEAD/share/cursor-skills/ai-flow/SKILL.md](https://github.com/d3mlabs/dev/blob/HEAD/share/cursor-skills/ai-flow/SKILL.md)
+ so agents do not hand-edit frontmatter into issue-facing prose.
+
+## Non-goals
+
+- Syncing Cursor `todos` to GitHub checklists (or the reverse).
+- Changing the `<!-- ai-flow -->` header format or conflict-guard rules.
+- Requiring frontmatter on every local plan — absence remains valid.

⚙️ workflow run

[JPDuchesne]

/ask Currently dev plan pull pulls the file with a .plan.md extension (which cursor doesn't interpret the frontmatter). Granted we will be removing the frontmatter from GH, but is there a reason to keep the .plan format for Cursor to work correctly? I.e. does it use .plan extension in any way shape or form? Markdown is markdown so it should be interpreted correctly regardless

[d3mlabs-ai-flow]

✅ /ask

Yes — keep .plan.md. Cursor’s own plan files are always *.plan.md under .cursor/plans/, and this repo’s sync stack is hard-wired to that glob (PLAN_GLOB / plan_path / linked-plan discovery in https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/workspace.rb, plus the afterFileEdit hook). The markdown body would render fine as plain .md, but the extension is the local “this is a Cursor plan” convention our CLI and hooks rely on; renaming would break discovery and diverge from every Cursor-native plan file. The “Cursor doesn’t interpret frontmatter on pull” observation is not an extension problem: a fresh dev plan pull writes header + body only (no YAML), and when YAML is present it sits after the <!-- ai-flow --> comment — unlike Cursor-native plans, which put --- at byte 0. So keep .plan.md; frontmatter remains optional local UI state Cursor may invent later, independent of shipping it to GitHub.

⚙️ workflow run

[JPDuchesne]

Cursor’s own plan files are always *.plan.md

/ask hmmmm I think I misinterpreted the signals here, I see in my editor:

its contents are:

---

name: Dummy Presentation Test Plan
overview: A throwaway plan used purely to test Cursor IDE plan presentation, frontmatter handling, and todo rendering. No real work is described here.
todos:

• id: dummy-todo-1
  content: First dummy todo item (does nothing)
  status: pending
• id: dummy-todo-2
  content: Second dummy todo item (does nothing)
  status: pending
• id: dummy-todo-3
  content: Third dummy todo item (does nothing)
  status: pending
  isProject: false

---

Dummy Plan for Testing Cursor Plan Presentation

Purpose

This plan exists only to exercise the Cursor IDE plan UI: frontmatter, headings, todos, code blocks, lists, and diagrams. Nothing in it should be implemented.

Sample Sections

Text and Lists

• A bullet point with inline code and a file link
• A second bullet with bold and italic text
• A nested list:
  • Child item one
  • Child item two

Code Block

def dummy_method
 puts "This is only here to test rendering"
end

Diagram

flowchart LR
 planFile[Plan File] --> cursorUI[Cursor Plan UI]
 cursorUI --> rendered[Rendered Presentation]

Loading

Notes

• Edit this file directly to experiment with frontmatter fields.
• Delete the file when done testing.

But if I dev plan link it, it gets moved to the dev's .cursor/plans file, but renders like this:

its contents are:

---

name: Dummy Presentation Test Plan
overview: A throwaway plan used purely to test Cursor IDE plan presentation, frontmatter handling, and todo rendering. No real work is described here.
todos:

• id: dummy-todo-1
  content: First dummy todo item (does nothing)
  status: pending
• id: dummy-todo-2
  content: Second dummy todo item (does nothing)
  status: pending
• id: dummy-todo-3
  content: Third dummy todo item (does nothing)
  status: pending
  isProject: false

---

Dummy Plan for Testing Cursor Plan Presentation

Purpose

This plan exists only to exercise the Cursor IDE plan UI: frontmatter, headings, todos, code blocks, lists, and diagrams. Nothing in it should be implemented.

Sample Sections

Text and Lists

• A bullet point with inline code and a file link
• A second bullet with bold and italic text
• A nested list:
  • Child item one
  • Child item two

Code Block

def dummy_method
 puts "This is only here to test rendering"
end

Diagram

flowchart LR
 planFile[Plan File] --> cursorUI[Cursor Plan UI]
 cursorUI --> rendered[Rendered Presentation]

Loading

Notes

• Edit this file directly to experiment with frontmatter fields.
• Delete the file when done testing.

So not sure what's going on, Cursor has custom rendering when the file is in ~/.cursor/plans folder maybe?

[d3mlabs-ai-flow]

✅ /ask

You likely mixed up two signals. Keep .plan.md — that is Cursor’s on-disk plan convention under .cursor/plans/, and this repo’s discovery is hard-wired to it (PLAN_GLOB = "*.plan.md" / plan_path / the afterFileEdit hook in https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/workspace.rb). Renaming to plain .md would break our CLI/hooks even if markdown still rendered.

What Cursor “interpreting frontmatter” depends on is not the .plan.md suffix. It depends on there being a leading Cursor YAML envelope (name / overview / todos / isProject between --- … ---), which Cursor-native plans put at byte 0. A fresh dev plan pull today writes <!-- ai-flow --> + markdown only (https://github.com/d3mlabs/dev/blob/HEAD/lib/dev/plan/accessor.rb write_linked_plan), so there is nothing for the plan UI to bind — that is the “no frontmatter” observation, not an extension problem. Linked files Cursor has touched often keep YAML at byte 0 above the ai-flow comment (so the UI works); this plan’s peel/preserve work is exactly about that local envelope staying local and never shipping to GitHub. So: extension stays .plan.md; frontmatter stays optional local UI state; GH stays markdown-only.

⚙️ workflow run

[JPDuchesne]

/split --dry

📋 /split --dry — staged 3 subtasks in the ## Subtasks section

• d3mlabs/dev — Plan file: peel/rejoin Cursor YAML frontmatter
• d3mlabs/dev — Plan sync: issue body is markdown-only (strip/preserve frontmatter)
• d3mlabs/dev — ai-flow skill: document three-layer linked plan file shape

Review and edit the section, then comment /split --apply.

---

⚙️ workflow run

[JPDuchesne]

/split --dry

📋 /split --dry — staged 3 subtasks in the ## Subtasks section

• d3mlabs/dev — Plan file: peel/rejoin Cursor YAML frontmatter
• d3mlabs/dev — Plan sync: issue body is markdown-only (strip/preserve frontmatter)
• d3mlabs/dev — ai-flow skill: document three-layer linked plan file shape

Review and edit the section, then comment /split --apply.

---

⚙️ workflow run

[JPDuchesne]

Plan file: peel/rejoin Cursor YAML frontmatter

/ask do we even care to rejoin the cursor frontmatter? what if we stripped it entirely on link / push?

[d3mlabs-ai-flow]

✅ /ask

Yes — care about local rejoin, not about shipping frontmatter. The plan’s Decision already says GH gets markdown-only; peel on link/push is right for the issue body. Dropping frontmatter from the local file too would wipe Cursor-owned state (name / overview / especially todos progress) on every sync, which fights the “local-only envelope,” pull-preserve, and “frontmatter-only edits stay clean” rules. Strip entirely from the remote; peel + rejoin locally (or leave it untouched on disk) so Cursor UI state survives.

⚙️ workflow run

[JPDuchesne]

/split --apply

✅ /split — applied the subtask spec (created 3, adopted 0, referenced 0, kept 0, closed 0)

• created d3mlabs/dev#40 Plan file: peel/rejoin Cursor YAML frontmatter
• created d3mlabs/dev#41 Plan sync: issue body is markdown-only (strip/preserve frontmatter)
• created d3mlabs/dev#42 ai-flow skill: document three-layer linked plan file shape

---

⚙️ workflow run