gitgitWi

code-review

Run a multi-LLM code review on a pull request — gather the diff, dispatch reviewer CLIs in parallel via the file-write contract, synthesize a Korean summary, and post inline comments tagged by severity and model signature. Use this for any PR review whether the PR was just opened by flow:deploy or already exists on GitHub. Even when the user says "review PR

DevOps & Infrastructure Listed

deploy

Push the task branch, open a Korean pull request, then hand off to flow:code-review for the multi-LLM review pipeline. 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", run the full flow — multi-LLM review is the point of this skill, not optional dressing. 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

orchestrate

Run the full flow workflow end-to-end — prep → optional research → plan (with optional multi-LLM brainstorming) → optional plan-review → develop → deploy — 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, brainstorming, and plan-review 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-review

Run a multi-LLM review on `plan.md` and `tasks.md` before implementation starts, capturing each reviewer's output as a file and synthesizing a Korean summary the user reads. Use this whenever a plan is non-trivial (size M with external dependencies, or any size L). Different models catch different gaps; the cost of an extra reviewer pass is tiny compared to discovering a missing requirement halfway through develop. Also use whenever the user asks for a "second opinion" on a plan or wants to validate an approach before committing to it.

Data & Documents Listed

plan

Produce a tight one-pager `plan.md` and a Given-When-Then 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. The plan is for any coding agent (Claude, Codex, Gemini, 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 `.planning/<date>-<task>/research.md` so the planner and reviewer can build on it.