kickoff

kickoff 스킬 개요

kickoff가 하는 일

kickoff 스킬은 막연한 아이디어나 받은편지함 메모를 Project Management용 구조화된 Project Note로 바꿔줍니다. 한 번에 긴 답변으로 모두 작성하는 대신, kickoff는 2단계 흐름으로 작동합니다. 먼저 계획 수립 단계가 있고, 검토 후에 실행 단계가 이어집니다. 그래서 단순한 “이 프로젝트를 계획해줘” 프롬프트보다 인수인계가 깔끔해야 하거나 문맥이 흐트러지는 일을 줄이고 싶을 때 더 유용합니다.

kickoff가 가장 잘 맞는 사용자

이 kickoff 스킬은 이미 아이디어 메모를 관리하고 있고, 특히 00_Inbox/ 같은 inbox 스타일 폴더를 쓰면서 그 메모를 실행 가능한 프로젝트 문서로 일관되게 승격시키고 싶은 사용자에게 잘 맞습니다. 무거운 PM 도구를 따로 구축하지 않고도 가볍게 프로젝트 시작 루틴을 만들고 싶은 운영 담당자, 창업자, 빌더에게 특히 유용합니다.

사용자가 kickoff를 선택하는 이유

kickoff의 핵심 차별점은 오케스트레이션에 있습니다. 단순히 메모 초안을 한 번 생성하는 것이 아니라, 계획 수립과 실행을 명확히 분리하고 그 사이에 확인 단계를 둡니다. 최종 Project Note를 만들기 전에 범위, 네이밍, 구조, 언어를 점검하고 싶다면 이 검토 게이트가 큰 가치가 있습니다.

kickoff 설치 전에 알아둘 점

이 저장소 근거를 보면 SKILL.md 단일 파일만 있고, helper script, rule pack, resource file은 없습니다. 덕분에 kickoff는 구조를 확인하기 쉽지만, 반대로 결과물 품질은 입력의 질과 현재 환경이 스킬에서 설명하는 multi-agent 흐름을 실제로 지원하는지에 크게 좌우됩니다. 검토 없이 한 번에 끝나는 생성기를 원한다면 kickoff는 필요 이상으로 절차적이라고 느껴질 수 있습니다.

kickoff 스킬 사용 방법

설치 맥락과 가장 먼저 읽어야 할 파일

kickoff 설치 시에는 저장소에서 스킬을 추가한 뒤 EN/.agents/skills/kickoff/SKILL.md를 가장 먼저 읽는 것이 좋습니다. 전체 워크플로우, 역할 정의, 언어 규칙이 모두 그 파일에 들어 있기 때문입니다. 이 스킬 경로에는 README.md, metadata.json, helper 폴더 같은 보조 자료가 없어서, 사실상 거의 모든 동작이 이 한 파일에 정의되어 있습니다. 실제로 의존하기 전에, 현재 에이전트 환경이 task 스타일 도구를 통해 subagent를 호출할 수 있는지 먼저 확인하세요.

kickoff에 필요한 입력

kickoff 사용은 세 가지 시작점을 지원합니다:

• 00_Inbox/MyIdea.md 같은 파일 경로
• “Build a habit tracker app” 같은 인라인 텍스트
• 아무 입력도 없는 경우 — 이때는 00_Inbox/를 나열하고 선택을 요청하도록 설계됨

가장 좋은 입력에는 문제 정의, 대상 사용자, 원하는 결과, 제약 조건, 마감일이나 산출물 형식이 포함됩니다.
약한 입력: “make this into a project.”
더 강한 입력: “/kickoff Build a habit tracker app for iOS freelancers; MVP in 3 weeks; needs reminders, streaks, and CSV export; keep scope solo-developer friendly.”

실무적으로 쓰기 좋은 kickoff 워크플로우

안정적으로 쓸 수 있는 kickoff 가이드는 다음과 같습니다:

1. 메모 경로나 간결한 브리프와 함께 /kickoff를 호출합니다.
2. planning agent가 plan file을 생성하도록 둡니다.
3. 승인 전에 plan을 검토합니다.
4. 범위, 이름, 가정, 누락된 제약을 수정한 뒤에만 확인합니다.
5. execution agent가 plan file만을 바탕으로 최종 Project Note를 만들게 합니다.

이 “plan file only” 인수인계가 핵심 설계 포인트입니다. 원래의 긴 대화에서 불필요한 맥락이 딸려 들어가는 일을 줄여주지만, 동시에 plan에서 빠진 내용은 최종 출력에서도 빠지게 됩니다. 그래서 검토가 중요합니다.

출력 품질을 높이는 kickoff 프롬프트 패턴

Project Management용 kickoff를 쓸 때는 단순한 아이디어 브레인스토밍이 아니라, 실제 프로젝트 노트의 형태를 잡아줄 수 있을 정도로 구체적으로 프롬프트를 작성하는 편이 좋습니다. 좋은 패턴은 다음과 같습니다:

• source: 아이디어가 나온 출처
• objective: 성공의 기준
• scope: 지금 꼭 필요한 것과 나중으로 미룰 것
• constraints: 시간, 도구, 예산, 팀 규모
• deliverable: 기대하는 문서나 프로젝트 산출물

예시:
/kickoff 00_Inbox/ClientPortal.md

그다음 검토 단계에서는 아래처럼 수정사항을 추가할 수 있습니다:

• “Use English for the project note.”
• “Scope MVP to authentication, dashboard, and billing history only.”
• “Target a 2-person team and a 6-week timeline.”

또 하나 기억할 점은 내장된 언어 규칙입니다. kickoff는 사용자 입력이나 inbox 파일 내용의 언어를 따라가야 합니다.

kickoff 스킬 FAQ

일반적인 planning prompt보다 kickoff가 더 나은가요?

대체로 그렇습니다. 특히 검토 가능한 단계형 워크플로우가 필요하다면 그렇습니다. 일반 프롬프트는 더 빨리 프로젝트 계획을 만들 수 있지만, kickoff는 계획 수립과 최종 노트 생성 사이에 의도적인 체크포인트를 둡니다. 범위나 구조 오류가 이후 단계에서 비용이 크게 되는 경우라면 이 점이 특히 유용합니다.

kickoff는 초보자도 쓰기 쉬운가요?

네, 적어도 자신의 아이디어를 설명할 수 있을 정도로 이해하고 있다면 어렵지 않습니다. 이 kickoff 스킬은 모든 내용이 하나의 SKILL.md에 들어 있어 구조를 파악하기 쉽습니다. 초보자에게 더 어려운 지점은 설치 자체가 아니라, planning agent가 탄탄한 plan file을 만들 수 있을 만큼 충분한 맥락을 제공하는 일입니다.

어떤 경우에는 kickoff가 잘 맞지 않나요?

깊은 수준의 task automation, integration, 혹은 script로 강제되는 엄격한 template가 필요하다면 kickoff는 건너뛰는 편이 낫습니다. 이 저장소에는 helper code, validation logic, external resource가 포함되어 있지 않습니다. 또 검토 단계를 원하지 않고 빠르게 한 번에 노트를 만들기만 하면 되는 경우에도 적합하지 않습니다.

kickoff는 OrbitOS 폴더 구조에 의존하나요?

부분적으로는 그렇습니다. 입력이 없을 때 00_Inbox/를 명시적으로 참조하므로, 비슷한 관례를 따르는 노트 시스템에서 가장 잘 맞습니다. 물론 인라인 텍스트나 직접 파일 경로를 지정해 kickoff를 사용할 수도 있지만, 기본 탐색 흐름은 해당 inbox 구조가 존재한다고 가정합니다.

kickoff 스킬을 더 잘 활용하는 방법

kickoff에 더 풍부한 프로젝트 입력을 주기

kickoff 결과를 가장 빨리 개선하는 방법은 의사결정 맥락을 앞단에 충분히 넣는 것입니다. 다음을 포함하세요:

• target user
• problem statement
• constraints
• timeline
• success criteria
• known dependencies

이렇게 해야 planning agent가 execution agent가 안정적으로 확장할 수 있는 plan file을 생성합니다. 첫 프롬프트에 이런 정보가 부족하면, 결과가 일반적인 Project Note에 머물 가능성이 큽니다.

plan을 인수인계 문서처럼 검토하기

plan 검토를 선택 사항으로 취급하지 마세요. execution agent는 plan file만 읽기 때문에, 빠진 가정, 모호한 마일스톤, 불명확한 범위 경계를 꼭 확인해야 합니다. 사람이 이 plan만 보고도 실행할 수 없다면, 두 번째 단계도 제대로 수행하지 못할 가능성이 큽니다.

kickoff에서 자주 생기는 실패 패턴 살피기

kickoff 사용에서 흔한 실패 사례는 대체로 예측 가능합니다:

• 아이디어가 너무 모호함
• inbox note가 너무 지저분하거나 구조가 없음
• 제약 조건이 빠져 있음
• 언어 기대치가 불명확함
• 사용자가 plan을 너무 빨리 승인함

실무적인 해결책은 kickoff 전에 지저분한 메모를 먼저 정리하는 것입니다. 제목, 한 문장짜리 목표, 대상 사용자, 짧은 “must include” 목록을 추가하세요.

첫 결과물 이후에도 kickoff를 반복 개선하기

최종 Project Note가 거의 맞지만 바로 쓰기 어려운 수준이라면, 최종 노트만 손보지 말고 plan을 수정하는 방식으로 kickoff를 개선하세요. 더 좁은 범위, 더 명확한 마일스톤, 혹은 다른 프로젝트 구조를 요청한 뒤 planning 단계부터 다시 실행하면 됩니다. 이 스킬에서는 긴 초기 프롬프트를 쓰는 것보다 중간 구조를 더 잘 만드는 편이 대체로 더 중요합니다.