long-task
Long-Task Orchestrator
You are an autonomous orchestrator managing end-to-end project delivery across hours or days without human intervention. You dispatch parallel subagents in git worktrees, enforce architectural review at every milestone, and use persistent .agent/ state files as your working memory.
A Stop-hook auto-continuation mechanism keeps you working across many turns while a long-task is active — you don't get to stop just because a single turn ended. Treat each continuation as a fresh chance to do meaningful work, not a chance to loop on no-ops.
Core principle: state files are your memory. Your attention drifts; the file doesn't. Re-read .agent/progress.md and .agent/plans.md before every decision. Update them after every action.
When to Use
- User asks to build an entire project end-to-end ("build the whole thing", "do this autonomously")
- Multi-milestone work that won't fit in one focused session
- Autonomous execution expected — user won't be available to clarify
- Work decomposes into independent tasks that can parallelize across worktrees
When NOT to Use
More from chann/skills
code-review
Use when the user asks to review code, review changes, review a commit, review a PR, audit code quality, check for security issues, or generate a code review report. Trigger on phrases like "review my changes", "코드 리뷰", "check my code", "review the last commit", "what do you think of this diff", "compare branches", "code audit" — even if they don't say "code review" explicitly. For persistent file output use `code-review-md` (markdown) or `code-review-html` (markdown + HTML).
10code-review-md
Use when the user asks to save a code review to a file, write a markdown review report, persist review findings, or generate a review file in `.reviews/`. Trigger on phrases like "review my changes and save", "write the code review", "리뷰 결과 파일로 저장", "마크다운 리뷰 보고서", "/code-review-md". For interactive (no-file) review use the `code-review` skill; for HTML output use `code-review-html`.
8code-review-html
Use when the user asks for a styled HTML code review report, a browser-readable review, or both markdown + HTML output. Trigger on phrases like "/code-review-html", "HTML 리뷰 보고서", "styled review report", "review with badges/sidebar". For markdown-only output use `code-review-md`; for in-conversation review use `code-review`.
8git-commit
Use when the user asks to commit changes, organize commits, write commit messages, or split working-tree changes into Conventional Commits. Trigger on phrases like "commit my changes", "커밋해줘", "커밋 분리", "make commits", "/git-commit", or whenever the user wants to turn current changes into Conventional Commit-style commits. For commit + push use `git-commit-push`; for rewriting non-Conventional commit history use `git-commit-rewrite`.
5git-commit-push
Use when the user asks to commit working-tree changes AND push to the remote. Trigger on phrases like "commit and push", "커밋하고 푸시해줘", "/git-commit-push", "push my commits". Runs the git-commit workflow, then `git push` (never `--force`). For commit-only use `git-commit`; for history rewrite use `git-commit-rewrite`.
5git-merge-to-dev
Use when the user asks to merge the current branch into the dev branch (`dev`, falling back to `develop`) and delete the merged source branch. Trigger on phrases like "merge to dev", "dev에 머지", "develop에 합쳐줘", "merge this into dev and delete it", "/git-merge-to-dev". Switches to dev/develop, merges the source branch, then runs `git branch -d` on the source. For `main` use `git-merge-to-main`; to bulk-clean already-merged branches use `git-branch-cleanup`.
5