메뉴
This skill should be used when the user asks to "set mode", "change mode", "switch to exploration", "switch to hardening", "what mode", "current mode", or "/mode". Manages the project phase mode which controls hook and cue strictness.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
This skill should be used when the user asks "should I extract this?", "is this abstraction worth it?", "am I over-engineering?", "should I DRY this up?", or when evaluating whether to create a helper, utility, base class, or shared module. Use for any "extract vs inline" decision.
This skill should be used when reviewing a design proposal, RFC, technical plan, or before starting implementation. Use when asking "what could go wrong?", "what are we assuming?", "where is this fragile?", or "what happens if X changes?". Surfaces hidden dependencies and untested beliefs.
This skill should be used when the user asks to "review this code", "check this implementation", "what's wrong with this code", "review my changes", "code review", or when examining code for quality issues.
This skill should be used when asking "is this module too complex?", "why is this hard to change?", "what's causing coupling here?", or before refactoring a tangled system. Use to audit for accidental complexity, circular dependencies, god objects, and layering violations.
This skill should be used when the user asks to "help me debug", "why isn't this working", "this is broken", "debug this", "find the bug", or when systematically investigating an issue.
This skill should be used when asking "should we add this library?", "is this dependency safe?", "should we upgrade X?", or when evaluating npm packages, gems, crates, or any third-party code. Assesses maintenance risk, security, and exit strategy.
| name | mode |
| description | This skill should be used when the user asks to "set mode", "change mode", "switch to exploration", "switch to hardening", "what mode", "current mode", or "/mode". Manages the project phase mode which controls hook and cue strictness. |
| argument-hint | mode name (exploration, default, hardening, release) |
Run:
source "$HOME/.claude/hooks/validate-path.sh" && get_project_mode
To change mode, use the set_project_mode function:
source "$HOME/.claude/hooks/validate-path.sh" && set_project_mode "<MODE>"
Where <MODE> is one of:
| Mode | Guards | Cues | Use When |
|---|---|---|---|
| exploration | Lenient: skips uncommitted-change-guard, test-blocker, ai-guardrails, layering-guard | Fewer fire (mode-tagged cues filtered out) | Spiking, prototyping, exploring unfamiliar code |
| default | Normal | Normal | Standard development work |
| hardening | Strict: layering violations are blocked (not just warned) | More fire | Pre-merge stabilization, bug fixing |
| release | Strict + layering blocked | Release-focused cues | Cutting a release branch |
Report the new mode to the user and briefly explain what changed.
To go back to normal:
source "$HOME/.claude/hooks/validate-path.sh" && set_project_mode "default"
Mode is stored in ${CLAUDE_PROJECT_DIR}/.claude/project-mode (project-specific) or ${CLAUDE_HOME}/project-mode (global fallback). It persists across sessions.
User: /mode
Response: "Current project mode: default"
User: /mode exploration
Response: "Switched to exploration mode. Guards relaxed — uncommitted change warnings, test blockers, AI guardrails, and layering checks are disabled. Good for prototyping."
User: /mode hardening
Response: "Switched to hardening mode. Guards tightened — layering violations will be blocked outright. More quality cues will fire."