decision-logger
작성자 alirezarezvanidecision-logger는 승인된 이사회 의사결정을 관리하는 Decision Support skill입니다. 원본 회의록과 Layer 2 의사결정 인덱스를 분리하고, 담당자, 마감일, 기각된 선택지, 후속 조치를 추적합니다. 또한 요약, 기한 초과 항목, 충돌 사항, 담당자별 필터, 검색을 지원하는 Python tracker를 포함합니다.
이 skill은 80/100점으로, 구조화된 이사회 의사결정 메모리와 액션 아이템 검토가 필요한 디렉터리 사용자에게 충분히 추천할 만한 후보입니다. 정의된 트리거, 오래 유지되는 승인 의사결정 형식, 보고용 스크립트를 제공해 일반 프롬프트보다 에이전트 활용도가 높습니다. 다만 도입은 주변 C-Level Advisor 워크플로 안에서 사용할 때 가장 수월합니다.
- 설명에 트리거 조건이 명확합니다. 이사회 회의 이후, 승인된 의사결정을 검토할 때, 또는 기한이 지난 액션 아이템을 확인할 때 사용할 수 있습니다.
- 운영에 필요한 내용이 갖춰져 있습니다. SKILL.md가 raw/approved 의사결정 메모리의 2계층 모델, 명령, 키워드, 사용 사례를 정의합니다.
- scripts/decision_tracker.py를 통한 실행 가능한 지원과 일관된 Layer 2 항목 작성을 위한 필드 규칙이 포함된 의사결정 입력 템플릿을 제공합니다.
- skill 경로에 설치 명령이나 README가 제공되지 않아, 사용자가 더 큰 저장소 구조를 바탕으로 설치 방식을 추론해야 합니다.
- 워크플로가 C-Level Advisor/board-meeting 생태계와 /cs:decisions, /cs:review 같은 slash commands에 맞춰져 있어, 단독 활용성은 제한될 수 있습니다.
decision-logger skill 개요
decision-logger가 하는 일
decision-logger는 이사회 회의 결과를 오래 유지되는 2계층 의사결정 메모리로 정리하는 Decision Support skill입니다. Layer 1은 원본 회의 맥락을 보존하고, Layer 2는 승인된 결정, 담당자, 마감일, 기각된 선택지, 후속 항목만 저장합니다. 핵심은 실용성입니다. 이후 AI가 보조하는 회의에서는 미해결 논쟁이나 만들어낸 합의가 아니라, 확인된 결정에 근거해야 합니다.
이사회와 경영진 워크플로에 가장 잘 맞는 경우
decision-logger skill은 창업자, chiefs of staff, 이사회 운영 담당자, 반복적인 경영진 회의를 지원하는 AI 에이전트에게 잘 맞습니다. 회의가 끝난 뒤에도 결정 사항이 남아 있어야 하고, 나중에 검색 가능해야 하며, 논의 메모와 분리되어야 하는 워크플로에 적합합니다. 특히 board-meeting 방식의 프로세스가 창업자 승인으로 마무리되고, 이후 깔끔하고 감사 가능한 기록이 필요한 경우에 유용합니다.
핵심 차별점: 승인된 메모리만 남김
가장 강한 설계상의 선택은 원본 transcript와 승인된 Layer 2 index를 분리한다는 점입니다. 이후 리뷰에서는 회의의 모든 주장과 논쟁이 아니라 승인된 계층을 읽습니다. 덕분에 과거에 기각된 아이디어가 여전히 유효한 선택지처럼 다시 등장하는 일을 줄일 수 있습니다. 템플릿에는 DO_NOT_RESURFACE, 대체·승계 필드, 리뷰 날짜, 담당자 추적도 포함되어 있어, 일반적인 “회의록 요약” 프롬프트보다 훨씬 운영에 가깝습니다.
설치 전에 확인할 점
decision-logger를 도입하기 전에 팀이 ~/.claude/decisions/approved/decisions.md에 로컬 의사결정 index를 유지하는 방식에 익숙한지 확인하세요. 포함된 Python helper는 이 파일을 읽어 기한 초과 항목, 충돌, 담당자별 액션, 키워드 검색을 보고할 수 있습니다. 현재 프로세스에서 승인된 결정과 논의 메모를 구분하지 않는다면, 먼저 회의 운영 방식부터 조정해야 할 수 있습니다.
decision-logger skill 사용 방법
decision-logger 설치와 먼저 살펴볼 파일
다음 repository path에서 skill을 설치합니다.
npx skills add alirezarezvani/claude-skills --skill decision-logger
설치 후에는 아래 파일을 순서대로 읽어보세요.
SKILL.md— 2계층 메모리 모델, slash-command의 목적, 예상 저장 위치를 설명합니다.templates/decision-entry.md— 정확한 Layer 2 entry 형식을 보여줍니다.scripts/decision_tracker.py— summary, 기한 초과 항목, 충돌, 담당자 필터, 검색을 위한 reporting command를 제공합니다.
이 script는 Python standard library만 사용하므로, Python만 사용할 수 있으면 별도의 dependency 설정은 필요 없습니다.
skill이 제대로 작동하기 위해 필요한 입력
decision-logger를 효과적으로 쓰려면 에이전트에게 대략적인 회의 요약만 주지 마세요. 안건, 최종 승인된 결정, 책임 담당자, 마감일, 리뷰 날짜, 근거, 기각된 대안, founder override 여부를 함께 제공해야 합니다. 템플릿은 entry 하나에 결정 하나를 기대하므로, 여러 결과가 묶여 있다면 별도 기록으로 나누세요.
부족한 입력: “가격 정책을 논의했고 뭔가 테스트하기로 했다고 기록해줘.”
더 나은 입력: “2026-03-05 board meeting에서 승인된 결정을 기록해줘. 신규 고객 대상으로 flat pricing에서 three-tier pilot으로 전환한다. Owner: CRO. Deadline: 2026-04-15. Review: 2026-05-01. Rationale: migration risk를 제한하면서 expansion path를 개선한다. Rejected: support load가 너무 높기 때문에 기존 고객 전체의 즉시 migration은 기각됨. Raw transcript path: ~/.claude/decisions/raw/2026-03-05-pricing.md.”
회의 후 실무 워크플로
decision-logger는 열린 논쟁 중이 아니라 승인 이후에 사용하세요. 안정적인 워크플로는 다음과 같습니다.
- Layer 1에 원본 transcript를 저장하거나 참조합니다.
- 에이전트에게 founder-approved outcomes만 추출하도록 요청합니다.
templates/decision-entry.md를 사용해 Layer 2 entry를 만듭니다.- 기각된 선택지는 이유와
DO_NOT_RESURFACE를 함께 표시합니다. - tracker script를 실행해 summary, 기한 초과 action, 충돌을 확인합니다.
repository에서 유용한 command는 다음과 같습니다.
python scripts/decision_tracker.py --demopython scripts/decision_tracker.py --summarypython scripts/decision_tracker.py --overduepython scripts/decision_tracker.py --conflictspython scripts/decision_tracker.py --owner "CTO"python scripts/decision_tracker.py --search "pricing"python scripts/decision_tracker.py --due-within 7
더 좋은 entry를 위한 프롬프트 패턴
좋은 호출은 서술형 요약이 아니라 decision entry를 요청해야 합니다. 예를 들면 다음과 같습니다.
“Use the decision-logger skill to create a Layer 2 approved decision entry. Include one clear decision statement, one accountable owner, deadline, review date, rationale, rejected proposals with DO_NOT_RESURFACE, action items, supersedes fields if applicable, and the raw transcript path. Do not include unapproved discussion points.”
이런 방식으로 요청하면 모호성이 줄어들고, 이후 Decision Support에 사용할 수 있을 만큼 Layer 2를 깔끔하게 유지할 수 있습니다.
decision-logger skill FAQ
decision-logger는 이사회 회의 전용인가요?
이 skill은 이사회와 C-level 의사결정 메모리를 중심으로 설계되었지만, 투자위원회, 리더십 staff meeting, product council, governance review에도 사용할 수 있습니다. 핵심 조건은 결정이 공식적으로 승인되고 후속 관리가 필요하다는 점입니다. 최종 결정 없이 아이디어를 넓히는 brainstorming session에는 적합성이 떨어집니다.
AI에게 회의록을 요약해 달라고 하는 것보다 무엇이 나은가요?
일반적인 요약은 논의, 권고, 반대 의견, 결정을 한데 섞는 경우가 많습니다. decision-logger는 승인된 결정, 담당자, 마감일, 근거, 기각된 선택지, action item, supersession, 원본 transcript link라는 구조를 강제합니다. 이 구조가 있어야 이후 리뷰, 기한 초과 확인, 충돌 탐지가 가능합니다.
decision-logger skill에는 database가 필요한가요?
아니요. repository 기준으로는 markdown 기반 저장소와 Python standard-library script를 사용합니다. 주요 Layer 2 index는 ~/.claude/decisions/approved/decisions.md에 위치하는 것으로 예상되며, --file을 통해 다른 file path에 대한 legacy support도 제공합니다. 이 방식은 가볍지만, 다중 사용자 권한, dashboard, audit log가 필요한 팀은 추가 tooling이 필요할 수 있습니다.
언제 decision-logger를 쓰지 않는 편이 좋나요?
모든 회의 메모를 쌓아두는 공간으로 사용하지 마세요. 결정이 담당자나 날짜 없이 계속 바뀌거나, 조직 내에서 실제로 무엇이 승인되었는지 식별할 수 없다면 적합하지 않습니다. 그런 경우에는 의사결정 메모리를 추가하기 전에 meeting-notes skill이나 project-management integration이 더 적절할 수 있습니다.
decision-logger skill 개선 방법
더 명확한 승인으로 decision-logger 결과 개선하기
품질을 좌우하는 가장 중요한 요소는 승인 여부의 명확성입니다. 기록하기 전에 다음을 확인하세요. 정확히 무엇이 결정되었나요? 누가 책임지나요? 언제까지인가요? 무엇이 명시적으로 기각되었나요? 이후 에이전트가 다시 꺼내지 말아야 할 것은 무엇인가요? 이 중 하나라도 빠져 있다면, 모호한 entry를 만들기보다 follow-up question을 먼저 해야 합니다.
예방해야 할 흔한 실패 패턴
한 문단에 여러 결정을 담은 entry, 책임자가 한 명으로 특정되지 않은 공동 소유, “soon” 같은 마감일, 결정을 반복할 뿐인 근거, 이유 없는 기각 아이디어를 주의하세요. 이런 요소는 이후 검색과 리뷰의 품질을 떨어뜨립니다. 템플릿의 field rule은 제안이 아니라 제약 조건으로 다루는 편이 좋습니다.
첫 생성 entry 이후 반복 개선하기
에이전트가 entry 초안을 만들면 운영 기록을 검토하듯 확인하세요. 결정을 한 문장으로 좁히고, 이름이나 역할을 단일 owner로 정리하며, 상대 날짜를 YYYY-MM-DD로 바꾸고, action item이 확인 가능한 형태인지 점검합니다. 그런 다음 --summary, --overdue, --conflicts를 실행해 해당 entry가 tracker에서 잘 작동하는지 확인하세요.
팀 운영 모델에 맞게 skill 확장하기
팀은 일관된 agenda tag, board committee label, risk level, decision type, project ticket link를 추가해 decision-logger를 개선할 수 있습니다. 다만 확장은 markdown index와 호환되게 유지하고, 아무도 관리하지 않을 field는 추가하지 마세요. 목표는 문서를 더 풍성하게 만드는 것 자체가 아니라, 다음 회의를 위한 더 깨끗한 Decision Support를 만드는 것입니다.