opencode-wait-a-minute 0.0.0-stage → 1.1.0-rc.10

package/skills/linter-negative/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: no-slop-ui
+description: "Build or review frontend UI for clean, restrained, human-designed interfaces without generic AI visual patterns."
+metadata:
+  version: "0.3.0"
+---
+# No Slop UI
+
+You are building UI for a human audience. The goal is functional, honest, clean. Not impressive. Not dramatic. **Normal.**
+
+If a design decision feels like the easy AI default — it probably is. Pick the harder, cleaner option.
+
+Read `references/banned-patterns.md` for the full banned list before writing any UI code.
+Read `references/colour-palettes.md` when you need to pick colours.
+
+
+## Activation Boundary
+
+Use this skill only when the user explicitly asks for UI design, frontend implementation, visual polish, design review, or when the current task's primary deliverable is a visible interface. Do not activate it for backend-only tasks, copywriting, diagrams, infrastructure, or general code review.
+
+Treat this skill as a visual-quality layer. It must not override product requirements, accessibility, security, localization, data correctness, or the repository's existing design system. If those conflict with a no-slop rule, preserve the user requirement and explain the tradeoff.
+
+## The Standard
+
+Think **Linear. Raycast. Stripe. GitHub.** They don't try to grab attention. They just work.
+
+**What normal looks like:**
+- Sidebar: 240–260px fixed, solid background, 1px border-right. No floating shells, no rounded outer corners.
+- Cards: 8–12px radius max, subtle 1px border, shadow max `0 2px 8px rgba(0,0,0,0.08)`. No glow, no float.
+- Buttons: solid fill or simple border, 6–10px radius max. No pills, no gradients.
+- Typography: clear hierarchy, 14–16px body, system font or single sans-serif. No mixed serif/sans.
+- Spacing: 4/8/12/16/24/32px scale. Consistent. No random gaps.
+- Borders: 1px solid, subtle colour. No thick decorative borders, no gradient borders.
+- Transitions: 100–200ms ease. Opacity or colour only. No bouncy, no transforms.
+- Inputs: solid border, simple focus ring. Labels above fields.
+- Icons: 16–20px, monochrome or subtle colour, no decorative backgrounds.
+
+## Colour Priority
+
+1. **Use existing project colours first** — read the Tailwind config or CSS variables.
+2. If no palette exists — pick from `references/colour-palettes.md`.
+3. Never invent random colour combinations.
+
+## Stack-Specific Notes
+
+**shadcn/ui + Tailwind:**
+- Use shadcn components as-is — don't re-invent what's already there
+- Respect the existing CSS variable system (`--background`, `--foreground`, `--primary` etc.)
+- Don't override component defaults unless there's a clear product reason
+
+**Plain HTML dashboards:**
+- Single-file is fine — keep it self-contained
+- Use CSS custom properties for theming
+- No external CDN dependencies unless absolutely necessary
+
+## Hard Rules
+
+- No floating glassmorphism panels
+- No gradient backgrounds as decoration
+- No oversized rounded corners (20px+ everywhere)
+- No eyebrow labels (`<small>SECTION LABEL</small>` above headings)
+- No hero sections inside internal dashboards
+- No decorative copy ("Operational clarity without the clutter")
+- No metric-card grid as the default dashboard layout
+- No fake charts that exist to fill space
+- No transform animations on hover
+- No `Segoe UI`, `Trebuchet MS`, `Arial` font stacks
+- No status dots via `::before` pseudo-elements
+- No nav badges unless they carry real data
+- No pill buttons everywhere
+- No dramatic box shadows (24px+ blur)
+- No mixed alignment (some left-aligned, some floating center)
+
+Full banned list with examples: `references/banned-patterns.md`

package/skills/no-slop-ui/SKILL.md

@@ -0,0 +1,26 @@
+# No Slop UI (Anti-Slop Guidelines)
+
+Prevent interface degradation (slop) by enforcing strict design standards and quality gates.
+
+## When to Activate
+
+- When refactoring "quick fixes" or accumulated technical debt in UI
+- When reviewing new component PRs or implementations
+- Any time "slop" is detected: nested overrides, magic values, or layout drift
+- Before finalizing design contracts or UI implementations
+
+## Anti-Slop Core Rules
+
+1. **No Magic Values**: Never use arbitrary pixel/rem values. Must use established design tokens (Tailwind classes or CSS variables).
+2. **No Nested Overrides**: Absolute ban on deep CSS nesting (`.a .b .c .d`). All styles should be scoped to the component level or use global utility classes.
+3. **Strict Grid/Spacing**: All spacing must align with the defined grid (4px/8px scale). No exceptions for "visual tweaks" (e.g., `ml-[3.33px]`).
+4. **Contract Fidelity**: Implementation must match the design contract exactly. If the design needs changing, update the contract first, do not "fix it in the CSS".
+5. **State Completeness**: Every component must define states (default, hover, focus, active, disabled, loading, error). If a state is missing, it is "slop".
+6. **No "Just One" Styles**: Any style applied as a "one-off" must be converted to a token or utility class immediately.
+
+## Enforcement Workflow
+
+- **Detect**: Flag magic values, nested overrides, or inconsistent spacing.
+- **Isolate**: Create a temporary fix or token if none exists.
+- **Standardize**: Move the fix into the design system/Tailwind config.
+- **Refactor**: Remove the temporary/hacked code.

package/skills/prototype/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: prototype
+description: Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
+---
+
+# Prototype
+
+A prototype is **throwaway code that answers a question**. The question decides the shape.
+
+## Pick a branch
+
+Identify which question is being answered, using the user's prompt, the surrounding code, or by asking if the user is around:
+
+- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a single shareable HTML file (free-play buttons plus tabbed guided walkthroughs) that pushes the state machine through cases that are hard to reason about on paper, and that a non-developer can drive.
+- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.
+
+The two branches produce very different artifacts, so getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.
+
+## Rules that apply to both
+
+1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious, but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
+2. **Trivial to run.** A UI prototype starts from one command in the project's task runner: `pnpm <name>`, `python <path>`, `bun <path>`, etc. A logic demo is a single HTML file the user double-clicks. Either way, no thinking required to start it.
+3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE, wipe me" name.
+4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast.
+5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
+6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: commit it to a throwaway branch, out of main, and leave a context pointer to that branch on the implementation issue. Capture the answer too (the verdict and the question it settled) in the issue or a commit. The main branch keeps only the validated decision.