SuperAPI AI Directory
Partner中文AI newsFavorites
Skillstrmnl-paper-blade

trmnl-paper-blade

Frontend & websites

View repository

Updated 10-15 23:43

About this skill

trmnl-paper-blade

Overview

Generate directly renderable Blade component markup for Laravel + trmnl-blade . Prefer reusing x-trmnl:: components and Framework v3 layout semantics; avoid freely assembling CSS/HTML.

Two sources of truth：

  1. Framework v3 rules: structural hierarchy, color system, runtime mechanisms such as Overflow/Clamp/Content Limiter/Pixel Perfect
  2. Actual scope wrapped by trmnl-blade: currently available Blade components (see below); for capabilities not wrapped, use native classes

Current Blade components

screen、mashup、view、layout、title-bar、columns、column、flex、grid、col、richtext、content、text、item、table、label、title、value、description、divider、meta、progress(progress-bar wrapper),track、clamp、background、aspect

Not wrapped as Blade components: chart (Highcharts/Chartkick JS), image (native class), progress-dots (native class)

Workflow

  1. First confirm the goal:
    • Create a new TRMNL screen
    • Rewrite existing HTML / sketch / data description into TRMNL Blade
    • Only the skeleton, or a complete screen
  2. Then collect the minimum input:
    • Screen theme and core data
    • Whether a title bar is needed
    • Whether two columns, lists, tables, charts, progress bars, KPIs, large numeric values, rich text are needed
    • Whether there are constraints such as device, orientation, bit depth
  3. Choose the component path (Prefer high-level components / Components）：
    • First priority:Rich Text / Item / Table / Chart / Progress. When it can be mapped directly, do not first break it into scattered div、grid、flex
    • Copy, quotes, notifications, paragraphs → richtext(old markdown route is deprecated)
    • Lists, schedules, events → item
    • Simple tables, structured data → table
    • Data visualization → chart native class / Highcharts / Chartkick
    • Progress expression → <x-trmnl::progress> or div.progress-dots
    • KPI, large numbers → value + label
    • Multiple regions / multiple columns → columns / mashup / grid
    • Color tokens, utility classes,data-* attributes → native class / data attributes
    • Read specific props, limits, and gotchas as needed references/components/、references/attributes.md、references/patterns.md
  4. Start from the basic skeleton, then fill in modules.
  5. By default, only generate markup; leave API push instructions to trmnl-paper-screen。

Default skeleton

<x-trmnl::screen>
    <x-trmnl::view>
        <x-trmnl::layout>
            <!-- content -->
        </x-trmnl::layout>
        <x-trmnl::title-bar title="..." />
    </x-trmnl::view>
</x-trmnl::screen>
  • can be omitted title-bar
  • When columns are needed, prefer columns / column
  • When centered stacking is needed, prefer layout direction="col" alignment="center"

Generation rules

  • Prefer using x-trmnl:: components; do not first write free-form classes
  • When requirements can be mapped directly to Rich Text / Item / Table / Chart / Progress, use these high-level components/patterns first, then consider columns、grid、flex
  • Ensure a clear structure first, then consider details
  • Keep hierarchy shallow and information density readable
  • Avoid hardcoded pixel values
  • title / label / description does not automatically clamp by default; when overflow is possible, explicitly use data-clamp="1" and other attributes to truncate
  • When the user has not requested it, do not invent unverified props
  • When props are uncertain, prefer using the default slot rather than inventing an API
  • When outputting a complete screen, prefer giving a complete renderable Blade snippet
  • When outputting a partial module, explain where it should be inserted layout / column position

Self-check before output

Auto-verifiable (run validate_markup.py）

  • has run validate_markup.py to validate the structural hierarchy and table usage rules (authoritative description see references/design-rules.md）
python3 skills/trmnl-paper-blade/scripts/validate_markup.py <markup-file>

still requires manual inspection

  • prioritize using verified <x-trmnl::...> components;chart / image / progress-dots use native class
  • may overflow title / label / description has explicitly added data-clamp
  • if only outputting a partial module, has stated where to insert layout、column or mashup 's position

Reference materials

Suggested reading order

  1. references/design-rules.md: first confirm the structural hierarchy and e-paper constraints
  2. references/patterns.md: first find the closest layout template, do not assemble from scratch
  3. references/components/: look up props, CSS mappings, and gotchas by actual component
  4. references/attributes.md: when utility classes,data-* attributes are needed, read further
  5. references/examples/_index.md: when a complete official example is needed, first look at the index, then expand as needed
  6. references/colors.md / references/guides.md: when color tokens or v3 differences are needed, look up further

Quick reference as needed

  • Component quick reference (props / CSS mappings / usage): read the corresponding component file under the references/components/ directory
  • Utility classes and data attributes (spacing, sizing, border radius, visibility, etc.): read references/attributes.md
  • utilities.md compatibility entry: read references/utilities.md(authoritative content has been consolidated into attributes.md）
  • Common layout templates (complete examples that can be copied directly): read references/patterns.md
  • Official example index: first read references/examples/_index.md
  • Official examples (complete HTML source reference): read references/examples/ the corresponding file under the directory
  • Complete v3 color system reference (grayscale / chroma / semantic colors): read references/colors.md
  • v3 features and upgrade differences: read references/guides.md
  • v3 design constraints (authoritative description of structural hierarchy / e-paper rules): read references/design-rules.md
  • Upstream documentation:https://trmnl.com/framework/docs/v3
  • Blade source:https://github.com/bnussbau/trmnl-blade

Available scripts

  • scripts/validate_markup.py — validate Blade markup structural rules (title-bar position, layout nesting, view must have exactly one layout, native table nested within table, ignore HTML/Blade comments)

Output conventions

Output in the following order by default:

  1. Blade markup
  2. If necessary, add 1-3 brief integration notes

If the user only wants code, output only code.

Pipeline output

When the markup needs to be passed directly to trmnl-paper-screen for pushing:

  • Save to file → trmnl-paper-screen read via --markup-file <path> Read
  • Via pipeline → echo '<markup>' | python3 skills/trmnl-paper-screen/scripts/push_screen.py --markup-stdin ...

Handoff format

When receiving the issue list returned by trmnl-paper-screen , the field format follows skills/trmnl-paper-screen/SKILL.md 's "Handoff format":

  • issue
  • location
  • suggested_fix