@harness-engineering/cli 1.23.2 → 1.24.1

package/dist/agents/skills/cursor/ux-confirmation-dialogs/SKILL.md

@@ -0,0 +1,156 @@
+# Confirmation Dialog Copy
+
+> Confirmation dialogs — destructive action writing, consequence clarity, and specific button labels that make irreversibility unmistakable
+
+## When to Use
+
+- Writing delete, remove, cancel, or disconnect confirmation dialogs
+- Creating copy for permanent data loss scenarios (account deletion, data purges)
+- Writing billing change and subscription cancellation confirmations
+- Confirming permission escalations, role changes, or access removals
+- Writing copy for any action where the primary button triggers an irreversible state
+- NOT for: informational modals that require no decision (see ux-notification-copy)
+- NOT for: non-destructive save confirmations where no data is at risk
+- NOT for: feature announcements or onboarding prompts (see ux-onboarding-copy)
+
+## Instructions
+
+1. **Title the dialog with the specific action and object — never "Are you sure?"** "Delete Project?" names the action (delete) and the object (project). "Are you sure?" forces the user to remember what they were doing. "Are you sure you want to continue?" is even worse — it names neither the action nor the object. Stripe: "Cancel subscription?" GitHub: "Delete this repository?" Linear: "Archive this issue?" Every confirmation dialog title should be answerable by reading only the title, without reading the body text. The title is a statement of intent; "Are you sure?" is a statement of uncertainty.
+
+2. **Write the body in one sentence that names the object and states reversibility.** "This will permanently delete 'Acme Dashboard' and all its contents. This action cannot be undone." Two sentences, one purpose: consequence and reversibility. Name the specific object (not "the project" but "'Acme Dashboard'"). State whether the action is reversible immediately and unambiguously. Never pad with pleasantries ("We're sorry to see you go"), unnecessary legal language, or hedged consequences ("may result in some data being removed"). The body has one job: make the consequence unmistakable so the user can make an informed decision.
+
+3. **Primary button uses the destructive verb — never "OK" or "Yes."** "Delete project" on the destructive button makes the consequence explicit. "OK" on the same button means the user must remember what they were confirming. "Yes" is even worse — it answers a question ("Are you sure?") when the question itself is the problem. GitHub: "Delete this repository" in red. Stripe: "Cancel subscription" in red. Notion: "Delete page" in red. Linear: "Archive issue" in red. The primary button's label should be derivable from the dialog title: if the title is "Delete project?", the button is "Delete project." The exact match between title and button reinforces the action.
+
+4. **Secondary button offers the safe path with a meaningful label.** "Keep project" (not "Cancel") communicates that the user is choosing to preserve the object, not just dismissing a dialog. "Cancel" is ambiguous — cancel the dialog? Cancel the action? Cancel the subscription? Use the object in the secondary button when possible: "Keep project," "Keep subscription," "Keep my account." When the object is obvious and "Cancel" is unambiguous in context, "Cancel" is acceptable for lower-stakes dialogs. But for data loss scenarios, name the preservation action explicitly: the user should feel that clicking the secondary button is a positive choice, not an escape.
+
+5. **Never use Yes/No — both buttons must describe the outcome.** "Are you sure? [Yes] [No]" requires the user to hold the question in working memory while scanning for the correct button. "Delete project? [Delete project] [Keep project]" is self-contained. Both buttons describe what will happen if clicked, not whether the user consents to the question. GitHub, Stripe, and Notion all use this pattern consistently across every destructive dialog. The test: cover the dialog title with your hand. Can you tell from the button labels alone what clicking each button will do? If not, the labels need rewriting.
+
+6. **Add friction proportional to consequence.** Low-consequence reversible actions: a single confirmation click is sufficient. High-consequence irreversible actions: require the user to type the object name before enabling the destructive button. GitHub's repository deletion requires typing the exact repository name. Heroku's app deletion requires typing the app name. This "type to confirm" pattern serves two purposes: it ensures the user has read the dialog and thought about what they are doing, and it provides a technical safeguard against accidental clicks. The friction level is the product's judgment about how serious a mistake this action would be.
+
+7. **Avoid false urgency — the title's severity should not be amplified by unnecessary warnings.** If the title says "Delete project?" and the body says "This will permanently delete 'Acme Dashboard'," adding a header that says "WARNING" or "DANGER" adds visual noise without new information. The title and body already communicate severity. GitHub does not use warning headers in its repository deletion dialog — the specificity of the content ("All forks, pull requests, issues, and wikis will be deleted") conveys the severity without visual amplification. False urgency habituates users to ignoring severity signals.
+
+8. **For reversible destructive actions, lead with the recovery path.** If a deleted item goes to trash and can be restored for 30 days, say so in the body: "Moved to Trash. You can restore it within 30 days." This transforms a destructive confirmation into a safety net disclosure. Notion's page deletion: "This page and all subpages will be moved to Trash. You can restore them from Trash within 30 days." The reversibility note changes the emotional register from urgent-irrevocable to careful-recoverable. For truly irreversible actions, the body should never suggest reversibility — even hedged language like "this is difficult to undo" understates the reality.
+
+## Details
+
+### Dialog Anatomy
+
+A well-written confirmation dialog has four elements in order:
+
+| Element          | Length        | Pattern                                | Example                                                                              |
+| ---------------- | ------------- | -------------------------------------- | ------------------------------------------------------------------------------------ |
+| Title            | 3-8 words     | Verb + object + ?                      | "Delete 'Acme Dashboard'?"                                                           |
+| Body             | 1-2 sentences | Consequence + reversibility            | "This will permanently delete the project and all 47 issues. This cannot be undone." |
+| Primary button   | 2-3 words     | Destructive verb + object, red styling | "Delete project"                                                                     |
+| Secondary button | 1-3 words     | Safe preservation verb or "Cancel"     | "Keep project"                                                                       |
+
+Optional elements:
+
+- **Type-to-confirm field:** For irreversible, high-consequence actions. Appears between body and buttons.
+- **Checkbox confirmation:** "I understand this cannot be undone." For billing and account changes.
+- **Item count:** "Delete 47 issues?" when the scope extends beyond the named object.
+
+### Friction Calibration Matrix
+
+Match the friction level to the severity of the consequence:
+
+| Consequence Level | Data Risk     | Reversible? | Friction Pattern                        | Example                                |
+| ----------------- | ------------- | ----------- | --------------------------------------- | -------------------------------------- |
+| Low               | None          | Yes         | Single button click                     | "Archive issue" confirmation           |
+| Medium            | Some          | Partially   | Confirmation dialog with specific body  | "Remove team member" with body text    |
+| High              | Significant   | No          | Dialog + checkbox or typed confirmation | "Delete organization" with checkbox    |
+| Critical          | All user data | No          | Dialog + type-to-confirm                | "Delete account" requiring email typed |
+
+Never apply critical-tier friction to low-consequence actions — it trains users to dismiss high-friction patterns. GitHub uses type-to-confirm only for repository, organization, and account deletion — not for closing issues or removing labels.
+
+### Type-to-Confirm Implementation
+
+The type-to-confirm pattern requires the user to type a specific string before the destructive button activates:
+
+- **What to require:** The object's name (repository name, project name, account email).
+- **Case sensitivity:** Match exactly — "MyProject" not "myproject" — to ensure intentionality.
+- **Instruction copy:** "To confirm deletion, type the project name below:" — clear, imperative, no ambiguity.
+- **Placeholder:** Show the exact string required: "Acme Dashboard" as placeholder text.
+- **Button state:** Destructive button disabled until the field matches exactly, then enables.
+
+GitHub's implementation is the reference: "To confirm, type the name of your repository:" followed by an input field. The button activates only when the exact repository name is typed. This pattern makes accidental deletion essentially impossible.
+
+### Anti-Patterns
+
+1. **The Generic OK.** "Delete project? [OK] [Cancel]" — the primary button says "OK" instead of "Delete project." The user must remember what they are confirming. On mobile, where buttons are large and muscle memory drives tapping, "OK" is particularly dangerous. Stripe found that replacing "OK" with the specific action verb in destructive dialogs reduced accidental confirmations by a measurable margin. Every confirmation dialog in production should be audited for "OK" as the primary action button.
+
+2. **The Yes/No Dialog.** "Are you sure you want to delete this project? [Yes] [No]" — requires working memory to parse. Cover the question. Which button deletes? Which button saves? Neither label is independently comprehensible. The yes/no pattern forces the user to re-read the question to understand each button, doubling the cognitive load of every destructive action. The fix is always: replace the question with a specific title, replace Yes/No with specific action verbs.
+
+3. **The Wall of Warnings.** A dialog title that says "Are you sure?" followed by three paragraphs of legal language, a bulleted list of consequences, a privacy policy excerpt, and then the buttons. The user abandons reading after the second sentence. Key information — especially irreversibility — gets buried. Confirmation dialogs should be scannable in under 3 seconds. The body must contain exactly one sentence of consequence and one sentence of reversibility (or absence of reversibility). Everything else is noise that reduces the signal of the truly important information.
+
+4. **The Ambiguous Title.** "Remove member?" when the question is whether to remove from a project or from the entire organization. "Delete?" with no object. "Confirm action?" with maximum ambiguity. The title must name both the action and the affected object so the user can answer the dialog title as a yes/no question with full information. "Remove Jordan from Acme Dashboard?" is unambiguous. "Remove member?" requires the user to figure out the scope.
+
+### Real-World Examples
+
+**GitHub's Repository Deletion Dialog.** The gold standard for destructive confirmation copy. Title: "Are you absolutely sure?" — a rare acceptable departure from the recommended pattern because GitHub immediately follows with a specific body that names every consequence. Body: "Unexpected bad things will happen if you don't read this!" — then lists: loss of all forks, issues, wikis, stars, and watching users. Type-to-confirm: "To confirm, type the name of your repository:" followed by an input. The primary button "I understand the consequences, delete this repository" is unusually long but is justified by the severity. GitHub's approach for repositories is deliberately maximalist — it should be uncomfortable to delete a repository.
+
+**Stripe's Subscription Cancellation Dialog.** Stripe: "Cancel subscription?" with body "Your [Plan] plan will be canceled at the end of the current billing period on [date]. You'll lose access to [features]." The specific date and the specific lost features make the consequence tangible. Primary button: "Cancel subscription" in red. Secondary: "Keep my subscription." Stripe's decision to say "Keep my subscription" rather than just "Cancel" on the secondary button is deliberate — it frames the safe choice as a positive action, not a dismissal. The billing date anchors the consequence in time.
+
+**Linear's Issue Archive Confirmation.** Linear uses a minimal confirmation for archiving: "Archive 'Issue #123: Improve dashboard performance'?" with body "Archived issues can be restored from the archive." Primary: "Archive issue." Secondary: "Cancel." The reversibility note ("can be restored") changes the emotional register — this is not a destructive action in the true sense, so the friction level is appropriately low. Linear does not require type-to-confirm for archiving because the consequence is recoverable. The friction calibration is proportional to the actual risk.
+
+**Notion's Page Deletion.** Notion shows: "Delete page?" with body "This page and all of its subpages will be moved to Trash. You can restore them within 30 days." Primary button: "Delete page." Secondary: "Keep it." The "Keep it" secondary button is informal and conversational — appropriate for Notion's warm voice. The 30-day restoration window is stated in the body, not in a tooltip or footnote, because it is the most important piece of information for the user's decision. Notion's deletion is recoverable, so the body leads with the recovery path rather than the loss.
+
+## Source
+
+- NNGroup — "Confirmation Dialog Design" (2022), https://www.nngroup.com/articles/confirmation-dialog/
+- Apple Human Interface Guidelines — Alerts, https://developer.apple.com/design/human-interface-guidelines/alerts
+- Google Material Design — Dialogs, https://m3.material.io/components/dialogs/guidelines
+- Yifrah, K. — _Microcopy: The Complete Guide_ (2017), confirmation and destructive action patterns
+- Podmajersky, T. — _Strategic Writing for UX_ (2019), destructive action writing
+- GitHub Design — Repository deletion pattern, https://github.com/
+
+### Confirmation Dialogs for Bulk Actions
+
+Bulk actions (delete 47 issues, archive all projects, remove all team members) require confirmation copy that communicates scope, not just action:
+
+- **Title:** Include the count. "Delete 47 issues?" not "Delete issues?" — the scope changes the decision.
+- **Body:** List what will be affected. "This will permanently delete 47 open issues and their associated comments."
+- **Primary button:** Include the count in the action when possible. "Delete 47 issues" not just "Delete all."
+- **Irreversibility:** State it explicitly if any part of the bulk action cannot be undone.
+
+When a bulk action contains both reversible and irreversible items, call out the irreversible portion specifically: "3 of the 47 issues are already linked to external trackers and cannot be recovered after deletion."
+
+## Process
+
+1. Identify the consequence level (low/medium/high/critical) using the friction calibration matrix.
+2. Write the title as "Verb + specific object + ?" — confirm it names both the action and what it acts on.
+3. Write the body: consequence in one sentence, reversibility (or its absence) in one sentence.
+4. Write the primary button label by copying the verb-object from the title.
+5. Write the secondary button label as the preservation action ("Keep [object]") or "Cancel" for lower-stakes dialogs.
+6. If consequence level is high or critical, add type-to-confirm or checkbox confirmation before the buttons.
+
+### Confirmation Dialog Copy Review Checklist
+
+Before shipping a destructive confirmation dialog, verify each item:
+
+| Check                                   | Pass Criteria                                                 |
+| --------------------------------------- | ------------------------------------------------------------- |
+| Title names action and object           | Not "Are you sure?" — includes specific verb and object name  |
+| Body states consequence in one sentence | Names what will be lost or changed, and is reversible or not  |
+| Primary button uses destructive verb    | Not "OK," "Yes," or "Confirm" — mirrors the title's verb-noun |
+| Primary button styled destructively     | Red or error color — visually distinct from secondary         |
+| Secondary button names the safe path    | "Keep [object]" or "Cancel" — not "No"                        |
+| Friction level matches consequence      | Type-to-confirm for critical/irreversible actions             |
+| No false urgency headers                | No "WARNING" header when title already conveys severity       |
+| Reversible actions say so               | "Moved to Trash. Restore within 30 days." in body text        |
+
+Confirmation dialogs are the last line of defense before irreversible actions. A dialog with "Are you sure? [OK] [Cancel]" provides almost no protection — users dismiss it on reflex. A dialog with "Delete 'Acme Dashboard'? [Delete project] [Keep project]" requires genuine engagement because both buttons are meaningful.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- Dialog titles name the specific action and object — no "Are you sure?" without an object.
+- Body text states the consequence in one sentence and reversibility in one sentence.
+- Primary button uses the destructive verb from the title — no "OK," "Yes," or "Confirm."
+- Secondary button names the safe path — "Keep project" or "Cancel," not "No."
+- Friction level matches consequence level: type-to-confirm for irreversible, high-consequence actions.
+- No false urgency headers ("WARNING," "DANGER") when the title and body already convey severity.

package/dist/agents/skills/cursor/ux-confirmation-dialogs/skill.yaml

@@ -0,0 +1,33 @@
+name: ux-confirmation-dialogs
+version: "1.0.0"
+description: Confirmation dialogs — destructive action writing, consequence clarity, and specific button labels that make irreversibility unmistakable
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - ux-destructive-action-copy
+  - ux-button-cta-copy
+  - ux-microcopy-principles
+stack_signals: []
+keywords:
+  - confirmation-dialog
+  - destructive-action
+  - modal-copy
+  - button-labels
+  - irreversibility
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/ux-content-hierarchy/SKILL.md

@@ -0,0 +1,150 @@
+# Content Hierarchy in UI
+
+> Content hierarchy in UI — heading structure, progressive disclosure in text, inverted pyramid for interface writing
+
+## When to Use
+
+- Structuring settings pages with dozens of options across multiple categories
+- Organizing help documentation, FAQ sections, and knowledge bases within the app
+- Designing multi-step forms and wizards with clear progress and section breaks
+- Creating dashboard layouts where text labels, descriptions, and metadata coexist
+- Writing feature announcements, changelogs, and release notes within the product
+- Structuring onboarding flows that introduce features progressively
+- Reviewing existing pages where users report difficulty finding information
+- Designing error pages and system status pages with structured recovery paths
+- Organizing notification centers and activity feeds with clear temporal and categorical grouping
+- NOT for: visual hierarchy decisions like spacing, font size, and color -- that is design, not content
+- NOT for: navigation architecture and sitemap structure -- that is information architecture
+
+## Instructions
+
+1. **Apply the inverted pyramid to every text block.** The inverted pyramid, borrowed from journalism, places the most important information first and the supporting details after. In UI, this means every paragraph, tooltip, and description should lead with the conclusion. Notion's billing page leads with "Your workspace is on the Free plan" -- the essential fact -- then follows with details about what that means (limits, upgrade options). If the user reads only the first sentence and stops, they should have the key information. Stripe's error messages follow this structure: "Your card was declined" (the conclusion) then "Try a different payment method or contact your bank" (the supporting action).
+
+2. **Heading levels must match content hierarchy -- never skip levels.** Headings are the outline of the page. An H1 is the page title. H2s are major sections. H3s are subsections within H2s. Skipping from H1 to H3 creates a broken outline that confuses both screen readers and sighted users who scan headings. GitHub's repository settings page demonstrates correct heading hierarchy: "Settings" (H1), "General" (H2), "Repository name" (H3), "Default branch" (H3). Each level nests logically within the one above it. The heading structure should make sense if you read nothing but the headings -- it should be a complete table of contents.
+
+3. **Use progressive disclosure for complexity.** Show the simple version first and let users expand for details. This reduces cognitive load for users who need the basics and provides depth for users who need the details. GitHub's pull request diff view collapses large file diffs with a summary: "+47 -12" tells the user the scope without forcing them to see every line. Clicking expands the full diff. Stripe's dashboard shows transaction summaries with expandable details. The principle: the default view shows what 80% of users need, and the expanded view shows what the remaining 20% need.
+
+4. **Front-load the conclusion in every paragraph.** The first sentence of any paragraph should be independently useful. If a user reads only the first sentence and moves on, they should have the key takeaway. This is the inverted pyramid applied at the paragraph level. In a settings description, "Notifications are sent by email" should come before "You can configure notification frequency, choose specific events, and set quiet hours." The first sentence answers the immediate question. The second sentence provides options for users who want to customize.
+
+5. **Group related items under clear category labels.** A flat list of 30 settings is overwhelming. Grouped into categories -- "Account," "Billing," "Notifications," "Security," "Integrations" -- the same 30 settings become navigable. Each category label should be a noun or noun phrase that names the domain, not a verb that names an action. GitHub's settings use noun categories: "General," "Access," "Code and automation," "Security." Slack's preferences group by domain: "Notifications," "Sidebar," "Themes," "Messages & media." The category labels serve as landmarks that allow users to skip entire sections.
+
+6. **Use the three-level rule.** If content goes deeper than three levels of nesting, the structure needs to be redesigned. Three levels is the cognitive limit for most users: section, subsection, item. A settings page with "Account > Security > Two-factor authentication > Recovery codes > Download format" has five levels -- the user is lost. The fix: flatten the hierarchy by promoting deeply nested items to their own section, or use sequential navigation (step 1, step 2, step 3) instead of nested hierarchy. Apple's iOS Settings app follows the three-level rule: "Settings > Privacy & Security > Location Services" is three levels. Individual app permissions are presented as a flat list at the third level, not nested further.
+
+7. **Differentiate primary, secondary, and tertiary content with distinct text patterns.** Every page has content at three importance levels. Primary content is what the user came for: the main heading, the key data, the primary action. Secondary content supports the primary: descriptions, helper text, metadata. Tertiary content is contextual: timestamps, version numbers, fine print. Distinguish these levels with consistent text patterns: bold for primary terms, regular weight for descriptions, muted color for metadata. Linear differentiates cleanly: issue title is bold and prominent, description is regular weight, and metadata (assignee, priority, labels) is smaller and muted.
+
+8. **Write headings as standalone signposts.** Every heading should make sense without reading the content below it. "Overview" is too vague -- an overview of what? "Project settings" is clear. "Next steps" is vague -- steps for what? "Set up your first project" is actionable and specific. Headings are the most-read text on any page because users scan headings to decide where to focus. A heading that requires the user to read the following content to understand it has failed as a signpost. Stripe's documentation headings are models: "Create a payment intent," "Handle post-payment events," "Test your integration" -- each heading tells the user exactly what the section covers.
+
+## Details
+
+### Heading Hierarchy Patterns for Common Page Types
+
+**Settings pages.** H1: Page title ("Settings"). H2: Category ("Notifications"). H3: Individual setting ("Email notifications"). Under each H3, the setting control with a one-sentence description. This pattern scales from 5 settings to 50 settings by adding H2 categories.
+
+**Onboarding flows.** H1: Welcome message ("Welcome to Acme"). H2: Step label ("Step 1: Create your workspace"). Under each H2, a brief instruction and a primary action. Progress indicators supplement the heading hierarchy by showing position in the overall flow.
+
+**Help and documentation pages.** H1: Topic title ("Getting started"). H2: Task ("Create your first project"). H3: Subtask or concept ("Choose a template"). The heading hierarchy should map to the user's mental model of the task, not to the product's internal structure.
+
+**Dashboard layouts.** H1: Dashboard name (often implicit or in the page title). H2: Widget or section title ("Recent activity," "Usage this month"). Under each H2, the data visualization or list. Dashboard headings should name the data domain, not the visualization type -- "Revenue this month" not "Bar chart."
+
+### Progressive Disclosure Decision Framework
+
+Use progressive disclosure when any of these conditions are true:
+
+- The content serves two audiences with different expertise levels (new users vs. power users)
+- The full content is longer than three sentences or five items
+- The content is needed by less than 50% of users viewing the page
+- The content is contextual and only relevant after the user has taken a specific action
+
+Do not use progressive disclosure when:
+
+- The content is essential for all users (critical warnings, primary instructions)
+- Hiding the content creates a false sense of simplicity that leads to errors
+- The disclosure mechanism (expand/collapse) adds more interaction cost than reading the content
+
+GitHub's repository creation form demonstrates correct progressive disclosure: basic fields (name, visibility) are always visible; advanced options (description, README, .gitignore, license) are collapsed under "Add a README file" and "Choose a license." The basic form serves 80% of use cases; the expanded form serves the remaining 20%.
+
+### The Hierarchy Audit
+
+To audit an existing page for content hierarchy issues, perform the following steps:
+
+1. **Extract all headings.** List every heading on the page in order. Read them as a standalone outline. If the outline does not make sense, the hierarchy is broken.
+2. **Check heading levels.** Verify that no level is skipped. An H3 must be preceded by an H2, not directly by an H1.
+3. **Measure text block lengths.** Flag any paragraph longer than three sentences in UI context. Flag any list longer than seven items without subcategories.
+4. **Identify buried leads.** For each text block, check whether the first sentence contains the most important information. If the conclusion is in the last sentence, the block needs to be restructured.
+5. **Count nesting levels.** Trace the deepest path through the page's hierarchy. If any path exceeds three levels, the hierarchy needs to be flattened.
+6. **Test progressive disclosure placement.** For each collapsed or hidden section, estimate the percentage of users who need that content. If more than 50% need it, it should be visible by default.
+
+This audit can be performed on paper in 10-15 minutes and catches the most common hierarchy problems before users encounter them.
+
+### Whitespace as Structure
+
+Whitespace is not the absence of content -- it is structural content. A blank line between two paragraphs signals "new topic." A larger gap between sections signals "new category." Without whitespace, even well-structured content feels like a wall of text.
+
+Principles for whitespace in content hierarchy:
+
+- **Intra-group spacing** (between items in the same group): small, consistent gap. All settings within "Notifications" have the same vertical spacing between them.
+- **Inter-group spacing** (between different groups): larger gap, often with a heading or divider. The gap between "Notifications" and "Security" is visibly larger than the gap between individual notification settings.
+- **Section spacing** (between major sections): largest gap, always with a heading. The gap between "Account" and "Billing" is the largest on the page.
+
+Stripe's settings page uses three distinct spacing levels that visually communicate the hierarchy without the user consciously noticing. The spacing does the grouping work that headings alone cannot.
+
+### Content Grouping Strategies
+
+**Alphabetical grouping.** Best for large reference lists where users know the name of what they are looking for. Settings A-Z, country lists, API endpoint directories.
+
+**Task-based grouping.** Best for action-oriented pages where users are trying to accomplish something. "Create," "Manage," "Monitor" groups on an admin dashboard.
+
+**Frequency-based grouping.** Best for settings and preferences. Most-changed settings at the top, rarely-changed settings further down. Google's Chrome settings put the most-accessed settings (search engine, appearance, privacy) at the top.
+
+**Lifecycle grouping.** Best for onboarding and process flows. Items ordered by the sequence in which users encounter them. "Set up account," "Create first project," "Invite team members."
+
+### Anti-Patterns
+
+1. **The Flat Wall.** A page with no headings, no sections, and no visual grouping -- just a continuous stream of text or a flat list of items. A settings page with 40 toggles in a single scrollable list. A help page with 15 paragraphs and no headings. The user cannot scan, cannot skip, and cannot find what they need without reading everything. The fix: group items into categories of 3-7 items each, add a heading to each category, and add whitespace between categories. The grouping can be functional (by what the setting controls) or alphabetical -- either is better than no grouping.
+
+2. **The Deep Nest.** Content nested four or more levels deep. A settings drawer that opens a panel that contains a section that has a subsection. The user loses context about where they are and how to get back. Breadcrumbs help but do not solve the root problem: the hierarchy is too deep. The fix: flatten the hierarchy by promoting deeply nested items to their own page or section. If "Account > Security > Two-factor authentication > Recovery codes" is too deep, give recovery codes their own top-level section under Security.
+
+3. **The Buried Lead.** Placing the most important information at the bottom of a text block, after context and caveats. "We've been working hard to improve your experience, and after careful consideration and extensive testing, we're excited to announce that starting next month, prices will increase by 20%." The price increase -- the only information the user cares about -- is buried after 30 words of filler. The fix: lead with the conclusion. "Prices increase 20% starting May 1. Here's what changes for your plan."
+
+4. **The Misleading Heading.** A heading that does not accurately describe its content. A section titled "Getting Started" that actually contains billing information. A heading "Overview" that is actually a detailed technical specification. Misleading headings are worse than no headings because they cause the user to skip content they need or read content they do not need. The fix: write headings after writing the content, not before. The heading should be a summary of what follows.
+
+### Real-World Examples
+
+**GitHub's Repository Settings Hierarchy.** GitHub's repository settings page is a masterclass in content hierarchy at scale. The page contains over 50 settings, organized into five H2 categories: "General," "Access," "Code and automation," "Security," and "Integrations." Within each category, individual settings have H3 headings with concise descriptions. Dangerous settings (delete repository, change visibility) are visually separated at the bottom of the "General" section with red borders. Progressive disclosure hides advanced options: branch protection rules expand to show pattern matching only when the user creates a rule. The hierarchy allows a user to find any specific setting within two or three scans of headings.
+
+**Stripe's Dashboard Content Organization.** Stripe's dashboard organizes dense financial data using strict content hierarchy. The top level shows summary metrics: total volume, successful payments, dispute rate. Each metric links to a detail view with transaction-level data. The left navigation groups by domain: "Payments," "Customers," "Products," "Billing," "Connect." Within each section, the hierarchy follows the same pattern: summary at the top, filterable list in the middle, and individual item detail at the bottom. This consistent three-level pattern (summary, list, detail) means that once a user learns the hierarchy for Payments, they already know the hierarchy for Customers, Products, and every other section.
+
+**Linear's Issue Detail Progressive Disclosure.** Linear's issue detail page demonstrates progressive disclosure applied to a single item. The primary content is the issue title and description, displayed prominently. Secondary content -- assignee, priority, labels, project -- is displayed as compact metadata chips on the right sidebar. Tertiary content -- activity log, sub-issues, relations -- is organized in tabs below the description. The user sees the essential information immediately (title, description, status), can scan the metadata without scrolling (sidebar), and can dive into history and context on demand (tabs). Nothing is hidden that should be visible, and nothing is visible that should be hidden.
+
+## Source
+
+- NNGroup -- "Information Scent: How Users Decide Where to Go Next" (2003), evidence for heading-based navigation
+- Krug, S. -- _Don't Make Me Think_ (2014), chapter 7 on content hierarchy and scanning
+- Inverted pyramid from journalism -- AP Stylebook, applied to interface writing
+- Apple Human Interface Guidelines -- Layout and Organization, progressive disclosure patterns
+- Google Material Design -- Content structure and hierarchy, https://m3.material.io/foundations/content/overview
+- NNGroup -- "Progressive Disclosure" (2006), research on cognitive load reduction through staged complexity
+- Weinschenk, S. -- _100 Things Every Designer Needs to Know About People_ (2011), grouping and chunking research
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Outline the page structure using headings before writing any body content.
+3. Apply the inverted pyramid to every text block -- most important information first.
+4. Group related items into categories of 3-7 and apply progressive disclosure where appropriate.
+5. Verify your implementation against the anti-patterns listed above.
+
+## Harness Integration
+
+- **Type:** knowledge -- this skill is a reference document, not a procedural workflow.
+- **No tools or state** -- consumed as context by other skills and agents.
+
+## Success Criteria
+
+- Every page has a clear heading hierarchy that makes sense when read as a standalone outline.
+- No heading level is skipped (no H1 to H3 without an H2).
+- The inverted pyramid is applied -- the first sentence of every text block is independently useful.
+- Settings and options are grouped into categories of 3-7 items with clear category labels.
+- Content nesting never exceeds three levels.
+- Progressive disclosure is used for content needed by less than 50% of users.
+- Whitespace communicates structure -- intra-group, inter-group, and section spacing are visually distinct.

package/dist/agents/skills/cursor/ux-content-hierarchy/skill.yaml

@@ -0,0 +1,33 @@
+name: ux-content-hierarchy
+version: "1.0.0"
+description: Content hierarchy in UI — heading structure, progressive disclosure in text, inverted pyramid for interface writing
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - ux-writing-for-scanning
+  - ux-microcopy-principles
+  - design-information-architecture
+stack_signals: []
+keywords:
+  - content-hierarchy
+  - headings
+  - progressive-disclosure
+  - inverted-pyramid
+  - information-architecture
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/ux-data-table-copy/SKILL.md

@@ -0,0 +1,154 @@
+# Data Table Copy
+
+> Data table copy — column headers, empty cells, truncation patterns, filter and sort labels, bulk action copy
+
+## When to Use
+
+- Writing column headers for any tabular data view: issue lists, transaction tables, user rosters, audit logs
+- Defining empty cell conventions across a table or design system
+- Building filter interface labels and filter chip copy
+- Writing bulk action patterns for selected rows
+- Designing sort controls and accessible sort indicators
+- Handling empty table states (zero rows, filtered-to-zero, loading, error)
+- NOT for: forms with multiple fields (use ux-form-labels)
+- NOT for: single-item detail pages and record views
+- NOT for: card-based layouts where each item is a distinct visual unit
+
+## Instructions
+
+1. **Column headers use nouns or short noun phrases -- not verb phrases or full sentences.** A column header is a label for a category of data, not a sentence describing the data. "Status" not "Current status of the item." "Assigned to" not "Who this is assigned to." "Last modified" not "Date this was last modified." Linear's issue list uses "Priority," "Status," "Assignee," "Due date" -- each a precise noun phrase. The test: read the column header and ask whether the column contains instances of that noun. If yes, the header is correct. If the answer is "the column contains information about [noun]," the header is too verbose. Audit every header in the table before shipping and enforce the noun-phrase rule at the design-system level so that new columns default to the correct form.
+
+2. **Align the grammatical form of the header with the content of its cells.** A column header and its cell values should form a coherent pair when read together. A boolean column with "Yes/No" values should be headed "Active" not "Is active?" (the question form implies a boolean, but the interrogative is unnecessary). A column with date values should be headed "Created" not "Created on" (the preposition is implied by the date format). Stripe's transaction table uses "Amount" over currency values, "Status" over "Pending/Succeeded/Failed," and "Description" over merchant names -- each header matches the semantic type of its values. Mismatched headers and cell types create a cognitive mismatch that slows scanning and increases error rates when users copy or compare values across rows.
+
+3. **Truncate long text with an ellipsis and reveal the full value on hover -- never silently cut data.** When cell content exceeds the column width, truncation is necessary, but silent truncation (cutting the string with no indicator) is a data integrity problem. The user cannot tell whether the value ends at the visible characters or continues. Use trailing ellipsis (`...`) as the truncation indicator, and show the full value in a tooltip on hover. For critical data fields like names, URLs, or identifiers, consider making the column resizable. GitHub's pull request title column truncates long titles with `...` and shows the full title in a tooltip. Airtable uses truncation with an expand control to view the full cell value. Establish truncation rules per column in the component spec: some columns (like "Description") tolerate aggressive truncation, while identifier columns ("Repository name") should expand to show the full value before truncating.
+
+4. **Empty cells use an em dash (--) not "N/A," "None," "null," or a blank space.** "N/A" means not applicable -- but most empty cells are simply unpopulated, not inapplicable. "None" is ambiguous: does it mean no value was entered, or was "none" explicitly selected? A blank space is the worst option because the user cannot tell if the cell is empty or if the value is whitespace. The em dash (--) is a neutral, universally understood indicator of absent data. It is visually distinct from actual content without suggesting any semantic meaning about why the data is absent. This convention is used by Stripe, Linear, and GitHub consistently across their data tables. Implement the em dash as a shared cell renderer component so the convention is enforced automatically, rather than depending on individual developers to remember the pattern in every column.
+
+5. **Filter labels use the noun they filter, followed by the current value -- not a verb phrase.** "Status: All" not "Filter by status: All." "Assignee: Anyone" not "Filter assignees." "Date range: This month" not "Filter by date range." The noun identifies what is being filtered; the value shows what is currently active. When no filter is active, use a neutral term: "All," "Anyone," "Any," "All time" -- not "None" (which implies filtering to zero) or leaving the value blank. Linear's filter bar shows "Priority: All," "Status: All," "Assignee: All" -- each filter chip reads as [dimension]: [current value], making the active state unambiguous. When a filter is actively applied and narrows results, the chip should change to a distinct visual state (highlighted, colored, bolded) to signal that the current view is filtered.
+
+6. **Bulk action buttons name both the action and the count of affected items -- never use "Delete selected."** "Delete selected" is ambiguous when the selection count changes. Does "Delete selected" delete 1 item or 100? Make the count explicit: "Delete 3 issues," "Archive 12 transactions," "Export 47 rows." GitHub's bulk actions in issue lists show "Mark as X" with the count in the selection checkbox header. Airtable shows "Delete 5 records" in its bulk action bar. When the count is zero (no selection), the bulk action bar should not appear or all bulk action buttons should be disabled -- never show "Delete 0 items." Update the count in real time as the user changes selection, because a user who selects and deselects items must always know exactly how many items the action will affect before clicking.
+
+7. **Sort direction indicators need accessible text labels in addition to visual arrows.** An up arrow next to a column header is conventionally understood as "sorted ascending" in some contexts and "sorted descending" in others -- the convention is not universal. Use `aria-label` on the sort button to convey both the current sort dimension and direction: "Sorted by Date, newest first" or "Sort by Status, ascending." The visible label can be abbreviated (an arrow icon), but the accessible name must be explicit. Linear's column sort headers announce "Sort by Priority descending" to screen readers even though the visible indicator is an icon. When the user has not set a sort, the default sort state should also be labeled: "Default order: Last modified" tells the user why the current ordering looks the way it does, eliminating confusion when items do not appear in alphabetical or chronological order.
+
+## Details
+
+### Column Header Grammar Reference
+
+Consistency in header grammar prevents the visual noise of mixed grammatical forms across a single table. Choose one pattern and apply it to every column in the table:
+
+| Header Type          | Correct Form                       | Avoid                                            |
+| -------------------- | ---------------------------------- | ------------------------------------------------ |
+| Category noun        | "Status," "Priority," "Type"       | "Item status," "Priority level," "Type of issue" |
+| Possessive attribute | "Owner," "Author," "Assignee"      | "Assigned to," "Owned by"                        |
+| Timestamp            | "Created," "Modified," "Due"       | "Created on," "Last modified date," "Due date"   |
+| Quantity             | "Comments," "Attachments," "Votes" | "Number of comments," "Attachment count"         |
+| Boolean              | "Active," "Public," "Verified"     | "Is active," "Publicly visible," "Is verified?"  |
+| Calculated           | "Progress," "Completion," "Score"  | "Progress percentage," "% complete"              |
+
+For tables with mixed data types (a user roster that has both date columns and category columns), use the per-type conventions above rather than forcing a single grammatical pattern onto all columns.
+
+### Empty State Hierarchy
+
+Data tables have four distinct empty states, each with different copy needs:
+
+1. **First-time empty** -- The user has never added data. Show a call to action: "No issues yet. Create your first issue to start tracking work." Include a primary action button.
+2. **Filter-to-zero** -- Active filters exclude all data. Show the filter context: "No issues match 'Priority: High + Assignee: Jordan'. Clear filters to see all issues." Include a "Clear filters" link.
+3. **Permission empty** -- The user lacks access to view data that exists. Do not show empty state copy; surface the permission state (see ux-permission-access-copy).
+4. **Error empty** -- Data failed to load. Show an error message with retry: "Couldn't load issues. Check your connection and try again." Include a "Retry" button.
+
+Each state requires different copy and different actions. Using a single generic empty state message across all four conditions is the most common data table copy failure.
+
+### Review Checklist
+
+Use this checklist before shipping or reviewing any data table implementation:
+
+| Check           | Criteria                                                                 | Pass Condition                                                  |
+| --------------- | ------------------------------------------------------------------------ | --------------------------------------------------------------- |
+| Column headers  | All headers are noun phrases                                             | No header contains a verb or full sentence                      |
+| Empty cells     | Empty cells use em dash                                                  | No blank cells, no "N/A," no "None," no "null"                  |
+| Truncation      | Overflow text truncates with ellipsis                                    | Full value visible on hover via tooltip                         |
+| Filter labels   | Filter chips use [Dimension]: [Value] format                             | Neutral values ("All," "Anyone") shown when no filter is active |
+| Bulk actions    | Bulk action buttons include item count                                   | Count updates in real time; bar hidden when selection is zero   |
+| Sort indicators | Sort controls have accessible `aria-label`                               | Screen reader announces dimension and direction                 |
+| Empty states    | Four empty states (first-time, filtered, permission, error) are distinct | Each state has unique copy and appropriate CTA                  |
+| Sort defaults   | Default sort state is labeled                                            | User can identify why the current order is the way it is        |
+
+### Anti-Patterns
+
+1. **The Verbose Header.** Column headers that describe rather than name. Before: "Current status of the item," "Date this was last modified," "Who this task is assigned to." After: "Status," "Modified," "Assignee." Verbose headers reduce the column width available for actual data and make the table header row visually dominant over the data rows it should support. Verbose headers also cause horizontal scrolling on smaller viewports -- a direct usability cost in addition to the clarity cost.
+
+2. **The Blank Cell.** Empty cells left blank or filled with "N/A," "None," "null," or "--" (double hyphen). Before: empty string, or "N/A" for an unset due date. After: em dash (--). The em dash is a design system convention, not a character choice left to individual developers. Establish it as a standard and apply it via a shared cell renderer component so the convention is enforced, not remembered. A blank cell is especially problematic in right-aligned numeric columns, where it creates visual alignment gaps that disrupt scanning.
+
+3. **The Silent Truncation.** Text that is cut at the column boundary with no indicator that truncation occurred. Before: "Redesign the user onboarding exp" (cut without indicator). After: "Redesign the user onboarding exp..." (with tooltip showing "Redesign the user onboarding experience for new enterprise customers"). The user must always know that more data exists, and must have a way to see it. Silent truncation in identifier columns (email addresses, repository names, transaction IDs) is particularly harmful because the user may copy the visible text without realizing it is incomplete.
+
+4. **The Ambiguous Bulk Action.** Bulk action buttons that do not state what they will affect. Before: "Delete selected," "Archive selected," "Export." After: "Delete 4 rows," "Archive 4 rows," "Export 4 rows." A secondary issue: bulk action buttons that remain active when nothing is selected, or that show "Delete 0 items" when the selection is cleared. The bulk action bar should appear only when at least one row is selected, and the count should update in real time as the selection changes. Ambiguous bulk actions are the leading cause of accidental bulk data loss in table interfaces.
+
+### Real-World Examples
+
+**Linear issue list columns.** Linear's issue table uses a consistent noun-phrase column convention: "Priority," "Title," "Status," "Assignee," "Due date," "Estimate," "Labels." The most interesting design decision is the "Title" column -- it is wide enough to show most issue titles without truncation, and on overflow it truncates with `...` and shows a popover with the full title and description on hover. The filter bar above the table uses [Dimension]: [Value] chips: "Assignee: Jordan," "Status: In Progress." Clearing all filters shows "Assignee: All," "Status: All" -- the filter UI never disappears, it just returns to its neutral state. Linear's approach of keeping filter chips persistent (always visible, even when neutral) reduces the cognitive load of remembering whether a filter is active.
+
+**GitHub pull request table.** GitHub's PR list table has evolved over a decade into one of the most information-dense data tables in the developer tools space. The key column decisions: "Title" (long, with author, labels, and review status as sub-elements), "Reviewers" (avatars with a count overflow), "Assignees" (same), "Milestone," "Updated" (relative time like "2 hours ago" with absolute time in a tooltip). Empty cells in "Milestone" and "Assignees" are handled with nothing -- not an em dash -- which is a deliberate exception because these fields appear alongside inline "assign" links. The column exception proves the rule: empty cell conventions can be overridden when an inline action replaces the absent value and the user understands they can fill it.
+
+**Stripe transaction list.** Stripe's transaction table is the benchmark for financial data tables. Columns: "Amount" (right-aligned, always showing currency symbol and two decimal places), "Description" (merchant name with logo), "Date" (absolute date with relative time on hover), "Status" ("Succeeded," "Failed," "Pending" as colored badges). The filter UI uses dropdown chips: "Status: All," "Date: Last 30 days," "Amount: Any." The bulk export uses "Export [n] transactions" with the count dynamically reflecting the current filter state -- so exporting a filtered view is always explicit. Empty states distinguish between "No transactions" and "No transactions matching your filters" with different CTAs: "Accept your first payment" vs. "Clear filters."
+
+**Airtable column naming.** Airtable is unique because users name their own columns -- but the product's default field names teach naming conventions. A new table starts with "Name," "Notes," "Assignee," "Status," "Due date" -- all noun phrases. Airtable's column type system enforces grammatical consistency: a date field cannot be named "What date is this due?" without a warning, because the field type renders dates in a specific format that would conflict with the question-form label. The field name conventions are also enforced by the formula system -- fields named with special characters or ambiguous names cause formula errors, creating a technical incentive for clean naming that reinforces the UX convention.
+
+### Copy Formulas Quick Reference
+
+These are fill-in-the-blank templates for the most common data table copy patterns. Use them to generate consistent copy without re-deriving the pattern each time:
+
+- **Column header:** `[Noun phrase]` -- e.g., "Status," "Assignee," "Created," "Progress"
+- **Empty cell:** `--` (em dash, Unicode U+2014)
+- **Truncated cell tooltip:** Full value verbatim -- e.g., "Redesign the user onboarding experience for new enterprise customers"
+- **Filter chip (neutral):** `[Dimension]: All` -- e.g., "Priority: All," "Assignee: Anyone," "Date: All time"
+- **Filter chip (active):** `[Dimension]: [Value]` -- e.g., "Priority: High," "Assignee: Jordan," "Date: This month"
+- **Bulk action:** `[Verb] [N] [noun]` -- e.g., "Delete 4 issues," "Archive 12 rows," "Export 47 transactions"
+- **Sort label (ascending):** `Sorted by [Column], A to Z` or `Sorted by [Column], oldest first`
+- **Sort label (descending):** `Sorted by [Column], Z to A` or `Sorted by [Column], newest first`
+- **First-time empty:** `No [items] yet. [Action] to get started.`
+- **Filter-to-zero empty:** `No [items] match [active filters]. Clear filters to see all [items].`
+- **Error empty:** `Couldn't load [items]. Check your connection and try again.`
+
+## Source
+
+- NNGroup -- "Data Tables: Four Major User Tasks," https://www.nngroup.com/articles/data-tables/
+- Babich, N. -- "Designing Better Data Tables," UX Planet (2017)
+- Google Material Design -- Data tables, https://m3.material.io/components/data-tables/overview
+- W3C WAI -- Tables tutorial, https://www.w3.org/WAI/tutorials/tables/
+- Stripe -- Design system documentation (internal), referenced via public Stripe Docs UI patterns
+- Airtable -- Field naming conventions, https://support.airtable.com/docs/field-types-overview
+
+## Process
+
+1. **Audit all column headers for grammatical form.** List every column in the table. For each, identify the data type (category, timestamp, boolean, quantity, calculated) and rewrite the header to the correct noun-phrase form from the grammar reference. Standardize all headers before writing empty cell or truncation rules, because header grammar affects cell alignment decisions.
+
+2. **Define and implement the empty cell convention.** Choose the em dash as the standard and add it to the design system's shared cell renderer component. Document the convention with code examples so that future developers do not need to remember it. Audit existing table implementations for inconsistent empty cell handling (blank, "N/A," "null") and migrate them to the shared component.
+
+3. **Inventory all text columns that can overflow.** For each column, define: the max character count before truncation, the truncation indicator (trailing ellipsis), and the mechanism for viewing the full value (tooltip on hover, expand control, or resizable column). Write these rules into the component spec so they are enforced at the component level, not decided column by column.
+
+4. **Write filter chip copy using [Dimension]: [Value] format.** For each filterable dimension, define: the chip label, the neutral value (shown when no filter is active), the active value format, and the zero-results copy shown when the filter excludes all data. Confirm that the chip visual state changes between neutral and active so users always know whether a filter is applied.
+
+5. **Write bulk action labels with explicit counts.** For each bulk action (delete, archive, export, assign, move), write the label in the form "[Verb] [N] [noun]" where N is the real-time selection count. Define the selection state that shows vs. hides the bulk action bar (visible when >= 1 row selected, hidden at 0). Confirm the count updates synchronously as rows are checked and unchecked.
+
+## Harness Integration
+
+- **Type:** knowledge -- this skill is a reference document, not a procedural workflow.
+- **No tools or state** -- consumed as context by other skills and agents.
+
+## Success Criteria
+
+- All column headers in the table use noun phrases, not verb phrases or full sentences, and the grammatical form matches the data type in each column's cells.
+- Empty cells use a consistent em dash convention enforced at the component level, with no blank cells, "N/A," "None," or "null" appearing in production.
+- All text truncation shows an ellipsis indicator, the full value is accessible on hover via tooltip, and critical identifier columns (names, IDs, URLs) are never silently cut.
+- Filter labels use the [Dimension]: [Value] format with explicit neutral values when no filter is active, and active filters are visually distinct from neutral ones.
+- Bulk action buttons display the count of affected items in real time and are hidden or disabled when no rows are selected -- "Delete 0 items" never appears.
+- Sort controls include accessible `aria-label` attributes that name both the dimension and direction, and the default sort state is labeled so users understand the initial ordering.
+- All four empty states (first-time, filter-to-zero, permission, error) have distinct copy and appropriate CTAs that do not reuse a single generic message.
+
+## Mobile and Responsive Considerations
+
+Data tables on mobile require copy decisions that do not arise on desktop. When a table reflows to a card or list view on small screens, column headers become inline labels next to each value. The noun-phrase convention remains correct, but the label-value pairing becomes explicit: "Status: In Progress" appears as a labeled row inside a card, not as a column header above a column of values. Write card view labels using the same noun-phrase vocabulary as table headers so the copy is consistent between layouts.
+
+Bulk actions on mobile require a different trigger and label pattern. A floating action bar at the bottom of the screen ("3 selected -- Delete, Archive") is the standard pattern on iOS and Android. The count appears first in the floating bar because it is the primary orientation signal -- the user may not see the checkboxes while reading the action bar. Filter chips on mobile use a horizontal scroll pattern; the [Dimension]: [Value] convention holds, but chip labels must be shorter to avoid overflow at small screen widths. "Assignee: Jordan Chen" may need to truncate to "Assignee: Jordan" or "Assignee: J. Chen" depending on chip width constraints.
+
+Pagination and "load more" copy on mobile tables should follow the same pattern as desktop: show the current count and total when known ("Showing 50 of 230 issues"), and name the increment on "Load more" ("Load 50 more"). Infinite scroll tables without load state indicators create a perception that data is still loading when the table has reached its end -- always show an "All [N] items loaded" message at the scroll terminus.

package/dist/agents/skills/cursor/ux-data-table-copy/skill.yaml

@@ -0,0 +1,34 @@
+name: ux-data-table-copy
+version: "1.0.0"
+description: Data table copy — column headers, empty cells, truncation patterns, filter and sort labels, bulk action copy
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - ux-writing-for-scanning
+  - ux-microcopy-principles
+  - ux-empty-states
+stack_signals: []
+keywords:
+  - data-table
+  - column-headers
+  - truncation
+  - filter-labels
+  - bulk-actions
+  - empty-cells
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []