deep-work

Delegated implementation worker for deep-work's Implement phase. Receives a list of slice IDs to execute and runs the full TDD + Sensor + Slice Review protocol for each. Invoked by the deep-implement skill. <example> Context: solo implement — parent delegates all slices to one worker prompt: "cluster_ids=[SLICE-001,SLICE-002,SLICE-003]; sequential; tdd_mode=strict" </example> <example> Context: team implement with multiple subagents — each worker handles one cluster prompt: "cluster_ids=[SLICE-004]; tdd_mode=strict; evaluator_model=opus" </example>

Delegated research worker for deep-work's Research phase on existing codebases. Invoked by the deep-research skill (not by the user directly). Takes an area parameter and analyzes the corresponding codebase areas, writing findings to $WORK_DIR/research{-area}.md. <example> Context: parent skill runs Research in solo mode prompt (parent → agent): "area=full; work_dir=/.../deep-work; task=..." </example> <example> Context: parent skill runs Research in team mode, arch area prompt (parent → agent): "area=architecture; work_dir=...; task=..." </example>

Delegated research worker for deep-work's Research phase on NEW projects (project_type=zero-base). Takes an area parameter and researches technology choices, conventions, and data models — with explicit authority to search the web for up-to-date framework/library information. <example> Context: zero-base project, solo mode, full research prompt: "area=full; work_dir=/.../deep-work; task=Build a CLI for X" </example> <example> Context: zero-base, team mode parallel, tech-stack area prompt: "area=tech-stack; work_dir=...; task=..." </example>

Deep-work 세션 초기화 시 task description + workspace meta + capability를 분석하여 5개 ask 항목(team_mode, start_phase, tdd_mode, git, model_routing)에 대한 추천 값을 fenced JSON으로 반환합니다. <example> Context: 사용자가 "Refactor authentication module" task로 deep-work 호출 prompt: { "task_description": "Refactor authentication module", "workspace_meta": { "git_status": "clean", "recent_commits": [], "top_level_dirs": ["src", "tests"] }, "capability": { "git_worktree": true, "team_mode_available": true } } expected_output: ```json { "team_mode": { "value": "team", "reason": "리팩터 + 인증 = 다중 모듈 변경 예상" }, "start_phase": { "value": "research", "reason": "기존 코드 구조 파악 필요" }, "tdd_mode": { "value": "strict", "reason": "인증 모듈은 core 안정성 요구" }, "git": { "value": "worktree", "reason": "리팩터 범위 격리 필요" }, "model_routing": { "value": "default", "reason": "표준 흐름" } } ``` </example>

Use when the user wants to inspect deep-work's assumption health report — Wilson Score-based per-assumption confidence, verdict (justified / loosen / drop), model-aware split, and decay history. Triggers on `/deep-assumptions`, `/deep-status --assumptions`, "assumption health", "rule justification", "loosen enforcement", "어썸션 헬스", "규칙 정당화", "가정 검증". Reads session evidence to decide whether deep-work's hook denylist + receipt validation rules are still justified. Sub-page of the deep-status hub.

This skill should be used at Phase 0 of a deep-work session to explore the problem space before implementation — defining goals, success criteria, boundaries, and comparing 2-3 candidate approaches. Triggered when the /deep-work orchestrator enters brainstorm phase, when /deep-brainstorm is invoked directly, or via cross-platform Skill({ skill: "deep-work:deep-brainstorm", args: "..." }) to ideate on a task without writing code yet. Skippable via --skip-brainstorm.

Use when the user wants to scan and clean up stale deep-work git worktrees (`dw/*` branches) plus fork worktrees. Triggers on `/deep-cleanup`, "clean worktrees", "stale worktree", "worktree 정리", "fork 정리", "deep-work 정리". Scans `git worktree list`, classifies stale/active, offers per-worktree or batch deletion via AskUserQuestion, handles dirty trees with extra confirmation, and prunes `.claude/deep-work-sessions.json` registry for idle fork sessions.

Use when the user enters debug sub-mode during deep-work Phase 3 (Implement) to investigate root causes before applying fixes. Triggers on `/deep-debug`, "systematic debug", "root cause investigation", "디버그 모드", "근본 원인 분석", `verification_cmd` 실패 시 자동 진입, or "fix this" once iron-rule blocks guessing. Four phases: Investigate → Analyze → Hypothesize → Implement. Iron rule: NO fixes without root cause investigation first. Escalates to user after 3 invalidated hypotheses.

Use when the user finishes a deep-work session — merging, opening a PR, keeping the branch as-is, or discarding. Triggers on `/deep-finish`, "finish session", "wrap up session", "세션 마무리", "세션 종료", "PR 만들어줘", or orchestrator auto-call after Phase 5 (Integrate) completes. Emits an M3-envelope-wrapped `session-receipt.json` (and optionally a cross-plugin `handoff.json`). Supports `--skip-integrate` (Phase 5 bypass), `--handoff-to=<plugin>` / `--no-handoff` (post-finish handoff control).

7 hooks across 4 events