TimothyHan

e2e-pom

라이브 요소 디스커버리로 Page Object Model을 빌드하고 유지합니다 -- 셀렉터를 절대 추측하지 않습니다. Build 모드는 사용자와 페어링: 테스트 케이스에서 요소 인벤토리를 도출하고, 실행 중인 앱에 대해 모든 로케이터를 증명하고, 하이라이트 스크린샷으로 확인받은 후에만 POM에 넣습니다. Heal 모드는 검증 스펙이 깨졌을 때 자율 실행: 재디스커버리, 명확한 이름 변경은 자동 수정, 제거된 요소는 플래그, 그 외에는 아무것도 건드리지 않음. 사용 시점: "build POM", "page objects", "map elements", "heal selectors", "verification spec failing". 사용하지 않을 때: 초기 Playwright 셋업 시 (/qa-e2e-setup 사용), 테스트 스펙 작성 시 (/qa-e2e-write 사용), 테스트 케이스 생성 시 (/qa-test-cases 사용).

e2e-setup

이 팀과 앱에 맞춘 Playwright e2e 자동화를 셋업합니다. 실행 중인 앱을 프로브(인증 방식, API 표면, 스펙 존재 여부)하고, 열린 질문 대신 추천을 제시하는 인터뷰를 진행하고, playwright/ 폴더를 스캐폴드하고, 모든 결정을 playwright/AUTOMATION.md에 기록해 다른 e2e 스킬들이 읽게 합니다. 스캐폴드가 green으로 실행되기 전까지 셋업은 끝난 것이 아닙니다. 사용 시점: "e2e setup", "set up playwright", "configure test automation", "automation setup". 사용하지 않을 때: 페이지 객체 빌드 시 (/qa-e2e-pom 사용), 테스트 스크립트 작성 시 (/qa-e2e-write 사용), QABuddy 일반 설정 시 (/qa-setup 사용).

e2e-write

테스트 케이스로부터 e2e 테스트 스위트를 작성합니다: 사전 조건용 API 클라이언트, fixture, 그리고 증명된 POM 위의 의도만 담은 스펙. 로케이터를 절대 지어내지 않습니다 -- 페이지에 POM이 없으면 먼저 /qa-e2e-pom을 호출합니다. 스위트가 세 게이트(green, 다시 green(정리 증명), --repeat-each=3에서 green(플레이크 증명))와 금지 패턴 기계 린트를 통과해야 완료입니다. 사용 시점: "write e2e tests", "automate test cases", "generate the test suite", "API client for tests". 사용하지 않을 때: Playwright 셋업 시 (/qa-e2e-setup 사용), 페이지 객체 빌드/힐링 시 (/qa-e2e-pom 사용), 수동 테스트 실행 시 (/qa-qa 사용).

eval

스킬에 대해 eval fixture를 실행하여 올바른 출력을 생성하는지 검증합니다. fixture별 두 가지 모드: simulate(SKILL.md를 읽고 시나리오를 시뮬레이션하여 assertion 확인)와 execute(스킬이 생성한 아티팩트를 로컬 fixture 앱에 대해 실제로 실행하고 exit code와 파일 검사로 채점). /qa-improve 후에 수정이 기존 동작을 깨뜨리지 않았는지 검증할 때 사용합니다. 사용 시점: "eval", "run evals", "test skill", "check fixtures", "regression test". 사용하지 않을 때: 실제 앱 QA 수행 시 (/qa-qa 사용), 스킬 개선 시 (/qa-improve 사용), 스프린트 상태 확인 시.

exploratory

탐색적 테스트 세션을 생성하고 안내합니다. 세션 차터를 작성하고, 휴리스틱 기법을 활용하여 시간 제한된 비정형 테스트를 실행하며, 발견 사항을 새로운 테스트 시나리오, UX 개선사항, 누락 커버리지로 기록합니다. 발견 사항을 지식 베이스(KB)와 테스트 케이스에 반영합니다. 사용 시점: "exploratory test", "explore this feature", "charter for testing". 사용하지 않을 때: 정형 테스트 케이스 실행 시 (/qa-qa 사용), 특정 버그 수정 검증 시 (/qa-verify-fix 사용), 테스트 계획 수립 시 (/qa-test-plan 사용).

improve

실제 사용 실패를 기반으로 다른 스킬을 개선하는 메타 스킬입니다. SDT가 스킬의 출력이 잘못되었거나 예상과 다르다고 보고하면, 근본 원인을 분석하��, 개선안을 작성하며, CONTRIBUTING.md 가이드라인에 따라 수정을 적용하고, PR 생성 또는 로컬 적용을 제안합니다. 프로젝트 학습 레이어 유지보수(distill 모드)도 담당합니다: 중복 제거, 반증된 항목 은퇴, 증명된 학습의 레퍼런스/업스트림 승격. 사용 시점: "improve", "this didn't work", "fix this skill", "the output was wrong", "skill improvement", "qa-improve", "distill learnings", "학습 정제". 사용하지 않을 때: 출력 내용에 대한 피드백을 줄 때 (확인 단계에서 옵션 B 사용), QA 방법론에 대해 문의할 때, 일반 QA 워크플로우를 실행할 때.

qa

SDT 테스트 실행 스킬. 지식 베이스(KB)의 테스트 케이스를 실행하고, 브라우저에서 인수 조건(AC)을 검증하며, 실패 항목은 Jira에 버그로 등록하고, KB에 결과를 반영합니다. 스프린트 맥락 안에서 동작합니다 — 티켓, AC, 테스트 케이스를 파악하고, 티켓이 다음 단계로 넘어가려면 무엇이 통과해야 하는지 알고 있습니다. --fix 플래그를 사용하면 SDT가 경미한 수정을 직접 처리할 수 있습니다. 사용 시점: "qa", "이 티켓 테스트해줘", "테스트 케이스 실행", "AC 검증", "이거 통과해?". 사용하지 않는 경우: QA 방법론 질문, 버그 수정 검증(/qa-verify-fix 사용), 버그 등록 없이 탐색만 할 때(exploratory).

review-ticket

백로그 그루밍 또는 리파인먼트 중 Jira 티켓을 리뷰합니다. 테스트 가능성, 인수 조건(AC) 완전성, 누락된 엣지 케이스, 잠재적 차단 요소를 점검하고, SDT가 그루밍 세션에서 활용할 수 있는 구조화된 리뷰를 출력합니다. 사용 시점: "review this ticket", "check ACs", "testability review", "grooming". 사용하지 않을 때: 에픽에 대한 테스트 계획을 작성할 때 (/qa-test-plan 사용), 테스트 케이스를 작성할 때 (/qa-test-cases 사용), 브라우저에서 테스트할 때 (/qa-qa 사용).

setup

QABuddy 초기 설정 마법��. 컨텍스트 소스(Jira, 스펙 문서, 채팅, 커스텀), 팀 모드(솔로 vs PR 기반), 프로젝트 환경설정을 구성합니다. 프로젝트 루트에 .qabuddy.json을 생성합니다. 원하면 QABuddy가 풀 리퀘스트마다 실행되도록 (재사용 PR 커버리지 워크플로우) 연결합니다. 재실행하면 재구성할 수 있습니다. Use when: "setup", "configure", "first time setup", "change settings". Do NOT use when: asking about QABuddy features, asking how to use a skill, mid-workflow.

start

가이드 방식의 E2E QA 워크플로우. 테스트 계획, 티켓 리뷰, 테스트 케이스 생성을 순차적으로 진행하며, 각 단계가 끝나면 SDT가 검토할 수 있도록 멈춥니다. 중단된 경우 이전 지점부터 다시 시작합니다. 새 에픽의 주요 진입점입니다. Use when: "start", "begin workflow", "qa workflow", "guided qa", "new epic". Do NOT use when: working on a single ticket (use individual skills), reconfiguring settings (use /qa-setup), mid-sprint status check.

test-cases

Jira 티켓의 인수 조건(AC)에서 테스트 케이스를 생성합니다. E2E 테스트 시나리오 (단계와 기대 결과, 코드 없음)와 개발자용 단위 테스트 체크리스트를 작성합니다. 테스트 케이스는 추적성을 위해 요구사항에 매핑됩니다. 사용 시점: "테스트 케이스 작성", "테스트 생성", "PROJ-789 E2E 테스트", "이 티켓 테스트 케이스". 사용하지 않는 경우: 티켓 테스트 가능성 리뷰(/qa-review-ticket 사용), 테스트 실행(/qa-qa 사용), 앱 탐색(/qa-exploratory 사용).

test-plan

새 에픽이 생성되면 테스트 계획을 수립합니다. Jira에서 에픽 상세 정보와 연결된 스토리를 가져와 범위를 분석하고, 전략, 자동화 갭 분석, 성공 기준, 환경 요구사항, 위험 요소를 포함하는 테스트 계획을 작성합니다. 결과물은 Confluence와 로컬 테스트 지식 베이스(KB)에 저장합니다. 사용 시점: "테스트 계획", "이 에픽 테스트 계획 세워줘", "EPIC-123 테스트 전략". 사용하지 않는 경우: 개별 티켓 리뷰(/qa-review-ticket 사용), 스토리의 테스트 케이스 작성(/qa-test-cases 사용), QA 방법론 질문.

verify-fix

개발자가 수정한 버그를 재테스트합니다. Jira에서 원본 버그를 가져오고, 브라우저에서 재현 단계를 다시 실행하며, 회귀 여부를 확인하고, 버그 상태를 업데이트합니다. 티켓이 Done으로 넘어가기 전 SDT 워크플로우의 마지막 단계입니다. 사용 시점: "수정 검증", "재테스트", "이거 고쳐졌어?", "BUG-123 확인", "BUG-123 검증". 사용하지 않는 경우: 최초 QA 실행(/qa-qa 사용), 새 버그 등록, 기능을 처음 테스트할 때.