dd-shared-ui

Defines shared UI observability gate rules with evidence tiers and closure criteria.

Updated Jun 11, 2026
One-click install
npx skills add https://github.com/marcocpt/trae_skills --skill dd-shared-ui-marcocpt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dd-shared-ui
Source: https://github.com/marcocpt/trae_skills/tree/main/dd-shared-ui
Command: npx skills add https://github.com/marcocpt/trae_skills --skill dd-shared-ui-marcocpt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams building UI features often close acceptance criteria based only on internal state or unit tests, leaving user-visible behavior unverified. This Skill provides a shared, reusable gate that defines what counts as valid UI evidence so multiple dd workflow skills apply consistent verification standards. ## Core Features & Use Cases - Five-Tier Evidence Hierarchy: Ranks evidence from real-path automation (E2E, XCUITest, Playwright, Appium) down to internal state (unit tests, ViewModel state), clarifying what each tier can prove. - Closure Rules: Requires every UI acceptance criterion to have at least one tier 1-4 evidence; tier-5-only items must be marked as "UI verification incomplete" or "UI risk exists". - Manual Acceptance Fallback: When automation is infeasible, mandates documented reasons, manual steps, evidence storage locations, and residual risks in design specs and sub-plans. - Use Case: A desktop app feature involving window overlays and keyboard shortcuts references this gate from dd-feature-development-workflow to decide whether Playwright traces or manual screen recordings suffice to close its UI acceptance criteria. ## Quick Start Apply the dd-shared-ui observability gate to evaluate whether the UI acceptance criteria in my current feature plan have sufficient evidence to be closed.

Frequently Asked Questions about dd-shared-ui

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What evidence is required to close a UI acceptance criterion?

Each UI acceptance criterion needs at least one piece of evidence from tiers 1-4, such as E2E automation, accessibility tree markers, component rendering tests, or documented manual acceptance. Internal state evidence like unit tests alone cannot close a UI criterion.

How are UI testing evidence types ranked in priority?

Evidence is ranked in five tiers: real-path automation (E2E, XCUITest, Playwright, Appium) first, then stable observability markers (DOM, accessibility tree, screenshots), component-level UI tests, manual acceptance records, and finally internal state evidence like unit tests.

Can unit tests alone verify UI acceptance criteria?

No. Unit tests, ViewModel state, and core state machine checks are tier-5 evidence that only proves supporting logic. Items with only tier-5 evidence must be marked as "UI verification incomplete" or flagged as a UI risk.

What should I do when UI automation testing is not feasible?

Document the reason automation is infeasible, the manual acceptance steps, where evidence (screenshots, recordings, logs) is stored, and the remaining risks in the design spec and sub-plan. Conclusions like "untestable but probably fine" must be escalated as risk items.

Which types of features does this UI observability gate apply to?

The gate applies to any feature involving UI, desktop apps, web apps, visualizations, keyboard shortcut interactions, windows, overlays, menus, forms, or canvases. It is referenced by other dd workflow skills to avoid duplicating these rules.