idea-refine

idea-refine 스킬 개요

idea-refine는 거친 아이디어를 발산적 사고, 비판적 검토, 수렴 과정을 통해 더 선명하고 실제로 만들 수 있는 방향으로 정리해 주는 구조화된 아이데이션 스킬입니다. 특히 명세를 쓰거나 구현에 들어가기 전에 “무엇을 만들지” 먼저 결정해야 하는 창업자, 제품 리드, 엔지니어, 그리고 Requirements Planning을 수행하는 AI 에이전트에 잘 맞습니다. idea-refine 스킬의 핵심 가치는 막연한 브레인스토밍이 아니라, 모호한 생각을 가정, 범위, 그리고 명확한 “하지 않을 것” 목록이 포함된 구체적인 원페이지 문서로 밀어붙여 정리한다는 데 있습니다.

idea-refine가 특히 잘 맞는 상황

막연한 기능 아이디어, 제품 구상, 워크플로 변경안을 두고 실제로 추진할 가치가 있는지 검증해야 할 때 idea-refine를 쓰면 좋습니다. 진짜 문제 정의가 아직 흐릿하거나, 타깃 사용자가 분명하지 않거나, 가능한 해결 방향이 너무 넓게 열려 있을 때 특히 도움이 됩니다. 초기 제품 탐색, 기능 프레이밍, 그리고 idea-refine for Requirements Planning 용도로 특히 유용한 이유는, “흥미로운 아이디어”를 “구체적인 실행 방향”으로 끌고 가기 때문입니다.

이 스킬이 다른 이유

idea-refine 가이드는 3단계 흐름을 중심으로 구성됩니다. 먼저 이해하고 확장한 뒤, 평가하고 수렴하고, 마지막으로 다듬어 전달 가능한 형태로 정리합니다. 이 차이는 중요합니다. 많은 아이데이션 프롬프트는 곧바로 해결책부터 제시하기 때문입니다. 반면 이 스킬은 먼저 아이디어를 다시 정의하고, 더 날카로운 질문을 던지고, 여러 변형안을 만든 다음에야 방향을 고릅니다. 그 결과, 섣부른 확신을 줄이고 최종 산출물을 실제 의사결정에 바로 쓸 수 있는 수준으로 끌어올립니다.

idea-refine가 강하게 맞는 경우

옵션을 가볍지만 규율 있게 탐색하고, 가정을 드러내며, 공유 가능한 markdown 산출물까지 남기고 싶다면 idea-refine를 고르세요. 이 스킬은 어시스턴트가 단순히 기능을 뽑아내는 생성기가 아니라, 함께 사고를 정리해 주는 아이데이션 파트너처럼 움직이길 원할 때 잘 맞습니다. 이미 요구사항이 정확히 정해져 있다면 일반 프롬프트로도 충분할 수 있습니다. 반대로 아직 그 정도로 명확하지 않다면, 보통은 idea-refine를 설치하는 편이 더 나은 선택입니다.

idea-refine 스킬 사용 방법

idea-refine 설치

다음 명령으로 agent-skills repo에서 설치할 수 있습니다:

npx skills add addyosmani/agent-skills --skill idea-refine

repo에서 사용하는 선택형 로컬 설정까지 함께 쓰고 싶다면, 보조 스크립트를 실행하세요:

bash /mnt/skills/user/idea-refine/scripts/idea-refine.sh

이 스크립트는 docs/ideas/를 초기화하며, 결과물을 일정한 위치에 저장하고 싶을 때 유용합니다. 프롬프트 동작만 쓰는 것이 아니라 전체 워크플로까지 활용하려는 사용자에게는 이것이 실질적인 idea-refine install 경로입니다.

시작 입력을 제대로 주기

이 스킬은 첫 메시지에 거친 아이디어와 함께 문제를 좁혀 주는 맥락이 들어 있을 때 가장 잘 작동합니다. 좋은 입력은 아이디어가 무엇인지, 누구를 위한 것인지, 그리고 어떤 제약이 가장 중요한지를 함께 알려줍니다. 예를 들어 “소규모 에이전시를 위한 워크플로 도구를 다듬고 싶다. 새 대시보드를 하나 더 추가하지 않으면서 고객 승인 지연을 줄이는 방향으로” 같은 입력이 “아이디어 좀 같이 내줘”보다 훨씬 강합니다.

idea-refine usage를 제대로 하려면 다음 정보를 포함하세요:

• 타깃 사용자 또는 고객
• 해결하려는 문제 또는 기회
• 현재 쓰는 우회 방식이나 경쟁 대안
• 예산, 시간, 플랫폼, 범위 같은 제약
• 세션이 끝날 때 내려야 할 결정

repo 파일은 이 순서로 보면 됩니다

먼저 SKILL.md로 전체 워크플로를 파악한 뒤, examples.md, frameworks.md, refinement-criteria.md를 확인해 이 스킬이 아이데이션, 비교, 평가를 어떤 식으로 다루는지 보세요. 디렉터리 설정 동작이 궁금하다면 scripts/idea-refine.sh까지 읽으면 됩니다. idea-refine guide를 repo 전체를 처음부터 다 읽지 않고 빠르게 이해하려면, 이 순서가 가장 효율적입니다.

거친 프롬프트를 더 좋은 세션으로 바꾸기

그냥 “아이디어를 달라”고 하기보다, 원하는 출력 형태를 분명히 한 상태에서 refinement pass를 요청하세요. 예를 들어 “Use idea-refine to evaluate three directions for a B2B onboarding assistant, then recommend one MVP with assumptions and a not-doing list.” 같은 프롬프트가 좋습니다. 이렇게 하면 스킬이 실제로 내려야 할 판단이 생기고, 최종 원페이지 결과물의 품질도 더 좋아집니다.

idea-refine 스킬 FAQ

idea-refine는 초기 스타트업 아이디어에만 쓰는 건가요?

아닙니다. idea-refine skill은 기능 기획, 프로세스 재설계, 내부 도구 구상, 그리고 아직 범위가 너무 넓어 깔끔하게 스코프를 잡기 어려운 모든 요구사항에도 쓸 수 있습니다. 특히 구현 세부사항을 쓰기 전에 팀이 여러 선택지 중 무엇을 좁혀야 하는 상황에서 가장 큰 가치를 냅니다.

일반적인 브레인스토밍 프롬프트와는 무엇이 다른가요?

일반 프롬프트는 아이디어 목록만 돌려주는 경우가 많습니다. 반면 idea-refine는 확장, 압박 검증, 수렴의 과정을 거치도록 설계되어 있어서 결과물이 훨씬 실행 가능하게 나옵니다. idea-refine for Requirements Planning 관점에서는, 흩어진 아이디어는 줄고 실제 결정을 내릴 수 있는 구조는 더 많아진다는 뜻입니다.

초보자도 아이데이션 프레임워크를 먼저 알아야 하나요?

그럴 필요 없습니다. 이 스킬은 프레임워크 지식이 없어도 사용할 수 있습니다. 물론 HMW나 SCAMPER 같은 프레임워크를 알고 있다면 후속 질문을 더 잘 던지는 데 도움이 되지만, 핵심적인 idea-refine usage 자체가 그런 배경지식에 의존하지는 않습니다.

idea-refine를 쓰지 말아야 할 때는 언제인가요?

요청이 이미 충분히 구체적이거나, 당장 최종 구현 계획이 필요하거나, 핵심 작업이 방향 선택이 아니라 코드 작성인 경우에는 쓰지 않는 편이 낫습니다. 이런 상황에서는 더 좁은 프롬프트나 별도의 planning skill이 더 잘 맞습니다.

idea-refine 스킬을 더 잘 활용하는 방법

말만 늘리지 말고 제약을 더 날카롭게 주기

품질을 가장 크게 끌어올리는 방법은 설명을 길게 하는 것이 아니라 경계를 분명히 주는 것입니다. 대상 사용자, 비즈니스 목표, 플랫폼, 일정, 그리고 무엇을 명시적으로 범위 밖에 둘지까지 넣어 주세요. idea-refine 스킬은 두루 그럴듯하지만 차별점 없는 옵션을 늘어놓을 때보다, 실제 제약 사이에서 트레이드오프를 판단해야 할 때 가장 강합니다.

요약이 아니라 결정을 요구하기

더 좋은 결과를 원한다면, 어시스턴트가 어떤 판단을 내려야 하는지 분명히 지정하세요. 예를 들어 한 방향을 고르기, 두 접근법 비교하기, 가장 위험한 가정 찾기, MVP 범위 정의하기 같은 요청입니다. 이런 지시가 없으면 스킬이 탐색 단계에 너무 오래 머물 수 있습니다. 좋은 idea-refine usage는 가능성 나열로 끝나는 것이 아니라, 권고안으로 마무리됩니다.

출력 구조를 확인하고 재사용하기

repo의 출력 형식 자체가 좋은 힌트가 됩니다. 문제 정의, 추천 방향, 핵심 가정, MVP 범위, 하지 않을 것 목록으로 구성되어 있기 때문입니다. 첫 결과가 너무 모호하다면 전체를 다시 생성시키기보다, 한 번에 한 섹션씩 더 타이트하게 다듬어 달라고 요청하세요. 대개 이 방식이 세션 전체를 처음부터 다시 시작하는 것보다 더 빠르게 명확성을 높여 줍니다.

흔한 실패 패턴을 주의하기

주요 위험은 지나치게 넓은 아이데이션, 숨은 가정의 미끄러짐, 그리고 실제 사용자 문제와 연결되지 않는 그럴듯한 해법입니다. 출력에 특정 사용자가 명시되지 않았거나, painkiller와 vitamin 수준의 가치 차이가 구분되지 않거나, 왜 한 방향이 더 나은지 설명하지 못한다면 바로 되짚어야 합니다. 이것이 idea-refine를 Requirements Planning에 더 유용하게 만드는 가장 빠른 방법입니다.