菜单
Health Trainer를 MVP 슬라이스 단위로 체계적으로 구현하는 오케스트레이터. main에서 슬라이스별 브랜치/워크트리를 만들고, 슬라이스마다 설계→TDD구현/골격→검증→리뷰→머지 파이프라인으로 진행한다. Health Trainer 기능 구현·MVP 진행·새 슬라이스 추가·이전 슬라이스 보완·재실행·워크트리 작업을 요청하면 사용. 단순 질문은 직접 응답.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
이 프로젝트에서 실수·교정·발견을 docs/LESSONS.md에 기록하고, 그 교훈을 하네스(에이전트·스킬·CLAUDE.md)·규약·코드에 되먹여 같은 실수가 재발하지 않게 하는 실천. 버그를 고쳤거나, 사용자에게 교정받았거나, "이렇게 했어야 했다"는 깨달음이 생겼거나, 구조의 모순·개선점을 발견했을 때 반드시 사용. "교훈 기록", "lesson", "compound", "하네스 개선/업데이트" 상황에 사용.
Health Trainer를 빌드·테스트하는 운영 스킬 — system gradle이 없을 때 Gradle wrapper 부트스트랩, :core 단위 테스트 실행 + JUnit XML에서 정확한 통과/실패 수 집계 + :core 순수성(Android import 금지) 검사. Health Trainer에서 "테스트 돌려줘", ":core 빌드", "테스트 몇 개 통과", "gradle이 없다/안 된다", "빌드 환경 설정", 또는 변경 후 검증이 필요할 때 사용. 번들된 scripts/를 우선 쓴다.
Health Trainer의 rule/tracker 단위 테스트에서 목표 각도의 합성 PoseFrame을 손쉽게 만드는 방법 — 검증된 공유 헬퍼 com.healthtrainer.core.testutil.SyntheticPose. 스쿼트/푸쉬업/플랭크 rule 테스트나 rep/set tracker 테스트를 새로 작성·수정할 때, "무릎 각도 90도인 프레임", "팔꿈치 ~170도", "깊이 부족 회차" 같은 합성 입력이 필요할 때 반드시 사용. 좌표를 손으로 계산하지 말 것.
Health Trainer의 운동별 정자세 rule engine을 작성·확장하는 도메인 지식 — ExerciseRule 인터페이스 계약, MovementPhase/FeedbackCode 의미, 스쿼트/푸쉬업/플랭크 자세 기준 임계값, rep state machine이 phase를 소비하는 방식. 새 운동 rule을 추가하거나 자세 판정 기준·임계값을 작성·튜닝할 때 반드시 참조.
Health Trainer 프로젝트의 코드 규약 — :core/:app 모듈 구조, 패키지 네이밍(com.healthtrainer.*), 랜드마크 데이터 모델(LandmarkName/PoseLandmark/PoseFrame/Point3), :core 순수성 규칙, Gradle 멀티모듈 + Android SDK 조건부 include 설정, JUnit4+Truth 테스트 패턴. Health Trainer의 Kotlin 코드를 작성·수정·리뷰하거나 모듈 구조·패키지·테스트 위치를 결정할 때 반드시 참조.
| name | mvp-pipeline |
| description | Health Trainer를 MVP 슬라이스 단위로 체계적으로 구현하는 오케스트레이터. main에서 슬라이스별 브랜치/워크트리를 만들고, 슬라이스마다 설계→TDD구현/골격→검증→리뷰→머지 파이프라인으로 진행한다. Health Trainer 기능 구현·MVP 진행·새 슬라이스 추가·이전 슬라이스 보완·재실행·워크트리 작업을 요청하면 사용. 단순 질문은 직접 응답. |
Health Trainer를 "체계적으로 진행한 프로젝트"로 만드는 워크플로우. 전문가 풀(에이전트) + 생성-검증 하이브리드.
superpowers:using-git-worktrees — 슬라이스별 격리 작업공간superpowers:executing-plans / superpowers:subagent-driven-development — 계획 실행superpowers:finishing-a-development-branch — 슬라이스 완료/머지 결정superpowers:requesting-code-review, superpowers:verification-before-completion시작 시 현재 상태를 판별해 실행 모드를 정한다:
_workspace/ 없음 + 슬라이스 미시작 → 초기 실행 (mvp-0부터)git worktree list로 떠 있는 워크트리 확인.mvp-N-이름)의존 순서대로. 각 슬라이스는 독립 브랜치에서 작업 후 main에 머지한다.
| 브랜치 | 모듈 | 내용 | 검증 |
|---|---|---|---|
mvp-0-scaffold | root | Gradle 멀티모듈, wrapper, settings 조건부 include, .gitignore | :core configure 통과 |
mvp-1-pose-geometry | :core | LandmarkName/PoseLandmark/PoseFrame, Point3, AngleCalculator, LandmarkNormalizer | :core:test green (TDD) |
mvp-2-rule-engine | :core | ExerciseType/FeedbackCode/MovementPhase/ExerciseFeedback/ExerciseRule, Squat/PushUp/Plank Rule | :core:test green (TDD) |
mvp-3-rep-tracking | :core | RepRecord/SetRecord/ExerciseSession, RepStateMachine, SetTracker | :core:test green (TDD) |
mvp-4-app-skeleton | :app | MainActivity, MediaPipe 어댑터, CameraPreview, SkeletonOverlay, ExerciseScreen, ResultScreen, 3D viewer (골격) | 컴파일 구조만, 런타임 미검증(requires device) |
mvp-5-docs-demo | docs | demo-script.md, 진행 현황 문서 갱신 | 문서 리뷰 |
슬라이스 범위는 고정이 아니다. 사용자 요청에 맞춰 android-architect가 재분해할 수 있다.
실행 모드: 전문가 풀(슬라이스 성격에 맞는 에이전트 dispatch) + 생성-검증.
superpowers:using-git-worktrees로 mvp-N-이름 격리 작업공간 확보. (main은 항상 깨끗하게 유지) 워크트리/repo-level git 작업은 메인 repo 절대경로로 한다(git -C /abs/main worktree add …). 워크트리 안에서 git rev-parse --show-toplevel은 현재 워크트리 루트를 반환하므로 메인 repo 경로 대용으로 쓰면 워크트리가 중첩 생성된다(LESSONS 2026-06-05).android-architect로 _workspace/mvp-N-plan.md 작성(파일 목록·단계·검증 명령). 범위가 명확하면 생략 가능.:core 슬라이스 → kotlin-tdd-engineer (RED→GREEN→REFACTOR, 실제 :core:test green):app 슬라이스 → android-platform-engineer (골격, 미검증 표기)verification-qa로 :core:test 실행 + 경계면 교차 비교. 실패 시 3으로 복귀.code-reviewer로 diff 검토(:core 순수성, TDD, 계약, 규약). blocker 있으면 3으로 복귀.--no-ff로 main에 머지(슬라이스 경계가 히스토리에 남도록). superpowers:finishing-a-development-branch로 정리.모든 Agent 호출은 model: "opus"로 한다.
<slice>: <변경> 예) mvp-1: add AngleCalculator with right/straight angle tests.git merge --no-ff mvp-N-이름 (슬라이스 단위 보존)._workspace/mvp-N-*.md (파일 기반, 감사 추적).:core/:app 소스 + git 히스토리.superpowers:systematic-debugging로 근본 원인. 증상만 가리지 않는다.unverified (requires device)로 정직하게 보고.정상 흐름: "스쿼트 rule 구현" → Phase 0(이어가기 판별) → mvp-2-rule-engine 브랜치 → architect 계획 → kotlin-tdd-engineer가 RED(BOTTOM 인식, 깊이 실패) → GREEN → qa가 :core:test green + rule↔tracker 경계 확인 → reviewer가 :core 순수성 확인 → --no-ff 머지.
에러 흐름: kotlin-tdd-engineer가 :core:test 실패 보고 → systematic-debugging으로 각도 공식 부호 오류 발견 → 수정 → 재실행 green → 진행. (실패를 숨기고 머지하지 않는다.)