home / skills / commontoolsinc / labs / pattern-ui

pattern-ui skill

safe

This skill enhances UI polish by applying layout and styling patterns to pattern-ui components, ensuring responsive structure and two-way data bindings.

npx playbooks add skill commontoolsinc/labs --skill pattern-ui

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.1 KB

---
name: pattern-ui
description: Add UI polish with layout and styling
user-invocable: false
---

# UI Polish Phase

Only do this AFTER all logic is verified and tests pass.

## Read First
- `docs/common/components/COMPONENTS.md` - Full component reference
- `docs/common/patterns/style.md` - Styling patterns
- `docs/common/patterns/two-way-binding.md` - $value, $checked bindings

## Available Components

Layout: `ct-screen`, `ct-vstack`, `ct-hstack`, `ct-box`
Input: `ct-input`, `ct-textarea`, `ct-checkbox`, `ct-select`
Action: `ct-button`
Display: `ct-text`, `ct-status-pill`

## Key Patterns

**Two-way binding:**
```tsx
<ct-input $value={field} />
<ct-checkbox $checked={done} />
```

**Layout structure:**
```tsx
<ct-screen title="My Pattern">
  <ct-vstack gap="md">
    <ct-hstack gap="sm">
      {/* horizontal items */}
    </ct-hstack>
  </ct-vstack>
</ct-screen>
```

## Reference Existing Patterns
Search `packages/patterns/` for UI layout examples ONLY (not data/action patterns).

## Done When
- UI renders correctly
- Bindings work (typing updates state)
- No regression in data behavior

Overview

This skill adds UI polish to TypeScript patterns by applying layout, spacing, and styling using the project's component primitives. It focuses strictly on presenting work — not changing logic — and is intended to be run only after logic and tests are complete. The result is consistent, accessible, and maintainable UI that matches project patterns.

How this skill works

I use the provided layout and input components (ct-screen, ct-vstack, ct-hstack, ct-box, ct-input, ct-textarea, ct-checkbox, ct-select, ct-button, ct-text, ct-status-pill) to structure and style screens. I implement two-way bindings for form controls via $value and $checked and follow the documented styling patterns and component reference. I verify rendering, interactions, and that visual changes introduce no data or behavior regressions.

When to use it

After all logic is verified and unit/integration tests pass
When UI looks functional but needs consistent spacing, alignment, and visual hierarchy
When preparing a pattern for reuse in the patterns library
Before a design review or visual QA pass

Best practices

Read the component reference and styling patterns first to match existing conventions
Use ct-screen as the top-level wrapper and ct-vstack/ct-hstack for predictable spacing
Prefer two-way bindings ($value, $checked) on inputs so state updates remain simple
Reference existing patterns in packages/patterns/ for layout examples, not data logic
Keep changes limited to markup and props to avoid altering behavior

Example use cases

Polish a form: wrap fields in ct-vstack, add labels with ct-text, bind ct-input $value to state
Convert a raw layout to patterns: replace divs with ct-hstack/ct-box for consistent gaps
Make action controls consistent: replace native buttons with ct-button and add status pills
Prepare a pattern component for publication by aligning spacing and accessibility attributes

FAQ

Do I change business logic during this phase?

No. Only visual structure, styling, and bindings should change; business logic and tests must remain untouched.

How do I wire inputs to state?

Use the two-way binding props: <ct-input $value={field} /> and <ct-checkbox $checked={done} /> so typing updates state automatically.