git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/design && cp -r /tmp/design/plugins/ai-agency/hyperflow/skills/design ~/.claude/skills/designSKILL.md
# Design Systematic, anti-slop product design. All agents inherit the session model. Reviewers bold-labeled; Workers plain. This skill exercises **Layer 4 (Brainstorming/Spec)** and the design layer of **Layer 0 (Project Analysis)**. It is **thinking, not building** — no source code is written here. The only writes are to `.hyperflow/design/system.md` and `.hyperflow/specs/`. It ends with a handoff gate into `/hyperflow:plan` → `/hyperflow:dispatch` for the build. ## Iron Rules - **Design system first.** Every run establishes or extends `.hyperflow/design/system.md` before designing a screen, per [`../hyperflow/design-system.md`](../hyperflow/design-system.md). The system is created once and extended, never regenerated. - **Researched, not invented.** Ground every direction in **≥2** real products from the project's field, combine them, then diverge with one deliberate signature (the method in [`design-system.md`](../hyperflow/design-system.md)). - **Local taste skills are invoked live.** The main session calls `Skill` to invoke the matching taste skill; the dispatched `designer` agent Reads the `SKILL.md` and applies it (it has no `Skill` tool). - **Per-step agents (DOCTRINE rule 12).** No inline design — the [`designer`](../../agents/designer.md) specialist does the work; an `accessibility-reviewer` pass gates the result. - **No code in the design phase.** Design produces a system file and a design spec; `dispatch` executes them. - **Failure recovery (DOCTRINE rule 14)** per [`../hyperflow/failure-recovery.md`](../hyperflow/failure-recovery.md). - **No AI attribution** in any file written. ## Per-Step Agent Map (DOCTRINE rule 12) | Step | Sub-phase | Workers | Reviewers | Notes | |---|---|---|---|---| | 1 — Triage | — | — | — | Mechanical classification (exempt) per [`../hyperflow/task-triage.md`](../hyperflow/task-triage.md) | | 2 — Design system | 2a — establish/extend `.hyperflow/design/system.md` | `designer` | **Reviewer** | Creates if missing; extends if present | | 3 — Research + direction | 3a — prior-art research + combine + diverge | `designer` (fan-out ≤ 3 by dimension) | **Reviewer** | Web-research-first; ≥2 references | | 4 — Design spec | 4a — translate direction into tokens/spec | `designer` | **Reviewer** | Written to `.hyperflow/specs/<slug>.md` | | 5 — Taste + a11y review | — | — | **`designer`** verdict + **`accessibility-reviewer`** | Anti-slop floor + WCAG floor | | 6 — Handoff gate | — | — | — | `AskUserQuestion` only (exempt — structural gate) | ## Approval Gates | Gate | When | Format | |---|---|---| | Handoff gate | Step 6, after the spec is written | `AskUserQuestion` — build now / plan first / stop | ## Flow ### Step 1 — Triage Classify the request per [`../hyperflow/task-triage.md`](../hyperflow/task-triage.md). `types` will include `ui` and/or `creative`; the [Brain](../../agents/brain.md) confirms `designer` on the roster. ### Step 2 — Design system Read `.hyperflow/design/system.md`. If missing, dispatch `designer — establish design system` to create it (domain, tokens, type scale, spacing, motion, voice, components, references, anti-patterns) per [`design-system.md`](../hyperflow/design-system.md). If present, dispatch `designer — extend design system` to add only what this brief needs. Then `**Reviewer** — design-system coverage check`. ### Step 3 — Research + direction Invoke the matching local taste skill(s) live via `Skill` (per the index in `design-system.md`). Then dispatch `designer — research prior art + propose direction` (fan-out ≤ 3 by visual language / motion+interaction / IA when the surface is broad): study ≥2 real systems in the field, combine, diverge with one named signature. Then `**Reviewer** — direction grounding check` (≥2 references combined, not copied; signature is deliberate). ### Step 4 — Design spec Dispatch `designer — author design spec` to translate the chosen direction into the bound design-system tokens and write it to `.hyperflow/specs/<slug>.md` (format per [`../hyperflow/artefact-format.md`](../hyperflow/artefact-format.md)). Then `**Reviewer** — spec sanity check`. ### Step 5 — Taste + accessibility review Dispatch in parallel: `**designer** — taste verdict` (anti-slop floor) ∥ `**accessibility-reviewer** — a11y floor` (WCAG AA, focus, reduced-motion, RTL). On a11y conflict, the floor wins (Step 5 defers to the a11y verdict). ### Step 6 — Handoff gate (STRUCTURAL GATE · DOCTRINE rule 8) ``` ? Design spec ready at .hyperflow/specs/<slug>.md — build it? Build now (Recommended) — chain to /hyperflow:plan → /hyperflow:dispatch Plan first — open /hyperflow:plan to decompose without building yet Stop — leave the spec; build later ``` On **Build now** → invoke `Skill` with `skill: plan` and `args: "session=one spec=.hyperflow/specs/<slug>.md"`. On **Plan first** → invoke `plan` without auto-dispatch. On **Stop** → print one line and stop. If `AskUserQuestion` is unavailable, print the gate as a `Hyperflow Question` block and wait — never auto-build silently. ## Output Format Two outputs: 1. **The design system** at `.hyperflow/design/system.md` — living token document (created or extended this run). 2. **The design spec** at `.hyperflow/specs/<slug>.md` — the direction, tokens, signature, and `References:` block. Chat shows one status box pointing at the files, never the token dump (file-first, rule 8): ``` ── Design Result ───────────────────── Brief: <one line> System: .hyperflow/design/system.md (created | extended) Spec: .hyperflow/specs/<slug>.md Verdict: taste PASS · a11y PASS ───────────────────────────────────── ``` ## Hand-off - **Plan it** — auto-chain to `/hyperflow:plan` for decomposition; plan then stops at its build-location gate and asks where to build (it never auto-implements). - **Stop** — spec persists for a later build. ## Doctrine Full rules in [DOCTRINE.md](../hyperflow/DOCTRINE.md). Design method, taste-ski
Guard the beads execution record: enforce the write-flush-verify discipline that defeats the bd rapid-write race, audit epic dependency graphs for cycles and orphans, catch closures whose title overstates what shipped, flag open beads carrying no disposition or a disproven premise, and reconcile bd against its GitHub and Plane projections. Owns RECORD INTEGRITY; delegates graph analysis to bead-dependency-mapper and epic-closure drift to bead-epic-auditor rather than duplicating them. Use before closing an epic, after any batch of bd writes, when a bead premise looks stale, or when auditing whether the record matches reality. Trigger with "audit beads", "check the bead DAG", "did that close actually land", "bead hygiene".
Verify every factual assertion in a diff, PR body, commit message, bead note, or governing doc against the actual repository, and fail anything that cannot be substantiated by a command. Use before merging any PR that makes claims about counts, coverage, consumers, enforcement, provenance, or certification, and when auditing standing docs for rot. Trigger with "verify claims", "check this PR body", "is this claim true", "claim audit".
Design and build Omarchy (Quickshell/QML) bar-widget, panel, and service plugins that actually work on a stock install. Knows the hard runtime constraint (no node on the graphical session PATH), the first-party contracts (BarWidget, Panel, KeyboardPanel, PanelKeyCatcher, Service), the curl-from-QML data pattern, FileView persistence, and the marketplace submission bar. Use when starting a new Omarchy plugin, porting a plugin off an external runtime, wiring a service to a bar widget, or deciding how a widget should fetch and persist. Trigger with "build an omarchy plugin", "omarchy widget", "quickshell plugin", "port this plugin to QML".
Audit an Omarchy plugin before it reaches the marketplace: prove it installs and runs on a stock box (no node/python on the session PATH), run the omarchy-submit gate lane, validate on the rig with omarchy-plugin-validate and qmllint, and check the QML security invariants and first-party idiom contracts. Read-only: it reports and blocks, it does not rewrite the plugin. Use before submitting an entry, after any data-layer change, or when a plugin works on the dev box and you need to know whether it works for a real user. Trigger with "audit this omarchy plugin", "is this plugin submission ready", "will this plugin work when installed".
Audit and fix Claude Code SKILL.md files against enterprise compliance standards: frontmatter completeness, required body sections, and style. Use when validating or repairing skills in a plugin directory. Trigger with "audit skill", "fix skill compliance".
Learn how SKILL.md files work in Claude Code plugins, then build a production-quality agent skill from scratch. Covers frontmatter schema, body structure, testing, and iteration.
Step-by-step guide to writing a SKILL.md file for Claude Code. Learn how to plan, structure, and test auto-activating skills with proper frontmatter, allowed-tools, dynamic context injection, and supporting files.
|