메뉴
Structured reasoning before implementing. Use when: planning a feature, designing architecture, evaluating an approach, criticizing a draft implementation, solving a complex problem, debugging a non-obvious issue. Wraps the think MCP (think / plan / criticize).
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | think-plan |
| description | Structured reasoning before implementing. Use when: planning a feature, designing architecture, evaluating an approach, criticizing a draft implementation, solving a complex problem, debugging a non-obvious issue. Wraps the think MCP (think / plan / criticize). |
| argument-hint | Describe the problem or decision to reason through |
Mandatory reasoning gate before non-trivial work. Do NOT skip this for anything that involves more than a single file change or a well-understood one-liner fix.
criticizeAll three calls go through the think MCP server via the mcp-compressor pattern:
mcp_wulfnet-think_think_invoke_tool(tool_name, tool_input)
Always call mcp_wulfnet-think_think_get_tool_schema first if the schema is not already in context.
Use for: "what's the right approach here?", debugging hypotheses, tradeoff analysis.
tool_name: "think"
tool_input: { "thought": "<specific question or problem statement>" }
Use for: new features, project scaffolding, any task > 2 steps.
tool_name: "plan"
tool_input: { "goal": "<what we're building>", "context": "<relevant constraints / stack>" }
The output is a numbered action list. Translate this directly into TODO.md entries.
Use for: reviewing your own proposed solution before implementing, catching edge cases.
tool_name: "criticize"
tool_input: { "draft": "<the plan, code, or design to stress-test>" }
Address every raised issue before proceeding. If you disagree, document why.
think before plan. Don't jump to a step list without framing the problem.criticize a plan before writing code. One extra call, saves hours.plan must map to TODO.md — don't let plans live only in the chat.criticize surfaces a fatal flaw, restart from think, not from plan.Execute build commands, dev servers, scripts, and interpret their output. Use when: running builds, starting/stopping dev servers, executing install commands, running linters or type-checkers, interpreting non-zero exit codes, or orchestrating multi-step command sequences. Manages terminal lifecycle and output parsing.
Explore and understand an existing codebase before implementing. Use when: starting work on an unfamiliar codebase, finding where a function is defined or called, looking for existing patterns to follow, checking if a feature already exists before building it, or doing cross-repo code intelligence. Uses gitnexus MCP and workspace search tools.
Aggressive, thorough code review. Use when: reviewing a PR, auditing a file before merge, checking for security issues, OWASP Top 10 violations, performance problems, missing error handling, poor logging, or just reviewing a junior dev's work. Uses think.criticize + workspace analysis.
Systematic error triage and fix loop. Use when: build fails, type errors appear, runtime exceptions occur, get_errors returns problems, tests fail with unexpected errors, logs show exceptions. Reads VS Code diagnostics, terminal output, and log files to form hypotheses and drive fixes to zero errors.
Git operations with enforced conventions: branch from issues, conventional commits, clean history, tagging releases. Use when: starting work on a new feature or bug fix (create branch), committing completed work, creating a release tag, cleaning up branches, or enforcing commit message standards. Does NOT push or force-push without confirmation.
GitHub operations: create/update issues, open PRs, review PR status, check workflow runs, search code across repos, manage releases, list branches. Use when working with GitHub repos, tracking work in issues, or managing the release process. Uses github MCP.