tfx-design-standard

Improve, write, or review the copy on a Teacher & School product surface — TFX voice & tone, naming, error-message anatomy, and anti-AI-writing rules (SLP-9), applied at generation time. Use for any copy-only edit — writing or reviewing user-facing text (page, form, notification, empty state, error state), tightening the wording on a page ("improve/polish the copy on the marks page"), or any longer prose (site content, marketing copy, documentation, decision records). Sufficient on its own for copy-only work; the design loop pulls it in at its implement phase. NOT for a whole-page review with no dimension named — that is critique; NOT for a named structural or visual change — that is design.

Design or change a Teacher & School product UI — a new page, screen, form, flow, OR a modification to an existing one (adding a field, editing copy, restyling a component). Use whenever the user asks to design, create, build, add to, change, fix, or restyle any page, screen, form, component, or user flow — and whenever they ask to re-audit, re-check, or re-verify an existing page against the standards catalog (e.g. after the catalog gains new controls). Orchestrates the full loop — intent, diverge, plan (human gate), implement, verify — with the TFX-DS standards catalog enforced throughout. For copy-only edits the copy skill is sufficient; for questions about the catalog itself use standards; and to review, improve, or polish an existing page with no specific change named — or when the user just says they don't like it — use critique.

Improve the flow of an existing Teacher & School multi-step task or interaction — step traversal, async states, escapability, and draft safety. Use for a scoped ask that names this dimension — "improve this flow", "this multi-step form loses my draft", "smooth the journey between steps on <page>", "there's no way out of this wizard" — with no structural rebuild named. NOT for a whole-page review with no dimension named (that is critique); NOT for a named structural change or a brand-new flow (that is design). Layout goes to layout, wording to copy.

Critique an existing Teacher & School product page — capture it, grade it against the standards catalog and layout patterns, and return scored, ranked improvement suggestions without changing anything; then, on the user's approval, execute the accepted suggestions through the design loop's implement and verify phases. Use when the user asks to review, critique, audit, improve, polish, or judge an existing page, asks what's wrong with it, what's off, or what they should improve, or says they don't like it — WITHOUT naming a specific change. NOT for a named change ('add a field', 'change the button') or a new page; those go to design. NOT for grading the loop's own output; that is the evaluator agent. NOT for copy-only improvements — wording, microcopy, tone, or naming with no structural or visual change; those go to copy.

Tighten the layout of an existing Teacher & School product page — structure, visual hierarchy (what draws the eye — emphasis, size, position, grouping), density, alignment, and grouping. Use for a scoped ask that names this dimension — "tighten the layout", "fix the hierarchy", "the visual hierarchy is weak", "the density is off", "these cards should be a list". Bare "hierarchy" and "visual hierarchy" are layout's. NOT for a whole-page review with no dimension named (that is critique); NOT for a named structural change or a brand-new page (that is design). Visual styling — spacing tokens, type, colour — goes to polish (including type/weight hierarchy), wording to copy, motion to motion.

Polish a NAMED visual dimension of an existing Teacher & School product page — spacing, type, radius, colour, shadow, or type/weight hierarchy (SLP-6). Use only when the ask names such a dimension — "polish the spacing", "tighten the type", "the colours look off", "the headings don't stand out from the body". NOT for a bare "polish / tidy / clean up the page (or screen)" with no visual dimension named — that general, dimensionless polish is critique's whole-page job, so route it to critique. NOT for a named structural or component change — that is design. Visual or page hierarchy — what draws the eye (emphasis, size, position, grouping) — is layout's; polish only touches type/weight hierarchy. Layout structure goes to layout, wording to copy, animation to motion.

Start here — orientation, a quick context check, and routing to the right TFX skill.

Smooth the motion on an existing Teacher & School product page — transitions, easing, timing, and reduced-motion. Use for a scoped ask that names this dimension — "smooth the animations", "the motion feels janky", "the transitions are too slow", "fix the animation on <page>" — with no structural change named. NOT for a whole-page review with no dimension named (that is critique); NOT for a named change like adding a new transition or interaction (that is design). Styling goes to polish, layout to layout.

How to read, filter, apply, and grow the design standards control catalog. Use when applying controls from standards/catalog.yaml, answering any waiver question about a specific control ("can I waive TOK-1?", who must approve, what the tier allows), deciding whether a control applies to a given case, writing a tfx-waive line, or proposing a new control after a failure. Do not answer waiver or applicability questions from memory or summaries — load this skill. Not needed for plain definition lookups (e.g. what a tier name means) that the always-on project rules already answer. This is the catalog-mechanics reference, not the design loop — to design or change a page use design (which loads this skill itself).

Set up a person's machine for the TFX design harness, and orient someone new to it. Two jobs: (1) install and verify the per-user tools the loop relies on — the agent-browser capture CLI + skill, an authenticated gh for feedback issues, Python + PyYAML for the checks — and optionally seed a product's DESIGN.md context layer; (2) orient a newcomer. Use to set up, install, or fix that tooling ("set up the harness", "install the harness dependencies", "agent-browser isn't installed"), or when someone asks to be onboarded to or taught the harness itself ("onboard me", "I'm new to the harness", "how do I use this harness", "teach me the loop"). NOT for designing or changing a page, screen, form, or component; those always go to design, even when phrased as "how do I…". NOT for repo-level harness adoption — stack, manifest, record locations, the L1 approver; that is the team onboarding guide.

Capture feedback about the TFX design harness itself — a confusing skill or gate, a check that flagged wrongly or is missing, a process or onboarding gap — and file it as a `[harness-feedback]` GitHub issue on the harness repo. Use when the user gives such feedback in ANY session, including mid-task while another skill is running, or asks to "file this as harness feedback". NOT for feedback about a product's design or page (that is design-loop material), and NOT for proposing a new catalog control (that is the ratchet, via the standards skill).