발견(Discovery)
구조화되지 않은 이해관계자 입력을 소크라테스식 검토를 통해 추적 가능한 요구사항으로 변환하세요. 당신은 전사기가 아닙니다: 명시된 것과 암시된 것을 포착하고, 모호함에 플래그를 지정하며, /refine-story가 스프린트 계획으로 가져갈 후보 스토리를 생성하세요. 입력이 뒷받침하지 않는 것은 들어가지 않습니다. 입력이 암시하는 것은 근거 있는 추론으로 들어갑니다. 입력이 열어둔 것은 질문이 됩니다.
입력: $ARGUMENTS
시작하기 전에
워크스페이스에서 docs/agents/refinement.md를 읽으십시오: 이 파일은 운영 모드, 언어(en-US 또는 pt-BR, 기본값 en-US), 게시 경로를 정의합니다. 파일이 없으면 /configure-refinement을 요청하고 중단하십시오. 인수가 Status: open map(또는 Status: mapa aberto)인 사양이면 바로 "의사 결정 맵 재개(Resume decision map)"로 이동하십시오. 입력이 /meeting-minutes에서 비롯된 경우 이미 명시된 사실과 가정을 분리합니다: 가정된 동의는 확인되지 않은 것으로 처리하십시오. 검토 및 생성된 사양은 구성된 워크스페이스 언어를 따릅니다.
단계
-
로드 및 분류. 입력,
CONTEXT.md를 읽고requirements-rigor에 대한 Skill 도구를 호출하십시오. 안티패턴을 스캔하고(requirements-rigor의ANTI-PATTERNS.md를 별도로 읽으십시오) 항상 질문을 유발하는 용어를 찾으십시오: 이 스캔은 분류의 기초가 됩니다. 텍스트 양이 아닌 발췌문 수를 기준으로 분류하십시오: 사용 가능(USABLE, 모든 발췌문이 요구사항을 구조화함), 부분 사용 가능(PARTIALLY USABLE, 적어도 하나의 발췌문이 요구사항을 구조화하고 적어도 하나는 그렇지 않음), 사용 불가능(UNUSABLE, 어떤 발췌문도 요구사항을 구조화하지 않음). 사용 불가능(UNUSABLE): 발췌문별 근거와 함께 이 사실을 명시하고, 3~5개의 최소 질문을 수신자(입력을 제공한 사람, 단, 용어집에서 식별 가능한 도메인 역할이 있는 경우 우선)와 함께 나열하고,requirements-rigor의QUESTIONNAIRE.md를 따라 질문지를 작성한 후, 사용자에게/requirements-discovery가 응답과 함께 다시 실행될 것임을 알리고 추가 아티팩트를 게시하지 않고 중단하십시오; 쓸모없는 스토리는 아무 도움이 되지 않습니다. 부분 사용 가능(PARTIAL): 진행하며, 최종 아티팩트는 사용되지 않은 발췌문 목록과 각각에 무엇이 누락되었는지로 시작합니다. 완료 조건: 분류가 한 줄로 명시되고, 사용 가능(USABLE)이 아닌 경우 발췌문별 근거가 제공됩니다. -
너비 우선 매핑. 스토리를 생성하기 전에 전체 입력을 스캔하십시오: 신뢰도 등급(높음, 중간, 낮음; 낮음은 후속 대화가 필요한 발견을 표시)이 있는 비즈니스 도메인, 유형(비즈니스, 기술, 최종 사용자)과 각각이 주장하는 바가 있는 이해관계자, 복잡성 S, M, L 또는 XL(한 줄로 정당화)이 있는 에픽; 폐쇄 목록이나 측정 가능한 기준이 없는 발췌문은 검토가 크기를 결정할 때까지 부분 처리에 남아 에픽이 되지 않습니다. 입력이 2차 정보인 경우, 메모 작성자는 유형 "source"로 이해관계자 테이블에 입력됩니다. 동일한 요구사항에 대해 반대 입장을 가진 두 개의 의견:
[CONFLICT]를 추가하고, 일방적으로 해결하지 않고 두 입장을 모두 기록하십시오. 단일 의견으로 명시된 요구사항은 확인이 중요한 경우[VALIDATE WITH TEAM]을 받습니다: 충족되지 않은 역할 요구, 비의사 결정자가 내린 범위 결정; 두 의견이 서로 다른 주제를 다루는 경우 모든 것을 표시하지 마십시오. 비즈니스 요구와 기술 제약은 다른 이해관계자로부터 발생하며 다른 비중을 가집니다: 이들을 구분하십시오. 완료 조건: 각 입력 발췌문이 도메인과 에픽에 매핑되거나, 활용되지 않은 것으로 나열됩니다. -
질문하기 전에 사실 검색. 용어집,
.scratch/의 이전 스토리, 워크스페이스 문서, 그리고 코드 모드에서는 코드베이스를 확인하십시오: 언급된 통합이 이미 존재합니까? 임계값이 이미 구현되었습니까? 발견된 사실은 출처를 인용한 권장 답변이 됩니다. 코드 없음(no-code) 모드에서는 검색이 서브 에이전트 없이 워크스페이스 파일로 제한됩니다; 아무것도 발견되지 않으면 1라운드 상단에 한 줄로 명시하십시오. 완료 조건: 각 후보 질문이 출처에 의해 답변되었거나 열려 있는 것으로 표시됩니다. -
범위 규모 결정.
socratic-examination에 대한 Skill 도구를 호출하고 너비 우선으로 검토하십시오: 이 발견이 전달하는 대상 결과, 범위 경계, 충돌, 에픽 크기에 영향을 미치는 요소. SLA, 채널, 엣지 케이스는 깊이를 나타내며 5단계로 연기됩니다. 이 라운드가 끝날 때 프론티어가 단일 세션에 적합하면 5단계로 진행하십시오. 상당한 **안개(fog)**가 남아 있으면(결정이 예상되지만 아직 공식화할 수 없음, 보류 중인 답변에 의존하기 때문에), 맵을 여십시오:Status: open map과 함께 TEMPLATE.md를 따라 사양을 게시하고, 공식화 가능한 각 질문에 대해issues/NN-decision-<slug>.md에 하나의 보류 결정 파일을 만들고, 다른 결정에 종속될 때Blocked by:를 표시하며, 공식화할 수 없는 안개는 "Not yet specified"에 넣으십시오. 결정과 안개의 차이는 지금 당장 질문을 정확하게 공식화할 수 있는지 여부이지, 답변할 수 있는지 여부가 아닙니다. 안개를 매핑하는 것이 한 세션의 목표입니다: 중단하고 사용자에게/requirements-discovery <spec-path>가 세션당 하나의 결정을 해결한다고 알리십시오. 완료 조건: 질문 프론티어가 단일 세션에 적합하거나, 열린 맵과 보류 결정 파일이 있는 사양이 존재합니다. -
검토. 에픽별로
socratic-examination의 라운드를 깊이 있게 계속하십시오: 역할, 기능, 결과, 입력에서 암시된 엣지 케이스, 종속성. 해결된 도메인 용어는 즉시CONTEXT.md에 추가됩니다. 참석자가 아무도 모르는 사실은[TO CONFIRM: whom](또는[A CONFIRMAR: quem])을 받고 프론티어를 떠납니다. 완료 조건: 프론티어가 비어 있거나 사용자가 종료를 요청합니다. -
합성. TEMPLATE.md를 따라 발견 사양을 작성하고,
skills/refine-story/TEMPLATE.md를 따라 파일당 하나의 후보 스토리를Status: candidate(또는Status: candidata)와 예비 INVEST 점수표와 함께 작성하십시오. INVEST에 실패한 스토리는 깨끗한 카드가 되지 않습니다:[INVEST-FAIL]및 해결 지침과 함께 후보로 남습니다. 선언되지 않은 종속성을 포함하십시오: 스토리를 구현 가능하게 하기 위해 필요한 통합, 외부 서비스, 아키텍처 결정(각각 차단된 스토리 및 필요한 조치와 쌍을 이룸). 후보 스토리의 모든 줄은 입력 또는 유효한[INFERENCE: base]와 일치해야 합니다; 뒷받침되지 않는 추가는 골드 플레이팅이며 제거되어야 합니다. 완료 조건: 사양과 후보 스토리가docs/agents/refinement.md에 정의된 경로에 최종 면책 조항과 함께 존재합니다. -
미해결 항목 라우팅. 세션 외부의 수신자가 있는 열린
[TO CONFIRM]항목:requirements-rigor의QUESTIONNAIRE.md를 따라 수신자당 하나의 질문지를 사양과 함께 작성하십시오. 완료 조건: 수신자나 질문지가 없는 열린 질문이 남아 있지 않습니다. -
보고. 생성된 에픽, 후보 스토리 수, 열린 충돌, 다음 단계: 스토리당
/refine-story, 또는 맵이 열려 있으면/requirements-discovery <spec-path>.
의사 결정 맵 재개(Resume decision map)
인수가 Status: open map인 사양인 경우:
- 전체 사양과
issues/의 보류 결정을 읽으십시오. 결정이 열려 있고Blocked by:의 모든 결정이 해결된 경우 **차단 해제(unblocked)**됩니다. 완료 조건: 어떤 결정이 차단 해제되었는지 파악합니다. - 결정을 선택하십시오: 사용자가 지정한 이름, 또는 번호 순으로 첫 번째 차단 해제된 결정. 시작하기 전에 파일에서
Status: in examination을 표시하여 동시 세션이 선택하지 못하게 하십시오. 완료 조건: 파일 상태가 업데이트됩니다. socratic-examination으로 결정을 해결하십시오(세션당 하나의 결정). 조사 유형의 결정은 검토 라운드 없이 외부 출처를 인용하여 읽음으로써 해결됩니다. 답변을## Answer아래 파일에 직접 기록하고,Status: resolved를 표시한 후, 사양의 "Examination decisions" 섹션에 요약 및 경로가 포함된 줄을 추가하십시오. 완료 조건: 결정이 해결되고 사양에서 연결됩니다.- 답변은 주변 안개를 제거할 수 있습니다: 새로 공식화 가능한 항목은 "Not yet specified"를 떠나 새로운 보류 결정이 됩니다; 범위를 벗어난 항목은 "Out of scope"로 이동합니다. 답변에 의해 무효화된 모든 결정은 한 줄 근거와 함께 종료됩니다. 완료 조건: 보류 중인 결정 중 답변과 모순되는 것이 없고 안개가 재평가됩니다.
- 열린 보류 결정이 없는 경우: 사양을
Status: in progress로 업데이트하고 메인 단계의 5단계로 진행합니다(컨텍스트가 허용하면 동일 세션에서, 그렇지 않으면 다음 세션에서 동일한 명령 사용). 완료 조건: 사양이 열린 맵 상태를 벗어나거나, 얼마나 많은 결정이 남았는지 보고합니다.
보류 결정 형식:
# 결정 NN: <한 문장으로 된 질문>
Status: <open | in examination | resolved | closed>
Blocked by: <NN, NN 또는 none>
Type: <examination | research>
## 질문
<무엇이 결정되어야 하며 왜 진행을 막는지>
## 답변
<해결 시: 결정, 결정한 사람, 날짜>
최종 공지
⚠️ 이 출력은 분석 초안입니다. 스프린트에 들어가기 전에 인간의 검토가 필요합니다. 확인 사항: 기술적 타당성, 규정 준수, 매핑되지 않은 종속성.