vscode-ui-acceptance

Maintain and prove truST VS Code UI acceptance journeys. Use for acceptance-board rows, ux_accepted gates, screenshot evidence, journey coverage, and visible workflow review.

Jump to install

Repository: johannesPettersson80/trust-platform
Last source activity: July 18, 2026 at 19:04
Detected SKILL.md language: English
Stars: 220
Forks: 28

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/johannesPettersson80/trust-platform --skill vscode-ui-acceptance

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

trust-ci-release-gates

CI and release-gate hardening workflow for truST, including exact pre-push parity, cross-platform test harnesses, and artifact-based release gating.

2026-08-29

trust-remote-builder

Use when compiling trust-platform, running just/cargo/npm/VS Code gates, synchronizing local work to the shared Hetzner CPU builder, or reporting remote build/test proof.

2026-08-28

trust-lsp-iec

IEC 61131-3 Structured Text workflow for compliance, language behavior, spec updates, and IEC decision/deviation classification in truST. Use whenever editing docs/IEC_DECISIONS.md or docs/IEC_DEVIATIONS.md; reject IEC-deviation entries for IEC-silent, product-specific, platform, runtime, CLI, or truST-only behavior.

2026-08-20

View all from this repository

VS Code UI Acceptance

Use this skill when a VS Code workflow is not complete until a visible user journey is accepted. Use trust-test-authoring first for the cataloged behavior and proof route; this skill owns the additional rendered acceptance evidence.

Workflow

Identify the acceptance row or create a new row before implementation.

Name the visible VS Code surface: Home view, Testing view, Problems, Live Values, Devices & Connections, HMI, generated-ST diff, or report webview.

Define the journey in user terms, not command-palette terms.

Define one observable behavior slice and add/register the smallest focused rendered interaction, state, or layout test before implementation.

Run it and confirm the expected behavior assertion is red because the feature is missing or the behavior is wrong; compile, dependency, harness, timeout, and unrelated failures do not count.

Implement only enough to make the same focused test green, then rerun it until green before starting another slice.

Capture screenshots using the vscode-capture skill for core visible states after the focused test is green.

Run the required theme triplet for core surfaces: light, dark, high contrast/forced colors when applicable.

Record the red and green test commands/results, and mark ux_accepted only after reviewer != implementer and evidence artifacts are attached.

Acceptance Rules

A slice that says "visible" must name the VS Code surface and attach screenshot evidence.

CLI-only proof does not close a VS Code UX acceptance row.

Static source-text assertions do not prove rendered behavior or layout.

Disabled actions must carry the reason in the UI.

Do not add a second Start/Run surface when the existing shell can be wired by project kind.

New webview chrome must use shared theme tokens, not one-off colors.

Reference

Read references/journeys.md for the expected journey/evidence shape.