think

think 스킬 개요

think 스킬이 하는 일

think는 코드 작성 전에 거친 아이디어를 명확하고 승인 가능한 계획으로 정리해 주는 의사결정 지원 스킬입니다. 기능 설계, 아키텍처 선택, 트레이드오프 분석, 그리고 무엇보다 “이걸 해야 하나?” 같은 판단형 질문에 특히 잘 맞습니다. 핵심이 구현이 아니라 판단일 때 가장 효과적입니다.

누가 설치하면 좋은가

리포지토리 중심 워크플로에서 제품 의사결정, 기술 방향, 범위가 정해진 계획 수립을 자주 도와야 한다면 think 스킬을 설치하세요. 요청이 “이걸 어떻게 계획할까”, “가장 나은 접근은 뭐지”, “이걸 유지하는 게 맞을까”처럼 가치 판단으로 시작될 때 특히 유용합니다.

무엇이 다른가

이 스킬은 꽤 의견이 분명합니다. 구체적인 추천안을 밀어주고, 어떤 증거가 나오면 추천이 바뀔 수 있는지까지 짚어 주며, 시기상조인 코딩은 피합니다. 그래서 think for Decision Support는 의사결정에 바로 쓸 수 있는 출력이 필요할 때, 일반적인 브레인스토밍 프롬프트보다 훨씬 강합니다.

think 스킬 사용 방법

설치하고 트리거하기

npx skills add tw93/Waza --skill think로 설치한 뒤, 작업이 알려진 버그를 고치는 게 아니라 방향을 고르거나, 다듬거나, 타당성을 검증하는 일일 때 사용하세요. think install 단계 자체는 간단하지만, 결과의 질은 실제 의사결정 맥락을 얼마나 잘 주느냐에 달려 있습니다.

입력 형식을 제대로 맞추기

효과적인 think usage 프롬프트에는 목표, 제약, 대상, 그리고 실제로 열려 있는 선택지가 들어가야 합니다. 예: “SMB 관리자를 위한 온보딩 흐름을 더 빠르게 만들어야 합니다. 이번 스프린트에서는 UI만 바꿀 수 있고 백엔드 작업은 불가합니다. 트레이드오프까지 포함한 추천이 필요합니다.”

먼저 읽어야 할 파일

이 저장소는 의도적으로 최소 구성이라 rules/, references/, resources/ 폴더가 없습니다. 따라서 먼저 SKILL.md부터 읽으세요. 실무적인 가이드는 주로 스킬 본문에 들어 있습니다. 가벼운 모드, 평가 모드, 그리고 승인 전까지 구현 단계로 들어가지 말라는 규칙이 핵심입니다.

워크플로를 의사결정 퍼널로 쓰기

좋은 think guide 흐름은 다음과 같습니다. 먼저 결정을 명시하고, 제약을 나열한 다음, 가장 나은 경로를 요청하세요. 필요할 때만 위험 요소와 대안을 포함한 계획을 추가로 받으면 됩니다. 가벼운 모드와 전체 모드 중 무엇을 써야 할지 애매하다면, 문제가 이미 정의되어 있는지 설명하세요. 이 한 가지 정보만으로도 출력이 크게 달라집니다.

think 스킬 FAQ

think는 새 기능에만 쓰나요?

아닙니다. 아키텍처 결정, 제품 가치 판단, 실제 트레이드오프가 있는 리팩터링, 그리고 “이걸 할 가치가 있나?” 같은 질문에도 유용합니다. 다만 답이 이미 자명한 단순 버그 수정이나 작은 수정에는 가장 잘 맞지 않습니다.

일반 프롬프트와 무엇이 다른가요?

일반 프롬프트는 종종 애매한 선택지만 내놓습니다. 반면 think 스킬은 하나의 추천 경로, 명시적인 트레이드오프, 그리고 승인 전에는 코딩하지 않겠다는 분명한 경계를 강제하도록 설계되어 있습니다. 그래서 팀원이나 이해관계자가 검토할 수 있는 계획이 필요할 때 더 적합합니다.

think는 초보자도 쓰기 쉬운가요?

네, 사용자가 목표를 평이한 언어로 설명할 수 있다면 그렇습니다. 초보자는 기술 용어를 몰라도 문제, 제약, 원하는 결과만 분명히 적어 주면 가장 큰 효과를 볼 수 있습니다.

언제 think를 쓰지 말아야 하나요?

이미 수정 방법을 알고 있고 실행만 필요할 때는 쓰지 마세요. 또는 작업이 너무 좁아서 분석보다 직접 수정이 더 빠른 경우도 마찬가지입니다. 또, 실제로 결정할 일이 없고 빠른 재작성만 필요하다면 이 스킬의 가치가 상대적으로 낮습니다.

think 스킬 개선 방법

의사결정 수준의 맥락을 제공하기

가장 좋은 think skill 입력에는 현재 상태, 목표 상태, 양보할 수 없는 제약, 그리고 성공 기준이 들어갑니다. 예를 들어 “설정 시간을 10분에서 2분으로 줄여야 하고, 현재 백엔드는 유지해야 하며, 새 의존성은 피해야 합니다”는 “온보딩을 개선해 주세요”보다 훨씬 좋은 답을 끌어냅니다.

아이디어만 말하지 말고 결정을 요청하기

더 나은 think usage를 원한다면, 가능한 선택지를 나열하기보다 근거가 있는 추천안을 요청하세요. 좋은 예: “이 제약 아래에서 왜 이 접근이 가장 유리한지 설명하면서 하나를 선택해 주세요.” 약한 예: “아이디어 좀 주세요.”

중요하게 보는 트레이드오프를 드러내기

속도, 유지보수성, 비용, UX, 리스크, 팀 역량 중 무엇이 중요한지 알려 주세요. 그러면 think for Decision Support가 일반적인 모범 사례 답변이 아니라, 당신의 우선순위에 맞는 계획을 제시하기 쉽습니다.

더 날카로운 제약으로 반복하기

첫 결과가 너무 넓다면 후속 질문 하나로 범위를 좁히세요. 마감일, 금지된 의존성, 대상 사용자, 반드시 유지해야 하는 구성 요소를 추가하면 됩니다. 출력 품질을 가장 빠르게 높이는 방법은 다음 계획을 요청하기 전에 숨은 가정을 명시적인 제약으로 바꾸는 것입니다.