gitgitWi

code-review-brief

Write the base material for a code review — a "review brief" for a pull request that the USER feeds to their own external agent(s) to post review/comments on GitHub. This skill does NOT perform the review itself and does NOT post comments; it prepares the document a reviewer works from. The flow agent gathers the diff, the changed-file list, a summary of major changes, and the original intent/plan plus the user's key requests, then writes multi-angle review prompts (UX, code quality, redundant or over-engineered implementation, security, stability) tailored to the change. Use to prepare a review for any PR, whether just opened by flow:deploy or already on GitHub. Triggers on "코드리뷰 준비", "리뷰 brief 만들어줘", "PR 리뷰 자료 작성", "prep a review for PR

commit-pr

The fast commit → push → open-or-update-PR loop, with the standard rules baked in so they never need retyping. Use whenever the user says "commit", "commit and push", "push", "PR 올려", "PR 갱신", "update the PR", or wants the current changes shipped to a pull request. Splits work into atomic Conventional Commits, pushes the branch, and opens a Korean PR (or updates the existing one) with the project's assignee/labels/milestone. This is the everyday "ship what I have" command — distinct from flow:deploy, which opens the PR and then offers the code-review brief step.

DevOps & Infrastructure Listed

deploy

Push the task branch and open a Korean pull request, then ask the user whether to run flow:code-review-brief and, on confirm, run it inline for the new PR. Use this whenever development for a flow task is done and the branch is ready for review. Even when the user says "just open a PR", finish by offering the review-brief step. Run in its own session from develop; do not bundle.

AI & Automation Listed

develop

Execute the implementation phase of the flow workflow — read `tasks.md`, pick the next unchecked behavior, write a failing test (when TDD applies), implement until green, commit atomically with conventional commits, and check the box. Use this for any actual code change in a flow task, whether or not a plan exists. Even when the user says "just implement this", invoke develop so the atomic-commit and TDD discipline applies. The skill resumes cleanly from interrupted sessions because `tasks.md` is the source of truth for progress.

AI & Automation Listed

kickoff

The single entry point for any flow task — it both frames the work AND sets up the workspace, so there is nothing to call before it. Start here for every new piece of work — a feature, bug fix, debug, chore, refactor, or research question — even a one-line "fix X" or "이거 작업하자". Kickoff figures out the task type (asking if unstated), runs cost-efficient research subagents for just-enough context, writes a short visual brief (goal + acceptance + scope, with a Mermaid diagram), then creates the isolated worktree, branch, and `.flow/tasks/<date>-<task>/` directory — landing you ready to plan or develop. It replaces retyping the same kickoff prompt and forces the fields that were chronically missing (how do we know it's done? how is it verified? what is out of scope?). Do not start coding from here. Also fires on "frame this task", "create a worktree", "세션 시작", "이거 작업 시작하자".

AI & Automation Listed

orchestrate

Run the full flow workflow end-to-end — kickoff (framing + setup) → optional research → plan (with optional multi-LLM brainstorming) → develop → deploy → optional cleanup — based on a single task goal from the user. Use this when the user wants to hand off a complete task and let the workflow run, rather than driving each step manually. Skips research and brainstorming automatically for size S tasks; runs the full pipeline for size L. Even when the user just says "build me X", consider this skill if the task warrants the full discipline.

plan

Produce a short, visual `plan.md` (goal + approach + a Mermaid diagram of the direction) and a concise checklist `tasks.md` for an upcoming task. Use this whenever the user is about to start a non-trivial change — a feature, multi-file fix, refactor — before any code is written. Even if the user just says "let's start", produce a plan first; the develop skill consumes these documents. Keep it lightweight — a one-minute read and a diagram beat a long document; the goal is fast plan→implement→review→fix iteration, not exhaustive up-front detail. The plan is for any coding agent (Claude, Codex, a teammate) to pick up and execute, so it must stand on its own.

prep

Set up an isolated worktree, branch, and `.planning/<date>-<task>/` directory for a new development task before any planning or coding starts. Use this whenever the user kicks off non-trivial work — a feature, a fix, a refactor, anything that warrants its own branch. Even if the user does not explicitly say "create a worktree", invoke this when they describe a new task that will involve multiple changes; it is the standard entry point for the flow workflow.

research

Investigate codebase context, related projects, and external sources for a task that is large or unfamiliar enough that planning blind would waste effort. Use this when the task crosses modules, touches a subsystem the user has not worked on recently, or depends on external APIs / libraries whose current shape matters. Also use whenever the user explicitly asks for research, exploration, or a "deep dive" before planning. Output goes to `.flow/tasks/<date>-<task>/research.md` so the planner and reviewer can build on it.

review-triage

Triage and address code-review feedback on a pull request. Fetches ALL feedback types — review summaries, inline review comments, review threads/discussions, and general PR conversation comments — then assesses each for validity and priority, writes a fix plan, and (after the user approves) applies the fixes as atomic commits. This is the counterpart to flow:code-review-brief — that skill prepares a review; this one processes the feedback that came back. Usually run in its own session, separate from the review. Recommend-only — never auto-invoked by another skill; the user starts it. Triggers on "리뷰 반영", "PR 코멘트 검토/정리", "리뷰 피드백 반영해줘", "address review comments", "PR

cleanup

Tear down a finished task's transient resources — kill the dev server / e2e / Playwright processes it started, remove the git worktree, prune stale preview deployments (keeping the last N), and note the cleanup on the parent issue. Use once a task's PR is merged (or abandoned) and you want the workspace and running resources reclaimed. Recommend-only — never auto-invoked by another skill; the user starts it. Triggers on "정리해줘", "리소스 정리", "worktree 제거", "cleanup", "teardown", "clean up the task", "e2e 종료".