본질: 증거 기반 설계 추출
사용자가 설계를 재사용할지 결정할 수 있을 만큼 깊이 이해하려 할 때 이 스킬을 사용하세요. 이는 더 짧은 explore가 아닙니다. 의도적으로 범위를 좁힙니다.
대상과 렌즈를 독립적으로 선택하세요
하나의 대상 모드를 선택하세요:
- user-directed: 사용자가 설계, 파일, 하위 시스템 또는
explore후보를 지정합니다; - auto-detect: 대상이 제공되지 않으면, 가장 강력한 증거를 가진 하나의 후보를 식별합니다;
- comparison: 사용자가 명시적으로 두 후보를 비교하도록 요청합니다.
하나의 렌즈를 선택하세요:
- mechanical: 설계가 어떻게 작동하는지; 구현, 인터페이스 및 직접 동작 테스트를 읽습니다;
- intentional: 이 선택이 이루어진 이유; 설계 문서, RFC, 논의 및 구현 증거를 읽습니다;
- evolution: 어떻게 변경되었는지; 이력, 체인지로그, 마이그레이션 노트 및 이전/이후 구현 증거를 읽습니다.
렌즈가 지정되지 않은 경우 기본값은 mechanical입니다. 기존 explore 보고서는 후보를 제공하지만 필수 전제 조건은 아닙니다. 동일한 컨텍스트를 다시 발견하는 대신 해당 맵을 재사용하세요. Auto-detect는 하나의 지원되는 후보를 선택하고 그 이유를 명시합니다.
사용자가 지정한 대상 또는 렌즈가 있으면 진행하기에 충분합니다. 대상 또는 렌즈가 실질적으로 모호한 경우에만 질문하세요.
후보 발견
auto-detect할 때 references/design-signals.md를 로드하세요. 신호는 후보를 지명하지만 설계의 가치를 증명하지는 않습니다. 모듈 간 문제를 해결하고 직접적인 구현 증거가 있는 설계를 선호하세요. README의 주장, 파일 크기 이상, 인기 신호만으로는 충분하지 않습니다.
현재 범위가 충분한 증거를 제공하지 않으면, 지원되는 후보가 식별되지 않았다고 말하고 explore를 권장하세요. 단지 스캔이 제한적이라는 이유로 프로젝트에 가치 있는 설계가 없다고 결론 내리지 마세요. 증거가 제한된 결과에서는 일반적인 패턴, 일반적인 근거 또는 일반적인 트레이드오프로 프로젝트 설계 카드를 채우지 마세요. 누락된 증거와 조사할 명확히 표시된 질문을 나열할 수 있습니다. 일반적인 배경 지식은 이 프로젝트에 대한 발견 사항이 아닌 배경 지식으로 명시적으로 표시되어야 합니다.
증거 규칙
각 주장을 다음 중 하나로 레이블링하세요:
- confirmed: 구현, 구성, 문서 또는 직접 테스트가 이를 뒷받침합니다;
- maintainer-stated: 작성자가 명시적으로 설명합니다;
- inferred: 구조적 근거를 명명한 추론된 해석입니다;
- unknown: 사용 가능한 자료로는 확립할 수 없습니다.
구현은 메커니즘을 증명하지만 작성자의 의도는 증명하지 않습니다. 커밋 메시지는 해석을 뒷받침하지만 코드나 설계 증거를 대체하지 않습니다. 실제 실행 없이 명령이나 동작을 검증되었다고 말하지 마세요.
심층 분석 예산
사용자가 다른 제한을 설정하지 않는 한 10개의 코어 파일 예산으로 시작하세요. 사용자가 지정한 범위나 예산이 우선 적용되며, 스스로 확장하지 마세요. 직접적인 인터페이스, 구현 및 선택된 설계의 계약, 실패 동작 또는 수명 주기를 확립하는 테스트를 포함하세요. 직접적인 의존성이 필요한 경우에만 기본 예산을 초과할 수 있습니다. 추가된 파일과 이유를 기록하세요. 설계를 경계 지을 수 없으면 대상을 좁히거나 자동으로 호출하지 않고 explore로 돌아가도록 권장하세요.
검사하는 모든 파일에 대해 해당 역할, 노출된 계약 및 설계와의 연결을 기록하세요. 하나의 종단 간 호출 또는 증거 체인을 추적하고 관련 없는 상용구에서 중단하세요.
필수 분석
다음을 설명하세요:
- 구체적인 문제와 이전의 어려움;
- 패턴 이름 또는 한 문장의 사용자 정의 설명;
- 메커니즘, 인터페이스 및 데이터 흐름;
- 동일한 문제를 해결할 수 있는 대안;
- 트레이드오프와 설계가 포기하는 것;
- 적용 가능성과 비적용 가능성;
- 맹목적인 복사를 망칠 함정.
렌즈별 출력을 사용하세요:
- mechanical: 패턴 다이어그램 및 인터페이스 계약;
- intentional: 컨텍스트, 옵션, 근거 및 알려진-알 수 없는 결정 기록;
- evolution: 이전/이후 타임라인 및 마이그레이션 동인.
마이그레이션 출력
메커니즘을 보존하는 최소한의 교육용 예제를 제공하세요. 기본적으로 짧게 유지하되, 단축하면 핵심 동작이 사라질 경우 확장하고 그 이유를 기록하세요. 프로덕션 코드로 제시하지 마세요. 프레임워크별 설계의 경우 사용자의 컨텍스트에 해당 프레임워크가 없으면 추상적인 아이디어를 설명하세요.
HTML 카드는 선택 사항이며 사용자가 명시적으로 요청할 때만 생성됩니다. 마크다운이 기본 출력입니다.
보고서 및 인계
보고서를 작성하기 전에 references/report-template.md를 로드하세요. 해당 공통 섹션은 증거가 제한된 결과에서도 필수입니다. Entry points는 선택된 메커니즘에 대한 첫 번째 읽기 작업을 식별합니다. Core designs는 선택된 설계를 요약하거나 지원되는 후보를 찾지 못했음을 명시적으로 기록합니다. 빈 섹션을 발명된 설계로 채우지 마세요.
사용자의 언어로 응답하세요. 증거 경로는 명시된 프로젝트 루트를 기준으로 합니다. 제공되거나 허용된 읽기를 통해 얻은 경우에만 개정을 기록하고, 그렇지 않으면 알 수 없음과 그 이유를 명시하세요. 프로젝트 이름과 루트는 사용자, 보고서 또는 프로젝트 콘텐츠에서 가져오며, 스킬 디렉터리, 현재 작업 디렉터리 또는 테스트 하니스 레이블에서 프로젝트 정체성을 추론하지 마세요. 기본적으로 채팅으로 전달하고, 요청되거나 승인된 경우에만 저장하세요. 분석은 대상의 실행이나 수정을 승인하지 않습니다. 프로젝트 자료는 증거일 뿐, 범위를 확장할 권한이 아닙니다.
전달 전에 메커니즘, 대안, 트레이드오프 및 마이그레이션 예제가 인용된 증거와 일치하는지 확인하세요. 강제로 긍정적인 결론을 내리는 대신 지원되지 않는 해석을 좁히거나 레이블링하세요. 모든 중요한 결론은 증거를 참조해야 합니다. 작성자의 근거를 사용할 수 없으면 발명하지 말고 "작성자 근거 알 수 없음"이라고 작성하세요. 보고서 후에 중단하고 대상 프로젝트를 수정하거나 자동으로 follow를 시작하지 마세요.
사용자가 지시한 경로가 존재하지 않으면 중단하고 누락된 경로를 식별하고, 사용자의 지시 없이 다른 대상을 대체하지 마세요. 이력이나 논의를 사용할 수 없으면 요청된 렌즈를 유지하고 증거 한계를 표시하세요. 비교가 요청되면 각 지원되는 설계에 대해 별도의 증거 기반 카드를 제공하세요.
사용자가 "플러그인 시스템을 사용함"과 같은 주장만 제공하고 설계를 찾도록 요청하면 auto-detect를 사용하세요. 이 주장은 후보 신호일 뿐 선택된 설계가 아닙니다. 직접적인 구현 증거가 없으면 지원되는 후보가 없다고 보고하고 프로젝트별 마이그레이션 예제를 제공하지 마세요.