tunaFlow

tunaFlow Architect가 Developer subagent 또는 다른 Claude 세션에 일감을 넘길 때 쓰는 핸드오프 문서를 작성한다. 한 plan을 1~3개의 정확한 PR로 쪼개고, DO/DO NOT/Verification/CI 정책/보고 포맷을 명시해 다른 세션이 가정 없이 그대로 따라갈 수 있게 만든다. tunaFlow에서 일하면서 "developer 핸드오프", "Plan 의 Task 를 누군가에게 넘기자", "Developer subagent 에게 dispatch 할 프롬프트", "이 작업을 다른 세션에서 진행할 수 있게 정리", "PR 분리 전략 + 회귀 가드 명시" 같은 의도가 보이면 반드시 이 스킬을 사용한다. 외부 사용자 issue 대응 시에도 plan 작성 후 곧바로 핸드오프로 이어지므로 함께 트리거한다.

tunaFlow Architect가 작업 영역을 plan 문서로 형식화한다. 외부 사용자 issue 분석, 회귀 진단, 새 feature 설계, 리팩토링 묶음 — 모두 docs/plans/<slug>Plan_YYYY-MM-DD.md로 떨어진다. tunaFlow 작업 중 "plan 작성하자", "이슈 분석해서 plan으로 정리", "회귀 root cause 분해해서 task로 쪼개자", "구현 전 invariant + non-goals 명시", "이 작업을 어떻게 진행할지 문서화", "여러 PR로 분리될 작업의 그림 그리기" 같은 의도가 보이면 반드시 이 스킬을 사용한다. Plan 이 있어야 그 다음 단계인 developer 핸드오프로 이어지므로, plan 미존재 상태에서 갑자기 코드 수정으로 가지 말고 먼저 이 스킬을 거친다.

tunaFlow의 새 버전을 publish하는 11단계 사이클을 실행한다. CHANGELOG 갱신 → 3곳 version bump → tag → build watch → release notes → publish → external issue 회복 안내 댓글 → issue close 까지 한 흐름. tunaFlow 작업 중 "릴리즈 하자", "v0.X.Y-beta 발행", "다음 patch release", "이번 fix들 묶어서 publish", "issue 회복 안내", "release tag 만들기" 같은 의도가 보이면 반드시 이 스킬을 사용한다. 단계 순서가 어긋나거나 누락되면 자산이 stale 한 release 가 되거나 사용자가 fix 적용 사실을 모르므로 정확히 따른다.