PR

prosa-panel-rendering

Defines UI design and rendering standards using Go, HTMX, and Alpine.js.

Install

mkdir -p .claude/skills/prosa-panel-rendering && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12857" && unzip -o skill.zip -d .claude/skills/prosa-panel-rendering && rm skill.zip

Installs to .claude/skills/prosa-panel-rendering

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Panel behavior and rendering conventions for prosa. Use when changing internal/panel templates, HTMX partials, Alpine state, Frappe charts, CSS tokens, or OAuth flow.
166 chars✓ has a “when” trigger
Advanced

Key capabilities

  • Change internal panel templates
  • Modify HTMX partials
  • Adjust Alpine.js state
  • Manage CSS tokens
  • Add new routes
  • Build new charts

How it works

This skill defines conventions for server-rendered Go applications using HTMX and Alpine.js, enforcing specific architectural rules for panel behavior and rendering.

Inputs & outputs

You give it
HTML, templates, or client-side behavior changes
You get back
Updated panel rendering components

When to use prosa-panel-rendering

  • Update panel template
  • Modify HTMX partials
  • Configure Alpine.js state
  • Manage CSS modules

About this skill

Prosa Panel Rendering

Use this skill before changing the panel's HTML, templates, or client-side behavior.

Stack

  • Go + html/template + embed.FS — server-rendered, single binary, no build step.
  • HTMX — partial swaps for the sidepanel, transcript paging (/sessions/<id>/turns), and raw transcript pagination today; chart filter swaps as the panel grows.
  • Alpine.js (~15 KB) — local UI state only: toggles, modals, hover, filter pill open/close, command palette. Not for data fetching, and never per-repeated-element: anything that exists once per transcript turn (bubble collapse, tool/thinking group toggles) is delegated vanilla JS in assets/transcript.js, one listener for the document.
  • Charts via Frappe Charts (vendored ~19 KB SVG library). The server builds a charts.Spec in internal/panel/charts/ and emits it as a JSON island; assets/charts-init.js renders it client-side with the --chart-* palette. The heatmap / punch card stay CSS-grid (HTML, not a chart library). Bar leaderboards stay server-rendered HTML.
  • CSS in modules under internal/panel/templates/assets/css/, imported via native @import. No bundler.
  • SSE at /events — live badge of new sessions; future live KPI ticks.

The full surface is documented in docs/architecture/panel.md. The design contract is in docs/panel/screens.md and docs/panel/components.md.

Rules

  • No build step. No esbuild, no vite, no npm install. Everything ships via embed.FS.
  • No SPA patterns. No client-side router. No global store. No hydration.
  • Server-first state. Data state lives on the server; UI state lives on the client. The dividing line is HTMX (server data) versus Alpine (UI toggles).
  • Charts via Frappe Charts only. Build a charts.Spec in internal/panel/charts/ and let charts-init.js render it; don't add a second charting library (Chart.js / D3 / ECharts / …). Vendoring the one prebuilt UMD file via embed.FS is not a build step; adding npm / a bundler still is, and is out.
  • Design tokens are the only colors. tokens.css defines --bg, --text-*, --accent, --ok, --danger, etc. Templates reference vars; nobody else uses literal hex.
  • Templates compose via base.html. Per-view templates are parsed bundled with the base layout at startup (internal/panel/server.go); execute by view name.
  • Auth shapes are public contract. OAuth cookie is HMAC-signed (PROSA_PANEL_COOKIE_KEY), HttpOnly, Secure when configured, SameSite=Lax. PROSA_PANEL_DEV_LOGIN is dev-only and logs a loud warning at boot.

Routes (current)

Public: /healthz, /login, /oauth/github/callback, /logout, /dev-login (only when env set), /assets/*.

Gated by session cookie: /, /sessions/<id> (HTMX partial), /raw/<id>?offset=N (HTMX append), /devices, /devices/<id>/rename, /devices/<id>/revoke, /cli/authorize, /cli/authorize/approve, /analytics/<report>, /events (SSE proxy).

Adding something

  • New route: register in server.go. Decide gated vs public. Document in docs/architecture/panel.md.
  • New template: add to internal/panel/templates/. If top-level, add to loadViews().
  • New chart: build a charts.Spec in internal/panel/charts/ (pick a Frappe type: bar/line/donut/axis-mixed), unit-test the JSON shape in spec_test.go, render it from the handler, and add a [data-chart] container + JSON island in the template. Verify visually; there are no golden SVGs anymore.
  • New env var: add to internal/panel/config.go and document in docs/self-hosting.md.
  • New static asset: drop into templates/assets/. embed.FS picks it up on rebuild.

Testing

  • Smoke render: stand up the panel with PROSA_PANEL_DEV_LOGIN set, hit /, click through to the sidepanel, hit Esc.
  • Template parse: go test ./internal/panel/....
  • Chart spec shape: go test ./internal/panel/charts/....
  • Full lane: just test-race.

See also

  • docs/architecture/panel.md — internals, routes, auth, SSE proxy.
  • docs/panel/design-brief.md — direction, palette, motion.
  • docs/panel/screens.md — screen-by-screen layout.
  • docs/panel/components.md — KPI, charts, filter pills, command palette, design tokens.
  • docs/self-hosting.md — env vars and OAuth setup for owners.

When not to use it

  • When using a build step
  • When implementing SPA patterns
  • When adding a second charting library

Limitations

  • No build step is allowed
  • No SPA patterns are allowed
  • Only Frappe Charts are allowed for charting

How it compares

This workflow strictly avoids SPA frameworks and build steps, relying on server-side rendering and embedded assets for panel updates, unlike typical modern web development.

Compared to similar skills

prosa-panel-rendering side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
prosa-panel-rendering (this skill)02moNo flagsAdvanced
ui41moReviewIntermediate
telegram-mini-app626moReviewAdvanced
playwright-browser-automation297moReviewIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

ui

nuxt

Build UIs with @nuxt/ui v4 — 125+ accessible Vue components with Tailwind CSS theming. Use when creating interfaces, customizing themes to match a brand, building forms, or composing layouts like dashboards, docs sites, and chat interfaces.

427

telegram-mini-app

davila7

Expert in building Telegram Mini Apps (TWA) - web apps that run inside Telegram with native-like experience. Covers the TON ecosystem, Telegram Web App API, payments, user authentication, and building viral mini apps that monetize. Use when: telegram mini app, TWA, telegram web app, TON app, mini app.

62163

playwright-browser-automation

lackeyjb

Complete browser automation with Playwright. Auto-detects dev servers, writes clean test scripts to /tmp. Test pages, fill forms, take screenshots, check responsive design, validate UX, test login flows, check links, automate any browser task. Use when user wants to test websites, automate browser interactions, validate web functionality, or perform any browser-based testing.

29146

svelte-expert

Raudbjorn

Expert Svelte/SvelteKit development assistant for building components, utilities, and applications. Use when creating Svelte components, SvelteKit applications, implementing reactive patterns, handling state management, working with stores, transitions, animations, or any Svelte/SvelteKit development task. Includes comprehensive documentation access, code validation with svelte-autofixer, and playground link generation.

11107

shopify-development

davila7

Build Shopify apps, extensions, themes using GraphQL Admin API, Shopify CLI, Polaris UI, and Liquid. TRIGGER: "shopify", "shopify app", "checkout extension", "admin extension", "POS extension", "shopify theme", "liquid template", "polaris", "shopify graphql", "shopify webhook", "shopify billing", "app subscription", "metafields", "shopify functions"

1299

desktop

lobehub

Electron desktop development guide. Use when implementing desktop features, IPC handlers, controllers, preload scripts, window management, menu configuration, or Electron-specific functionality. Triggers on desktop app development, Electron IPC, or desktop local tools implementation.

941

Search skills

Search the agent skills registry