나의 스킬

당신의 미지의 것 찾기

개요

사용자의 작업 설명(프롬프트, 맥락, 참고 자료)과 실제 작업(코드베이스, 제약 조건, 현실) 사이의 간격에는 미지의 것이 존재합니다. 에이전트가 미지의 것과 마주치면 사용자의 의도를 추측합니다. 이 스킬의 임무는 추측을 중단시키는 것입니다. 구현 전, 중, 후에 반복적으로 사용자가 미지의 것을 발견하고 명명하도록 돕습니다. 일회성 사전 계획이 아닙니다.

이것은 고정된 파이프라인이 아니라 도구 상자입니다. 먼저 진단한 다음, 상황에 맞는 기술만 적용하세요. 간단한 작업에 모든 기술을 실행하지 마세요.

네 가지 미지의 것

기술을 선택하기 전에 무엇이 누락되었는지 분류하세요.

• 알고 있는 알려짐 — 이미 프롬프트에 명시된 것.
• 알려진 미지 — 사용자가 아직 결정하지 않았음을 알고 있는 것.
• 모르는 알려짐 — 너무 명확해서 적지 않았지만, 사용자가 보면 바로 인식하는 것 (종종 시각/UX 취향).
• 모르는 미지 — 전혀 고려하지 않은 것. 사용자는 자신이 무엇을 모르는지조차 모릅니다.

0단계 — 진단

무엇보다도, 어떤 미지의 것이 지배적인지 판단하고 그에 따라 기술을 선택하세요.

• 낯선 도메인 또는 코드베이스의 낯선 부분 → 블라인드스팟 스캔 (모르는 미지).
• 설명하기 어렵고, "보면 알겠어" → 프로토타입 (모르는 알려짐).
• 방향은 명확하지만 세부 사항이 모호함 → 사용자 인터뷰 + 계획 초안 (알려진 미지).

항상 사용자가 누구이며 무엇을 이미 알고 있는지에 대한 맥락을 제공하세요. 이는 아래 모든 기술을 더욱 예리하게 만듭니다.

다른 스킬로 전환

이 스킬을 전체 워크플로우가 아닌 발견 레이어로 사용하세요. 미지의 것을 명명한 후, 다음 불확실성을 해소할 가장 작은 후속 스킬을 선택하세요.

미지의 것 또는 다음 필요 사항	전환할 스킬	사용 시기
사용자가 의도를 완전히 표현하지 않음	interview-me	근본적인 필요가 명확해질 때까지 한 번에 한 가지 질문을 합니다.
계획에 압력 테스트가 필요함	grill-me 또는 grill-with-docs	가정을 스트레스 테스트합니다. ADR이나 용어집 업데이트를 캡처해야 할 때 docs 변형을 사용합니다.
외부 사실이 누락됨	research 또는 source-driven-development	결정을 내리기 전에 1차 증거를 수집합니다.
사용자가 보면 알게 될 것	prototype	구현에 착수하기 전에 가짜 데이터로 구체적인 옵션을 보여줍니다.
작업에 공식 명세가 필요함	spec-driven-development	발견된 제약 조건과 결정을 PRD/명세로 변환합니다.
작업이 직접 실행하기에 너무 큼	planning-and-task-breakdown 또는 writing-plans	정렬된 명세를 순서가 있고 검증 가능한 조각으로 나눕니다.
인터페이스 경계가 불명확함	api-and-interface-design 또는 design-an-interface	API, 모듈 또는 타입 계약을 결정합니다.
코드베이스 형태가 불확실함	codebase-design 또는 improve-codebase-architecture	올바른 모듈 경계, 추상화 또는 리팩터링 방향을 찾습니다.
UI 동작 또는 시각적 품질이 불확실함	frontend-ui-engineering	선택한 프로토타입이나 선호도를 프로덕션 UI 작업으로 전환합니다.
버그가 존재하지만 원인이 불명확함	systematic-debugging 또는 diagnosing-bugs	재현, 격리, 가설 수립, 계측 및 수정합니다.
구현이 독립적인 작업에 걸쳐 있음	subagent-driven-development 또는 dispatching-parallel-agents	작업이 상태나 순차적 종속성을 공유하지 않을 때만 분할합니다.
작업이 완료된 것으로 보임	verification-before-completion, requesting-code-review 또는 code-review	증거를 확인한 후, 완료 또는 병합을 주장하기 전에 검토합니다.

전환하기 전에 다음을 요약하세요.

• 현재 알려진 것.
• 여전히 알려지지 않은 것.
• 어떤 결정이 구현을 변경할지.
• 어떤 산출물(프로토타입, 명세, 계획, 구현 노트 또는 승인 보고서)을 전달해야 할지.

단계별 기술

각 기술에는 트리거와 바로 사용할 수 있는 프롬프트 템플릿이 있습니다. 대괄호로 표시된 부분을 상황에 맞게 조정하세요.

탐색 (미지의 것 찾기)

1. 블라인드스팟 스캔 — 낯선 영역에서의 첫 번째 움직임.

저는 [X]를 추가하려고 하지만 이 코드베이스의 [Y] 모듈을 거의 모릅니다. 블라인드스팟 패스를 수행하여 제 "모르는 미지"를 찾아 설명해 주세요. 그러면 더 나은 프롬프트를 작성할 수 있습니다.

2. 프로토타입 — 설명할 수 없을 때, 보여주세요. 가짜 데이터를 사용하고 백엔드는 없습니다.

실제 앱을 건드리기 전에 가짜 데이터로 [인터페이스]를 모킹한 HTML 파일을 만드세요. 어떤 것이 적합한지 알 수 있도록 완전히 다른 네 가지 디자인 방향을 제시해 주세요.

3. 사용자 인터뷰 — 남아 있는 모호한 부분을 짜내세요.

한 번에 한 가지 질문을 해 주세요. 모호한 영역을 대상으로 하고, 그 답변이 아키텍처를 변경할 질문에 우선순위를 두세요.

계획 (의도 정렬)

4. 참조 보여주기 — 가장 좋은 참조는 스크린샷이 아니라 소스 코드입니다.

[경로 / 라이브러리]는 제가 원하는 [동작]을 구현합니다. 그것을 읽고, 동일한 의미를 [저희 스택]으로 다시 구현하세요.

5. 계획 초안 작성 — 변경될 가능성이 가장 높은 결정을 먼저 표면화하세요.

HTML 구현 계획을 작성하되, 제가 조정할 가능성이 가장 높은 결정을 위에 두세요: 데이터 모델 변경, 새 타입 인터페이스, 사용자에게 보이는 모든 것. 기계적인 리팩터링은 마지막에 두세요. 그것들은 제가 신뢰합니다.

구현 (작업 중 발생하는 미지의 것 포착)

6. 진행하면서 노트 작성 — 새 세션을 시작하고, 명세/프로토타입을 입력한 후 다음을 수행하세요.

implementation-notes.md를 유지하세요. 엣지 케이스가 계획을 벗어나도록 강제하면 보수적인 옵션을 선택하고 "이탈" 섹션 아래에 기록한 후 계속 진행하세요.

출시 (다른 사람 정렬, 이해 확인)

7. 핸드오프 설명

프로토타입, 명세 및 구현 노트를 하나의 문서로 패키징하여 채팅에 붙여넣어 동의를 구할 수 있도록 하세요. 상단에 데모 GIF를 넣으세요.

8. 승인 퀴즈 — 작성자의 엄격한 규칙: 병합 전에 통과해야 합니다.

이 변경 사항을 완전히 이해했는지 확인하고 싶습니다. 변경 사항의 맥락, 직관, 수행된 작업을 포함하는 HTML 보고서를 만든 다음, 하단에 제가 통과해야 하는 퀴즈를 넣으세요.

운영 규칙

• 사용자의 의도를 추측하려고 할 때마다 중단하고 일치하는 기술을 대신 적용하세요.
• 산출물을 연결하세요: 프로토타입 → 명세 → 구현 노트 → 승인 보고서. 각각은 다음의 입력이므로 새 세션이 맥락을 잃지 않습니다.
• 작은 작업의 경우 블라인드스팟 스캔 + 계획 초안 + 승인 퀴즈만으로도 대부분의 가치를 포착할 수 있습니다. 과도하게 실행하지 마세요.