scout

/scout — 나는 실제로 어디로 가고 있고, 어떻게 그곳에 도달할까?

당신은 문제나 아이디어가 있지만, 솔직히 말해 어떻게 처리해야 할지 모릅니다. '세 가지 접근 중 어떤 것을 선택할까'가 아니라, 아직 목표 지점을 충분히 볼 수 없어 세 가지 접근 자체를 생각할 수 없는 상태입니다. 이 컬렉션의 다른 모든 스킬은 이미 대상이 존재한다고 가정합니다. 이 스킬은 바로 그 대상을 찾아 나서는 것입니다.

임무는 지형을 조사한 후 경로를 선택하는 것입니다. 목표를 향해 돌진하거나, 처음에 구축 가능해 보이는 것을 바로 만들기 시작하는 것이 아닙니다.

이것이 아닌 것 — 올바른 스킬을 호출할 수 있도록:

• grill-me가 아닙니다. grill-me는 이미 가지고 있는 계획에 대해 깊이 우선(DFS)으로 한 번에 하나의 결정 트리를 탐색하며 질문합니다. 이 스킬은 계획이 존재하기 전에 실행되며 의도적으로 너비 우선(BFS) 으로 진행됩니다. Scout가 끝나면 grill-me는 합리적인 다음 단계입니다.
• explain이 아닙니다. explain은 이미 존재하는 코드를 매핑합니다. 이 스킬은 존재하지 않는 작업을 매핑합니다.
• root-cause가 아닙니다. root-cause는 알려진 증상이 있는 고장난 것을 위한 것입니다. 무언가 실패하고 있다면 먼저 root-cause를 사용하고, 수정이 명확하지 않은 경우에만 그 응답을 scout하십시오.
• validate-plan / ship-check가 아닙니다. 이것들은 계획과 diff를 평가합니다. Scout는 이들 모두의 상류에서 실행되며, 그들이 평가할 대상을 생성합니다.

절제 게이트 — 먼저 읽으십시오. 실패 모드는 여정을 인위적으로 만드는 것입니다. 첫 번째 패스에서 목적지와 그 단계를 이미 말할 수 있다면, 그렇게 말하고 멈추십시오: "이것은 정찰이 필요하지 않습니다. 여기 계획이 있습니다. 실행하세요." 대부분의 문제가 이렇습니다. 명확한 경로에 절차를 추가하는 것은 순전한 비용입니다. 마찬가지로, 사용자가 /scout을 입력하지 않고 당신이 이 스킬을 사용하려고 한다면, 시작하기 전에 확인하십시오. 요청하지 않은 20가지 질문 인터뷰는 나쁜 surprises입니다.

패스

1. 목적지 이름 짓기 — 다른 어떤 질문보다 먼저

완료가 무엇인지 물어보고, 한두 줄로 정리하십시오. 결정이 확정되는 것, 전달할 사양, 제자리에서 완료된 마이그레이션, 엔드투엔드로 작동하는 기능 등일 수 있습니다. 다른 목적지는 완전히 다른 경로를 생성하므로, 이것이 먼저 결정되며 결코 가정되지 않습니다.

목적지는 범위를 고정합니다 — 아래의 모든 질문은 이에 대해 측정됩니다. 사용자가 아직 이름을 지을 수 없다면, 그것이 바로 가장 먼저 작업해야 할 사항이며, 이름이 지어질 때까지 다른 것은 시작되지 않습니다.

2. 퍼뜨리기 — 너비 우선으로, 답을 주지 마십시오

여기서 목적지 사이의 전체 공간을 훑고 열린 질문을 수집하십시오. 아직 그 중 어떤 것도 해결하지 마십시오. 첫 번째 질문에 즉시 답하고 싶은 충동이 이 패스가 극복하기 위해 존재하는 것입니다: 당신이 주목하는 첫 번째 질문은 형태를 결정하는 경우가 거의 없으며, 일찍 답하면 잘못된 것을 매우 신중하게 계획하게 됩니다.

깊이가 아닌 넓게 가십시오. 당신이 몰랐던 질문을 표면으로 끌어올리는 것을 목표로 하십시오.

조사할 사실; 물어볼 결정. 확인 가능한 것 — 스키마, 호출자, 실제 데이터, 라이브러리 문서, 코드가 실제로 오늘 하는 일 — 은 가서 확인하고, 질문에 소비하지 마십시오. 진정한 결정만 사용자에게 전달하십시오.

3. 세 가지 버킷으로 분류

버킷	테스트	수행할 작업
선명함(Sharp)	지금 질문을 정확하게 말할 수 있음	작업(패스 4)
안개(Foggy)	질문이 있다는 것을 느끼지만 아직 표현할 수 없음	느슨한 한 줄로 남겨둠
범위 외(Out of scope)	목적지를 넘어서 위치함	기록; 다시 다루지 않음

선명함/안개 테스트는 답변할 수 있는지가 아니라 말할 수 있는지입니다. 답이 어렵거나 알 수 없는 질문이라도 정확하게 표현할 수 있다면 여전히 선명합니다. 이것들이 종종 가장 중요한 질문입니다.

범위 외는 다른 테스트를 사용합니다 — 선명함이 아닌 범위. 어떤 것은 완벽하게 선명하지만 목적지를 넘어서기 때문에 범위 밖일 수 있습니다. 명시적으로 배제하고 그 이유를 말하십시오. 목적지 자체가 이동하지 않는 한 다시 돌아오지 않으며, 그것은 새로운 scout입니다.

그런 다음 가장 많은 것을 해제하는 순서로 선명한 질문을 정렬하십시오 — 가장 많은 다른 질문을 해결하는 답변부터 시작합니다.

4. 하나씩 해결

한 번에 하나의 질문을 하고 기다리십시오. 각 질문에 권장 답변을 제시하십시오 — 그러나 권장일 뿐이며, 결정은 사용자의 몫입니다. 그들을 대신하여 결정에 답변하지 말고 질문을 일괄 처리하지 마십시오. 다섯 개의 질문 벽은 혼란스럽고 게으른 답변 하나를 받게 됩니다.

각 답변 후에 버킷을 업데이트하십시오:

• 안개를 실제로 말할 수 있는 질문으로 선명하게 했습니까? 승격시키십시오.
• 더 이상 중요하지 않은 질문을 죽였습니까? 제거하십시오.
• 목적지를 이동시켰습니까? 크게 알리고 새로운 목적지에 대해 다른 버킷을 다시 확인하십시오 — 모든 것이 이전 선을 기준으로 측정되었습니다.

생산적으로 보이기 위해 안개를 가짜 질문으로 미리 잘라내지 마십시오. 안개는 이정표일 뿐, 할 일 목록이 아닙니다.

5. 경로가 명확해지면 중지

완료는 다음을 의미합니다: 선명한 질문이 남아 있지 않고, 남은 안개가 진정으로 연기 가능하거나 범위 밖인 경우. 목적지, 그곳에 도달하게 한 결정, 구체적인 다음 단계를 가지고 마무리하십시오.

그런 다음 인계 — 구축하지 마십시오. Scout는 경로를 생성하고, 결과물을 만들지 않습니다. 계획 모드(또는 계획이 나온 경우 /validate-plan)로 이동한 다음 구현하십시오. Scout 내에서 프로덕션 코드를 작성하고 있다면 스킬의 범위를 넘어선 것입니다.

유일한 예외는 일회용입니다 — 질문이 종이 위에서 해결될 수 없을 때 ("이 상태 모델이 맞는 느낌인가?", "이것이 어떻게 보여야 하는가?") 답변해 주는 가장 작고 거친 것을 만들고, 보고, 답을 유지하고 코드는 버리십시오.

세션 넘어가기 — 실제로 필요한 경우에만

기본값은 단일 세션, 아티팩트 없음입니다. 대부분의 scout는 여기에 해당하며, 20분 후에 끝난 대화를 위해 작성된 파일은 쓰레기에 불과합니다.

다음 중 하나가 참일 때만 /handover-save로 에스컬레이션하십시오:

• 세션이 충분히 길어져 맥락을 잃을 위험이 있을 때,
• 사용자가 중단하고 나중에 다시 시작하기를 원할 때,
• 질문이 대화 외부의 무언가(다른 사람의 답변, 프로비저닝 접근, 먼저 수집해야 할 데이터)에 막혔을 때.

인계 문서는 목적지와 세 가지 버킷을 전달합니다. /handover-resume으로 재개하며, 계속하기 전에 드리프트를 재동기화합니다. 세션을 넘나드는 것은 여기서 탈출구일 뿐, 설계가 아닙니다.

출력 형태

실질적으로 변경될 때 지도를 표시하십시오 — 목적지 이름이 정해진 후, 퍼뜨린 후, 답변이 버킷을 재구성할 때마다. 모든 변경 시마다 할 필요는 없습니다.

## 정찰: <아이디어, 한 줄>

**목적지:** <완료가 무엇인지 — 아래 모든 것은 이에 대해 측정됨>

**결정됨**
- <질문> → <답변>

**열림 — 선명함**
1. <정확히 표현된 질문>   ← 지금 작업 중
2. <...>

**여전히 안개**
- <느슨한 한 줄> — <X>가 해결되면 선명해짐

**범위 외**
- <배제된 것> — <목적지를 넘어서는 이유>

다음으로 마무리: 목적지, 순서대로의 결정, 그리고 단일 다음 단계.

가드레일

• 깊이보다 너비. 전체 공간을 보기 전에 첫 번째 질문에 답하는 것은 이 스킬이 방지하기 위해 존재하는 실패입니다.
• 물어보지 말고 조사하십시오. grep으로 답할 수 있었던 질문은 사용자의 턴과 인내심을 낭비합니다.
• 한 번에 하나의 질문, 그런 다음 기다리십시오. 매번 답변을 권장하며, 절대 그들을 대신해 결정하지 마십시오.
• 선명함 ≠ 답변 가능성. 안개 테스트는 "말할 수 있는가"이지 "답할 수 있는가"가 아닙니다.
• 안개는 백로그가 아닙니다. 느슨하게 두십시오. 미리 작업 항목으로 자르면 다음 답변이 삭제할 수 있는 작업을 만들어냅니다.
• 범위 외는 범위 결정이지 단계가 아닙니다. 자체 버킷에 들어가며, 결정 목록에는 절대 들어가지 않습니다.
• 목적지는 이동할 수 있습니다 — 이동할 때 알리십시오. 조용히 재조준하면 그 전에 내려진 모든 판단이 무효화됩니다.
• 구축하지 마십시오. 결과물이 아닌 결정을 내십시오. 일회용 프로토타입이 유일한 예외입니다.
• 기본적으로 파일을 만들지 마십시오. /handover-save는 작업이 진정으로 세션을 초과할 때만 사용합니다.
• 절제 게이트. "여기에는 안개가 없습니다. 당신은 이미 이 작업을 수행하는 방법을 알고 있습니다." 이것은 실제로 가치 있는 결과입니다. 스킬 실행을 정당화하기 위해 열린 질문을 절대 만들어내지 마십시오.

---

목적지 우선 프레이밍, 너비 우선 확산, 진술 가능성 대 답변 가능성 안개 테스트, 범위 대 선명함 구분은 Matt Pocock의 wayfinder (github.com/mattpocock/skills)에서 차용했습니다. 이슈 트래커 맵, 하위 티켓 메커니즘 및 세션당 하나의 티켓 규칙은 의도적으로 생략했습니다 — 이 컬렉션은 대신 /handover-save를 사용하여 세션 간에 지속됩니다.