team-incube

Creates a new git branch following the project's branch naming convention. Use this skill whenever the user wants to start new work, create a branch, switch to a new branch.

Generate PR title and body from commits since the base branch, then create the PR on GitHub following the project PR template exactly.

Check PR review comments, reflect valid feedback into code, commit, push, then reply to each comment with the resolving commit hash.

Create Git commits following Flooding project conventions. Splits changes into logical units with correct type prefix and Korean description.

Run a structured checklist over changed files — Kotlin style, JPA/transaction correctness, naming conventions, test coverage, and security basics. Produces a ✓/⚠/✗ report.

Run KtLint formatting on all Kotlin source files via Gradle. Use when .kt files need formatting or after bulk edits.

Kotest + MockK testing patterns for this project — BehaviorSpec structure, mock creation, stubbing, argument capture, and exception assertions. Reference when writing or reviewing test code.

Architecture reference for Flooding project — Controller/Service/Repository layer responsibilities, @Transactional strategy, ExpectedException usage, entity conventions, and response wrapping.

Run a structured checklist over changed files — naming conventions, DTO, Kotlin style, JPA/transaction correctness, GraphQL schema, and security basics. Produces a ✓/⚠/✗ report.

Create Git commits by splitting changes into logical units following project conventions. Handles Git Flow automatically — detects develop branch and checks out a feature branch before committing.

Code conventions for naming, DTO, Entity, Repository, Service, and Controller in this project.

Run KtLint formatting on all Kotlin source files via Gradle. Use when .kt files need formatting or after bulk edits.

Conduct an in-depth structured interview with the user to uncover non-obvious requirements, tradeoffs, and constraints, then produce a detailed implementation spec file.

Hexagonal architecture structure and rules for this project. Use this when creating new files or features to place them in the correct layer.

Parse code review comments left by bot reviewers (gemini-code-assist, coderabbitai, copilot, etc.) on the current PR, apply the suggested fixes to the code, then reply to each review comment thread mentioning that reviewer with a summary of what was addressed.

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

깃허브 커밋 메시지 작성

깃허브 PR 생성

깃허브 이슈 생성

Finish the current branch — verify, commit remaining work with the emoji-:: convention, push, and open a PR to develop that passes the PR title check CI. Use when the user says "PR 올려", "출고", "ship", "머지 준비".

Start work on a GitHub issue — pick or create the issue, then create the convention branch ({type}/{issue}-{slug}) off fresh develop. Use when the user says "이슈 시작", "작업 시작", "start issue", or names an issue number to work on.

Run the CI-equivalent verification chain (build_runner codegen → flutter analyze → flutter test) and keep fixing + re-running until everything passes. Use before committing, before PRs, or when the user says "검증", "verify", "CI 통과 확인".

Iterative implement → verify → commit cycle on the current branch until the stated goal is done. No branch creation, no PR. Use when the user says "작업 루프", "work loop", or wants heads-down implementation of a defined task list.

Full autonomous cycle for one issue - start-work (issue → branch) → work-loop (implement/verify/commit) → ship (push → PR). Use when the user says "전체 루프", "full loop", "이슈 끝까지", or hands over an issue to complete end-to-end.