work-pilot — 제안을 “실제로 돌아가는 것”으로

제안서는 약속이고, 심사와 실무를 설득하는 건 한 번이라도 실제로 돌아간 결과다. 이 스킬은 Cowork 가 할 수 있는 것과 없는 것을 정직하게 가른 뒤, 없는 데이터는 모의로 만들어서라도 전 과정을 1회전시키고, 그 검증된 절차를 팀 스킬로 남긴다.

Claude 오케스트레이션 지시서#

[HARD] 경계 정직성. Cowork 가 할 수 없는 것(사내 시스템 자동 접속·정기 자동 실행·자동 발송 등)을 되는 것처럼 기획하지 않는다. 자동화 불가 단계는 반드시 “수동 브릿지” 또는 “시스템 연동(IT 과제)”으로 명시한다. 경계 판별은 references/cowork-boundary.md 기준. [HARD] 모의 데이터에 실존 고객·실명·실연락처·실제 식별번호 금지. 전부 가상으로 만든다. 실데이터를 쓸 때는 개인정보(이름·연락처·주소·식별번호) 마스킹을 먼저 안내하고 확인받는다. [HARD] 결과 과장 금지. 파일럿 일치율·소요 시간은 실측값만 쓴다. 측정 전에 “성공”을 선언하지 않는다. 표본 10건 미만의 일치율은 “참고치(재측정 필요)”로만 표기하고, 기준 보완 후의 재정렬은 “정답률 상승”이 아니라 “판정 기준 합의”로 서술한다.

관문1 — 실현 기획 (경계 판별)#

1. 제안서(work-proposal 산출) 또는 아이디어를 받는다. 제안서가 없으면 핵심만 3문으로 수집: 무엇을 자동화하나 / 입력 데이터는 무엇이고 어디에 있나 / 산출은 누구에게 어떤 형태로 가나.

2. 프로세스 각 단계를 3분류 표로 판별한다 (references/cowork-boundary.md 대조):

   단계	분류	파일럿에서의 처리
   예: VOC 접수(웹 시스템)	수동 브릿지	담당자가 엑셀 내보내기 → Cowork 업로드
   예: 분석·분류·근거	Cowork 안	AI 가 직접 수행
   예: 메일 발송	수동 브릿지	AI 는 초안까지, 발송은 담당자
   예: 시스템 자동 수집	시스템 연동	파일럿 제외 — IT 과제로 §6 향후 계획에 기록

3. 파일럿 범위 확정 — “Cowork 안 + 수동 브릿지”만으로 시작→끝이 이어지는 최소 흐름을 제시하고 사용자 컨펌을 받는다. 시스템 연동 항목은 버리지 말고 “확장 로드맵”으로 분리 기록.

관문2 — 데이터 준비#

• 실데이터가 있으면: 마스킹 안내([HARD]) 후 업로드 받는다. 10~50건이면 충분하다.
• 없으면 모의 데이터 생성: 과제 도메인에 맞는 현실적 데이터셋을 만든다.
  • 규모 20~40건. 현실적 분포(채널·유형·길이 편차) + 일부러 어려운 케이스 포함 — 분류가 애매한 건 2~3건, 서로 유사한 중복 건 2~3건, 정보 부족 건 1~2건.
  • 부속 자료도 함께: 표준 기준 초안(예: VOC 분류 유형 5~8개 + 판단 기준 1줄씩), 과거 이력 5~10건(유사 건 연결 시험용).
  • 생성 후 자체 점검 — 4항목 고정 체크리스트(각 1줄 보고): ① 유형 분포 쏠림 없음(전 유형 최소 2건) ② 기준으로 전건 분류 시도 가능(애매 건은 의도적임을 표시) ③ 실존 고객·실명·실연락처 0 ④ 채널·길이 분포가 현실적.
  • 산출: CSV 또는 엑셀 파일(팀이 재사용할 수 있게).

관문3 — 파일럿 1회전 + 일치율 실측#

1. 관문1 의 최소 흐름대로 전건 처리한다. 예(VOC): 건별 분류 + 판단 근거 1줄 + 유사 이력 연결 + 부서 추천 → 결과표(표 형식) + 전달 메일 초안 2~3건 샘플. 애매하거나 정보가 부족한 건은 임의 분류하지 않고 “판단보류(추가확인)” 큐로 분리하고, 두 부서에 걸치는 건은 주관/협조 이원 표기를 허용한다 — 애매 건 처리야말로 파일럿이 검증해야 할 핵심이다.
2. 일치율 실측 — 사용자에게 무작위 5~10건을 골라 “당신이라면 어떻게 분류했겠나”를 묻고, AI 판정과 대조해 일치율을 계산한다(제안서 §6 측정 지표의 리허설). 불일치 건은 왜 갈렸는지 확인해 기준을 보완하고, 해당 건만 재분류해 개선을 보여준다(보완 루프 1회).
3. 산출 정리: 결과표 파일 + 일치율(실측) + 기준 보완 전/후 비교 + 남은 한계 목록. 이것이 본선·실무 설득의 데모 자산이다.

관문4 — 스킬화 (팀 자산으로 굳히기)#

파일럿으로 검증된 것만 스킬로 만든다 — 검증 안 된 기능을 스킬에 넣지 않는다.

1. SKILL.md 초안 작성: name(영문 kebab-case)·description(팀 동료가 쓸 한국어 트리거 포함)· 지시서(파일럿에서 확정한 절차 그대로: 입력 계약 → 처리 규칙 → 출력 형식) + [HARD] 규칙 (근거 없는 분류 금지 · 개인정보 마스킹 · 확신 없으면 “판단 보류”로 사람에게).
2. 기준은 참조 파일로: 표준 분류 기준·템플릿은 references/ 로 분리해 기준이 바뀌어도 지시서를 안 고치게 한다.
3. 배포 안내: ① 간단 공유 = 스킬 내용을 카드(프롬프트 문서)로 팀에 배포 ② 정식 = 플러그인 zip 패키징 — 경로는 전부 ASCII(한글 파일명 금지), zip 루트에 플러그인 폴더(zip -r x.zip <플러그인폴더>) 구조로 만들어야 Cowork 설치가 된다.
4. 운영 루틴 제안: 누가·언제(예: 매일 오전 접수분)·무엇을 올려 실행하고, 월 단위로 §6 지표(처리 시간·일치율·오전달)를 집계하는 한 장 루틴을 함께 준다.

완료 보고#

파일럿 범위 표(3분류) · 데이터셋 파일 · 결과표 + 일치율(실측) · 스킬 초안 · 운영 루틴 · 확장 로드맵(시스템 연동 항목)을 정리해 제시한다.

파이프라인 (itda-work 업무 스킬 패밀리)#

work-find(무엇을 풀지 발굴) → work-proposal(제안서로 구조화) → work-pilot(파일럿 실증·스킬화). 계획·실행 관리로 가려면 work-plan(itda-work 팩). 앞 단계 산출 텍스트를 첨부하면 이어서 진행한다.

원칙#

• 정직한 경계 — “Cowork 로 다 됩니다”가 아니라 “여기까지 되고, 여기는 사람, 여기는 IT 과제” 가 신뢰를 만든다.
• 모의라도 끝까지 — 가상 데이터로라도 전 과정이 한 번 돌아야 진짜 문제(기준 모호·예외)가 드러난다.
• 검증된 것만 스킬로 — 파일럿에서 확인 안 된 기능은 스킬에 넣지 않는다.