The component library
Plans are more than prose. They contain decisions, code changes, schemas, and risks, and each of those deserves purpose-built review UI instead of another wall of text.
Components are flow-level elements from a closed, built-in registry, rendered entirely server-side so documents stay self-contained and readable without JavaScript. The registry never evaluates code from a plan: attributes are strings or bare booleans, structured data arrives as fenced or scoped children, and any authoring mistake fails the render with a positional diagnostic.
If two of them look interchangeable, the pairs worth separating at the bottom of this page say which to reach for.
The sidebar groups these five ways, and so does this page.
Decisions
Section titled “Decisions”Ask the reviewer something, and end with a recorded answer.
| Component | What it is for |
|---|---|
| Decision | One tradeoff read option by option, each carrying its own verdict-lined considerations |
| DecisionAnalysis | A weighty choice audited in a keyed qualitative or weighted criteria matrix |
| QuickDecision | One small question the reviewer can settle from the option titles alone. Repeat it for a batch |
Code and files
Section titled “Code and files”Show the reviewer the code itself, and where it lives.
| Component | What it is for |
|---|---|
| CodeDiff | One file’s unified diff with gutters, change counts, and line-anchored annotations |
| CodeSnippet | Existing code with optional file identity, file-absolute line numbers, and annotations |
| FileTree | A plain file hierarchy with optional per-entry notes |
| FileTreeDiff | Entry-level change status as one combined change tree |
Data and contracts
Section titled “Data and contracts”Reference material the reviewer queries, and the interfaces they will have to live with.
| Component | What it is for |
|---|---|
| DataTable | A dataset with sortable columns, optional search, selectable columns, grouping, and text fit |
| DatabaseTableSchema | One table’s DBML-subset schema and its titled verbatim DDL |
| HttpEndpoint | One HTTP endpoint: parameters, request body, and status-coded responses |
| GraphqlOperation | One query, mutation, or subscription with input and payload shapes and executable examples |
| GrpcMethod | One gRPC method headed by its proto signature, with fields, status codes, and examples |
Pictures
Section titled “Pictures”Things a sentence cannot carry.
| Component | What it is for |
|---|---|
| FlowDiagram | A flow, dependency, or fan-out as staged cards joined by verb-labeled connectors |
| MermaidDiagram | A compile-time Mermaid diagram with static light and dark SVG and stable review anchors |
| Wireframe | True-size product screens connected into a short walkable prototype |
Document structure
Section titled “Document structure”The shape of the document itself, and the one thing a skimmer must not miss.
| Component | What it is for |
|---|---|
| Callout | A note, tip, warning, or danger a skimming reviewer must not miss |
| Part | The plan’s sections divided into numbered acts, rendered as anchored divider bands |
| QuickSummary | The plan’s key points as a standout opening card. Exactly one per plan |
| Slide | A recurring slide type and its guidance applied to one section |
| TableOfContents | The plan in one look: one linked row per section with its one-line gist |
Pairs worth separating
Section titled “Pairs worth separating”A few of these look like each other. The dividing line is what the reviewer needs to see.
| Reach for | Rather than | When |
|---|---|---|
QuickDecision |
Decision |
The reviewer can answer from the option titles alone |
Decision |
DecisionAnalysis |
Option-by-option considerations are enough, and a matrix would be ceremony |
DecisionAnalysis |
Decision |
The reviewer should audit the choice across explicit criteria, or check weighted arithmetic |
CodeSnippet |
CodeDiff |
You are showing existing code to read, with no change to mark |
CodeDiff |
CodeSnippet |
The point is what changes, not what is there |
FileTree |
FileTreeDiff |
The tree carries no change status. FileTreeDiff rejects a tree with no change and points you here |
FileTreeDiff |
FileTree |
Entries carry added, modified, removed, or renamed status |
FlowDiagram |
MermaidDiagram |
The content is a staged left-to-right story and you want Big Plan’s own cards and connectors |
MermaidDiagram |
FlowDiagram |
It is a general graph, or a sequence, class, state, or ER view |
| A Markdown table | DataTable |
The author needs only a plain grid; reader sorting, filtering, reshaping, and maximize are automatic |
DataTable |
A Markdown table | The author needs a title, typed columns, opening sort, grouping, or summary row |
And before any of them: if the content is an argument, prose is usually right. Reach for a component when the reader needs to compare, scan, sort, or point at something. Never draw an illustration as ASCII art in a code fence.
Every page has the same shape
Section titled “Every page has the same shape”Each component page carries How it looks, When to use it, When not to use it, Compared with where a look-alike exists, Usage, and Authoring with its attributes and children. So once you have read one, you know where to look on the rest.
Scoped children
Section titled “Scoped children”A scoped child component is valid only in its declared hierarchy: Annotation in CodeDiff and CodeSnippet; Column in DataTable; Ddl in DatabaseTableSchema; Stage and Edge directly in FlowDiagram, with Node directly in that Stage; Entry in TableOfContents; Option directly in Decision, with Consideration directly in that Option; Criterion, Details, Option, and Reversibility directly in DecisionAnalysis, with Score directly in an Option; Option directly in QuickDecision; Param, Request, and Response in HttpEndpoint; Argument, Field, Returns, Operation, Variables, and Response in GraphqlOperation; Field, Error, Example, and Proto in GrpcMethod; and the screen and drawing vocabulary documented under Wireframe.
Start a review — see these components in a complete plan review.