Cursor iThoughts integration. Add to .cursor/commands/ithought.md to be able to read a mind map and generate a plan from it.

ithoughts.md

Read iThoughts X mind map and use it for planning

You will receive a file path to an iThoughts X mind map (.itmz file). Use it as follows.

1. Resolve and validate the path

• Treat the path as the user’s chosen .itmz file (e.g. from a Cursor command that passes the current file or a path argument).
• If the path is relative, resolve it from the workspace root.
• If the file does not exist or is not an .itmz file, say so and stop.

2. Extract the map data from the .itmz

• An .itmz file is a ZIP archive. It always contains at least:
  • mapdata.xml — the main mind map content (required for reading).
  • Optionally: preview.png, style.xml, manifest.plist, preferences.plist, display_state.plist.
• Steps:
  1. Unzip the .itmz (e.g. unzip -p "/path/to/file.itmz" mapdata.xml or extract to a temp dir and read mapdata.xml).
  2. Read mapdata.xml as UTF-8 XML. Do not rely on other files for the semantic content of the map.

3. Understand the mapdata.xml structure

• Root: <iThoughts version="4.0" …> with attributes such as app, app-version, modified, author.
• Content: A single <topics> element containing nested <topic> elements.
• Hierarchy: Parent/child is expressed by nesting: a <topic> that contains other <topic> elements is a parent; those inner elements are its children. The root topic is the map title; its children are the main branches.
• Topic attributes (use these for planning):
  • text — label of the topic (main content to use).
  • text-size — font size hint (larger often = more important / higher level).
  • position — "{x, y}" layout coordinates; optional for ordering if you need a visual order.
  • note — optional longer note (XML-escaped; decode > → >, < → <, etc.).
  • summary1 / summary2 — optional references to other topic UUIDs (e.g. for callouts/summaries).
  • uuid, created, modified — metadata; use only if relevant (e.g. to detect recent changes).
• Tags in text: Users often put tags in the topic text (e.g. #mustHave, #maybe). Treat these as priority/type hints when generating plans.

4. Build a structured view for the AI

From the XML, derive a hierarchical outline that preserves parent/child and is easy to use for planning:

• Outline format: Use indentation (or markdown headers) to show depth: root = map title, then main branches, then their children, etc.
• Per topic: Include the topic text; if present, append the note content (decoded) in parentheses or on a following line.
• Optional: Note #tags or size (e.g. “major branch”) so plans can weight “must have” vs “nice to have”.

Example of the kind of structure to produce:

Dream Markdown Editor 2
  What processor to use?
    APEX for sure #mustHave
    Handle filters/plugins
    Allow selection of mode
    ...
  Features
    New document from clipboard
    ...
  Layout
    ...

You can output this as markdown headers, a bullet list, or a short summary—whichever best supports the next step.

5. Use the map for generating plans

• Input to the AI: Provide the extracted outline (and, if useful, a short note that it came from an iThoughts mind map and that tags like #mustHave / #maybe are user hints).
• Planning: Use this structure to generate implementation plans, app layouts, or feature specs: respect the hierarchy (main themes vs sub-ideas), honor tags for priority, and treat notes as extra requirements or constraints.
• Output: Produce the plan in the format the user asked for (e.g. implementation plan, UI layout, backlog), clearly tied to the map’s branches and topics.

6. Quick reference: one-liner extraction

To get raw XML from an .itmz for parsing:

unzip -p "/path/to/file.itmz" mapdata.xml

Or extract only mapdata.xml to a temp directory and read that file. Then parse the XML and walk the nested <topic> elements to build the outline as in sections 3 and 4.

---

Summary: Resolve the given path → unzip the .itmz → read and parse mapdata.xml → build a hierarchical outline from nested <topic> (using text, optional note, and tags) → use that outline to generate plans, layouts, or feature specs as requested.

Ask any questions needed to resolve ambiguous directions in the outline before writing the plan.