paulmil11/decks

decks은(는) 무엇을 하나요?

사용자는 브라우저에서 데크를 검토합니다. 슬라이드 아래에 댓글을 입력하거나(또는 슬라이드에서 직접 텍스트를 편집) "process changes"라고 말하거나 데크에서 Ask Claude를 클릭하면 데크 파일과 아래 sb 단계를 명명하는 프롬프트가 복사됩니다. 해당 프롬프트를 해당 데크에 대한 "process changes"로 처리하십시오. 모든 댓글에 대해 조치하고, 슬라이드 자체에 답변하고, 작업을 확인하고, 내보냅니다. 채팅 요약은 짧게 유지하십시오: 슬라이드의 답변이 세부 정보를 전달합니다.

위치

• 앱 폴더는 Decks 저장소입니다: 이 스킬이 포함된 폴더(내부의 .claude/skills/decks/) 또는 ~/.claude/skills/에 있는 이 스킬의 복사본의 경우 사용자가 복제한 위치입니다. Ask Claude 프롬프트가 이를 명명합니다. 여기에는 server.py, sb 명령줄, static/의 브라우저 셸, templates/의 템플릿 및 tools/의 헤드리스 도구가 포함됩니다. 거기서 sb를 실행하십시오: ./sb ....
• 서버: python3 server.py, config.json 또는 SB_PORT가 달리 지정하지 않는 한 http://localhost:8790/ 에서 실행됩니다. sb가 서버에 연결할 수 없다고 말하면 (백그라운드에서) 시작하고 다시 시도하십시오. sb는 SB_URL 또는 설정된 포트에서 찾습니다.
• 데크는 데크 폴더(기본값 ~/slide-decks)에 있으며, 데크당 하나의 폴더이며, 해당 폴더의 decks.json에 나열됩니다. ./sb decks는 주소와 함께 데크를 나열합니다.
• http://localhost:<port>/d/<slug>/<entry>에서 데크를 엽니다. #s=<slide-id>는 슬라이드로 이동하고, #v=<version>&s=<id>는 버전을 선택합니다.
• 저장된 상태는 각 데크 옆의 .slidebuilder/에 있습니다:
  • state.json: 페이지에서 미러링된 검토자의 편집 내용, 댓글 및 슬라이드 순서. 수동으로 쓰지 마십시오.
  • review.json: 답변, 라운드 및 변경된 배지. sb를 통해 작성하십시오.
• 모든 데크 폴더는 git 저장소입니다. PDF, zip 및 PPTX 파일은 무시됩니다.

페이지

• 4개의 보기: 포커스(F), 스크롤(S), 소터(G) 및 검사(C). 왼쪽의 필름스트립은 드래그로 재정렬됩니다.
  • 포커스 및 스크롤에서 댓글 상자는 각 슬라이드 아래에 있으며 그 아래에 답변이 있습니다. 오른쪽 막대에는 슬라이드의 노트와 변경된 내용이 있습니다.
  • 검사에는 5가지 검사(키 1~5)가 있습니다: 5초 테스트(첫인상), 10초 테스트(가독성; 실패하면 다음 라운드를 위해 슬라이드에 댓글을 남깁니다), 수평 흐름(타이틀만 해당, 제자리에서 편집 가능), 수직 흐름(타이틀 먼저, 본문은 공개될 때까지 숨겨짐) 및 가이드.
  • 댓글은 검사에서 올 수 있습니다: 시간 제한 테스트 실패 후 "5초 테스트: …" 및 "10초 테스트: …", 그리고 Ask Claude에서 검사 › 가이드에서 수정하도록 "가이드: …"는 슬라이드가 위반하는 사항을 명명합니다. 다른 댓글과 마찬가지로 슬라이드가 통과하도록 수정하십시오.
  • H는 타이틀을 제외한 모든 것을 숨깁니다. ?는 모든 단축키를 나열합니다.
• 슬라이드 추가(N, "+ 슬라이드" 또는 슬라이드 사이의 +)는 레이아웃을 제안하고 데크가 전달하는 것을 추가할 수 있습니다. 해당 복사 프롬프트는 데크 파일, 위치 및 슬라이드가 말해야 하는 내용을 제공합니다. 프롬프트가 "방금 ... 슬라이드(LIBRARY['id'])를 추가했습니다"라고 말하면 해당 슬라이드를 채우고, "새 슬라이드 ...를 추가"라고 말하면 해당 위치의 데크 파일에 빌드하십시오.
• 검토자가 검사에서 타이틀을 편집하면 인라인 편집입니다: 다른 편집처럼 적용하십시오.
• 클라이언트 작업 숨기기(대시보드 스위치, 데크 폴더의 settings.json)는 녹화 또는 화면 공유를 위한 것입니다. 이 기능이 켜져 있으면 서버는 client로 표시된 데크와 clientVersions에 나열된 버전을 남깁니다. 이 기능이 켜져 있을 때 화면에 클라이언트 이름을 절대 표시하지 마십시오.

라운드("process changes")

1. cd를 앱 폴더로 변경합니다.
2. ./sb comments <deck>은 데크와 같이 번호가 매겨진 조치할 댓글을 나열합니다. 초안은 건너뜁니다. ./sb edits <deck>은 검토자의 인라인 텍스트 편집 및 슬라이드 이동을 보여줍니다. 둘 다 디스크에서 읽으므로 브라우저 탭이 필요하지 않습니다.
3. ./sb status <deck> "귀하의 9개 댓글을 읽는 중" --done 0 --total 9. 검토자는 상단 막대에서 이것을 실시간으로 봅니다. 진행하면서 업데이트하십시오.
4. 각 댓글에 대해:
   • ./sb working <deck> <slide>.
   • 데크 파일에서 변경합니다.
   • ./sb reply <deck> <slide> done "무엇이 변경되었는지에 대한 한 문장".
   • 검토자의 결정이 필요한 경우 done 대신 question을 사용하십시오. 의도적으로 그대로 둔 내용에 대해서는 skipped를 사용하고 이유를 설명하십시오.
   • 반쯤 입력된 댓글에는 추측하지 말고 question 답변을 사용하십시오.
5. 검토자의 인라인 편집을 데크 파일에 적용하십시오(그들의 편집이 우선). Git에는 이전 버전이 있습니다.
6. 건드린 모든 슬라이드를 확인하십시오:
   • ./sb shot <deck> <ids…>, 그런 다음 각 이미지를 확인합니다.
   • ./sb audit <deck>은 오버플로, 겹치는 레이블 및 가이드가 플래그하는 모든 것을 찾습니다.
   • ./sb comments <deck>은 새롭고 처리되지 않은 것이 없어야 합니다.
7. 마무리:
   • ./sb export <deck>은 데크 파일에서 다음 번호의 PDF를 작성하고 이전 파일을 _archive/로 이동합니다. 브라우저에 아직 적용되지 않은 편집 내용이 있으면 알려줍니다: 먼저 적용하십시오. --with-edits는 브라우저에 표시되는 그대로 내보냅니다.
   • ./sb round <deck> --summary "…" --changed id="변경된 내용" … --export vN.
   • ./sb commit <deck> "라운드 N: …".
   • ./sb idle <deck>.
   • 사용자에게 PDF 위치를 알려줍니다.
8. 검토자가 입력을 멈추면 페이지가 자동으로 다시 로드됩니다. 탭을 다시 로드하거나 지우지 마십시오. 채팅에서는 몇 줄과 결정이 필요한 사항을 알려줍니다.

작업 중에 새 댓글이 도착할 수 있습니다. 마무리하기 전에 ./sb comments를 다시 실행하십시오.

검토자는 "좋아요"로 처리된 댓글을 지웁니다. DONE_FB에 추가하지 마십시오. 해당 목록은 Decks 외부에서 열린 복사본(예: 다른 사람에게 보낸 파일)에만 사용됩니다.

데크 파일

• 데크당 하나의 자체 포함 HTML 파일로, 편집하는 세 부분이 있습니다:
  • 콘텐츠: cat, layout, title, …, notes가 있는 LIBRARY 항목('id': { cat, layout, title, …, notes }), cat별로 부분으로 그룹화됨(부분은 CATS이며 CAT_LABELS에 명명됨)
  • 그림: FIGS 함수는 인라인 SVG를 반환합니다.
  • 버전: PITCHES(각각 이름과 슬라이드 ID 목록)
• 기본 버전은 각 부분 내의 LIBRARY 순서입니다. 재정렬하려면 LIBRARY 항목을 이동하십시오. 이전 기본값과 동일한 저장된 순서는 파일을 따릅니다.
• alt:true로 슬라이드를 은퇴시키고(소터의 선반으로 이동) 교체품을 바로 앞에 놓으십시오. 사용자의 슬라이드를 삭제하지 마십시오. 슬라이드의 대체 버전은 prop:true, replaces:'…'("제안됨"으로 태그됨)를 얻습니다.
• 소스 줄은 src:'출처: …'를 통해 바닥글에 들어가며 부제목이 아닙니다.
• 색상, 제목 글꼴 및 로고: 데크 파일의 <style id="deck-theme"> 블록 및 img/의 데크 로고용 LOGO. 해당 블록을 편집하여 스타일을 변경하고 개별 슬라이드는 변경하지 마십시오. LOGO가 없으면 슬라이드에 로고가 없습니다.
• 큰 시각적 변경(새 레이아웃, 재설계): 먼저 사용자에게 목업 또는 두 가지 옵션을 보여준 다음 빌드하십시오.
• 사용자가 보낼 파일을 원할 때는 ⋯ 메뉴의 클라이언트 복사본입니다: 화면에 표시된 슬라이드만 있는 버전(노트, 댓글, 진행자 슬라이드, 다른 버전 또는 편집 없음), 내부에 그림, 프레젠테이션 버튼 포함. 편집 가능한 복사본은 노트와 댓글이 있는 전체 데크입니다: 해당 파일을 클라이언트에게 절대 보내지 마십시오.
• 데크는 ./sb hide <deck>으로 대시보드에서 제거됩니다(./sb show로 다시 표시). ./sb delete <deck> --yes는 이 앱이 만든 데크를 휴지통으로 이동하고 사용자 자신의 폴더에 있는 데크만 등록을 취소합니다. 사용자가 요청할 때만 삭제하십시오.
• 이미지 또는 로고 다운로드는 매번 사용자의 승인이 필요합니다. 파일 이름, 출처, 크기 및 라이선스를 알려주고 바닥글에 크레딧을 넣으십시오.

방법론

Decks는 Paul Millerd가 StrategyU에서 가르치는 방법론을 기반으로 합니다. 작성하거나 수정하는 모든 슬라이드에 적용하십시오. strategy-slides 스킬이 설치된 경우 전체 버전이 있습니다: 스토리라인, 타이틀 및 피드백에 사용하십시오.

먼저 답변하십시오. 권장 사항, 그 다음 맥락, 그 다음 증거로 시작하십시오. 회의적인 청중에게만 권장 사항(상황과 복잡성, 그 다음 핵심 아이디어)을 작성하십시오.

고스트 데크 먼저. 슬라이드 본문을 작성하기 전에 모든 액션 타이틀을 순서대로 작성하고 하나의 문단으로 읽으십시오. 문단이 주장을 전달하지 않으면 지금 타이틀 또는 순서를 수정하십시오. 스토리를 수정하는 가장 저렴한 지점입니다. 각 본문이 타이틀을 증명하기 위해 무엇을 표시해야 하는지 기록하십시오.

수직 흐름: 타이틀은 핵심 내용이고 본문이 이를 증명합니다.

• 모든 타이틀은 액션 타이틀입니다: 요점을 말하는 완전한 문장. "Q3 매출이 엔터프라이즈 확장에 힘입어 22% 성장했습니다"는 절대 "Q3 매출"이 아닙니다.
• 모호한 타이틀을 넘어서십시오. "회사가 개선되고 있습니다"는 1단계입니다. "공급망 투자로 인해 수익성이 5년 만에 처음으로 증가했습니다"가 목표입니다.
• "핵심 요점" 상자 또는 하단 요약 스트립이 없습니다. 통찰력이 페이지를 이끕니다.
• 평범한 동사와 자연스러운 목적어를 사용하십시오. 데이터를 의인화하거나 숫자에 은유를 강요하지 마십시오. 쉼표-피벗 조각 없음("두 가지 사고 방식, 작업에 두 가지가 필요할 때"). 최대 두 줄. 큰 소리로 읽으십시오: 동료에게 말하는 것처럼 들려야 합니다.
• 숫자만 있는 타이틀은 비어 있습니다. "세 가지 위험과 대처 방법"은 발견으로 대체됩니다: "실질적 노출은 창고 용량이 아닌 서부 해안 서비스입니다."
• 표지, 섹션 구분선 및 부록 구분선은 예외입니다. 마무리 슬라이드는 예외가 아닙니다: "다음 단계"가 아닌 "3월 14일까지 승인하면 갱신 전에 두 임대를 모두 종료합니다."

수평 흐름: 타이틀만으로 스토리를 전달합니다. 순서대로 읽으십시오(검사 › 수평 흐름). 슬라이드 본문 없이 이해가 되지 않으면 타이틀 또는 순서를 수정하십시오.

슬라이드당 하나의 아이디어. 슬라이드에 "그리고 또한"이 필요하면 두 개의 슬라이드가 필요합니다.

5초 및 10초 테스트는 가독성에 관한 것입니다. 발표된 슬라이드는 5초 안에 한 가지 요점을 전달합니다. 사람들이 읽는 슬라이드는 10초 이내에 파악할 수 있어야 합니다: 하나의 주요 요점, 읽기 쉬운 계층 구조, 연구 없이 모양을 읽을 수 있는 차트. 텍스트 벽, 빽빽한 표에 묻힌 핵심 숫자 및 한 슬라이드의 여러 관련 없는 아이디어는 모두 실패합니다.

"그래서 뭐?"는 별도의 테스트입니다. 혁신, 우수성, 성장을 읽는 세 개의 깔끔한 상자는 10초 테스트를 통과하고 "그래서 뭐?"(예쁜 슬라이드 증후군)에 실패합니다. 모든 슬라이드는 청중에게 무엇을 생각해야 하는지 알려줍니다. 피드백을 제공할 때 두 가지 결과를 분리하여 유지하십시오.

차트는 타이틀을 증명합니다. 차트를 그리기 전에 메시지를 작성하십시오. 막대, 기둥 및 선은 거의 모든 것을 다룹니다. 원형 차트는 절대 사용하지 마십시오. 중요한 숫자는 가장 눈에 띄는 표시이고, 타이틀이 명명하는 모든 것(경기 침체, 변곡점)은 차트에 표시되며, 타이틀을 지원하지 않는 것은 모두 제거됩니다. 불확실한 데이터는 "예시" 레이블과 가정에 대한 메모를 받습니다.

경영진 요약은 가장 중요한 슬라이드입니다: 권장 사항이 타이틀이고, 각각 증거 한 줄이 있는 세 가지 통찰력. 섹션 구분선은 긴 데크(20개 이상의 슬라이드)에서 뚜렷한 섹션이 있는 경우에만 사용하십시오.

발표용 또는 읽기용. 발표용: 본문 20단어 미만, 하나의 아이디어, 큰 시각 자료. 읽기용: 더 많은 텍스트가 허용되며 굵은 선행 단어가 있고, 각 슬라이드는 독립적으로 전달될 수 있으므로 자체적으로 완결됩니다.

데크에 대한 피드백 제공. 먼저 전체 데크를 읽으십시오. 그런 다음 순서대로: 스토리(순서대로 타이틀, 내용 및 누락되거나 순서가 잘못된 것); 문제가 있는 슬라이드와 수정 사항(타이틀이 문제인 경우 새 타이틀 작성); 그리고 가장 중요한 세 가지 변경 사항과 주장 및 글꼴과 색상보다 먼저 순서. 주장이 성립하지 않으면 먼저 말하십시오. 인용하기 전에 모든 슬라이드 번호를 확인하십시오.

작문. 능동 동사, 축약형 및 형용사보다 숫자. 절대 사용 금지: delve, landscape, leverage, utilize, crucial, pivotal, robust, seamless, transformative, underscore, additionally, moreover, furthermore. 슬라이드당 최대 하나의 엠 대시.

슬라이드 스타일 규칙

방법론에 추가:

• 카드나 상자 하단에 작고, 흐리거나 기울임꼴 줄이 없습니다. 중요한 것은 속한 항목에 포함시키십시오.
• 동일한 카드의 그리드가 없습니다. 대신 관계를 그리십시오: 프로세스, 스펙트럼, 사다리, 차트 또는 지도.
• 지침은 하나의 평범한 문장입니다. 성찰 질문은 평범하며 청중 자신의 작업에 관한 것입니다.
• 의제 시간은 5분 블록으로 반올림합니다.
• 프레임워크를 발명하기 전에 사용자의 고유 자료, 다이어그램 및 표현을 사용하십시오. 잘라낼 때 발명된 슬라이드를 먼저 자르고, 빌드 및 설정/전개 쌍은 그대로 유지하십시오.
• 사용자가 교체할 수 있도록 작성한 텍스트를 노트에 표시하십시오.
• 인용문 및 숫자는 세션에서 연 출처에서만 가져오고, 정확하게 인용하고 실제 말한 사람에게 귀속시키십시오.
• 모든 것은 검사 › 가이드를 통과합니다: 보호된 테두리, 두 줄 타이틀, 12px 미만 없음, 슬라이드당 최대 4개의 텍스트 크기. 이는 지침이지 규칙이 아닙니다. sb audit이 나열하는 것을 수정하거나 슬라이드가 예외인 이유를 설명하십시오.

새 데크 시작하기

사용자는 대시보드의 새 데크 양식에서 데크를 시작합니다. 두 단계로 진행됩니다. 1단계: 이름, 구축 중인 것(프레젠테이션, 교육, 강연, 제안 또는 빈 데크) 및 함께 구축할 요소. 2단계: 대상, 대상이 알고 관심을 갖는 것, 한 가지 요점, 선택적 길이, 청중 유형, 구조, 밀도, 색상, 제목 글꼴, 로고 및 노트. 데크 만들기는 폴더를 만들고, 자체 저장소 접두사를 부여하고, decks.json에 추가하고, git 기록을 시작하고, BRIEF.md에 브리프를 작성하고, 클립보드에 프롬프트를 복사하고, 데크를 엽니다. 사용자가 프롬프트를 붙여넣으면:

1. 데크 폴더에서 BRIEF.md를 읽고 슬라이드를 작성하기 전에 템플릿을 이에 맞게 조정하십시오. 템플릿은 고정된 형식이 아닌 시작점입니다:
   • 사용 방법. 발표용: 슬라이드당 하나의 아이디어, 큰 글꼴, 적은 텍스트; 5초 테스트를 통과해야 합니다. 읽기용 보내기: 각 슬라이드는 더 풍부한 본문으로 독립적으로 서며 10초 테스트를 통과해야 합니다. 발표 후 보내기: 발표 가능한 슬라이드, 상세 내용은 노트 또는 부록에.
   • 청중과 그들이 아는 것. 어휘, 예제 및 설명 정도를 조정하십시오. 임원에게는 먼저 답변을 제공하십시오.
   • 구조. 먼저 답변: 권장 사항, 그 다음 이유. 상황, 복잡성, 해결: 해당 순서로. 몇 부분으로 나뉜 스토리: 구분선이 있는 섹션. 가르치고, 연습하고, 반영: 연습 문제와 성찰 질문이 있는 모듈.
   • 밀도. 단어가 말하는 대로 드문드문, 균형 또는 상세.
   • 빈 항목은 당신의 재량입니다.
2. LIBRARY 항목을 BRIEF.md 및 선택한 템플릿에 맞춰 작성하고 배치하십시오.
3. 수직 및 수평 흐름이 방법론을 따르는지 확인하십시오.
4. ./sb export <deck>으로 초안을 내보내고 사용자에게 초기 검토를 요청하십시오.

명령줄 참조

./sb 내에서:

• comments, edits, status, working, reply — 위 라운드 절차 참조.
• shot, audit — 위 검사 단계 참조.
• export, round, commit, idle — 위 마무리 단계 참조.
• decks — 등록된 모든 데크와 주소를 나열합니다.
• hide, show, delete — 위 데크 관리 참조.
• help — 전체 명령 목록을 표시합니다.

일반적인 오류 방지:

• 실행하기 전에 cd를 앱 폴더로 변경하십시오.
• 데크 슬러그를 올바르게 전달하십시오(./sb decks로 찾을 수 있음).
• --help로 필요한 경우 인수를 확인하십시오.