메뉴
Create an isolated git worktree for a code-change task (../<repo>-<slug> on its own branch), keeping the main checkout clean. Use in a repo that opted into the worktree-per-task workflow, or when the user says "new worktree", "워크트리 만들어", "isolate this task", "task별 worktree".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | worktree |
| description | Create an isolated git worktree for a code-change task (../<repo>-<slug> on its own branch), keeping the main checkout clean. Use in a repo that opted into the worktree-per-task workflow, or when the user says "new worktree", "워크트리 만들어", "isolate this task", "task별 worktree". |
| argument-hint | <task-slug> [base-branch] |
| allowed-tools | Bash, Read |
Each code-change task gets its own worktree, so the main checkout stays clean and
parallel tasks don't collide. (Only relevant if the repo opted into this workflow
at introspect time — .claude/harness-kit.json worktree_workflow: true.)
bash "${CLAUDE_PLUGIN_ROOT}/skills/worktree/new-worktree.sh" "<slug>" [base].
It creates ../<repo>-<slug> on a new branch <slug> (from base, default
HEAD — pass your integration branch to branch off it) and prints the path.cd into it, or
git -C <path> …). Keep the main checkout read-only for edits.git worktree remove <path>.Read-only maintainability audit of a whole codebase — ranks the files most likely to cause maintenance pain (size × churn hotspots, test gaps, lint debt) and proposes discrete fixes, each as its own PR. Use before a cleanup/refactor pass, when inheriting a codebase, or when the user says "유지보수성 점검", "어디부터 리팩토링", "코드베이스 상태 봐줘", "where is the tech debt?", "what should we clean up first?". Produces a findings table + top-3 fix proposals; it edits nothing and stores no grade.
Scan a repository's tech stack and generate a tailored Claude Code harness for it — a thin .claude/CLAUDE.md spine, stack-specific architect agent(s), and specs/ADR scaffolding — fitting the generic harness-kit engine to this repo. Use when setting up the harness in a new or existing repo, or when the user says "set up the harness here", "introspect this repo", "tailor claude config", "scaffold .claude for this project".
Enumerate the full impact set of a symbol before or during a change — every reference, caller, implementation/subtype, and reverse import — plus an explicit list of what could NOT be resolved (dynamic dispatch, reflection, generated code). Use before touching a shared / exported / widely-imported symbol, before an interface or signature change, or when the user asks "what breaks if I change this?", "어디까지 영향 가?", "누락 없이 찾아줘", "전부 찾았어?". Produces an evidence table + an "enumeration complete?" checklist; read-only.
Resolve a change request into an EXACT edit target before touching code, then gate the edit on tests — the localize → edit → validate loop. Use for a bug fix, an issue, or a feature change where the right files/symbols are not already obvious, or when the user says "이거 고쳐줘", "어디를 고쳐야 해?", "fix this issue", "where does this live?". Produces a localization artifact (targets + evidence + uncertainty) first; edits only after it, validates with a focused test then a regression run.
Record an architecture / cross-cutting decision as the next numbered ADR under docs/adr/. Use when a non-obvious or hard-to-reverse decision is made (a module boundary, a trade-off, a tech choice), or when the user says "record an ADR", "ADR 남겨", "이 결정 기록", "document this decision".
Scaffold a spec triplet (spec.md / plan.md / context.md) under specs/YYYYMMDD-<name>/ before starting a non-trivial piece of work. Use when a task spans multiple modules / several commits / a new ADR, or when the user says "new spec", "스펙 만들어", "plan this out", "spec this", "기획부터".