chore: audit and slim the ux-test skill

Đang mở
#431 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, docker
Lĩnh vực
testing, tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
C#
Star
1
Fork
0
Merge trung bình
2 giờ 2 phút
Pull request đã merge (30 ngày)
98

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của nevridge/TaskFlow

Tất cả issue của nevridge/TaskFlow

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.