retro
작성자 phurynretro는 팀 피드백을 주제, 실행 항목, 담당자, 마감일로 정리해 주는 구조화된 스프린트 회고를 돕습니다. Project Management, Agile 팀 리뷰, 스프린트 후 회고에서 일반적인 프롬프트보다 명확한 회고 가이드가 필요할 때 retro를 사용하세요.
이 스킬의 점수는 78/100으로, 구조화된 스프린트 회고 진행자가 필요한 사용자에게 적합한 디렉터리 항목입니다. 저장소에는 에이전트가 더 정확하게 트리거하고 일반 프롬프트보다 덜 추측하며 실행할 수 있을 만큼의 워크플로우 정보가 담겨 있습니다. 다만 보조 자료와 예외 상황 안내는 다소 부족한 편입니다.
- 전면 설명에 회고, 스프린트 리플렉션, 실행 항목 생성 등 명확한 트리거와 사용 사례가 담겨 있습니다.
- 운영 흐름이 분명합니다. 회고 형식을 고르고, 원시 피드백을 주제로 묶은 뒤, 담당자와 마감일이 포함된 우선순위 실행 항목을 만듭니다.
- 본문에는 Start/Stop/Continue, 4Ls, Sailboat 같은 구체적인 진행 형식이 포함되어 있어 에이전트가 재사용할 수 있는 구조를 제공합니다.
- 보조 파일, 참고 자료, 설치 명령이 없어 사용자는 SKILL.md 워크플로우 외의 근거를 얻기 어렵습니다.
- 저장소는 데이터 기반 회고 워크플로우보다 진행 가이드에 더 초점이 맞춰져 있어, 더 깊은 자동화나 도구 통합을 원하는 팀에는 활용 범위가 좁을 수 있습니다.
retro 개요
retro가 하는 일
retro skill은 팀 피드백을 명확한 실행 항목으로 바꾸는 구조화된 스프린트 회고를 진행하도록 돕습니다. 단순한 일반 프롬프트보다 더 많은 것이 필요할 때 유용합니다. retro skill은 대화의 흐름을 잡아주고, 흩어진 의견을 주제로 묶고, 결과가 담당자와 마감일로 이어지도록 이끕니다.
누가 사용하면 좋은가
retro는 Project Management, Agile 팀 리드, Scrum Master, 제품 팀, 또는 스프린트 리뷰에서 잘된 점, 막힌 점, 다음에 바꿀 점을 정리해야 하는 사람에게 적합합니다. 목표가 단순한 대화 기록이 아니라 실제로 쓸 수 있는 회고 결과라면 특히 잘 맞습니다.
무엇이 다른가
이 retro skill의 가장 큰 강점은 구조입니다. 여러 회고 형식을 지원하고, 사용자가 제공한 팀 데이터를 읽을 수 있으며, 잡담보다 요약과 정리에 무게를 둡니다. 그래서 한 번 쓰고 끝내는 “회고 써줘” 프롬프트보다, 반복되는 팀 의식에 더 잘 어울립니다.
retro skill 사용 방법
retro 설치하기
repo 경로를 사용해 skills 디렉터리에 retro skill을 설치한 다음, 회고를 요청하기 전에 에이전트가 해당 skill 콘텐츠를 보도록 지정하세요. 일반적인 설치 방식은 phuryn/pm-skills를 추가하고 pm-execution/skills/retro를 선택하는 형태입니다. 이 skill은 세션을 진행하고, 피드백을 요약하고, 스프린트 메모를 다음 행동으로 바꿔야 할 때 사용하면 좋습니다.
더 나은 입력 준비하기
retro는 막연한 요청보다 구체적인 맥락을 줄 때 가장 잘 작동합니다. 좋은 입력에는 보통 다음이 포함됩니다.
- 스프린트 날짜 또는 반복 이름
- 팀 이름과 프로젝트 맥락
- 원문 피드백, 메모, 설문 텍스트
- velocity, incident, carryover, blocker 같은 지표
- 원하는 의사결정 방식: Start/Stop/Continue, 4Ls, Sailboat
약한 프롬프트 예: “회고 해줘.”
더 강한 프롬프트 예: “Start/Stop/Continue 형식으로 Sprint 42 회고를 진행해줘. 스티키 노트 18개, incident 3건, 반복되는 blocker 2개가 있어. 주제를 묶고, 우선순위가 있는 액션 5개로 마무리해줘. 각 액션에는 담당자와 마감일을 넣어줘.”
먼저 읽을 파일
먼저 SKILL.md부터 보세요. 진행 규칙과 핵심 워크플로가 들어 있기 때문입니다. 나중에 skill이 확장되면 README.md, AGENTS.md, 또는 폴더 수준의 참조 파일도 확인하세요. 다만 현재 이 repo의 중심은 메인 skill 파일입니다. 즉, retro를 잘 쓰는 가장 빠른 방법은 지침을 읽고, 그것을 팀의 형식과 제약에 맞게 조정하는 것입니다.
실무 워크플로에 적용하기
좋은 retro 워크플로는 다음 순서입니다.
- 팀의 원문 입력을 모은다
- 팀 성숙도에 맞는 형식을 고른다
- skill에 주제 묶기와 패턴 도출을 요청한다
- 주제를 명확한 담당과 함께 action item으로 바꾼다
- 공유하기 전에 현실성 있는지 결과를 검토한다
팀이 바쁘다면 짧고 결정 품질이 높은 쪽에 맞춰 달라고 하세요. 회고가 민감한 분위기라면 비난 표현을 피하고 중립적인 문장을 유지해 달라고 요청하면 됩니다.
retro skill FAQ
retro는 스프린트 회고에만 쓰이나요?
아니요. retro skill은 sprint retro에 가장 잘 맞지만, 릴리스 이후 리뷰, 프로젝트 점검, incident 회고, 그리고 구조화된 학습과 후속 action item이 필요한 어떤 팀 debrief에도 잘 어울립니다.
retro가 잘 작동하려면 원문 메모가 꼭 필요한가요?
꼭 그렇지는 않지만, 팀 메모, 설문 댓글, 지표를 제공하면 결과가 훨씬 좋아집니다. 입력이 없어도 retro는 진행 개요를 만들 수는 있지만, 근거를 요약할 재료가 적어 더 일반적인 수준에 머물 수 있습니다.
retro가 일반 프롬프트보다 나은가요?
일관성이 필요할 때는 보통 그렇습니다. 일반 프롬프트로도 회고를 요청할 수 있지만, retro skill은 재사용 가능한 구조와 피드백에서 action까지 가는 더 분명한 경로를 제공합니다. 특히 반복성과 책임성이 중요한 Project Management 워크플로에서 그 차이가 큽니다.
언제 retro를 쓰지 말아야 하나요?
깊은 root-cause analysis, 공식 incident report, 또는 갈등 중재 스크립트가 필요하다면 retro를 쓰지 마세요. 이 skill은 회고 진행을 위한 것이지, 법무, HR, 기술 incident 문서화를 위한 도구가 아닙니다.
retro skill 개선하기
더 선명한 원문 자료를 주기
입력이 좋을수록 retro 결과도 좋아집니다. 인상보다 구체적인 사례를 넣으세요.
- “QA access가 없어서 배포가 두 번 지연됐다”
- “세 명이 acceptance criteria가 불분명하다고 언급했다”
- “스프린트 중간 범위 변경 이후 velocity가 42에서 31로 떨어졌다”
이 정도의 상세함이 있어야 skill이 주제를 만들어내는 대신 실제로 찾아낼 수 있습니다.
원하는 출력 형태를 분명히 요청하기
retro에 성공 기준을 알려주세요. 예를 들어 다음처럼 요청할 수 있습니다.
- 전체 대본이 아니라 3~5개 주제
- 30분 회고용 짧은 진행 아젠다
- 담당자, 마감일, 기대 효과가 있는 action item
- 비난을 피하는 중립적 표현
이렇게 하면 실제 회의에서 바로 쓰기 쉬운 형태가 되어 Project Management에 더 유용해집니다.
자주 생기는 실패 패턴을 점검하기
가장 흔한 문제는 피드백이 너무 넓어서 결과가 뻔한 권고로 끝나는 경우입니다. 또 하나는 action item을 너무 많이 요구해 후속 실행력이 약해지는 경우입니다. 첫 결과가 모호하다면 스프린트 맥락, 근거, 원하는 action 개수를 더해 프롬프트를 더 날카롭게 다듬으세요. 그런 다음 그 제약을 반영해 retro를 다시 실행하면 다음 결과를 더 쉽게 실행할 수 있습니다.