uinaf-design-system
uinaf design system
Apply uinaf's identity to any creative output that ships under the studio name. Web is the most-supported track, but the same voice, type, and visual rules carry across content, slides, social, email, terminal, and native surfaces.
The canonical brand spec is references/brand-spec.md. Read it before producing anything new — it is the upstream source for every other reference in this skill.
Hard rules — universal (apply to every uinaf output)
- Berkeley Mono is the only typeface. No serifs, no sans, no second face. Off-uinaf fallback: JetBrains Mono.
- Lowercase voice on product surfaces. Headings, nav, button labels, post titles, changelog entries, file names that show in UI, the studio name. Always — on uinaf-controlled surfaces. Repo collaboration docs (
README.md,CONTRIBUTING.md,SECURITY.md,AGENTS.md,CLAUDE.md, GitHub templates) are carved out and use proper-case headlines; see references/repo-docs.md. - No emoji. Anywhere. Brand artwork is the only flair.
- Voice is short, direct, dry. No SaaS sludge ("empower", "unlock", "synergies"). Sentence fragments end with periods. This applies everywhere, including repo docs.
- Illustrations live on pure black with no chrome. The slime palette (lime / green / cyan / blue / purple / magenta / pink) stays inside artwork, terminal output, and rare data-viz — never as button fills, gradient washes, or default text.
Hard rules — UI surfaces (web, slides, native, email HTML)
- Square corners. Cap radius at 6px; 2px is the norm. Status dots are the only pill.
- No coloured CTAs. UI is monochrome neutrals. Hierarchy comes from weight and box position, not fill color.
- No shadows on UI. Borders do all the elevation work.
More from uinaf/skills
verify
Self-check your own completed change before handing off to `review` — the pre-review sanity pass. Use when you want to verify your change, test it end-to-end, run the repo's guardrails (lint, typecheck, tests, build), exercise the real surface with evidence, and catch obvious self-correctable issues you can fix in seconds. Produces a `ready for review` / `needs more work` / `blocked` verdict — never a ship decision (that's `review`'s job). If the repo cannot be booted or exercised reliably, hand off to `agent-readiness`. If you are auditing someone else's diff, branch, or PR, use `review` instead.
37effect-ts
Implement, debug, refactor, migrate, review, or explain Effect TypeScript code. Use when a task touches `effect` or `@effect/*` APIs, especially services, layers, schemas, runtime wiring, platform or CLI packages, Effect testing, or Promise-to-Effect migration.
37docs
Update repo documentation and agent-facing guidance such as AGENTS.md, README.md, docs/, specs, plans, and runbooks. Use when code, skill, or infrastructure changes risk doc drift or when documentation needs cleanup or restructuring. Do not use for code review, runtime verification, or `agent-readiness` setup.
36viteplus
Migrate or align frontend repositories to the stock VitePlus workflow. Use when standardizing package or monorepo repos around `vp`, `voidzero-dev/setup-vp`, `vite-plus/test`, and VitePlus-native CI, test, packaging, and hook flows. Default to replacing direct package-manager and Vitest wiring with the VitePlus equivalents unless the repo has a proven exception.
29review
Independently audit existing code, diffs, branches, or pull requests using concern-specific reviewer personas and evidence. Use when triaging risk in a PR, deciding whether a change is safe to ship, or following up on a `verify` pass to make the call the builder cannot make on their own work. Produces a `ship it` / `needs review` / `blocked` verdict. Do not use to self-check a change you just authored; use `verify` for that.
23agent-readiness
Audit and build the infrastructure a repo needs so agents can work autonomously — boot scripts, smoke tests, CI/CD gates, dev environment setup, observability, and isolation. Use when a repo can't boot, tests are broken or missing, there's no dev environment, agents can't verify their work, or agents need human help to get anything done. Do not use for reviewing an existing diff or for documentation-only cleanup.
21