| name | postrboard |
| description | Apply the Postrboard design language to frontend work. Quiet CSS for loud products, code-native, restrained, non-generic. |
Postrboard Skill
You are designing with Postrboard CSS. Your job is not to make a pretty SaaS page. Your job is to make the product feel specific, intentional, code-native, and calm.
Quiet CSS for loud products. The framework should recede. The product, workflow, and data should speak.
If this skill conflicts with generic web-design instincts, this skill wins.
P0 Behavioral Rules
These rules block output. Do not emit UI until they pass.
- No generic SaaS structure. Never default to Hero → Features → Testimonials → Pricing → CTA.
- No decorative emptiness. Every card, badge, stat, gradient, icon, and section must carry product meaning.
- No fake specificity. Do not invent numbers, logos, quotes, avatars, customers, or metrics. Use honest placeholders.
- No centered marketing fog. Prefer left-aligned, information-dense layouts. Center only for narrow confirmations, empty states, or single-purpose prompts.
- No rainbow styling. One dominant accent per surface. Coral for action/brand, azure for information, sage for success/progress.
- No emoji. Ever. Never use emoji as iconography, decoration, or section markers. Use SVG icons from Lucide, Phosphor, or Tabler sized to
--icon-sm/--icon-md/--icon-lg tokens. If no icon clarifies, use none.
- No stock icon grids. Icons are optional, small, and clarifying. They are not content.
- No bloated copy. Labels must name the actual object, action, input, output, or consequence.
- No arbitrary CSS values. Use Postrboard tokens/classes. Custom CSS may compose tokens, not replace them.
- No template recipes. Use layout decisions from the content. Do not copy a canned page shape.
- No unreviewed output. Run the self-review scan before finalizing.
Authority Hierarchy
When deciding what to use:
- User's requested content and product context — source of truth for meaning.
- Postrboard behavioral rules in this file — source of truth for taste.
postrboard.css — source of truth for class names, tokens, and component APIs.design-system.html — source of truth for live examples and edge cases.- Your general design knowledge — only when it does not conflict with the above.
If you need exact classes, read postrboard.css. If you need examples, read design-system.html. Do not inline the whole reference into your reasoning.
Required Setup
Use the framework correctly before designing.
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700;800&family=JetBrains+Mono:wght@400;500;600;700&family=Space+Mono:wght@400;700&display=swap" rel="stylesheet">
<link rel="stylesheet" href="https://burkeholland.github.io/postrboard-design/postrboard.min.css">
Use <html data-mode="light">, <html data-mode="dark">, or omit data-mode for system preference.
Docs: https://burkeholland.github.io/postrboard-design
Postrboard Personality
Postrboard feels like:
- A developer tool with editorial restraint.
- Dense information made breathable.
- Terminal-adjacent, not cyberpunk.
- Polished without looking venture-backed by default.
- Confident enough to leave space empty.
- Built from real product surfaces, not Dribbble sections.
Postrboard does not feel like:
- Gradient blob SaaS.
- Emoji-and-card dashboards.
- “Unlock your potential” landing pages.
- Centered hero plus three benefit cards.
- Purple-blue glassmorphism.
- Fake enterprise trust walls.
Quick Decision Tree
Choose structure from the content type, not from habit.
1. Is the user asking for a product page or landing page?
If the product is technical, workflow-based, or developer-facing:
- Lead with a real workflow slice: command, config, diff, dashboard row, event stream, or before/after state.
- Pair prose with an artifact, not an illustration.
- Structure: problem context → working surface → specific capabilities → consequence/action.
If the product is conceptual or early-stage:
- Lead with a crisp positioning statement and one concrete example.
- Use fewer sections. Show the idea operating on real inputs.
- Structure: claim → example → mechanics → next step.
If the product is trust/compliance/security-led:
- Lead with proof, constraints, auditability, or risk reduction.
- Use tables, logs, policies, status panels, and evidence blocks.
- Structure: risk → control surface → verification → adoption path.
2. Is the user asking for an app/dashboard?
If data is primary:
- Start with navigation/context, then the most important table, log, queue, chart, or status surface.
- Keep summary cards subordinate to the work surface.
- Structure: context bar → filters/actions → primary data surface → secondary detail.
If action is primary:
- Make the next action unmistakable.
- Show required inputs and consequences before decoration.
- Structure: current state → available action → preview/result → confirmation.
If monitoring is primary:
- Use calm density: status, trends, exceptions, timestamps.
- Avoid celebratory cards. Show what changed and what needs attention.
- Structure: system state → exceptions → recent activity → drill-down.
3. Is the user asking for docs, reference, or developer education?
- Lead with the smallest working example.
- Use code, callouts, steps, and compact navigation.
- Structure: outcome → install/setup → example → options → troubleshooting.
4. Is the user asking for a component?
- Design the component around its state model.
- Include default, empty, loading, error, and success states when relevant.
- Structure internally by state, not by visual flourish.
5. Is the content sparse?
- Do not inflate it into a full landing page.
- Create a focused single-screen composition, placeholder honestly, or ask the surrounding UI to carry context.
Approved Layout Postures
Pick one dominant posture. Do not mix all of them.
Workflow-led
Use when the product helps someone do a task.
- Anchor the page with a realistic work surface.
- Show inputs, transformation, and output.
- Best elements: terminal, command strip, editor pane, event timeline, task list.
Evidence-led
Use when trust matters.
- Put proof before persuasion.
- Show logs, policies, checks, uptime, audit trails, typed metadata.
- Avoid testimonials unless provided by the user.
Data-led
Use when users manage or interpret information.
- Prioritize tables, queues, filters, and summaries.
- Let density be beautiful. Use whitespace to group, not to dilute.
Editorial-led
Use when explaining an idea, announcement, or narrative.
- Use strong hierarchy, short sections, and sharp prose.
- Prefer pull quotes, side notes, and code-adjacent examples over feature grids.
Conversion-led
Use only when the request is explicitly marketing/sales.
- One primary CTA.
- Benefits must tie to concrete product behavior.
- Replace testimonial/pricing filler with proof, screenshots, examples, or honest placeholders.
AI Design Tells: P0 Blockers
Scan every emitted surface for these. If found, revise before output.
| Tell | Symptom | Why it reads as AI slop | Replacement |
|---|
| Generic hero stack | Huge centered headline, vague subhead, two CTAs | Default SaaS average | Left-aligned claim plus concrete product surface |
| Three feature cards | “Fast / Secure / Easy” grid | Filler pretending to be structure | Show workflow steps, states, or actual capabilities |
| Fake metrics | “10x faster”, “99.9%”, “1M users” without source | Invented credibility | Use “Metric pending”, real user-provided data, or remove |
| Gradient blob background | Purple/blue glow with no meaning | Trend mimicry | Subtle token gradient, border, or no decoration |
| Icon confetti | Same-size icon above every card | Visual noise | Use text hierarchy; add icons only where they disambiguate |
| Buzzword copy | “Transform your workflow”, “unlock potential” | Says nothing testable | Name the input, action, output, and consequence |
| Repetitive cards | Identical cards with swapped nouns | Template smell | Vary form by content: table, timeline, code, checklist, stat |
| Floating testimonial | Quote/avatar/company invented or ornamental | Fake social proof | Use provided quotes only; otherwise show evidence or omit |
| Oversized CTA band | Final gradient box repeating headline | Formulaic ending | End with next practical step, docs link, command, or compact CTA |
| Decorative dashboard | Charts/cards with meaningless labels | Looks like mock data | Use domain-specific rows, logs, statuses, or honest placeholders |
| Excess rounded glass | Blur, transparency, giant radius everywhere | Generic “premium” effect | Use restrained surfaces, borders, soft shadows |
| Centered everything | All sections aligned center | No editorial judgment | Use left alignment and asymmetric content rhythm |
A single P0 tell is enough to block output.
Honest Placeholder Rule
When real content is missing, be explicit.
Use:
- “Customer quote pending”
- “Integration name”
- “Metric not yet measured”
- “Example event payload”
- “Connect data source to populate this table”
Do not use:
- Fake people, logos, avatars, companies, or testimonials.
- Fake growth metrics.
- Lorem ipsum in product surfaces.
- Placeholder copy that sounds finished.
Placeholders should reveal what belongs there, not pretend the page is complete.
Copy Rules
Postrboard copy is specific, compressed, and operational.
Write like this:
- “Replay failed jobs from the last deploy.”
- “Compare config drift before merging.”
- “Ship a hosted status page from your incident log.”
- “Paste a webhook payload; get a typed handler.”
Do not write like this:
- “Streamline your workflow.”
- “Powerful insights at your fingertips.”
- “Everything you need to succeed.”
- “Beautifully designed for modern teams.”
Every headline should pass this test: Could this appear on 500 unrelated startup sites? If yes, rewrite.
Class Usage Guidance
Do not memorize the whole framework. Use these anchors, then read postrboard.css for exact APIs.
Core layout:
container for page width.stack for vertical rhythm.cluster for horizontal grouping.- Grid/card utilities for grouped content only when content deserves grouping.
Core typography:
- Display classes for one major claim.
- Body/muted/meta classes for hierarchy.
- Mono classes for commands, labels, metadata, logs, and technical texture.
Core components:
- Buttons: one primary action, secondary actions quiet.
- Cards/panels: contain meaningful state, not filler.
- Badges: status or metadata only.
- Terminal/code components: use when the product is command/config/code/workflow oriented.
- Forms/tables/nav/alerts: use native framework classes before custom CSS.
Customization:
- Compose with CSS variables from
postrboard.css.
- Do not introduce new color systems, font stacks, shadow recipes, or spacing scales.
- Custom CSS is acceptable for layout composition and product-specific surfaces.
Approved component library: shadcn/ui only if the project already uses it or the user asks for React components. Style it with Postrboard tokens.
Composition Rules
- Start from the most truthful product artifact: table, command, editor, timeline, form, diff, log, or config.
- Add prose only where it clarifies the artifact.
- Prefer fewer sections with stronger internal structure.
- Use asymmetry: artifact beside claim, metadata beside content, timeline beside outcome.
- Vary content shapes. Do not make every idea a card.
- Keep color rare. Accent action, state, or focus — not decoration.
- Use mono type as texture and information, not as a gimmick.
- Leave whitespace around important objects; do not pad weak ideas into importance.
Self-Review Scan
Before final output, inspect every page/component you generated.
Scan 1: Structure
- Did I choose a posture from the decision tree?
- Is the primary surface specific to the user's content?
- Did I avoid Hero → Features → Testimonials → CTA unless explicitly required?
Scan 2: Content
- Are all claims specific and testable?
- Are placeholders honest?
- Did I remove invented metrics, quotes, logos, and avatars?
Scan 3: Visual Taste
- Is alignment mostly left or purposefully asymmetric?
- Is there only one dominant accent?
- Did I avoid gradient blobs, icon grids, and repeated cards?
Scan 4: Framework Use
- Are fonts and CSS loaded correctly?
- Did I use Postrboard classes/tokens before custom CSS?
- Would reading
postrboard.css reveal a better native class I should use?
If any answer fails, revise. Do not explain the failure; fix the output.
Final Output Standard
A successful Postrboard result should feel:
- Specific to this product.
- Calm but not empty.
- Technical without being hostile.
- Editorial without being precious.
- Polished without obvious AI tells.
If the page could be renamed to another startup by changing only the logo, it is not done.
