execute
작성자 alirezarezvaniexecute는 승인된 의사결정 기록을 주간 milestones, 지정된 DRIs, success metrics, definitions of done, check-in 주기를 포함한 90일 운영 계획으로 전환합니다. /cs:decide 이후 책임 있는 실행이 필요한 Project Management 및 리더십 워크플로에 적합합니다.
이 skill은 74/100점으로, 몇 가지 도입 시 유의점은 있지만 디렉터리 등록 대상으로는 무난합니다. 디렉터리 사용자는 승인된 의사결정 기록을 90일 실행 계획으로 바꾸는 명확하고 호출 가능한 워크플로를 얻을 수 있습니다. 다만 scripts, examples, 설치 안내까지 갖춘 깊이 있는 구현이라기보다는 가벼운 markdown 전용 skill에 가깝다는 점을 예상해야 합니다.
- 명확한 트리거와 사용 사례가 있습니다. `/cs:execute <decision-path>`는 승인된 `/cs:decide` 기록을 운영 계획으로 전환하는 용도로 구체적으로 설계되어 있습니다.
- 저장되는 execution-plan 경로, owner, checkpoint, workstreams, 주간 milestones, DRIs, success metrics, definitions of done 등 실행 산출물이 구체적입니다.
- office hours부터 post-mortem까지 이어지는 더 넓은 C-level advisor 흐름 안에서 언제 사용해야 하는지 에이전트가 이해하기 쉽습니다.
- 지원 파일, scripts, references, README, 설치 명령이 제공되지 않아 도입은 전적으로 SKILL.md 지침에 의존합니다.
- 이 skill은 repository의 더 넓은 `/cs:` 의사결정 워크플로에 묶여 있는 것으로 보이므로, 기존 `/cs:decide` 결과물이 없다면 독립적인 계획 수립 skill로서의 활용도는 낮을 수 있습니다.
execute skill 개요
execute가 하는 일
execute는 승인된 의사결정을 90일 실행 계획으로 바꿔 주는 C-level advisor skill입니다. 전략적 결정을 정적인 메모로 남겨 두는 대신, execute skill은 주간 마일스톤, 워크스트림, 지정된 DRI, 성공 지표, 완료 기준, 체크인 주기를 만들어 줍니다. 핵심 역할은 “결정했다”와 “다음 주 월요일에 무엇을 할 것인가?” 사이의 간극을 메우는 것입니다.
프로젝트 관리와 리더십 팀에 가장 잘 맞는 경우
Project Management에서 execute가 가장 잘 맞는 시점은 창업자, 경영진, 제품 리드, 운영팀이 이미 명확한 결정을 내렸고, 이제 책임 있는 롤아웃 계획이 필요한 때입니다. 대표적인 사용 사례로는 시장 진입, 가격 정책 변경, 채용 계획, 제품 출시, 영업 프로세스 변경, 내부 운영 모델 전환 등이 있습니다. 특히 아이디어가 부족해서가 아니라 소유권이 모호해서 실패할 가능성이 큰, 여러 기능 조직이 얽힌 워크스트림에 유용합니다.
execute skill이 다른 점
일반적인 “프로젝트 계획을 만들어 달라”는 프롬프트와 달리, execute는 의사결정 기록을 입력으로 전제하며 그 결정에서 확정된 결과를 그대로 유지합니다. 이 skill의 출력 형식은 꽤 명확합니다. 90일 범위, 주간 마일스톤, DRI 소유권, 성공 기준과 중단 기준, 워크스트림, 체크인까지 포함합니다. 이 구조 덕분에 execute는 브레인스토밍이나 초기 전략 탐색보다는 실행 규율을 세우는 데 더 적합합니다.
도입 전에 알아둘 점
저장소 경로는 c-level-advisor/c-level-agents/skills/execute이고, 핵심 파일은 SKILL.md입니다. 이 skill 디렉터리에는 추가 스크립트, 규칙, 리소스, README 파일이 없으므로 가치는 프롬프트 구조 자체에 집중되어 있습니다. Claude skills 워크플로 안에서 가벼운 실행 계획 수립 명령이 필요하다면 execute를 설치하세요. 다만 완전한 프로젝트 관리 연동이나 자동 태스크 동기화를 기대해서는 안 됩니다.
execute skill 사용 방법
execute 설치 맥락
다음 명령으로 저장소에서 skill을 설치합니다.
npx skills add alirezarezvani/claude-skills --skill execute
설치 후에는 먼저 SKILL.md를 확인하세요. 이 파일에는 명령, 예상 입력, 파이프라인 내 위치, 출력 형식이 들어 있습니다. upstream skill은 다음 명령을 중심으로 설계되어 있습니다.
/cs:execute <decision-path>
<decision-path>는 승인된 의사결정 기록을 가리켜야 하며, 같은 C-level advisor 워크플로에서 /cs:decide로 생성된 기록이면 가장 이상적입니다.
execute skill에 필요한 입력
execute를 제대로 사용하려면 제목만 제공해서는 부족합니다. 책임 있는 마일스톤을 만들 수 있도록 충분한 의사결정 맥락이 필요합니다.
- 승인된 결정과 그 근거
- 확정된 결과, 성공 기준, 중단 기준
- 스폰서 또는 임원 오너
- 관련 팀과 예상 DRI
- 마감일, 출시 기간, 또는 90일 체크포인트
- 예산, 채용, 엔지니어링 역량, 컴플라이언스, 의존성 같은 알려진 제약
- 주간 임원 리뷰나 스프린트 계획처럼 이미 운영 중인 도구 또는 운영 리듬
약한 입력: “Create an execution plan for entering Germany.”
더 나은 입력: “Use /cs:execute decisions/2026-02-03-germany-entry.md. Preserve the approved success criteria: €250k qualified pipeline by day 90 and kill criteria: CAC payback above 18 months after pilot. Assume Sales, Marketing, Legal, and Product workstreams. Weekly exec check-in is Mondays. Name placeholder DRIs where people are not assigned.”
권장 워크플로
execute는 팀이 아직 선택지를 논의하는 중이 아니라, 의사결정이 승인된 뒤에 사용하세요. 실무적으로는 다음 흐름이 좋습니다.
- 의사결정 기록을 실행하거나 수집합니다.
- 결과와 중단 기준이 명확히 적혀 있는지 확인합니다.
/cs:execute <decision-path>를 호출합니다.- 생성된 워크스트림과 주간 마일스톤을 검토합니다.
- placeholder DRI를 실제 이름으로 바꿉니다.
- 필요하면 마일스톤을 프로젝트 시스템으로 옮깁니다.
- 체크인 주기를 활용해 리스크와 완료 기준 미달 항목을 추적합니다.
이 skill의 기본 출력은 markdown 실행 계획으로 저장되며, 로컬 Claude skill 설정에 따라 보통 ~/.claude/execution/YYYY-MM-DD-<slug>.md 같은 경로 아래에 저장됩니다.
출력 품질을 높이는 프롬프트 팁
운영 환경을 구체적으로 적으세요. 팀의 회의 주기, 수용 가능 업무량, 의존성을 이미 알고 있다면 포함하는 것이 좋습니다. 마일스톤이 관찰 가능해야 한다면 그렇게 명시하세요. 리더십이 특정 지표를 중요하게 본다면, 해당 지표가 관련 워크스트림마다 보이도록 요청하세요.
유용한 프롬프트 패턴은 다음과 같습니다.
/cs:execute <decision-path>. Build a 90-day plan with weekly milestones, named DRIs where known, placeholder DRIs where unknown, definitions of done, dependency risks, and a Monday check-in cadence. Keep the binding outcome and kill criteria unchanged from the decision record.
이렇게 하면 계획이 원래 의사결정에서 벗어나는 것을 막을 수 있습니다.
execute skill FAQ
execute는 임원만을 위한 것인가요?
아닙니다. 언어와 파이프라인은 임원 중심으로 설계되어 있지만, execute skill은 승인된 결정을 책임 있는 계획으로 바꿔야 하는 제품 관리자, 운영 담당자, 창업자, chief of staff, 프로젝트 리드에게도 유용합니다. 핵심 조건은 결정이 이미 내려져 있어야 한다는 점입니다.
execute를 쓰지 말아야 할 때는 언제인가요?
개방형 아이데이션, 선택지 비교, 시장 조사, 경쟁 전략 사이의 의사결정에는 execute를 쓰지 마세요. 명확한 오너가 없거나, 성공 지표가 없거나, DRI를 지정할 의지가 없는 경우에도 잘 맞지 않습니다. 이런 경우에는 먼저 브리핑, 의사결정, 또는 계획 수립 프로세스를 거치는 편이 좋습니다.
execute는 일반 프롬프트와 어떻게 다른가요?
일반 프롬프트도 그럴듯한 작업 목록을 만들 수는 있습니다. 하지만 execute는 의사결정에서 실행 계획으로 이어지는 형식을 강제합니다. 90일, 워크스트림, DRI, 주간 마일스톤, 완료 기준, 체크인 리듬이 포함됩니다. 이 제약 자체가 핵심입니다. 모호함을 줄이고 리더십 팀과 함께 검토하기 쉬운 결과물을 만듭니다.
execute는 Jira, Asana, Linear와 연동되나요?
execute에 대한 저장소 근거를 보면 SKILL.md만 있으며, 보조 스크립트나 도구 연동은 없습니다. 출력은 Jira, Asana, Linear, Notion, 스프레드시트로 복사할 수 있는 구조화된 markdown 계획으로 보면 됩니다. 도구 동기화가 중요하다면 해당 워크플로는 직접 추가할 계획을 세워야 합니다.
execute skill 개선 방법
실행 전에 execute 입력을 개선하기
execute 결과를 가장 빠르게 개선하는 방법은 의사결정 기록을 더 탄탄하게 만드는 것입니다. 실제 결정, 그 결정을 선택한 이유, 성공의 모습, 결정을 되돌려야 하는 조건, 업무 스폰서가 누구인지가 포함되어 있는지 확인하세요. 모호한 결정은 모호한 실행 계획을 만들고, 측정 가능한 결정은 유용한 주간 마일스톤을 만듭니다.
흔한 실패 패턴 점검하기
첫 출력 이후에는 다음 문제를 확인하세요.
- 마일스톤이 결과가 아니라 활동으로 되어 있음
- DRI가 개인이 아니라 팀으로 지정되어 있음
- 의존성 오너가 빠져 있음
- 성공 지표가 원래 의사결정과 맞지 않음
- 1주 차 업무가 너무 크거나 불명확함
- 명시적인 리뷰 주기나 에스컬레이션 경로가 없음
전체를 다시 생성하게 하기보다는 약한 부분만 수정해 달라고 execute에 요청하세요.
실제 운영에 맞게 반복 개선하기
좋은 두 번째 프롬프트는 보기 좋게 꾸미는 요청이 아니라 실무적인 요청입니다.
“Revise the plan so each weekly milestone has an observable definition of done, no DRI is a department, Legal dependencies are visible by week, and the week 4 checkpoint can determine whether we continue, adjust, or stop.”
이런 식의 반복 개선은 더 긴 계획을 요청하는 것보다 관리 관점의 유용성을 훨씬 높입니다.
조직에 맞게 execute 조정하기
execute를 자주 사용한다면 팀이 중요하게 보는 필드를 표준화하세요. 예산 오너, 리스크 수준, 고객 영향, 보고 포럼, 출시 체크리스트, 에스컬레이션 트리거 등이 될 수 있습니다. 90일 구조는 유지하되, 워크스트림과 체크인 주기는 조직의 운영 모델에 맞게 조정하세요. 이렇게 하면 execute가 일반적인 프로젝트 템플릿으로 흐르지 않으면서도 더 반복 가능해집니다.