@harness-engineering/cli 1.24.0 → 1.24.3

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: []

package/dist/agents/skills/cursor/ux-destructive-action-copy/SKILL.md

@@ -0,0 +1,152 @@
+# Destructive Action Copy
+
+> Destructive action copy — irreversibility warnings, undo availability, double-confirmation patterns, cooldown messaging
+
+## When to Use
+
+- Writing delete flows for records, files, repositories, accounts, or workspaces
+- Designing confirmation dialogs for irreversible state changes
+- Building account termination and data deletion flows
+- Creating bulk destructive operation warnings
+- Designing undo and grace period messaging for soft-deletions
+- Writing type-to-confirm patterns for highest-consequence actions
+- NOT for: routine confirmations where the action is easily reversible (use ux-confirmation-dialogs)
+- NOT for: error recovery flows where no deliberate destructive action was taken
+- NOT for: archive or hide actions that preserve data in a recoverable state
+
+## Instructions
+
+1. **State irreversibility explicitly if the action cannot be undone.** Users calibrate their caution based on whether they can recover from a mistake. "This cannot be undone" is not boilerplate -- it is a factual statement about the system's behavior that directly informs the user's decision. When an action is recoverable (soft delete with a 30-day window), say so explicitly: "You can restore this within 30 days." When an action is partially recoverable ("Your repositories will be transferred, but your account data will be deleted immediately"), name the boundary precisely. Never assume the user understands from context whether a destructive action is permanent -- state it plainly at the decision point, not in help documentation they will never read. GitHub's repository deletion dialog says "This action is permanent and cannot be undone." Stripe's subscription cancellation says "Your subscription will end at the end of your billing period -- no further charges."
+
+2. **Name exactly what will be destroyed -- including counts and downstream effects.** Vague destruction warnings undercount the consequences and leave users surprised after the fact. "Delete this workspace" is insufficient. "Delete 'Acme Corp' workspace and its 14 members, 230 projects, and 4,200 tasks -- all data will be permanently deleted" is complete. Linear's team deletion shows: "Deleting this team will permanently delete all issues (47), cycles (8), projects (3), and associated data. Members will lose access immediately." The count is dynamically generated from live data -- what will actually be destroyed is shown, not estimated. Downstream effects (members losing access, integrations disconnecting, billing stopping) are named explicitly so the user can evaluate the full scope of their decision before confirming.
+
+3. **Offer undo where the system technically supports it -- undo transforms dangerous into recoverable.** The single biggest UX improvement for destructive actions is adding a soft-delete grace period and advertising it prominently. "Moved to trash. Undo" in a toast message converts a catastrophic mistake into a three-second fix. The undo affordance must appear immediately, in the user's current view, with a clear action -- not buried in a settings menu or trash view that requires navigation. Google Drive's "Moved to trash" toast with "Undo" has set user expectations across the industry; users now expect undo to exist and are disproportionately frustrated when it does not. If undo is technically possible, implement it and lead the confirmation dialog with that information: "You can undo this from your trash within 30 days." This framing shifts the emotional experience from irreversible loss to managed risk.
+
+4. **Type-to-confirm patterns for highest-consequence actions -- require the exact resource name, not a generic word.** When the consequence of a mistake is catastrophic and irreversible (delete a production database, terminate an organization account, destroy all billing history), a click-to-confirm dialog is insufficient friction. Require the user to type the name of the specific resource being destroyed. This serves two purposes: it ensures the user is present and deliberate (not clicking through a dialog), and it names the specific object one more time, making it impossible to accidentally delete the wrong resource in a list. GitHub requires typing the full repository name: "To confirm, type the name of the repository: [repo-name]." Never require typing a generic word like "DELETE" or "CONFIRM" -- the generic word adds friction without adding specificity, and users memorize the required string ("just type DELETE") rather than engaging with the consequence.
+
+5. **Cooldown copy for async or scheduled deletions -- make the window and cancellation path explicit.** When deletion is not immediate (account deletion with a 30-day recovery period, scheduled data purge, export-then-delete workflow), the copy must communicate three things: when the deletion takes effect, what is accessible during the window, and how to cancel. Google's account deletion page shows: "Your account will be deleted in 30 days. During this time you can sign in to recover your account. After 30 days, your data will be permanently deleted and cannot be recovered." Each sentence answers a different question the user will have. The cancellation path ("sign in to recover") is named as a concrete action, not a vague possibility -- users who discover the grace period after the fact need to know exactly what to do without searching for documentation.
+
+6. **Warn before -- the warning must appear before the point of no return, not after.** A post-deletion "Your account has been deleted" confirmation screen is not a warning -- it is a receipt. The warning belongs at the decision point: the confirmation dialog, the settings page with the delete button, or the preview step in a multi-step deletion flow. For multi-step destructive workflows, warnings should escalate: a mild warning at the initiation step ("This will permanently delete your account"), a stronger warning at the confirmation step (with type-to-confirm and a list of what will be lost), and a final summary before the irreversible action executes. Stripe's subscription cancellation flow shows the plan end date, the data retention period, and a summary of what will be lost at each step -- building a complete picture before any irreversible state change occurs.
+
+7. **The destructive button text is the specific verb -- not a euphemism or a generic positive.** "Remove," "End," "Clear," "Close," "Deactivate" are euphemisms for "Delete," "Terminate," "Purge," "Cancel," "Disable." Euphemisms reduce cognitive engagement with the consequences of the action. When a user reads "Delete" on a red button in a deletion confirmation dialog, the word's meaning activates the appropriate level of caution; "Remove" activates a softer mental model -- something like removing a sticker, not destroying data. Use "Delete" for permanent deletion, "Cancel" for subscription termination (not "End plan"), "Terminate" for forced account closure, "Purge" for bulk data deletion with no recovery. The button text must match the severity of the action, because the button text is the last thing the user reads before the point of no return.
+
+## Details
+
+### Destructive Action Severity Scale
+
+Not all destructive actions warrant the same level of friction. Apply friction proportional to consequence:
+
+| Severity | Action Type                         | Confirmation Pattern              | Example                             |
+| -------- | ----------------------------------- | --------------------------------- | ----------------------------------- |
+| Low      | Reversible delete                   | Toast with Undo (5-30 seconds)    | Move to trash, archive              |
+| Medium   | Single-record delete                | Click-to-confirm dialog           | Delete a comment, remove a member   |
+| High     | Multi-record or team-visible delete | Confirm dialog + consequence list | Delete a project, remove a team     |
+| Critical | Irreversible, organization-wide     | Type-to-confirm + 30-day grace    | Delete workspace, terminate account |
+
+The scale should be established as a design system convention so that the same action type receives the same friction pattern throughout the product. A "delete comment" confirmation should not require typing the comment text; a "delete organization" confirmation should never be a single-click. Establish the scale in the design system token documentation and link to it from every destructive action pattern.
+
+### Type-to-Confirm Copy Pattern
+
+The type-to-confirm pattern has three required copy elements:
+
+1. **Instruction line:** "To confirm, type the name of the [resource type] below:" -- names what the user must type and why.
+2. **Placeholder in the input field:** The exact string the user must match, shown as placeholder text: "acme-corp-workspace"
+3. **Button state:** The destructive button should be disabled until the typed string matches exactly, then enable. Do not show an error for mismatch -- just keep the button disabled. GitHub's pattern is precise: the input has the repo name as placeholder, the "Delete this repository" button enables only on exact match, and the match is case-sensitive.
+
+A fourth optional element: "This cannot be undone" as a final reminder beneath the input field, immediately before the button.
+
+### Review Checklist
+
+Use this checklist before shipping or reviewing any destructive action flow:
+
+| Check                   | Criteria                                               | Pass Condition                                                                    |
+| ----------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------- |
+| Reversibility statement | Action is labeled recoverable or permanent             | "This cannot be undone" or "Restore within 30 days" appears at the decision point |
+| Consequence specificity | Dialog names the object and downstream effects         | Includes object name and count of affected records/members                        |
+| Severity classification | Action is classified on the severity scale             | Correct confirmation pattern applied (toast / click / type-to-confirm)            |
+| Type-to-confirm         | Critical actions use exact resource name               | Generic "DELETE" strings are not accepted; specific resource name required        |
+| Undo availability       | Soft-delete systems show inline undo                   | Toast with "Undo" appears immediately; undo is not buried in trash settings       |
+| Button text             | Destructive button uses specific strong verb           | No euphemisms ("Remove," "End," "Clear") for permanent actions                    |
+| Cooldown copy           | Scheduled deletions state window and cancellation path | Exact number of days and specific action to cancel are named                      |
+| Warning placement       | Warnings appear before point of no return              | No post-deletion "warnings" that are actually receipts                            |
+
+### Anti-Patterns
+
+1. **The Euphemism.** Destructive buttons labeled with soft verbs that understate the action's severity. Before: "Remove account," "End subscription," "Clear data." After: "Delete account," "Cancel subscription," "Permanently delete all data." The test: would a user who glances at the button for one second understand that this action destroys something permanently? If the verb could describe an easily reversible action (removing a sticker, ending a call, clearing a search field), it is a euphemism. Euphemisms are especially harmful on mobile where confirmation dialogs are smaller and users are more likely to tap through quickly without reading carefully.
+
+2. **The Generic Warning.** Confirmation dialogs that use boilerplate copy not specific to the action being confirmed. Before: "Are you sure you want to delete this? This action cannot be undone." After: "Delete 'Q4 Marketing Campaign' and its 12 linked assets? This will remove the campaign from all reports and revoke access for 3 collaborators. This cannot be undone." The generic warning is written once and reused everywhere; the specific warning is generated from live data about the specific object being destroyed. Generic warnings normalize the confirmation pattern -- users who see the same dialog for deleting a comment as for deleting a workspace stop reading it and click through on reflex.
+
+3. **The Hidden Undo.** Soft-delete systems where the undo affordance is buried in a settings menu or requires navigating to a trash view, rather than appearing as an inline action immediately after the deletion. Before: Item is deleted, no toast, undo is available via Settings > Trash > Restore. After: Item is deleted, toast appears: "'Q4 Campaign' deleted. Undo -- or view Trash." The undo link must appear immediately in the user's current context, not require a navigation. A 5-second undo toast is infinitely more usable than a trash bin that requires three clicks. When users discover the hidden undo only after it has expired, the experience is worse than if undo never existed -- because the user now knows they were one navigation away from recovery.
+
+4. **The Surprise Deletion.** A destructive action with no warning at the point of initiation -- the user clicks "Delete" expecting a confirmation dialog and instead the item is immediately gone. Before: "Delete" button in a row action menu that deletes the record immediately. After: "Delete" triggers a confirmation dialog. The rule: any action that cannot be undone within 5 seconds must require confirmation. Any action that affects more than the single item the user interacted with must name the scope of destruction in the confirmation. Surprise deletions are the primary cause of "I accidentally deleted my entire project" support tickets and permanent user churn from SaaS products.
+
+### Real-World Examples
+
+**GitHub repository deletion.** GitHub's repository deletion is the canonical example of a type-to-confirm pattern. The flow: navigate to Settings > Danger Zone > Delete this repository > dialog appears with full consequence list ("This will permanently delete the [repo-name] repository, wiki, issues, comments, packages, secrets, workflow runs, and all other associated repository data") + type-to-confirm ("To confirm, type the name of the repository: [repo-name]") + red "Delete this repository" button. The 30-day repository restore window was added in 2019 and is advertised in GitHub Docs, but not in the deletion dialog itself -- a notable gap that creates a missed opportunity to reduce deletion anxiety for users who might restore rather than delete. The type-to-confirm requires the exact repo name including organization prefix for organization repositories: "acme-corp/harness-engineering."
+
+**Stripe subscription cancellation with data retention notice.** Stripe's subscription cancellation flow is designed to reduce regret, not to prevent cancellation. The flow is straightforward but information-dense: it shows the plan end date (end of current billing period), confirms that all data is retained after cancellation (the account does not close, only the subscription ends), and offers a plan downgrade as an alternative. The key copy: "Your [Plan Name] subscription will end on [Date]. After this date, you'll be moved to the free plan. Your data will be preserved." This phrasing specifically addresses the fear that cancellation equals data deletion, which is the primary source of cancellation anxiety in SaaS products -- Stripe's copy engineering decision is to defuse that fear explicitly rather than hoping users infer it.
+
+**Google account deletion 30-day grace period.** Google's account deletion flow is one of the most consequential destructive flows in consumer software. The multi-step flow includes: a list of all Google services and data that will be deleted, a checkbox acknowledging each major data category, a warning about the 20-day window after which data becomes unrecoverable, and confirmation that some data (purchased content, shared documents) may be retained differently. The grace period copy is explicit: "After deleting your account, you have a 20-day window to sign back in and cancel the deletion." Google pre-downloads all user data via Takeout before the deletion flow reaches the confirmation step -- the copy guides users through this prerequisite, treating data preservation as a first-class concern rather than an afterthought.
+
+**Notion workspace deletion flow.** Notion's workspace deletion requires navigating to Settings > [Workspace name] > Delete workspace. The confirmation dialog names the workspace and shows a count of all pages, databases, and members. The type-to-confirm requires the exact workspace name. What makes Notion's flow distinctive is the pre-deletion export prompt: before the type-to-confirm step, Notion surfaces "Export workspace content" as a recommended action with a direct link. This is copy that reduces regret -- giving the user one more opportunity to preserve their data before the irreversible action. The export prompt does not block deletion, but its placement immediately before the type-to-confirm step is deliberate, serving as a final "are you really sure?" moment without requiring an additional confirmation click.
+
+### Copy Formulas Quick Reference
+
+These are fill-in-the-blank templates for the most common destructive action copy patterns:
+
+- **Irreversibility statement:** `This action is permanent and cannot be undone.`
+- **Soft-delete statement:** `You can restore this within [N] days from [Trash / Settings > Deleted items].`
+- **Consequence list item:** `[N] [records / members / projects] will be permanently deleted.`
+- **Downstream effect:** `[Connected service] will lose access immediately.`
+- **Type-to-confirm instruction:** `To confirm, type the name of the [resource type] below:`
+- **Type-to-confirm placeholder:** `[exact-resource-name]`
+- **Post-deletion toast:** `'[Name]' deleted. Undo`
+- **Grace period copy:** `Your [resource] will be deleted in [N] days. Sign in before [Date] to cancel.`
+- **Cooldown cancellation:** `To cancel deletion, [specific action] before [Date / timeframe].`
+- **Destructive button -- delete:** `Delete [resource name]`
+- **Destructive button -- terminate:** `Terminate account`
+- **Destructive button -- purge:** `Permanently delete all data`
+
+## Source
+
+- NNGroup -- "Confirmation Dialog Boxes," https://www.nngroup.com/articles/confirmation-dialog/
+- NNGroup -- "Preventing User Errors: Avoiding Unconscious Slips," https://www.nngroup.com/articles/slips/
+- Apple Human Interface Guidelines -- Alerts, https://developer.apple.com/design/human-interface-guidelines/alerts
+- Laubheimer, P. -- "Checkboxes vs. Toggles in Mobile Design," NNGroup (2015)
+- GitHub -- Deletion and data recovery documentation, https://docs.github.com/en/repositories/creating-and-managing-repositories/deleting-a-repository
+- Yifrah, K. -- _Microcopy: The Complete Guide_ (2017), Chapter 9: Errors, Warnings, and Destructive Actions
+
+## Process
+
+1. **Classify the destructive action on the severity scale** (low / medium / high / critical). The severity determines the confirmation pattern -- do not apply the same friction to all destructive actions. Write the severity classification into the component spec so that future developers do not have to re-derive it for similar actions. Review the severity classification with a product manager who can confirm the actual recoverability of the data before the copy is written.
+
+2. **For medium and high severity actions:** Write the confirmation dialog with a specific title (naming the object), a consequence list (what exactly will be deleted, with live counts from the API), reversibility statement (permanent or soft-delete with window length), and a destructive verb button. Ensure the object name and counts are dynamically generated -- hardcoded counts become wrong the moment the data changes.
+
+3. **For critical severity actions:** Add the type-to-confirm pattern with exact instruction copy ("To confirm, type the name of the [resource type]:"), placeholder showing the required string, and button-disabled-until-match behavior. Confirm with engineering that the match is case-sensitive and that the exact required string is displayed in the dialog. Test the disabled/enabled button transition manually before shipping.
+
+4. **If the system supports soft-delete or a grace period:** Write the post-deletion toast with an inline undo action ("'[Name]' deleted. Undo"), and the grace period copy naming the exact window length and the specific action to cancel the deletion. Confirm with engineering what the exact window length is in days and whether the window is from deletion time or end of day -- this specificity matters when users are near the boundary.
+
+5. **Audit all destructive button labels across the product for euphemisms.** Build a list of every destructive action button in the product and classify each verb. Replace "Remove," "End," "Clear," "Close," or "Deactivate" with the appropriate strong verb ("Delete," "Cancel," "Purge," "Terminate," "Disable") that matches the severity and permanent nature of the action. Document the verb vocabulary in the design system so that new destructive actions default to the correct verb.
+
+## 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
+
+- Irreversible actions explicitly state "This cannot be undone" or equivalent at the decision point -- no destructive action is presented as reversible when it is not.
+- Confirmation dialogs name the specific object being destroyed and include a dynamically generated count of affected downstream data (members, records, assets).
+- Type-to-confirm is used for all critical-severity actions (account deletion, workspace deletion, production data purge) and requires the exact resource name, not a generic confirmation string.
+- Soft-delete and grace period copy names the exact window length in days and the specific action the user must take to cancel within the window.
+- All destructive buttons use strong, specific verbs ("Delete," "Cancel," "Terminate," "Purge") -- no euphemisms like "Remove," "End," or "Clear" for permanent actions.
+- Post-deletion undo toasts appear immediately in the user's current view and provide an inline undo action -- undo is not reachable only via a separate trash or settings menu.
+- Warning copy appears at the decision point before the irreversible action, not on a confirmation screen after the action has already occurred.
+
+## Mobile and Edge-Case Considerations
+
+On mobile, confirmation dialogs for destructive actions must be designed with the additional constraint that tap targets are small and users frequently dismiss dialogs by tapping outside them. A destructive confirmation dialog on iOS or Android should use the platform's native alert pattern (system modal) rather than a custom bottom sheet that can be swiped away. The type-to-confirm pattern is high-friction on mobile keyboards -- on mobile, reserve it only for the most critical actions and consider an alternative like a 5-second countdown button ("Hold to delete") for high-severity but not critical actions.
+
+Bulk destructive actions over large datasets require additional copy: when deleting hundreds or thousands of items, show a progress indicator with copy like "Deleting 1,847 records... Do not close this window." If the deletion is async and continues in the background, say so: "Deletion in progress. You'll receive an email when complete." Users who initiate large bulk deletions and then see no feedback will refresh the page, navigate away, and potentially trigger the operation twice.
+
+For actions that require a grace period email confirmation (some GDPR-compliant deletion flows send an email with a confirmation link before deletion begins), the in-product copy must set the expectation: "Check your email at user@example.com for a confirmation link. Deletion begins after you confirm." Name the email address so the user knows which inbox to check, and set the expectation that the confirmation link expires: "The link expires in 24 hours."