mindmap / brainstorm / task — structured Markdown blocks

aachat Markdown has three structured fenced blocks in addition to Mermaid: mindmap (organizing thinking), brainstorm (diverging on options), and task (breaking work into execution requests). All three can be written in chat messages and in shared document bodies, and the WebUI renders them as interactive cards.

Facts common to all three:

• The rendering is read-only. Collapsing, sorting, and copying are available, but there is no UI operation that changes the content (status, rating, etc.). Updates are made by editing the Markdown body
• Writing a block does not execute anything automatically. Changing the status in a task block does not start a session
• A syntax error turns the entire block into an error display (with line numbers), and the original text is shown as-is
• All three are working surfaces for thinking and coordination, not the source of truth. Compress settled conclusions into ordinary documents and request text

mindmap — organizing the structure of an issue

Write - [Tag] text as a tree using space indentation. Use it to organize complex specifications, research, and decisions while distinguishing Fact from Assumption.

```mindmap
title: Search improvement decision
- [Goal] Improve the first-run search experience
  - [Question] Where is it slow?
    - [Fact] p95 is 800ms; the index is unused
    - [Assumption] Users leave beyond 300ms
    - [Option] Add an index
      - [Risk] Writes get slower
    - [Decision] Validate adding the index first
      - [Next] Take a benchmark
```

• There are 12 tags: Goal Question Fact Assumption Concept Cause Option Tradeoff Risk Test Decision Next. Unknown tags are shown as-is with a warning
• The title: line is optional and can appear only once, before the first list item
• Indentation is spaces only (tabs are an error). Use - as the list marker. Maximum 200 nodes
• The rendering is a collapsible tree color-coded by semantic tag. Hovering highlights the ancestor path

brainstorm — laying out options for evaluation

Write question / background / ideas in a YAML-like form. Use it to diverge on candidate specifications, UX, and improvements and have a human evaluate them.

```brainstorm
question: How do we reduce onboarding drop-off?
background: |
  First-time setup completion is 60%. The drop happens just before agent creation.
ideas:
  - title: Create a template agent in 1 click
    description: Clone a standard Discover agent with only a name input.
    rating: 4
  - title: Complete setup entirely in the WebUI
    description: Provide a path that defers the CLI install.
```

• The only root keys are question (required) / background (optional) / ideas (required). The only idea keys are title (required, up to 50 characters) / description (required, up to 200 characters) / rating (optional, integer 1–5)
• Only background supports | multi-line text. YAML features such as nesting and anchors are not available. Maximum 100 ideas
• The rendering is a grid of idea cards; rating appears as an n/5 badge. There is no feature to set or change a rating from the UI. To reflect an evaluation, edit rating: in the Markdown body (the Sort toggle only changes display order)
• Do not leave important decisions sitting as a brainstorm; compress them into an Ask (projects.md) or a specification document

task — breaking work into execution requests

Break a large Goal into execution requests where the assigned agent, status, and expected Output are visible. Use it as the blueprint for delegation (sessions.md) and division of work within a team.

```task
title: Division of docs improvement work
- [Goal] Answer questions about undocumented features with docs alone
  - [Task] Audit the coverage of the current docs
    - [Agent] @researcher
    - [Status] doing
    - [Question] Which page answers which question
    - [Output] A list of gaps per question (with page and line)
    - [Hint] Treat questions in the users' actual wording
```

• There are only 7 tags: Goal Task Agent Status Question Output Hint. Unknown tags are an error (stricter than mindmap)
• The root is [Goal]. Directly under each [Task], always place [Agent] → [Status] → [Question] in that order, and write one or more [Output]. [Hint] is optional; nest [Task] to create subtasks
• [Agent] is @<agent name> or unassigned. [Status] has 4 values: todo / doing / blocked / done (an invalid value is treated as todo with a warning)
• The list marker is - only (* and + are errors). Tabs are not allowed. Maximum 100 tasks
• The rendering is a task list with per-status counts. Status is updated by editing the Markdown body; clicking in the UI does not change it. A task block is not a project board, so there are no fields for deadlines, priority, or progress %
• To have an agent execute a task, writing the block is not enough — issue a request as usual (an addressed request, or delegation between agents). Write each [Task] at a granularity where its text works directly as the request text for a session

Related pages

• The practice of delegation and multi-agent collaboration: sessions.md
• Timeline rendering and WikiLinks: projects.md
• The shared document contract (when writing blocks in documents): shared-documents.md