chore: audit and slim the ux-test skill

Aperta
  • Qualcosa non va?
#431 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp, docker
Ambito
testing, tooling

Direzione di ricerca

Start by reading .claude/skills/ux-test section by section alongside the simplicity test from issue #400, then record keep or cut decisions here before editing. Check how the allowed-tools entries handle the two docker compose variants and how the gh recipes manage result comments. Done means the file reflects the audit, a real /ux-test PR#N run completes the stated stack and cleanup steps, and a second run updates the existing results comment.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

tech-debt

Found while auditing the pipeline for #400 (piece 6). The ux-test skill is the largest single file in .claude/skills/ and has not had the simplicity pass the rest of the workflow is getting. This issue audits it, one section at a time, and then trims it.

What I found

  • It is 307 lines, and its allowed-tools header is about 48 lines of its own. Sixteen of those are the same eight docker compose commands written twice, once for the plain test file (variant B) and once with the local TLS-proxy override (variant L).
  • Steps 1 and 9 carry gh recipes for reading the PR or issue and for finding, updating and creating the marker comment.
  • Step 4 polls with up to 40 separate Bash calls and a Playwright wait between them, because the skill forbids a shell sleep or loop. A single retrying curl may do the same job.
  • Step 5 holds navigation hints (routes, filter behaviour, which task sections start collapsed). These describe UI that changes, so they go stale, and Claude can read them from the code.
  • The report template (Step 8) and the guardrails section restate rules already in the steps.
  • Two lines (Always --body-file and PascalCase enum values) are removed by #400, because pieces 1 and 2 cut those rules everywhere. This issue covers everything else.

Scope

  1. Walk the file one section at a time and apply the standing test from #400: a line stays only if Claude would get it wrong without it, Claude cannot find it in the repo, and a hook, setting or code comment cannot enforce it instead. Record the keep and cut decisions for each section on this issue before editing.
  2. Decide how the two compose variants are handled so the allowed-tools list no longer duplicates every command, or document why it must.
  3. Decide what happens to the gh recipes (the skill is standalone and posts its own results, so the recipes may stay in a shorter form).
  4. Trim the file to match the decisions.

Acceptance criteria

  1. Each section of ux-test has a recorded keep or cut decision on this issue before the file is edited.
  2. allowed-tools has no duplicated command pairs, or a comment in the skill says why a pair remains.
  3. A real run, /ux-test PR#N against an open PR with a UI change, still builds the taskflow-test stack, runs the plan, posts the results comment, tears the stack down and leaves .playwright-mcp/ clean.
  4. A second run on the same PR updates the existing <!-- ux-test-results --> comment instead of adding another.
  5. The live stack and its volumes are untouched (every docker compose command still carries -p taskflow-test).

Out of scope

  • Running ux-test from the feature-factory pipeline. #400 decided it stays manual: after the PR is created, the pipeline prints /ux-test PR#N when the UI changed. Revisit only after this audit.
  • Changing the test stack's compose files.
  • Moving ux-test into a plugin or rewriting it as an agent.
Lingua principale
C#
Stelle
1
Fork
0
Merge medio
2h 2m
PR unite (30g)
98

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nevridge/TaskFlow

Tutte le issue di nevridge/TaskFlow

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.