Central-MakeUs

이 저장소에서 신규 기능 개발, 기존 기능 리팩토링, 버그 수정, API 변경, 도메인 정책 변경을 수행할 때 설계 문서화, Red-Green-Refactor 테스트 작성, 구현, 관련 테스트와 전체 테스트 검증, 배포/PR 확인까지 자연스럽게 이어가도록 사용하는 워크플로우 스킬이다.

이 저장소에서 브랜치 변경 내역을 바탕으로 프로젝트 PR 본문 형식에 맞춰 요약, 상세 작업 내용, 참고사항을 작성할 때 사용한다.

이 저장소에서 변경 내용을 바탕으로 프로젝트 커밋 메시지 규칙에 맞는 커밋 메시지를 만들거나, staged 변경을 확인해 적절한 Type과 제목을 정리할 때 사용한다.

이 저장소에서 큰 기능 설계나 정책 변경을 시작하기 전에 AGENTS.md, CONTEXT.md, docs/adr, docs/history, 실제 코드를 근거로 요구사항을 질문하고 도메인 용어와 아키텍처 결정 및 작업 이력을 문서화할 때 사용한다.

이 저장소에서 신규 기능 개발, 기능 수정, PRD 작성, API 변경, 스케줄러/Redis/FCM/외부 API 연동 작업을 할 때 latency, availability, error rate 관점의 SLO 영향을 점검하고 필요한 metric, 테스트, 운영 확인 항목을 정리할 때 사용한다.

이 저장소에서 기능 요청, 정책 변경, API 변경, 앱 요구사항을 docs/history/{0001}-{기능명-slug}/PLAN.md 형식의 PRD 또는 구현 계획으로 정리할 때 사용한다.

이 저장소에서 controller, service, repository, Redis, integration 테스트를 작성하거나 수정할 때 사용한다. TDD red-green-refactor 흐름, 어노테이션 선택, fixture 사용, nested 테스트 구조, DisplayName 규칙, 현재 코드베이스의 테스트 패턴을 다룬다.

이 저장소에서 Spring Boot, JPA, Redis, Firebase FCM, 인증/인가, 테스트 실패, 운영성 버그를 재현하고 원인 분석부터 최소 수정 및 회귀 테스트까지 진행할 때 사용한다.

Ballog entity 슬라이스 생성 템플릿. ky API 그룹, query-key-factory 등록, query/mutation 훅 네이밍과 invalidation 규칙. /feat-new 가 참조.

Ballog(apps/web) FSD 레이어 규칙. 의존 방향, public API, import 순서, 네이밍. 파일 생성/리뷰 시 경계 위반 검증에 사용.

Ballog MSW handler/data 생성 템플릿과 handlers.ts 레지스트리 삽입 규칙. /feat-new 가 참조.

Ballog 커밋 및 PR 메시지 컨벤션. 이모지 prefix(✨Feat/💄Style/✏️Fix)와 fix:/feat: 간결 스타일 혼용 규칙, 한국어 PR 본문 작성 틀. /review-pr 이 참조.

/feat-new 가 읽는 Ballog API 명세 MD의 YAML 스키마 정의. endpoints/types/msw/figma 필드와 작성 규칙. spec 파일 작성이나 파싱할 때 참조.

Ballog 프로젝트의 Tailwind + cn() 사용 규칙. 조건부 클래스 가독성, twMerge 충돌 회피, 반복 유틸 추출 기준. className을 작성하거나 리뷰할 때 참조.

Build the signed Android release App Bundle (.aab) for this repository. Use when the user asks to create or export a release AAB, run `bundleRelease`, bump the Android app version for release, verify release signing configuration, or report the final bundle output path and size.

Use this skill when the user explicitly asks to create git commits. Do not trigger for code changes that do not request commit creation.

Use this skill when the user asks to synchronize project documentation after implemented changes. Do not trigger for planning-only conversations.

요구사항을 정리하고 docs/specs/에 스펙 파일을 생성한다. 기능 추가, 리팩터링 계획, 아키텍처 결정이 필요할 때 사용.