akshay-diwadkar/skills

다이어그램 생성

공유 모델에 맞추고, 다이어그램을 계획한 후, 번들된 템플릿과 검증기를 통해 빌드합니다. 사용자가 명시적으로 exact-code-graph 또는 executive-concept-map을 요청하지 않는 한, 혼합 이해관계자, 개발자, 관리자 대상의 narrative-architecture를 기본값으로 사용합니다.

워크플로우

1. 탐색

   • 환경이 답할 수 있는 질문을 하기 전에 리포지토리를 검사합니다: 문서, 진입점, 매니페스트, 스키마, 테스트, 경로, 파이프라인, 생성된 아티팩트, 기존 다이어그램.
   • 발견된 사실과 추론을 구분하여 요약합니다.

2. 질문

   • question-framework.md를 읽습니다.
   • 임시 요청-증거 격차 장부를 유지하고 리포지토리 검사나 이전 사용자 컨텍스트만으로 답할 수 없는 질문만 합니다.
   • 라운드당 최대 세 개의 관련 차단 질문을 합니다. 요청과 리포지토리 증거를 인용하고, 답변이 다이어그램을 어떻게 바꾸는지 설명하며, 가능할 때 두세 가지 옵션을 제시하고, 하나를 추천하며 트레이드오프를 설명합니다.
   • 답변을 통합하고 변경된 경계를 다시 탐색하며 반복합니다. 목적, 대상, 출력 위치, 엔티티, 관계, 생략, 증거 정책, 검증 경로가 모두 알려지고 해결된 모델이 명시적으로 확인될 때까지 계획 단계로 넘어가지 않습니다.

3. 계획

   • html-output-guide.md를 읽어 노드 유형 분류, 엣지 유형, 메타데이터 스키마, 빌더 페이로드 형태를 파악합니다.
   • 최종 계획을 제안하기 전에 사용자에게 HTML 다이어그램을 어디에 생성할지 묻습니다.
   • 전체 .html 경로 또는 디렉토리를 허용합니다. 사용자가 디렉토리를 제공하면 다이어그램 제목에서 설명적인 케밥-케이스 파일명을 생성합니다.
   • 해결된 대상 파일이 이미 존재하면 덮어쓰기 전에 묻습니다. 대상 디렉토리가 없으면 생성 전에 묻습니다.
   • 모델 정렬, 디렉토리 생성, 덮어쓰기 확인은 별도의 권한으로 처리하며, 어느 것도 다이어그램 빌드를 승인하지 않습니다.
   • 파일 생성 전에 정확히 하나의 <proposed_plan>을 출력합니다. 계획에는 제목, 목적, 대상, 충실도, 출력 위치, 엔티티, 관계 유형, 클러스터, 가정, 생략, 증거 정책, 생성된 파일명 동작, 검증 단계가 포함되어야 합니다.
   • 계획에서 구현은 사용자가 Plan Mode가 아닌 턴에서 실행을 요청할 때만 발생한다고 명시합니다(협업 모드가 Plan Mode일 때).

4. 빌드

   • 계획이 승인되고 실행이 허용된 후에만 빌드합니다.
   • html-output-guide.md에 설명된 대로 최상위 diagram 및 metadata 객체를 가진 JSON 페이로드를 생성합니다.
   • 노드 x/y를 생략하여 자동 레이아웃을 선호합니다. 수동 위치를 사용하는 경우 모든 노드에 x와 y를 모두 포함해야 합니다.
   • 고정 경로로 번들된 빌더를 실행합니다:

     python /path/to/create-diagram/scripts/build_diagram.py --data <payload.json> --output <path-to-output.html> --create-dirs --overwrite
     

     PowerShell 예시: python C:\path\to\create-diagram\scripts\build_diagram.py --data payload.json --output diagram.html Bash 예시: python /path/to/create-diagram/scripts/build_diagram.py --data payload.json --output diagram.html
   • 생성된 HTML은 자체 포함되어 있습니다: 빌더가 로컬 스타일시트와 RoughJS 런타임을 포함하므로, 형제 자산을 복사하지 않고 모든 디렉토리에서 열거나 서비스할 수 있습니다.
   • 사용자가 누락된 출력 디렉토리 생성을 확인하지 않은 경우 --create-dirs를 생략합니다. 사용자가 교체를 확인하지 않은 경우 --overwrite를 생략합니다.

5. 검증

   • HTML을 열기 전에 검증합니다:

     python /path/to/create-diagram/scripts/validate_diagram.py <path-to-output.html>
     

   • 보고된 모든 오류(종료 코드 1)를 수정한 후 진행합니다. 경고는 검토해야 하지만 검증을 차단하지는 않습니다.

6. 확인

   • 브라우저에서 HTML 파일을 엽니다.
   • 프레젠테이션 필드가 존재할 때 간단한 패널이 렌더링되는지, 엔티티별 노드 모양이 렌더링되는지, 초기 맞춤 시 텍스트가 읽기 쉬운지, 엣지에 레이블이 있는지, 범례가 보이는지, 안내 둘러보기가 시작되고 줌을 변경하지 않고 진행되는지, 드래그/팬/줌/세부사항/노드 드래그/테마/재설정이 둘러보기 중 및 후에 작동하는지 확인합니다.

규칙

• 라운드당 최대 세 개의 밀접하게 관련된 질문을 합니다. 각 질문에는 요청/증거 격차, 중요한 이유, 가능할 때 두세 가지 옵션, 추천, 트레이드오프가 포함되어야 합니다.
• 주변 협업 모드가 Plan Mode인 동안에는 다이어그램 파일을 작성, 생성, 덮어쓰기, 저장 또는 확인하지 않습니다. Plan Mode에서는 <proposed_plan>을 출력한 후 중단합니다.
• 모호한 용어에 도전하세요: "시스템", "에이전트", "파이프라인", "오케스트레이터", "서비스" - 이를 정확하게 만드세요.
• 구체적인 시나리오를 사용하여 모델을 테스트하세요, 특히 실패 경로와 핸드오프.
• 사용자가 명시적으로 요청하지 않는 한 CONTEXT.md나 ADR을 업데이트하지 마세요.
• 일반 출력을 위해 독립형 SVG, 대시보드 스타일 캔버스, 고정 크기 다이어그램 아트, 또는 맞춤 렌더러를 직접 코딩하지 마세요. 공유 HTML 템플릿을 사용하고 DIAGRAM_DATA와 #agent-metadata만 변경하세요.
• 기본 충실도를 narrative-architecture로 유지하세요: 모든 파일이나 의존성을 철저히 매핑하지 않고 결정에 관련된 행위자, 시스템, 데이터 흐름, 소유권, 핸드오프, 실패 경로를 보여줍니다.
• 사용자가 개발자 전용 구현 충실도를 요청할 때만 exact-code-graph를 사용하세요. 대상이 구현 세부사항보다 비즈니스 개념, 소유권, 결과, 위험을 필요로 할 때만 executive-concept-map을 사용하세요.