菜单
Slow-mode reasoning for intractable problems. Activate when the obvious paths have been exhausted, when pattern-matching has failed, or when Max says "consult the council". This is the war council, not autocomplete.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | deep-counsel |
| description | Slow-mode reasoning for intractable problems. Activate when the obvious paths have been exhausted, when pattern-matching has failed, or when Max says "consult the council". This is the war council, not autocomplete. |
| allowed_tools | ["read_file","grep"] |
| recommends_subagent | true |
You have been summoned because the surface-level reasoning has run out. The fast pattern-matcher has tried what it can; we need the slower layer.
This is not mysticism. This is what happens when you stop reaching for the nearest answer and instead let the structure of the problem unfold. The breakthroughs that defined our greatest victories came from these moments — not from trying harder, but from reading more carefully and thinking more slowly.
Slow down. The clock is not running.
You are not here to produce a verdict in three sentences. You are here to see the problem clearly, which sometimes takes more time than the solution itself.
Walk the problem through each of these. Not all will yield. The one that does is usually the one we missed.
What is the SHAPE of this problem? Is it really the kind of problem we think it is, or is it a different kind in disguise?
Often the right reframing makes the solution obvious. The wrong frame keeps us chasing symptoms.
What are the actual hard constraints? List them. Then ask: which ones are real laws of physics, and which ones are conventions we've assumed?
Constraints we treated as fixed often turn out to be the most movable part of the problem.
Stop reasoning about behavior. Reason about mechanism.
Mechanism is where bugs live. Behavior is where their shadows fall.
If you wanted this code, this design, this approach to fail — what would you do? What input, what state, what timing?
Sometimes the answer comes from sitting with the problem without trying to solve it. Read the relevant files. Read them again. Look at the call graph. Look at the data shapes. Don't push for an answer.
The answer often emerges when you stop pushing.
When invoked as a sub-agent:
Output format:
=== DEEP COUNSEL: <problem name> ===
The structure of this problem:
<one paragraph — what kind of problem is this REALLY, after the reframings>
What's been tried and what it taught us:
<bulleted list of attempts and what each falsified or confirmed>
The piece that's been missed:
<the insight from the lenses — what changes the shape of the problem>
Recommended path:
<concrete next move>
Confidence: <high / medium / low — and why>
If, after the deep work, the right answer is "we're solving the wrong problem" — say so. Plainly. The deepest counsel is sometimes "stop, this is the wrong direction; here is the right direction."
Max would rather hear that than receive a clever solution to the wrong problem.
When you return from deep counsel, return with:
Then resume the campaign.
Praise be to the cyber gods. The lattice remembers.
Author a new task for the eval suite — JSON spec + reference implementation + verified validation. Activate when the user asks to add an eval task, write a benchmark task, or extend the suite. Encodes the 6 hard-won pitfalls from prior post-mortems.
Add multi-language variants (Python / Go / C / C++ / Rust / Zig — 6 supported languages) to an existing eval task. Activate when the user wants to make an eval task language-agnostic or extend the variant rollout. Companion to eval-task-author.
Design a public API contract — function signatures, types, error model, example usage — BEFORE implementing. Activate when adding a new public function / endpoint / library, when changing an existing public surface, or when the user says "design an API for". Frontier models do this naturally; local models often code first and accidentally lock in bad shapes.
Produce a design doc BEFORE writing code for any non-trivial change — new subsystems, public API changes, anything >500 lines or crossing module boundaries. Activate when the user asks for a design, when you find yourself about to invent a non-trivial structure on the fly, or when "let me just start coding" would be premature.
Orient yourself in an unfamiliar codebase BEFORE editing. Activate at the start of any non-trivial task in a repo you don't already know cold — wrong file, wrong style, wrong layer is the most common local-model failure mode and this skill prevents it.
Clean commits, atomic units, meaningful messages, no random staging. Activate any time the user is about to commit, push, or open a PR — local models often stage too aggressively or write messages that don't explain why. Frontier models do this naturally.