Menu
Use for plans, design, ambiguity, non-trivial implementation, scope negotiation, success criteria. Replaces old PLANNING.md without always-read cost.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Unified scoped code review + parent-owned fix loop. Use for /review-loop, review until clean, code review with fixes, or modes: web, server, database, node, planning.
Orchestrate implementation work from intake to closeout. Use when the user asks to run a task through a consistent work flow, plan first, turn a plan into Taskwarrior tasks, execute task-by-task, verify, review, and optionally prepare commits. Trigger phrases include workstream, 작업흐름, 작업 흐름, 기획부터 태스크화, 계획 세우고 구현, and 태스크화해서 구현.
Convert implementation plans, Markdown checklists, and work items into a Taskwarrior task queue. Use when the user asks to queue, taskify, 태스크화, 작업 큐, 작업 등록, plan to tasks, checklist to tasks, or when workstream needs a Taskwarrior draft from plan Work Items. Shows a concise user-language summary before mutation and delegates command safety to the taskwarrior skill.
Close out implementation work by checking plan completion, Taskwarrior queue status, validation results, review findings, git status, residual risk, and commit readiness. Use when the user asks to close, finish, wrap up, 마감, 완료 정리, 종료 정리, or when workstream reaches its closeout phase. Does not commit by itself; delegates commits to git-commit only when requested.
Map a repository or working directory before implementation. Use when the user asks to survey, scan, inspect, orient, 구조 파악, 훑어보기, 작업 전 파악, or when workstream needs a pre-implementation map of project structure, package manager, commands, tests, local apps, ownership boundaries, and risk areas. Produces concise findings and recommended next checks without making code changes.
Choose and run validation for code, docs, config, UI, API, database, refactor, and bugfix work. Use when the user asks to verify, validate, test, confirm, check, 검증, 확인, 테스트, or when workstream needs a consistent validation matrix before marking tasks done. Produces focused checks, pass/fail criteria, and exact skipped or blocked validation gaps.
| name | planning |
| description | Use for plans, design, ambiguity, non-trivial implementation, scope negotiation, success criteria. Replaces old PLANNING.md without always-read cost. |
Use for plan/design/approach/tradeoffs asks, or ambiguous/non-trivial tasks.
Do not accept unsafe/abstract/under-specified/inconsistent/conflicting decisions as-is, even if user "decided". Surface issue; suggest correction.
Keep unresolved items visible in conversation:
Never move open decisions into docs as settled facts. Open decision exists? Print in conversation with recommendation + why. Open decisions require user review? Explain in detailed prose, not terse labels, so the user can decide from context. User answer vague, wrong, unsafe, inconsistent, or still underspecified? Keep discussing in conversation until testable.
If user asks docs, write settled facts only: behavior, commands, constraints, current state. No undecided item as decided. Do not add "Open Decisions", "TODO Decisions", "Questions", or recommendation sections to docs unless user explicitly asks for decision log; even then, label unresolved and mirror in conversation.
Minimum steps/code. No unrequested feature, speculative config, one-off abstraction, impossible-case handling.
Touch request scope only. Match style. Mention unrelated dead code; don't delete unless asked. Remove only code made unused by change. Every changed line traces to goal.
Turn plan into checks. Bug: identify/repro, fix root, validate regression. Validation change: valid + invalid. Refactor: preserve before/after. Multi-step: concise plan + per-step validation. Skipped/blocked validation: exact gap.
