Runs a lens-based UI/UX audit of the client and turns its findings into tracked, fenced work items, and measures the rendered page for a design review. Use when auditing the interface for quality gaps, running or scoping an audit (full, one lens, one surface, or a diff), driving the real-browser leg of an audit, measuring a page or a PR's change against the design review floors (phone sizes, icons, targets, contrast, focus), synthesizing raw lens findings into batches, or deciding how audit findings enter the tracker.

The marketing site shows the **real** DorkOS UI rendering **seeded** demo data — never mockups, never doctored screenshots. One command regenerates every asset. This skill is the map: when to run it, how it works, the honesty rules, the staging knobs, and how to add a new surface.

Collect CI Steward's pipeline numbers right now, locally, into a temporary directory, and show the ci-status screen from them, including this clone's local hook timings. Pushes nothing. Use when the daily snapshot is too old to answer the question.

Analyzes user prompts for gaps, ambiguities, and unstated assumptions, then asks clarifying questions before work begins. Use when requests are vague, lack acceptance criteria, or have hidden complexity.

Systematically investigates failing tests, distinguishes between test bugs and implementation bugs, and drives a fix with verification. Use when the user wants to debug failing tests.

Systematically investigates TypeScript compiler errors, traces the real type mismatch, and applies a minimal verified fix. Use when the user wants to debug TypeScript type errors.

First-touch triage for incoming GitHub issues on dork-labs/dorkos. Use when DorkBot is asked to triage the issue queue: label each new issue by type and runtime, find likely duplicates, and ask the reporter for missing reproduction steps. Read-and-suggest by default; only comments or edits labels when explicitly allowed to act.

`/app:upgrade` is the procedure; this is the reasoning it leans on. Read it before the first lane, and come back to the signature table the moment a dependency PR goes red.

The Dev Playground (`apps/client/src/dev/`, accessible at `/dev` in development) is a living gallery of every visual component in DorkOS. It exists so that designers and developers can review components in isolation, catch regressions visually, and verify that the design system is coherent.

The spec manifest (`specs/manifest.json`) tracks every specification in the project. Never edit it by hand — always use the manifest-ops script.

Build packages that work for both DorkOS and Claude Code. Every package must pass `dorkos package validate` before submission.

A sample task bundled with the valid-plugin fixture.

Summarizes long inputs into a short brief.

Browser-based visual companion for showing mockups, diagrams, comparisons, and interactive options. Use when the user would understand something better by seeing it than reading it.

Decides when agent work needs an isolated git worktree and how to create, enter, and clean one up safely. Use when starting code changes in a checkout that may be shared with another agent, dispatching a Linear task, executing a spec, or running any parallel work that mutates tracked files.

Every word a user reads should be plain enough for a smart 9th grader who does not write code. This skill is the readability standard for user-facing DorkOS writing. It is the shared source the other writing skills build on.

Guides writing concise, effective Architecture Decision Records. Use when creating ADRs, extracting decisions from specs, or reviewing ADR quality.

The DorkOS in-app copy standard - voice, the word-count cap, and the rules for buttons, errors, empty states, confirmations, toasts, settings, approvals, status, times and truncation. Use when writing, editing or reviewing any string the DorkOS app renders (apps/client/src, or server copy the client shows verbatim), or when sweeping app copy.

Writes non-release DorkOS blog posts - feature posts, decision essays, ecosystem posts, and release recaps - from the repo's own ADRs, specs, research reports, and changelog fragments. Use when drafting, researching, or reviewing anything in blog/ that is not a version release note.