멘탈 모델 스킬은(는) 무엇을 하나요?
액터, 경계, 커뮤니케이션을 통해 시스템을 설명합니다.
출력 계약: 다이어그램 우선
완성된 멘탈 모델 설명은 반드시 응답 자체에 다이어그램을 포함해야 합니다. 한 문장으로 독자를 안내한 후, 즉시 다음 중 하나를 포함하세요:
- 펜스 처리된
mermaid블록 (sequenceDiagram과autonumber사용, 기본값). - 렌더링 가능하고 D2가 요청된 경우, 임베드된 렌더링된 D2 이미지.
그런 다음 간결한 산문으로 흐름과 그 진화를 설명합니다. 긴 설명을 작성하기 전에 다이어그램을 먼저 구성하여, 시각 자료가 마지막에 누락되지 않도록 합니다. 이 계약은 명시적으로 호출된 멘탈 모델 논의를 이어가는 짧은 답변과 후속 설명에도 적용됩니다. 명확화 질문만 있는 경우에는 다이어그램이 필요하지 않습니다. 사용자가 명시적으로 다이어그램 없음을 요청하면 그 요청을 따릅니다.
ASCII 화살표, 글머리 기호 목록, 표, 일반 코드 블록, 다이어그램 링크, 나중에 그리겠다는 약속, 렌더링되지 않은 D2 소스는 이 계약을 충족하지 않습니다. 사용자에게 다이어그램을 원하는지 묻지 마십시오. 렌더러를 사용할 수 없는 경우에도 Mermaid 소스를 내보내십시오; 채팅이 렌더링하지 못할 수 있으므로 텍스트로 대체하지 마십시오. Mermaid 코드 블록에는 다이어그램 생성 도구가 필요하지 않습니다.
필요한 응답 형태의 예시 (액터를 실제 컨텍스트에 맞게 조정):
브라우저가 API에 데이터 저장을 요청합니다; API가 데이터베이스 액세스를 소유합니다.
```mermaid
sequenceDiagram
autonumber
participant Browser
participant API
participant Database
Browser->>API: Save form data
API->>Database: Store accepted data
Database-->>API: Saved record
API-->>Browser: Success response
```
폼은 브라우저에서 시작됩니다. API를 추가하면 원격으로 저장할 수 있게 되고, 데이터베이스를 추가하면 저장된 데이터가 개별 요청보다 오래 지속됩니다.
명시적 호출
이 스킬은 사용자가 명시적으로 요청할 때만 사용하세요: /mental, $mental, 또는 멘탈 스킬을 사용하라는 직접적인 요청. 일반적인 설명 요청은 이 스킬을 활성화하지 않습니다. 이를 설명 요청으로 간주하고, 설명되는 시스템을 구현, 설치, 게시 또는 변경할 수 있는 권한으로 간주하지 마십시오.
호출 뒤에 나오는 주제를 사용하거나, 대화에서 주제를 유추하세요. 주제를 합리적으로 유추할 수 없는 경우에만 집중된 질문 하나를 하세요.
설명 구성
- 대화와 사용 가능한 증거에 모델을 근거하세요. 기존 코드베이스의 경우, 관련 관계를 설정하는 데 필요한 진입점이나 구성만 검사하세요. 관찰된 사실과 가정을 구분하세요. 서비스, 성공적인 배포, 또는 검증된 동작을 임의로 만들지 마세요.
- 가장 작은 유용한 시스템부터 시작하세요: 로컬에서 실행되는 단일 스크립트, 페이지를 표시하는 브라우저, 또는 요청에 응답하는 서비스. 인프라를 도입하기 전에 이미 작동하는 것을 설명하세요.
- 논의 중인 시스템으로 점진적으로 진행하세요. 각 의미 있는 단계에서 새로운 요구, 이를 충족하기 위해 추가된 액터 또는 연결, 그리고 액션이 이제 시스템을 통해 어떻게 이동하는지 설명하세요. 이는 설명 단계이며, 역사적 연대기에 대한 주장이 아닙니다. 사용자가 실제 프로젝트 진화에 대해 묻는 경우, 사용 가능한 기록을 사용하고 격차를 식별하세요.
- 컨텍스트에 따라 액터를 선택하세요: 사람, 프로세스, 서비스, 스토리지, 레지스트리, 큐 또는 외부 공급자. 각각에 구체적인 역할을 부여하세요. 위치가 이해에 영향을 미치는 경우 관련 액터를 시스템, 프로세스 또는 네트워크 경계별로 그룹화하세요.
- 하나의 구체적인 액션을 액터를 통해 순서대로 추적하고, 호출자에게 결과가 반환되는 것을 포함하세요. 각 경계를 가로지르는 것을 레이블로 표시하세요: 소스 코드, 패키지 아카이브, HTTP 요청, JSON 응답, 이벤트 또는 저장된 데이터. 설정 및 배포와 런타임 통신을 둘 다 중요할 때 분리하세요.
- 혼란을 해결하는 경우에만 구분을 설명하세요. 예를 들어, 패키지 이름은 가져올 항목을 선택하고, 명령 이름은 실행할 항목을 선택하며, 인수는 해당 명령의 입력이 됩니다. 브라우저/API 예제의 경우, 코드 전달과 이후 API 요청을 구분하세요.
용어집이나 구성 요소 목록보다는 연결된 산문이 있는 짧은 진행을 선호하세요. 사용자가 현재 상호작용만 원하는 경우, 긴 진화를 강요하지 않고 해당 흐름을 보여주세요. 명령과 스니펫은 모델을 고정해야 합니다; 플래그 인벤토리, 구현 연습 및 관련 없는 대안은 피하세요. 캐시가 다운로드를 방지하거나 작업이 완료되기 전에 비동기 승인이 도착하는 등 모델을 변경하는 세부 사항은 유지하세요.
다이어그램 정확성
이 스킬로 생성된 모든 응답은 적어도 하나의 Mermaid 다이어그램 또는 렌더링된 D2 이미지를 포함해야 합니다. 기본값은 펜스 처리된 mermaid 블록입니다: 렌더링 도구가 필요 없으며 렌더링을 사용할 수 없을 때 소스를 읽을 수 있습니다.
- 번호가 매겨진 시퀀스 다이어그램을 선호하세요: Mermaid 다이어그램을
sequenceDiagram으로 시작하고autonumber를 추가하세요. 호출, 메시지 및 응답의 순서를 명확히 하세요. 참가자를 읽기 쉬운 왼쪽에서 오른쪽 순서로 도입하세요. - 요청뿐만 아니라 응답에도 번호를 매겨 독자가 전체 상호작용을 따라갈 수 있게 하세요. 산문에서 번호가 매겨진 단계를 추적하고, 다이어그램과 일관된 참조를 유지하세요. 번호 매기기는 설명된 시나리오를 보여주며, 동시 작업이 항상 하나의 고정된 순서로 실행된다는 주장이 아닙니다. 동시성, 대안 또는 선택적 단계가 모델을 변경할 때
par,alt또는opt를 사용하세요. - 진화의 경우, 의미 있는 단계에 대해 별도의 작은 번호가 매겨진 시퀀스를 사용하세요; 참가자 이름을 안정적으로 유지하고 추가된 액터나 메시지를 설명하세요.
- 토폴로지 또는 구조가 주요 질문이고 시퀀스가 이를 모호하게 할 때, 또는 사용자가 요청할 때만 플로우차트를 사용하세요. 상호작용을 보여주는 D2 이미지의 경우, 시퀀스 레이아웃을 선호하고 메시지에 명시적으로 번호를 매기세요.
- 구체적인 액터 이름과 액션이나 데이터로 레이블이 지정된 방향성 화살표를 사용하세요. 레이블이 없는 화살표와 아무것도 설명하지 않는 장식 상자는 피하세요.
- 각 다이어그램을 설명 중인 상호작용에 집중시키세요. 다른 단계나 복잡한 시스템은 작은 다이어그램으로 분할하세요. 단계별 다이어그램에서 새로 도입된 액터와 연결을 표시하세요.
- 레이블을 간단하게 유지하고 구두점이 포함된 플로우차트 레이블은 인용하세요. 보내기 전에 노드 참조, 화살표 방향, 서브그래프 및 펜스 처리된 구문을 확인하세요.
- 패키지 레지스트리는 코드를 배포합니다; 사용자의 CLI를 실행하는 것으로 그리지 마세요. 데이터베이스는 데이터를 저장합니다; 실제 시스템의 기능이 아닌 한 일반 애플리케이션 요청을 시작하는 것으로 그리지 마세요.
- 사용자가 D2를 선호하고 렌더러를 사용할 수 있는 경우, 결과를 렌더링하고 검사한 다음 이미지를 임베드하세요. D2 소스만으로는 이미지 요구 사항을 충족하지 않습니다. 렌더링을 사용할 수 없는 경우 Mermaid를 사용하고 대체 이유를 간략히 설명하세요. 모델을 설명하기 위해 렌더러를 설치하지 마세요.
다이어그램 뒤에는 구체적인 액션에 대한 짧은 설명을 작성하세요. 모델이 명확해지면 종료하세요; 구현 작업이나 일반적인 요약을 추가하지 마세요.
보내기 전에
응답 자체를 검사하세요: 펜스 처리된 mermaid 블록 또는 임베드된 렌더링된 D2 이미지가 포함되어 있습니까? 둘 다 없으면 설명이 불완전합니다. 보내기 전에 다이어그램을 추가하세요. Mermaid 시퀀스 다이어그램의 경우 autonumber가 있는지 확인하세요. 화살표가 산문과 일치하고 구체적인 액터와 레이블이 지정된 커뮤니케이션으로 적어도 하나의 실제 상호작용을 추적하는지 확인하세요.
예제
예제가 설명을 조정하는 데 도움이 될 경우 참조/예제.md를 읽으세요. npm 배포, 프론트엔드/백엔드 호출, 서비스 간 호출 및 비동기 작업이 포함되어 있습니다. 해당 액터를 모든 설명에 가져오지 말고 실제 컨텍스트에 접근 방식을 적용하세요.