brainstorm-experiments-existing

brainstorm-experiments-existing 개요

brainstorm-experiments-existing는 이미 존재하는 제품에 대해, 엔지니어링 시간을 본격적으로 쓰기 전에 저비용 실험을 설계하도록 돕는 워크플로 중심의 스킬입니다. 기능 아이디어와 여러 가정들을 프로토타입, 페이크 도어 테스트, A/B 테스트, 기술 스파이크, 위자드 오브 오즈 플로우, 행동 설문 같은 검증 가능한 विकल्प으로 바꿔 줍니다. 핵심 업무는 단순합니다. 위험한 과설계를 피하면서 불확실성을 빠르게 줄이는 것.

이 스킬이 가장 잘 맞는 사람

이미 제품이 있고, 바꾸려는 방향이 있으며, 답을 얻어야 할 질문이 최소 하나는 있을 때 brainstorm-experiments-existing를 사용하세요. 제품 관리자, 디자이너, 창업자, 엔지니어처럼 범위, 수요, 사용성, 기술적 타당성을 실용적으로 검증할 brainstorm-experiments-existing 가이드가 필요한 사람에게 잘 맞습니다.

무엇이 다른가

이 스킬은 흔한 아이디어 발상 프롬프트가 아닙니다. 단순한 의견이 아니라 행동을 측정하는 실험을 밀어붙이고, 테스트가 프로덕션에 닿을 때는 리스크 완화까지 함께 생각하게 합니다. 그래서 워크플로 자동화 맥락에서의 brainstorm-experiments-existing는, 넓은 기능 아이디어 목록보다 의사결정 지원이 필요할 때 특히 유용합니다.

언제 특히 적합한가

“이걸 만들어야 할까, 아니면 먼저 어떻게 싸게 검증할까?”를 결정해야 할 때 이 스킬을 선택하세요. 검증하려는 가정을 명확히 말할 수 있고, 학습 속도·비용·사용자 안전을 중요하게 볼수록 이 brainstorm-experiments-existing 스킬의 강점이 잘 드러납니다.

brainstorm-experiments-existing 스킬 사용법

설치 후 실제 맥락에 연결하기

스킬 관리자에서 brainstorm-experiments-existing 설치 경로를 사용한 뒤, 이미 가지고 있는 가장 관련성 높은 자료를 입력하세요. PRD 메모, 가정 목록, 디자인 목업, 고객지원 티켓, 대략적인 기능 브리프가 모두 좋습니다. 이 스킬은 $ARGUMENTS를 바탕으로 동작하도록 설계되어 있으므로, 입력이 명확할수록 실험 계획의 품질도 좋아집니다.

막연한 아이디어를 쓸 만한 프롬프트로 바꾸기

약한 프롬프트는 “새 온보딩 기능을 테스트하는 걸 도와줘” 수준입니다. 더 강한 프롬프트는 이렇습니다. “SMB 관리자들의 활성화를 높이기 위해 팀 기반 온보딩을 추가하려고 합니다. 핵심 리스크는 발견 가능성과 완료 시간이라고 가정합니다. 가장 적은 노력으로 검증할 수 있는 실험 3개를 제안하고, 각 실험의 성공 기준도 적어 주세요.”

이런 방식이 통하는 이유는 brainstorm-experiments-existing 사용 흐름에 구체적인 제품 영역, 목표 사용자, 측정 가능한 가정을 함께 주기 때문입니다.

저장소를 올바른 순서로 읽기

SKILL.md부터 보세요. 핵심 워크플로와 출력 기대치가 들어 있습니다. 로컬 복사본에 보조 문서가 있다면, 다음으로 README.md, AGENTS.md, metadata.json, 그리고 rules/, resources/, references/, scripts/ 폴더를 확인하세요. 이 저장소는 스킬이 간결하고 지원 파일도 최소한이라, 대부분의 가치는 메인 지침 파일을 정확히 이해하는 데서 나옵니다.

더 나은 의사결정을 위한 출력 형태 만들기

결과를 가정, 실험 유형, 비용, 리스크, 예상 신호 기준으로 정리해 달라고 요청하세요. 가능하다면 “프로덕션 리스크 없음”, “1주 일정”, “디자인 리소스 없음” 같은 제약도 함께 넣으세요. 그런 정보가 있어야 brainstorm-experiments-existing 가이드가 흥미로운 이론이 아니라 실제로 배포 가능한 실험을 제안할 수 있습니다.

brainstorm-experiments-existing 스킬 FAQ

이건 그냥 브레인스토밍 프롬프트인가요?

아닙니다. brainstorm-experiments-existing 스킬은 열린 발상 회의가 아니라, 이미 있는 제품에 대한 구조화된 검증에 초점을 둡니다. 긴 아이디어 목록보다 가설을 반증할 수 있는 실험이 필요할 때 가장 유용합니다.

언제 쓰지 않는 게 좋나요?

제품 문제, 목표 사용자, 검증할 가정이 아직 불명확하다면 이 스킬을 건너뛰세요. 또한 구현 계획이 필요할 뿐 검증이 목적이 아닐 때, 혹은 아이디어가 너무 초기 단계라 먼저 탐색 인터뷰가 필요한 경우에도 잘 맞지 않습니다.

초보자도 사용할 수 있나요?

네. 제품 아이디어를 평이한 언어로 설명할 수만 있으면 됩니다. 초보자는 대략적인 목표, 사용자 세그먼트, 의심되는 리스크를 함께 주면 가장 큰 도움을 얻습니다. 그러면 brainstorm-experiments-existing 스킬이 불확실성을 구체적인 테스트 विकल्प으로 바꿔 줍니다.

Workflow Automation과는 어떻게 맞물리나요?

검증 단계를 자동으로 제안하거나, 실험 유형을 비교하거나, 증거 수집 기준에 대해 팀을 정렬시키고 싶을 때 워크플로 자동화용으로 brainstorm-experiments-existing를 사용하세요. 다만 실험을 실행하는 자동화보다, 테스트 플랜을 설계하는 데 더 강합니다.

brainstorm-experiments-existing 스킬 개선 방법

가정을 더 날카롭게 정의하기

품질이 가장 크게 좋아지는 지점은 가정을 정확하게 적는 것입니다. “사용자가 좋아할까?” 대신 “처음 사용하는 관리자가 도움 없이 새로운 일괄 초대 흐름을 찾을 수 있을까?”처럼 바꿔 보세요. 그러면 brainstorm-experiments-existing 스킬이 각 가정을 더 저렴한 실험과 명확한 신호로 연결할 수 있습니다.

실험을 바꾸는 제약 조건 추가하기

일정, 위험 허용치, 사용 가능한 트래픽, 도구 제한을 포함하세요. 예를 들어 “스테이징에서만 테스트 가능”, “한 스프린트만 사용 가능”, “기존 분석은 쓸 수 있지만 새 트래킹은 불가” 같은 조건입니다. 이런 제약은 brainstorm-experiments-existing 가이드가 이상적인 실험이 아니라 현실적인 실험을 추천하도록 만듭니다.

의사결정에 바로 쓰일 출력 요청하기

가정, 실험, 신호, 리스크, 다음 단계를 포함한 형식을 요청하세요. 그래야 옵션 비교가 쉬워지고, 애매한 권고도 줄어듭니다. 첫 결과가 너무 넓다면 실험 수를 줄이거나, 반증 기준을 더 강하게 하거나, 노력 대비 얻는 확신 기준으로 순위를 매겨 달라고 다시 요청하세요.

첫 결과 이후 프롬프트 다듬기

결과가 일반적이라면, 현재 제품의 실제 동작, 사용자 여정, 성공과 실패의 기준에 대한 맥락을 더 보태세요. brainstorm-experiments-existing 설치는 검증 코파일럿처럼 다룰 때 가장 가치가 큽니다. 실제 제약을 넣고, 각 실험이 만들지 여부를 결정할 만한 근거가 될 때까지 계획을 계속 다듬으세요.