qa-only

qa-only 개요

qa-only는 웹 앱을 테스트하고, 버그를 문서화하고, 증거를 남기되 어떤 수정도 하지 않는 보고 전용 QA skill입니다. qa-only는 테스트-수정-검증 루프보다 깔끔한 버그 리포트 워크플로가 필요한 QA 리뷰어, 프로덕트 오너, 그리고 에이전트에 가장 잘 맞습니다. 목표가 “문제를 찾아서 정리하기”라면 qa-only가 적합하고, 코드 변경이 필요하다면 대신 /qa를 사용하세요.

qa-only는 무엇을 위한 skill인가

이 skill은 구조화된 QA 결과에 초점을 맞춥니다. 상태 점수, 스크린샷, 재현 단계, 그리고 명확한 버그 리포트를 만들어 내는 데 맞춰져 있습니다. 사용자가 원하는 것이 구현이 아니라 증거일 때, 즉 “그냥 버그만 확인해 달라”거나 “테스트만 하고 수정은 하지 말라”는 요청에 맞게 설계되어 있어 해석의 여지를 줄여 줍니다.

qa-only가 다른 이유

qa-only skill의 핵심 가치는 절제에 있습니다. 에이전트를 보고 중심의 동작으로 유도해 실수로 수정 작업에 들어가는 일을 막아 줍니다. 결과물이 리뷰 산출물, 트리아지 메모, 인수인계 보고서라면 이 차이가 특히 중요합니다. 그래서 Qa용 qa-only는 수정이 범위 밖이거나 위험한 환경에서 특히 유용합니다.

적합한 경우와 적합하지 않은 경우

기존 애플리케이션에 대해 QA 점검이 필요할 때, 특히 버그 발견, 회귀 확인, 서면 평가가 목적이라면 qa-only를 사용하세요. 코드 편집, 리팩터링, 반복적인 버그 수정이 필요하다면 일반 테스트 도우미처럼 설치하면 안 됩니다. qa-only guide는 의도적으로 수정보다 보고를 먼저 두는 방식입니다.

qa-only skill 사용 방법

skill 설치 및 확인

저장소 기반 설치 흐름을 사용하세요: npx skills add garrytan/gstack --skill qa-only. 설치 후에는 실제 업무에 쓰기 전에 skills 디렉터리에서 skill 파일이 존재하고 읽을 수 있는지 확인해야 합니다. qa-only install은 에이전트가 QA 실행 중에 skill 컨텍스트를 실제로 로드할 수 있을 때만 의미가 있습니다.

올바른 시작 프롬프트를 주기

강한 qa-only usage 프롬프트는 앱, 테스트 대상, “버그 리포트만”의 의미, 그리고 경계를 명확히 밝혀야 합니다. 좋은 예시는 다음과 같습니다: “staging의 checkout flow에 qa-only를 실행하고, 보이는 버그만 보고하며, 재현 단계와 스크린샷 메모를 포함하고, 수정 제안은 하지 마세요.” “이 앱 QA해줘”처럼 약한 입력은 범위와 심각도를 모델이 임의로 추정할 여지를 너무 많이 남깁니다.

먼저 읽어야 할 파일

먼저 SKILL.md를 보고, 이어서 SKILL.md.tmpl을 확인해 생성된 워크플로가 어떻게 구성되는지 이해하세요. 이 repo에는 추가 rules/, resources/, 스크립트가 없으므로, 두 skill 파일이 동작, 트리거, 제약에 대한 사실상의 원본입니다. qa-only를 채택하기 전에 빠르게 구조를 파악하려면 이 순서가 가장 좋습니다.

실무 QA 워크플로에 적용하기

좋은 qa-only guide 워크플로는 다음과 같습니다: 테스트할 영역을 정의하고, 기대 동작을 적은 뒤, skill이 집중 리뷰를 수행하게 하고, 그 결과를 버그 리스트나 QA 메모로 정리합니다. 첫 결과가 너무 넓다면, 한 사용자 여정, 한 기기/브라우저, 또는 한 릴리스 후보로 범위를 좁히세요. 과제가 경계가 분명하고 보고 형식이 명시적일수록 이 skill은 가장 강력합니다.

qa-only skill FAQ

qa-only는 브라우저 앱에만 쓰나요?

대체로 그렇습니다. qa-only는 웹 애플리케이션 QA와 버그 보고에 맞춰져 있어 UI 흐름, staging 환경, 관찰하고 문서화할 수 있는 사용자 여정에 잘 맞습니다. 반대로 백엔드 전용 검증이나 눈에 보이는 제품 동작이 없는 작업에는 효용이 떨어집니다.

일반 프롬프트와는 어떻게 다른가요?

일반 프롬프트로도 QA를 요청할 수 있지만, qa-only skill은 일관된 보고 태도와 “수정하지 말 것”에 대한 더 분명한 동작을 추가합니다. 덕분에 팀이 구현이 섞이지 않은 깔끔한 이슈 리포트를 필요로 할 때, 오가는 확인 질문을 줄일 수 있습니다.

qa-only는 초보자에게도 쉬운가요?

네, 앱, 환경, 목표를 명확히 말할 수 있다면 그렇습니다. 초보자가 가장 많이 하는 실수는 범위를 너무 대충 쓰는 것입니다. qa-only guide는 무엇을 테스트할지, 어떤 증거를 수집할지, 무엇을 하지 말아야 할지 알려 줄 때 가장 잘 작동합니다. 그 정보가 없으면 보고서가 너무 일반적이어서 바로 활용하기 어렵습니다.

언제 qa-only를 쓰지 말아야 하나요?

실제 필요가 디버깅, 패치, 엔드투엔드 수정 검증이라면 qa-only를 쓰지 마세요. 코드 변경에 대한 쓰기 권한이 필요한 심층 테스트 자동화 설정, 인프라 작업, 그리고 그 외의 작업에도 잘 맞지 않습니다.

qa-only skill 개선 방법

범위를 더 좁히고 성공 신호를 더 분명하게 주기

qa-only 결과를 개선하는 가장 좋은 방법은 명확한 대상 하나와 명확한 성공 조건 하나를 정하는 것입니다. 예를 들어: “모바일 Safari에서 로그인 폼을 테스트하고, 검증 오류가 깨지는 부분을 보고하며, 단계, 예상 결과와 실제 결과, 스크린샷 참조를 포함하세요.” 이렇게 하면 막연한 감사 요청이 아니라 측정 가능한 틀이 생깁니다.

보고서에 포함해야 할 증거를 추가하기

더 유용한 qa-only 보고서를 원한다면 재현 단계, 영향을 받는 URL 또는 route, 심각도, 발생 빈도, 그리고 해당 이슈가 차단적(blocking)인지, 단순 외관 문제인지, 간헐적인지 같은 구체적인 산출물을 요청하세요. 이는 “버그를 찾아줘”라고만 하는 것보다 낫습니다. 구조화된 결과를 강제해 다른 사람이 빠르게 조치할 수 있게 해 주기 때문입니다.

흔한 실패 모드 살피기

가장 흔한 실패 모드는 범위가 지나치게 넓어지는 것입니다. 에이전트가 모든 것을 테스트하려고 하다가 보고서는 얕아집니다. 또 다른 실패 모드는 보고 전용 과제에 수정 의도가 섞이는 경우인데, 이렇게 되면 qa-only의 목적이 약해집니다. 그런 일이 생기면 요청을 “report only, no fixes, no code changes”로 다시 명확히 하고 테스트 표면을 좁히세요.

첫 보고서에서 두 번째 점검으로 이어가기

첫 번째 패스는 의심되는 이슈를 찾는 데 쓰고, 두 번째 qa-only 패스는 가장 중요한 버그 경로에 집중하세요. 첫 보고서에서 중요한 흐름 하나가 드러났지만, 엣지 케이스, 브라우저 차이, 재현 안정성까지 더 확인하고 싶을 때 특히 유용합니다. 반복 점검을 할 때 qa-only는 일회성 프롬프트가 아니라 믿을 만한 QA 습관이 됩니다.