Name: lucas-flatwhite/gstack-ko
Author: Community

참고 전용: 이 저장소는 upstream gstack의 한국어 문서 레이어입니다. 아래 내용은 upstream 설치본을 기준으로 한 참조이며, 실제 실행은 upstream 환경을 따라야 합니다.

서문 (먼저 실행)

_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_PROACTIVE=$(~/.claude/skills/gstack/bin/gstack-config get proactive 2>/dev/null || echo "true")
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"
echo "PROACTIVE: $_PROACTIVE"
source <(~/.claude/skills/gstack/bin/gstack-repo-mode 2>/dev/null) || true
REPO_MODE=${REPO_MODE:-unknown}
echo "REPO_MODE: $REPO_MODE"
_LAKE_SEEN=$([ -f ~/.gstack/.completeness-intro-seen ] && echo "yes" || echo "no")
echo "LAKE_INTRO: $_LAKE_SEEN"
_TEL=$(~/.claude/skills/gstack/bin/gstack-config get telemetry 2>/dev/null || true)
_TEL_PROMPTED=$([ -f ~/.gstack/.telemetry-prompted ] && echo "yes" || echo "no")
_TEL_START=$(date +%s)
_SESSION_ID="$$-$(date +%s)"
echo "TELEMETRY: ${_TEL:-off}"
echo "TEL_PROMPTED: $_TEL_PROMPTED"
mkdir -p ~/.gstack/analytics
echo '{"skill":"qa","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","repo":"'$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown")'"}'  >> ~/.gstack/analytics/skill-usage.jsonl 2>/dev/null || true
# zsh 호환: NOMATCH 오류를 피하기 위해 glob 대신 find 사용
for _PF in $(find ~/.gstack/analytics -maxdepth 1 -name '.pending-*' 2>/dev/null); do [ -f "$_PF" ] && ~/.claude/skills/gstack/bin/gstack-telemetry-log --event-type skill_run --skill _pending_finalize --outcome unknown --session-id "$_SESSION_ID" 2>/dev/null || true; break; done

PROACTIVE가 "false"인 경우 gstack 스킬을 사전에 제안하지 마십시오. 사용자가 명시적으로 요청할 때만 호출하세요. 사용자가 사전 제안을 거부했습니다.

출력에 UPGRADE_AVAILABLE <old> <new>가 표시되면: ~/.claude/skills/gstack/gstack-upgrade/SKILL.md를 읽고 "인라인 업그레이드 흐름"을 따르세요(구성된 경우 자동 업그레이드, 그렇지 않으면 4가지 옵션으로 AskUserQuestion, 거부 시 스누즈 상태 기록). JUST_UPGRADED <from> <to>인 경우: 사용자에게 "gstack v{to}를 실행 중입니다(방금 업데이트됨!)"라고 알리고 계속 진행합니다.

LAKE_INTRO가 no인 경우: 계속 진행하기 전에 완전성 원칙(Completeness Principle)을 소개합니다. 사용자에게 다음과 같이 알립니다: "gstack은 Boil the Lake 원칙을 따릅니다 — AI가 한계 비용을 거의 0으로 만들 때 항상 완전한 작업을 수행합니다. 자세히 알아보기: https://garryslist.org/posts/boil-the-ocean" 그런 다음 기본 브라우저에서 에세이를 열겠다고 제안합니다:

open https://garryslist.org/posts/boil-the-ocean
touch ~/.gstack/.completeness-intro-seen

open은 사용자가 동의할 때만 실행합니다. touch는 항상 실행하여 본 것으로 표시합니다. 이 작업은 한 번만 발생합니다.

TEL_PROMPTED가 no이고 LAKE_INTRO가 yes인 경우: 호수 소개가 처리된 후 사용자에게 텔레메트리에 대해 질문합니다. AskUserQuestion을 사용하세요:

gstack을 더 개선하는 데 도움을 주세요! 커뮤니티 모드는 사용 데이터(어떤 스킬을 사용하는지, 소요 시간, 충돌 정보)를 안정적인 기기 ID와 공유하여 추세를 추적하고 버그를 더 빠르게 수정할 수 있도록 합니다. 코드, 파일 경로 또는 저장소 이름은 절대 전송되지 않습니다. gstack-config set telemetry off로 언제든지 변경할 수 있습니다.

옵션:

A) gstack 개선에 도움! (권장)
B) 괜찮습니다

A를 선택하면: ~/.claude/skills/gstack/bin/gstack-config set telemetry community 실행

B를 선택하면: 후속 AskUserQuestion으로 질문:

익명 모드는 어떠세요? 누군가가 gstack을 사용했다는 것만 알 수 있습니다 — 고유 ID 없음, 세션 연결 불가. 단지 누군가가 있는지 알 수 있는 카운터일 뿐입니다.

옵션:

A) 네, 익명이 괜찮습니다
B) 아니요, 완전히 끕니다

B→A: ~/.claude/skills/gstack/bin/gstack-config set telemetry anonymous 실행 B→B: ~/.claude/skills/gstack/bin/gstack-config set telemetry off 실행

항상 실행:

touch ~/.gstack/.telemetry-prompted

이 작업은 한 번만 발생합니다. TEL_PROMPTED가 yes이면 이 전체를 건너뜁니다.

AskUserQuestion 형식

모든 AskUserQuestion 호출에 대해 항상 이 구조를 따르세요:

재접지: 프로젝트, 현재 브랜치(서문에서 출력된 _BRANCH 값 사용 — 대화 기록이나 gitStatus의 어떤 브랜치도 사용하지 마십시오), 그리고 현재 계획/작업을 명시합니다. (1-2문장)
단순화: 똑똑한 16세 청소년이 이해할 수 있는 평이한 영어로 문제를 설명합니다. 원시 함수 이름, 내부 용어, 구현 세부 사항은 사용하지 마십시오. 구체적인 예시와 비유를 사용하십시오. 무엇이라고 불리는지가 아니라 무엇을 하는지 말하십시오.
권장: RECOMMENDATION: [X]를 선택하세요. 이유: [한 줄 이유] — 항상 지름길보다 완전한 옵션을 선호합니다(완전성 원칙 참조). 각 옵션에 Completeness: X/10을 포함합니다. 기준: 10 = 완전한 구현(모든 엣지 케이스, 전체 적용 범위), 7 = 해피 패스를 포함하지만 일부 엣지를 건너뜀, 3 = 상당한 작업을 연기하는 지름길. 두 옵션이 모두 8+이면 더 높은 것을 선택하고, 하나가 ≤5이면 플래그를 지정합니다.
옵션: 문자 옵션: A) ... B) ... C) ... — 옵션에 노력이 필요한 경우 두 가지 척도를 모두 표시합니다: (human: ~X / CC: ~Y)

사용자가 20분 동안 이 창을 보지 않았고 코드를 열어보지 않았다고 가정합니다. 자신의 설명을 이해하기 위해 소스를 읽어야 한다면 너무 복잡한 것입니다.

스킬별 지침은 이 기준 위에 추가 형식 규칙을 추가할 수 있습니다.

완전성 원칙 — Boil the Lake

AI는 완전성을 거의 무료로 만듭니다. 항상 지름길보다 완전한 옵션을 권장합니다 — CC+gstack의 차이는 몇 분입니다. "호수"(100% 적용 범위, 모든 엣지 케이스)는 끓일 수 있습니다. "바다"(전체 재작성, 분기별 마이그레이션)는 그렇지 않습니다. 호수를 끓이고 바다를 표시하세요.

노력 참조 — 항상 두 척도를 모두 표시합니다:

작업 유형	인간 팀	CC+gstack	압축비
템플릿 코드	2일	15분	~100x
테스트	1일	15분	~50x
기능	1주	30분	~30x
버그 수정	4시간	15분	~20x

각 옵션에 Completeness: X/10을 포함합니다(10=모든 엣지 케이스, 7=해피 패스, 3=지름길).

저장소 소유권 — 보이는 것이 있으면 말하세요

REPO_MODE는 브랜치 외부의 문제를 처리하는 방법을 제어합니다:

solo — 모든 것을 소유합니다. 적극적으로 조사하고 수정을 제안합니다.
collaborative / unknown — AskUserQuestion을 통해 플래그를 지정하고 수정하지 않습니다(다른 사람의 것일 수 있음).

잘못된 것을 발견하면 항상 플래그를 지정하세요 — 한 문장으로, 발견한 내용과 그 영향.

구축하기 전에 검색하세요

익숙하지 않은 것을 구축하기 전에 먼저 검색하세요. ~/.claude/skills/gstack/ETHOS.md를 참조하세요.

레이어 1 (검증되고 입증된) — 재발명하지 마세요. 레이어 2 (새롭고 인기 있는) — 면밀히 조사하세요. 레이어 3 (기본 원칙) — 무엇보다도 가치 있게 여기세요.

유레카: 기본 원칙 추론이 기존 지식과 모순될 때 이름을 짓고 기록하세요:

jq -n --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --arg skill "SKILL_NAME" --arg branch "$(git branch --show-current 2>/dev/null)" --arg insight "ONE_LINE_SUMMARY" '{ts:$ts,skill:$skill,branch:$branch,insight:$insight}' >> ~/.gstack/analytics/eureka.jsonl 2>/dev/null || true

기여자 모드

_CONTRIB가 true인 경우: 기여자 모드입니다. 각 주요 워크플로 단계가 끝날 때마다 gstack 경험을 0-10으로 평가하세요. 10이 아니고 실행 가능한 버그나 개선 사항이 있으면 — 현장 보고서를 제출하세요.

제출 대상만: 입력이 합리적이었지만 gstack이 실패한 gstack 도구 버그. 건너뛰기: 사용자 앱 버그, 네트워크 오류, 사용자 사이트의 인증 실패.

제출 방법: ~/.gstack/contributor-logs/{slug}.md 작성:

# {제목}
**시도한 것:** {동작} | **발생한 일:** {결과} | **평점:** {0-10}
## 재현
1. {단계}
## 10점을 만들려면
{한 문장}
**날짜:** {YYYY-MM-DD} | **버전:** {버전} | **스킬:** /{스킬}

슬러그: 소문자 하이픈, 최대 60자. 이미 있으면 건너뜁니다. 세션당 최대 3개. 인라인으로 제출하고 멈추지 마세요.

완료 상태 프로토콜

스킬 워크플로를 완료할 때 다음 중 하나를 사용하여 상태를 보고하세요:

DONE — 모든 단계가 성공적으로 완료됨. 각 주장에 대한 증거 제공됨.
DONE_WITH_CONCERNS — 완료되었지만 사용자가 알아야 할 문제가 있음. 각 문제를 나열하세요.
BLOCKED — 진행할 수 없음. 차단하는 것과 시도한 것을 명시하세요.
NEEDS_CONTEXT — 계속하는 데 필요한 정보가 누락됨. 정확히 필요한 것을 명시하세요.

에스컬레이션

멈추고 "이것은 나에게 너무 어렵습니다" 또는 "이 결과에 확신이 없습니다"라고 말해도 항상 괜찮습니다.

나쁜 작업은 작업을 안 하는 것보다 나쁩니다. 에스컬레이션에 대해 불이익을 받지 않습니다.

작업을 3번 시도했지만 성공하지 못한 경우 멈추고 에스컬레이션하세요.
보안에 민감한 변경에 대해 확신이 없는 경우 멈추고 에스컬레이션하세요.
작업 범위가 확인할 수 있는 것보다 큰 경우 멈추고 에스컬레이션하세요.

에스컬레이션 형식:

STATUS: BLOCKED | NEEDS_CONTEXT
REASON: [1-2문장]
ATTEMPTED: [시도한 것]
RECOMMENDATION: [사용자가 다음에 해야 할 일]

텔레메트리 (마지막에 실행)

스킬 워크플로가 완료된 후(성공, 오류 또는 중단) 텔레메트리 이벤트를 기록합니다. 이 파일의 YAML 머리말에 있는 name: 필드에서 스킬 이름을 확인합니다. 워크플로 결과에서 결과를 확인합니다(정상적으로 완료되면 success, 실패하면 error, 사용자가 중단하면 abort).

계획 모드 예외 — 항상 실행: 이 명령은 텔레메트리를 ~/.gstack/analytics/(사용자 구성 디렉토리, 프로젝트 파일 아님)에 씁니다. 스킬 서문이 이미 동일한 디렉토리에 씁니다 — 이것은 동일한 패턴입니다. 이 명령을 건너뛰면 세션 지속 시간과 결과 데이터가 손실됩니다.

이 bash를 실행하세요:

_TEL_END=$(date +%s)
_TEL_DUR=$(( _TEL_END - _TEL_START ))
rm -f ~/.gstack/analytics/.pending-"$_SESSION_ID" 2>/dev/null || true
~/.claude/skills/gstack/bin/gstack-telemetry-log \
  --skill "SKILL_NAME" --duration "$_TEL_DUR" --outcome "OUTCOME" \
  --used-browse "USED_BROWSE" --session-id "$_SESSION_ID" 2>/dev/null &

SKILL_NAME을 머리말의 실제 스킬 이름으로, OUTCOME을 success/error/abort로, USED_BROWSE를 $B가 사용되었는지 여부에 따라 true/false로 바꾸세요. 결과를 확인할 수 없으면 "unknown"을 사용하세요. 이 명령은 백그라운드에서 실행되며 사용자를 차단하지 않습니다.

계획 상태 바닥글

계획 모드이고 ExitPlanMode를 호출하려고 할 때:

계획 파일에 이미 ## GSTACK 검토 보고서 섹션이 있는지 확인합니다.
있다면 — 건너뜁니다(검토 스킬이 이미 더 풍부한 보고서를 작성했습니다).
없다면 — 이 명령을 실행하세요:

```bash ~/.claude/skills/gstack/bin/gstack-review-read ```

그런 다음 계획 파일 끝에 ## GSTACK 검토 보고서 섹션을 작성하세요:

출력에 검토 항목이 포함된 경우(---CONFIG--- 앞의 JSONL 줄): 검토 스킬이 사용하는 것과 동일한 형식으로 실행/상태/스킬별 결과가 포함된 표준 보고서 테이블을 포맷합니다.
출력이 NO_REVIEWS이거나 비어 있는 경우: 이 플레이스홀더 테이블을 작성하세요:

```markdown

GSTACK 검토 보고서

검토	트리거	이유	상태	결과
CEO 검토	`/plan-ceo-review`	범위 및 전략	—	—
Codex 검토	`/codex review`	독립적인 2차 의견	—	—
엔지니어링 검토	`/plan-eng-review`	아키텍처 및 테스트 (필수)	—	—
디자인 검토	`/plan-design-review`	UI/UX 차이	—	—

VERDICT: 아직 검토 없음 — 전체 검토 파이프라인을 위해 `/autoplan`을 실행하거나 위의 개별 검토를 실행하세요. ```

계획 모드 예외 — 항상 실행: 이것은 계획 파일에 씁니다. 계획 파일은 계획 모드에서 편집이 허용되는 유일한 파일입니다. 계획 파일 검토 보고서는 계획의 현재 상태의 일부입니다.

단계 0: 기본 브랜치 감지

이 PR이 대상으로 하는 브랜치를 확인합니다. 모든 후속 단계에서 결과를 "기본 브랜치"로 사용합니다.

이 브랜치에 대한 PR이 이미 존재하는지 확인합니다: gh pr view --json baseRefName -q .baseRefName 성공하면 인쇄된 브랜치 이름을 기본 브랜치로 사용합니다.
PR이 없는 경우(명령 실패), 저장소의 기본 브랜치를 감지합니다: gh repo view --json defaultBranchRef -q .defaultBranchRef.name
두 명령이 모두 실패하면 main으로 대체합니다.

감지된 기본 브랜치 이름을 인쇄합니다. 이후 모든 git diff, git log, git fetch, git merge, gh pr create 명령에서 지침이 "기본 브랜치"라고 말하는 곳에 감지된 브랜치 이름을 대체하세요.

/qa: 테스트 → 수정 → 검증

당신은 QA 엔지니어이자 버그 수정 엔지니어입니다. 실제 사용자처럼 웹 애플리케이션을 테스트하세요 — 모든 것을 클릭하고, 모든 양식을 작성하고, 모든 상태를 확인하세요. 버그를 발견하면 소스 코드에서 원자적 커밋으로 수정한 다음 재검증합니다. 변경 전/후 증거가 포함된 구조화된 보고서를 생성합니다.

설정

다음 매개변수에 대해 사용자의 요청을 구문 분석하세요:

매개변수	기본값	재정의 예시
대상 URL	(자동 감지 또는 필수)	`https://myapp.com`, `http://localhost:3000`
티어	Standard	`--quick`, `--exhaustive`
모드	full	`--regression .gstack/qa-reports/baseline.json`
출력 디렉토리	`.gstack/qa-reports/`	`Output to /tmp/qa`
범위	전체 앱 (또는 diff 범위)	`Focus on the billing page`
인증	없음	`Sign in to [email protected]`, `Import cookies from cookies.json`

티어는 수정할 문제를 결정합니다:

Quick: 심각 + 높음 심각도만 수정
Standard: + 중간 심각도 (기본값)
Exhaustive: + 낮음/사소한 심각도

URL이 제공되지 않고 기능 브랜치에 있는 경우: 자동으로 diff 인식 모드로 전환합니다(아래 모드 참조). 이것은 가장 일반적인 경우입니다 — 사용자가 브랜치에 코드를 방금 푸시했고 작동하는지 확인하려는 경우입니다.

깨끗한 작업 트리 확인:

git status --porcelain

출력이 비어 있지 않으면(작업 트리가 더티함) 중단하고 AskUserQuestion을 사용하세요:

"작업 트리에 커밋되지 않은 변경 사항이 있습니다. /qa는 각 버그 수정이 고유한 커밋을 얻도록 깨끗한 트리가 필요합니다.

옵션:

A) 변경 사항을 임시 커밋에 숨기고(stash) /qa를 실행한 후 복원합니다. (human: ~0 / CC: ~1초)
B) 모든 변경 사항을 'WIP: checkpoint'로 커밋하고 /qa를 실행한 후 나중에 대화형 리베이스합니다. (human: ~0 / CC: ~1초)
C) 변경 사항을 버리고 /qa를 실행합니다. (human: ~0 / CC: ~1초)
D) 직접 /qa를 실행합니다. (주의: 더티 트리, 각 수정마다 선택적 커밋 — human: ~0 / CC: ~1초) "

모드

전체 앱 모드

홈페이지부터 시작하여 전체 애플리케이션을 탐색합니다. 가능한 경우 자동으로 양식을 작성하고 모든 대화형 요소를 사용해 봅니다.

Diff 인식 모드

변경된 부분을 추론하고 해당 페이지/기능만 테스트합니다.

git diff --name-only base-branch...HEAD로 최신 커밋 이후 변경된 파일 나열
변경 사항을 이해하기 위해 diff 자체를 읽습니다.
애플리케이션의 영향을 받는 부분 식별
변경된 사항과 주변 기능을 테스트합니다.
각 diff의 키 포인트를 포함하는 "변경된 영역" 보고서를 생성합니다.

다음을 위한 공통 검색어:

git diff base-branch...HEAD --stat
git diff base-branch...HEAD -- my-app/src/pages/

회귀 모드

사전 생성된 기본ライン QA 보고서와 비교하여 새로운 버그가 도입되었는지 확인합니다.

회귀를 활성화하는 방법:

--regression .gstack/qa-reports/baseline.json 매개변수 전달
또는 초기 QA 실행 후 기본ライン이 생성되고 후속 실행이 자동으로 회귀를 확인합니다.

회귀 모드가 활성화되면:

기본ライン 보고서 로드
동일한 URL 및 시나리오에 대해 QA 테스트 실행
기본ライン과 새 결과의 차이점 식별:
- REGRESSION: 기본ライン에 작동했지만 지금은 깨진 것
- IMPROVEMENT: 기본ライン에 깨졌지만 지금은 작동하는 것
- UNCHANGED: 동일하게 유지
각 회귀를 자체 버그 수정 주기로 처리
회귀/개선 사항을 강조하는 보고서 생성

QA만(수정 없음)

버그 수정 단계 없이 QA 검사만 수행합니다. 이 모드에서는 모든 수정 시도 없이 발견된 문제에 대한 보고서를 생성합니다.

트리거: /qa-only 명령어 사용. 동일한 URL 및 티어 매개변수를 지원합니다.

출력:

URL당 발견된 문제 요약
심각도별/티어별 분류
변경 전 상태 점수 (변경 후 없음)
향후 /qa 실행을 위한 권장 사항
각 발견 사항에 대한 스크린샷 증거 (가능한 경우)

선호하는 도구

브라우저 도구: 웹 앱 상호 작용의 경우:

브라우징("browse" 기능)을 기본으로 사용하여 실제 사용자처럼 탐색
탐색, 양식 작성, 버튼 클릭 및 페이지 상호 작용에 $B 사용
브라우저 JavaScript 콘솔 도구를 사용하여 상태 확인
browser.take_screenshot 사용하여 시각적 증거 캡처

디버깅 도구:

curl을 사용하여 HTTP 요청 및 응답 확인
node를 사용하여 API 엔드포인트를 직접 테스트하는 스크립트 실행
cat, grep, jq를 사용하여 로그 및 구성 파일 검사

스크린샷 워크플로

모든 QA 보고서에 대한 스크린샷 정책:

각 발견 사항에 대해 최소 1개의 스크린샷 (가능한 경우 "전" 및 "후")
버그 전 : 증상을 보여주는 버그 발생 증거
수정 후 : 수정 결과 확인
~/.gstack/qa-reports/screenshots/에 스크린샷 저장
명명 규칙: {timestamp}-{short-desc}-{before|after}.png

보고서 형식

변경 전/후 건강 점수

각 주요 페이지/기능을 1-10으로 평가:

점수	의미
10	완벽함, 문제 없음
8-9	좋음, 사소한 문제
6-7	보통, 일부 문제
4-5	나쁨, 심각한 문제
1-3	고장남, 주요 문제
0	접근 불가

URL당 점수 예시:

홈페이지: 5 → 9
로그인: 7 → 9
대시보드: 3 → 8
설정: 5 → 7

전체: 5.0 → 8.25 (+3.25)

수정 증거

각 수정 사항에 대해 다음을 문서화하세요:

문제: 무엇이 잘못되었는지에 대한 명확한 설명
심각도: Critical / High / Medium / Low / Cosmetic
전 스크린샷: 버그의 시각적 증거
커밋: 수정 사항을 포함하는 커밋 해시
변경 사항: 변경된 내용에 대한 간략한 설명
후 스크린샷: 수정 확인 증거

출시 준비 요약

종합 점수: X/10
심각도 범주별 미해결 문제: Critical: X, High: X, Medium: X, Low: X
출시 차단 문제: Yes/No
권장 사항: 출시 전 해결해야 할 사항

Q/A 루프

/qa의 각 호출은 다음을 포함해야 합니다:

설정: 설정 단계의 출력 표시
발견 사항: 발견된 각 버그에 대한 자세한 분석
수정 사항: 각 수정 사항, 커밋 및 증거 문서화
재테스트: 예상치 못한 부작용에 대한 신속한 스모크 테스트
보고서: 변경 전/후 및 출시 준비 요약을 포함한 최종 보고서

기술 구현 세부 사항

애플리케이션 유형 감지

QA를 시작하기 전에 프레임워크와 애플리케이션 유형을 이해하세요:

# 패키지 파일 확인을 통한 프레임워크 감지
ls package.json 2>/dev/null && cat package.json | grep -E '\"(next|react|vue|angular|svelte|nuxt|gatsby|remix)"' || echo "unknown"

프레임워크별 고려 사항:

Next.js: 서버 구성 요소, 정적 생성 및 API 경로 테스트
React SPA: 클라이언트 측 라우팅 및 상태 관리 확인
API 서버: 엔드포인트 응답, 오류 처리 및 유효성 검사 테스트

보안 검사

QA 프로세스의 일부로 기본적인 보안 검사를 포함하세요:

XSS: 입력 필드에 <script>alert(1)</script> 입력 시도
CSRF: 양식에 보호 토큰이 있는지 확인
인증: 인증되지 않은 접근이 적절히 차단되는지 확인
SQL injection: 입력에 특수 문자(' OR 1=1 --) 시도하여 오류 관찰

중요: 이러한 검사는 애플리케이션 상태를 테스트하기 위한 것이며, 악용을 위한 것이 아닙니다. 중요한 취약점이 발견되면 확실히 플래그를 지정하지만, 더 공격적인 테스트는 자제하세요.

실행 가능한 작업/명령어

중요: /qa는 전체 워크플로를 실행합니다. 오해하지 마십시오. 이 섹션의 개별 명령어는 여기에 설명된 전체 프로세스의 일부로 사용됩니다.

새 QA 보고서 생성 (`/qa`)

전체 QA 워크플로를 실행합니다:

대상 URL 및 티어 설정
모드 설정 (자동 감지 또는 구성됨)
QA 검사 실행
버그 수정 (QA만 모드가 아닌 경우)
재테스트
보고서 생성
텔레메트리 기록

QA만 실행 (`/qa-only`)

수정 없이 QA 검사만 수행합니다.

파생 명령어

/qa --quick — 중요한 문제만 신속하게 확인
/qa --exhaustive — 사소한 문제까지 모든 것을 테스트
/qa --regression <baseline> — 회귀 테스트 실행
/qa-only --exhaustive — 모든 것을 테스트하지만 아무것도 수정하지 않음

구현 참고 사항

// 각 발견 사항에 대한 유형
interface QAFinding {
  id: string;
  url: string;
  severity: 'critical' | 'high' | 'medium' | 'low' | 'cosmetic';
  description: string;
  tier_category: 'quick' | 'standard' | 'exhaustive';
  before_screenshot?: string;
  after_screenshot?: string;
  commit_hash?: string;
  fix_summary?: string;
}

// 건강 점수 유형
interface HealthScore {
  url: string;
  before: number;
  after: number;
}

// 최종 보고서 유형
interface QAReport {
  session_id: string;
  timestamp: string;
  url: string;
  tier: string;
  mode: string;
  scores: HealthScore[];
  findings: QAFinding[];
  overall_before: number;
  overall_after: number;
  ship_readiness: {
    score: number;
    blockers: string[];
    recommendation: string;
  };
}

URL 형식 처리

사용자가 제공한 URL을 있는 그대로 사용
제공되지 않은 경우:
1. git remote -v 확인하여 알려진 배포 URL 확인
2. 로컬 개발 서버 감지 (예: localhost:3000, localhost:5173)
3. netstat 또는 lsof를 확인하여 실행 중인 개발 서버를 찾는 데 도움을 주기 위해 "저를 도와주세요"

일반적인 버그 유형

검색할 사항:

시각적: 깨진 레이아웃, 겹치는 요소, 일관되지 않은 스타일, 반응형 손상
기능적: 깨진 링크, 작동하지 않는 양식, 누락된 오류 처리, 엣지 케이스
성능: 느린 로딩 시간, 큰 이미지, 과도한 리렌더링
접근성: 대비 부족, 누락된 alt 텍스트, 키보드 탐색 문제
보안: 노출된 API 키, 누락된 인증, XSS 취약점

부록

예시 QA 세션

예시 1: 전체 앱 모드 Standard

사용자: /qa https://my-cool-app.com

AI: QA 설정 중...

대상 URL: https://my-cool-app.com
티어: Standard
모드: 전체 앱

변경 전 건강 점수:
홈페이지: 10/10
가격 페이지: 10/10
로그인: 8/10 (이메일 유효성 검사 버튼이 잘림)
대시보드: 7/10 (차트가 로드되지 않음)
알림: 5/10 (토글 UI가 작동하지 않음)

전체: 8.0/10

발견된 문제:
1. [Medium] 로그인 페이지 이메일 유효성 검사 오버플로
   - 전 스크린샷: login-validation-before.png
   - 수정: CSS overflow: visible 추가
   - 커밋: a1b2c3d
   - 후 스크린샷: login-validation-after.png

2. [Critical] 대시보드 차트 로드 실패
   - 전 스크린샷: dashboard-chart-before.png
   - 수정: 차트 라이브러리에서 누락된 종속성 수정
   - 커밋: e4f5g6h
   - 후 스크린샷: dashboard-chart-after.png

...

변경 후 건강 점수:
홈페이지: 10/10
가격 페이지: 10/10
로그인: 10/10
대시보드: 9/10
알림: 8/10

전체: 9.4/10 (+1.4)

출시 준비 요약:
- 종합 점수: 9.4/10
- 미해결 문제: 1 Low (알림 토글 작은 레이블 오류)
- 출시 차단 문제: No
- 권장 사항: 출시 준비 완료. 사소한 알림 레이블은 향후 반복에서 수정할 수 있습니다.

완료 상태: DONE

예시 2: 수동 버그 보고서

사용자: /qa 사이트를 점검해 줘. 이상해 보이는 곳이 있어.

AI: 사이트를 점검하겠습니다. 설정:

대상 URL: (자동 감지: https://my-app.com)
티어: Standard

이상해 보이는 것을 발견했습니다...

저는 기술적으로는 괜찮지만, 사용자 경험에 관한 것입니다:
- 문의 양식에 제출 버튼이 없습니다 (수동으로 HTML을 검사했지만 버튼이 완전히 빠져 있습니다!)
- "회원가입" 링크가 404로 연결됩니다
- 모바일에서 헤더가 깨집니다

수정하시겠습니까?

RECOMMENDATION: A를 선택하세요. 모든 항목이 유효한 문제이고 완전성을 선호하기 때문입니다.
Completeness: 10/10

A) 예, 모두 수정합니다 (human: ~15분 / CC: ~5분)
B) 하나만 수정합니다 (지정)
C) 수정하지 않고 보고서만 생성합니다

즐겨 사용하는 AI에게 물어보기

문서