Post UI component guide
A working template page for designing future mrakbook posts. Each section below previews one reusable UI element and names the shortcode to use when a post needs that pattern.
Use at the top of a post when the reader needs the section, title, summary, and quick context in one scan.
Extension package checklist before publish
A focused opening paragraph that states the job of the post, the reader benefit, and the boundary of the work.
Longform body text
Use normal markdown paragraphs for ordinary body copy.
The longform block should carry the main argument without decorative framing. It works for analysis, narrative explanation, release notes, product thinking, and careful technical writing.
A compact inline marker can point at an important phrase like ship only after rollback proof exists while preserving the reading rhythm.
Checklist
Use when the reader needs a pass/fail list with lightweight status labels.
- OKManifest version, display name, and description match the release notes.ready
- OKPackage signature and checksum are saved beside the release artifact.ready
- --Rollback install path is tested on a clean profile.needs proof
Warning callout
Use for context that should stand out from the article body.
Warning note
Use when an action is risky, irreversible, or likely to cause reader mistakes without extra care.
Card grid
Use for related but separate ideas.
Release proof
Link the build log, package checksum, and install screenshot.
Reader path
Show what a maintainer should do first, second, and last.
Fallback plan
Name the rollback command and the owner who can run it.
Metric grid
Use when numbers are part of the story.
Package delta
Compressed size added since the previous tagged build.
Manual checks
Install, settings migration, and rollback on a clean profile.
Comparison blocks
Use for two options, before/after states, or tradeoffs that need equal visual weight.
Before
Checklist lived in a private note, so release proof was hard to review later.
After
Checklist lives in the post with build evidence, status labels, and rollback notes.
Timeline
Use for chronological updates, changelogs, incident notes, and release diaries.
09:10 - Package built
The candidate artifact is generated from a clean working tree.
09:24 - Smoke pass complete
The extension opens, saves settings, and survives a profile restart.
09:40 - Release note staged
The public note includes install, update, and rollback instructions.
Data table
Use markdown tables for dense comparison.
| Asset | Required check | Owner | Status |
|---|---|---|---|
| package.zip | Checksum recorded | release | ready |
| CHANGELOG.md | Top entry matches tag | editorial | ready |
| rollback.md | Previous version path tested | support | open |
Code block and terminal card
Use code shortcodes or fenced code for commands, config fragments, logs, and short code samples.
npm run typecheck
zip -r extension-package.zip dist manifest.json README.md
shasum -a 256 extension-package.zip
Dark syntax block
Use when code should feel like a polished editor excerpt, with file context and line numbers.
type PostCardProps = {
title: string
tone?: "default" | "warning"
}
export function PostCard({ title, tone = "default" }: PostCardProps) {
return renderPostCard(title, tone)
}Quote panel
Use for a short pull quote, principle, or sourced note.
A release checklist is useful only when it records what actually happened, not what the team hoped would happen.Design note for future code posts
Media frame
Use for screenshots, diagrams, product states, and visual proof.
Resource list
Use for source links, downloads, related posts, and supporting material.
Action links
Use at the end of a post when the reader has a small set of next moves.