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.

Ir para a instalação

Repositório: johannesPettersson80/trust-platform
Última atividade na origem: 18 de julho de 2026 às 19:04
Idioma detectado do SKILL.md: inglês
Estrelas: 220
Forks: 28

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.

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

O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.

Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

SKILL.md

Instruções da origem · Visualização somente leitura

Voltar à pesquisa Voltar à instalação

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

Ver todas deste repositório

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.