菜单
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."