Mindmap Helper

Source: https://github.com/aipoch/medical-research-skills

When to Use

• Converting product requirements into a clear multi-level outline for review and alignment.
• Preparing a mind map document to import into tools like XMind, ProcessOn, or FreeMind.
• Drafting an information architecture (IA) for documentation, onboarding guides, or knowledge bases.
• Summarizing a complex topic into balanced branches with consistent granularity.
• Producing a machine-readable hierarchy (JSON) for downstream processing or automation.

Key Features

• Builds a hierarchical mind map structure from a topic, requirements, or notes.
• Supports two output formats:
  • Markdown (default): readable and easy to edit manually.
  • JSON: suitable for programmatic processing and tool import.
• Provides a structure-first workflow: draft the tree, then refine naming and granularity.
• Enforces naming and structure rules:
  • short phrases / noun phrases (avoid full sentences)
  • consistent granularity at the same level
  • recommended 5-9 sibling branches per parent (split if exceeded)
  • avoid duplicates/synonyms; merge when appropriate
• Handles missing information by producing a usable draft and marking items as "TBD/Optional/To confirm".

Reference templates and examples: references/mindmap_formats.md

Dependencies

• None

Example Usage

Input (prompt)

Create a mind map for "Mobile App Subscription System".
Audience: product + engineering.
Scope: subscription purchase, renewal, cancellation, and entitlement.
Output: Markdown. Depth: 4-5 levels.

Output (Markdown mind map)

• Mobile App Subscription System
  • Goals
    • Increase conversion
    • Reduce churn
    • Ensure entitlement accuracy
  • User Journeys
    • Purchase
      • Plan selection
      • Price display
      • Payment confirmation
      • Receipt / invoice
    • Renewal
      • Auto-renew rules
      • Renewal notification
      • Payment failure handling
    • Cancellation
      • Cancel entry points
      • Effective date rules
      • Win-back offers (Optional)
    • Restore Purchases
      • Platform restore flow
      • Cross-device sync
  • Product Rules
    • Plans
      • Monthly / yearly
      • Trial eligibility
      • Regional pricing
    • Entitlements
      • Feature gating
      • Grace period
      • Refund impact
    • Promotions
      • Intro offers
      • Coupons (TBD)
  • Platform & Integrations
    • iOS (StoreKit)
      • Product IDs
      • Receipt validation
      • Server notifications
    • Android (Google Play Billing)
      • Product IDs
      • Purchase tokens
      • RTDN notifications
    • Backend
      • Subscription state machine
      • Webhooks ingestion
      • Idempotency keys
  • Risks & Edge Cases
    • Payment failures
      • Retry policy
      • Dunning messaging
    • Refunds / chargebacks
      • Entitlement revocation timing
    • Account changes
      • Email change
      • Device migration
  • Metrics
    • Conversion funnel
    • Renewal rate
    • Churn reasons
  • Open Questions (To confirm)
    • Supported countries and currencies
    • Trial rules per platform
    • Tax/VAT invoice requirements

Implementation Details

• Workflow

  1. Confirm topic, audience, scope boundaries, and desired depth (default 4-5 levels).
  2. Produce a structural draft first, then refine branch names and granularity.
  3. Choose output format: Markdown (default) or JSON.
  4. Validate consistency: balanced hierarchy, consistent granularity at the same level, and short/clear naming.

• Output rules

  • Markdown: represent hierarchy using unordered list indentation.
  • JSON: root node contains title and children (each child follows the same structure).
  • If depth/format is not specified: default to Markdown with 4-5 levels.

• Naming rules

  • Use phrases or noun phrases; avoid full sentences.
  • Keep sibling nodes at the same conceptual granularity.
  • Target 5-9 children per parent; split into sub-levels if exceeded.
  • Avoid repetition and synonyms; merge when necessary.
  • Default to English node names; preserve established technical terms when appropriate.

• Missing information handling

  • If topic/scope is unclear, still output a usable structure.
  • Mark uncertain branches/items explicitly (e.g., TBD, Optional, To confirm) so they can be validated later.

When Not to Use

• Do not use this skill when the required source data, identifiers, files, or credentials are missing.
• Do not use this skill when the user asks for fabricated results, unsupported claims, or out-of-scope conclusions.
• Do not use this skill when a simpler direct answer is more appropriate than the documented workflow.