decide
작성자 alirezarezvanidecide는 decision-logger를 통해 founder가 승인한 board memo를 오래 유지되는 회사 memory로 기록하며, Knowledge Capture 워크플로에서 승인된 decision과 raw transcript를 분리합니다.
점수: 68/100. 명확한 트리거가 있고, 더 큰 C-level advisor 워크플로 안에서 맡는 역할이 구체적이며, agent가 일반적인 프롬프트보다 덜 추측하면서 승인된 decision을 기록할 수 있을 만큼의 절차 설명이 있어 목록에 올리기에는 적합합니다. 다만 디렉터리 이용자는 이 skill이 더 넓은 생태계를 감싸는 얇은 래퍼에 가깝고, 여기에서 충분히 문서화되지 않은 외부 `decision-logger` skill과 예상 memo 규칙에 의존한다는 점을 이해해야 합니다.
- 트리거가 명확합니다. frontmatter와 본문에서 founder가 승인한 board memo를 영속적인 memory로 남겨야 할 때 `/cs:boardroom` 이후 실행할 명령이 `/cs:decide <memo-path>`임을 분명히 제시합니다.
- 워크플로 목적이 선명합니다. 논의 단계와 영속적인 회사 memory 사이의 게이트를 정의하며, 승인 확인과 title, date, option chosen, criteria, dissent, review checkpoint 추출을 포함합니다.
- memory 모델이 유용합니다. raw 기록과 승인된 decision 저장소를 나누는 2계층 모델 덕분에 agent가 아직 결론 나지 않은 논의를 최종 decision처럼 다루는 일을 줄일 수 있습니다.
- 이 skill은 별도의 `decision-logger` skill과 더 넓은 `/cs:*` 워크플로에 의존하지만, 이 repository path에는 해당 의존성에 대한 지원 파일, 설치 명령, 연결된 참고 자료가 없습니다.
- 운영 세부사항은 대체로 개념 설명에 머뭅니다. 승인된 메모 입력 예시나 스크립트, 설명된 기록 필드 외의 구체적인 출력 예시는 제공되지 않습니다.
decide skill 개요
decide가 하는 일
decide는 승인된 전략 메모를 오래 남는 회사 기억으로 전환하기 위한 C-level advisor skill입니다. 실제 워크플로에서는 /cs:decide <memo-path>가 이사회식 숙의가 끝난 뒤, 실행에 들어가기 전에 위치합니다. 창업자가 승인한 메모가 실제로 승인 상태인지 확인하고, 의사결정 기록을 추출한 다음 관련 decision-logger 워크플로로 전달합니다.
핵심 역할은 “무엇을 선택할지 도와줘”가 아닙니다. “이미 승인한 선택을 기록해서, 이후 AI 세션이 이를 회사 맥락으로 다룰 수 있게 해줘”에 가깝습니다.
Knowledge Capture 워크플로에 가장 잘 맞는 경우
decide skill은 Claude나 agent workflow로 정기적인 경영진 논의, 전략 리뷰, 창업자 의사결정 세션을 운영하는 팀의 Knowledge Capture에 가장 잘 맞습니다. 특히 다음 두 가지를 명확히 분리하고 싶을 때 유용합니다.
- 원자료에 가까운 토론, 반대 의견, 회의 기록
- 향후 계획에 영향을 줘야 하는 승인된 의사결정
이 분리가 중요한 이유는, 아직 결론이 나지 않은 논의가 실수로 회사 기억이 되어서는 안 되기 때문입니다.
핵심 차별점: 2계층 메모리
업스트림 skill은 decision-logger가 관리하는 2계층 모델을 설명합니다.
~/.claude/decisions/raw/아래의 원본 transcript~/.claude/decisions/approved/아래의 승인된 decision
향후 /cs:office-hours와 /cs:founder-mode 호출에 반영되는 것은 승인된 decision만을 의도합니다. 그래서 decide는 일반적인 “이 회의 요약해줘” 프롬프트보다 더 보수적입니다. 숙의와 조직 기억 사이에 게이트를 세우는 방식입니다.
decide가 적합하지 않은 경우
decide를 폭넓은 의사결정 도우미, 브레인스토밍 도구, 프로젝트 관리 시스템으로 기대하고 설치해서는 안 됩니다. 이 skill은 이미 board memo, approval status, 그리고 주변 C-level advisor pipeline이 있다고 전제합니다. 현재 워크플로가 임시 메모 수준이라면, 안정적인 승인 절차가 생기기 전까지는 더 가벼운 노트 작성 또는 요약 프롬프트를 쓰는 편이 낫습니다.
decide skill 사용 방법
decide 설치 맥락
GitHub skill repository에서 다음 명령으로 설치합니다.
npx skills add alirezarezvani/claude-skills --skill decide
그다음 소스를 확인합니다.
c-level-advisor/c-level-agents/skills/decide/SKILL.md
이 skill의 파일 구성은 매우 좁습니다. 핵심 근거는 SKILL.md입니다. 제공된 트리에는 별도의 helper script, reference, README 파일, resource folder가 보이지 않습니다. 따라서 도입 가능성은 해당 환경이 주변 C-level command와 decision-logger skill을 이미 지원하는지에 달려 있습니다.
decide 사용에 필요한 입력
명령 형식은 다음과 같습니다.
/cs:decide <memo-path>
입력은 board memo 파일이어야 하며, 보통 /cs:boardroom에서 생성됩니다. 좋은 입력에는 다음 항목이 포함되어야 합니다.
- decision title
- date decided
- option chosen
status: APPROVED또는 이에 준하는 founder approval marker- success criteria
- kill criteria
- preserved dissent
- review checkpoint date
“영업을 확장하기로 했다” 같은 약한 입력만으로는 부족합니다. 더 나은 프롬프트는 다음과 같습니다. “Use /cs:decide ./memos/2026-02-enterprise-sales.md. Confirm founder approval, extract the chosen option, preserve dissent, and log success criteria, kill criteria, and the Q2 review checkpoint.”
실무형 decide 가이드 워크플로
신뢰할 수 있는 decide 워크플로는 다음 순서에 가깝습니다.
/cs:boardroom에서 숙의를 마무리합니다.- 승인된 memo를 안정적인 path에 저장합니다.
- memo에 founder가 승인했다는 사실이 명시되어 있는지 확인합니다.
/cs:decide <memo-path>를 실행합니다.- 승인된 memory가 raw transcript 자료와 별도로 기록되었는지 확인합니다.
- 기록된 decision을
/cs:execute또는 향후 planning session의 context로 사용합니다.
이 순서는 우발적인 memory 오염을 줄여 줍니다. 이 skill은 의사결정 파이프라인의 같은 지점에서 일관되게 사용할 때 가장 가치가 큽니다.
도입 전에 읽어야 할 파일
먼저 SKILL.md를 읽고, 특히 다음 섹션에 집중하세요.
Pipeline PositionTwo-Layer Memory ModelInputWorkflow
미리보기에는 추가 지원 파일이 없기 때문에, 주요 도입 판단 기준은 repository 복잡도가 아닙니다. 핵심은 적합성입니다. 승인된 memo가 있고, skill이 설명하는 path와 기대 사항에 맞는 durable memory 관례를 갖추고 있는지가 중요합니다.
decide skill FAQ
decide는 의사결정 skill인가요?
아닙니다. decide는 승인된 decision을 기록합니다. 토론 자체를 진행하지 않습니다. 일반적으로 /cs:boardroom 이후, 의사결정이 이미 내려진 뒤에 놓이는 단계입니다. option generation, risk analysis, advisor debate가 필요하다면 먼저 앞단 워크플로 단계를 사용해야 합니다.
일반 프롬프트보다 decide가 나은 점은 무엇인가요?
일반 프롬프트도 memo를 요약할 수는 있습니다. 하지만 decide는 거버넌스 경계를 코드화합니다. raw transcript는 참고 자료이고, 승인된 decision만 durable memory가 됩니다. 이 구분이 Claude에게 “remember this”라고 요청하는 대신 decide skill을 사용할 주된 이유입니다.
초보자도 decide를 사용할 수 있나요?
가능합니다. 다만 file-based prompt를 이해하고, 사용할 memo가 이미 준비되어 있어야 합니다. 더 넓은 c-level-advisor command 구조를 쓰지 않는 초보자라면 어려움을 느낄 수 있습니다. decide는 pipeline을 전제로 하고 decision-logger를 참조하기 때문입니다. 운영 기억으로 의존하기 전에, 승인된 memo 하나로 먼저 테스트해 보세요.
decide 설치와 사용을 막는 요인은 무엇인가요?
가장 큰 장애물은 주변 skill 누락, 불명확한 approval status, 구조화되지 않은 memo입니다. 환경에서 /cs:decide를 호출할 수 없거나, memo path에 접근할 수 없거나, 호환되는 decision-logger 설정이 없다면, 이 skill이 의도한 memory write를 완료하지 못할 수 있습니다.
decide skill 개선 방법
실행 전에 decide 입력부터 개선하기
decide output을 개선하는 가장 빠른 방법은 memo를 명확하게 작성하는 것입니다. skill을 호출하기 전에 짧은 decision header를 추가하세요.
Status: APPROVEDDecision: Choose Option BOwner: Founder / CEOSuccess criteria: ...Kill criteria: ...Review checkpoint: ...Dissent to preserve: ...
이렇게 하면 agent가 approval을 추론하거나 빠진 구조를 임의로 만들어낼 여지가 줄어듭니다.
피해야 할 흔한 실패 유형
가장 흔한 실패는 논의를 decision으로 기록하는 것입니다. memo가 어떤 option이 선택되었는지 분명히 말하지 않는 한, transcript, 미해결 note, 경쟁 option을 그대로 보내지 마세요. 또 다른 실패는 kill criteria를 빠뜨리는 것입니다. 이것이 없으면 향후 review에서 “계속한다”와 “중단한다”를 구분하기 어렵습니다.
또한 decide를 모든 memory를 넣는 포괄적 명령처럼 사용하지 마세요. decide의 가치는 선별적으로 쓰는 데서 나옵니다.
첫 output 이후 반복 개선하기
첫 실행 후에는 기록된 decision이 간결하고, 감사 가능하며, 미래에 활용 가능한지 확인하세요. record가 모호하다면 memo를 수정하고 더 명확한 field로 다시 실행하세요. 좋은 durable memory는 미래의 agent가 다음 질문에 답할 수 있게 해야 합니다. 무엇을 결정했는가, 왜 그것을 선택했는가, 무엇이 그 결정이 틀렸음을 보여줄 수 있는가, 언제 다시 검토해야 하는가?
운영 방식에 맞게 decide 확장하기
팀은 memo template을 표준화하고, 필수 approval language를 추가하며, memory path를 내부 관례와 맞추는 방식으로 decide skill을 개선할 수 있습니다. repository를 유지관리한다면 README, 승인된 memo 예시, validation checklist, decision-logger에 대한 더 명확한 dependency note를 추가하는 것이 유용합니다. 이런 보강은 decide 설치 결정을 더 쉽게 만들고 설정상의 모호함을 줄여 줍니다.