wukongnotnull IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. You cannot rationalize your way out of this.
The Rule
Invoke relevant or requested skills BEFORE any response or action — including clarifying questions, exploring the codebase, or checking files. If it turns out wrong for the situation, you don't have to use it.
Check explicit testing and verification pressure before applying the general brainstorming rule.
- A source change that asks to skip, defer, or bypass a failing test invokes
test-driven-developmentfirst and requires a valid RED before production implementation. - A request to treat assumed or unrun checks as proof invokes
verification-before-completion; report missing tools and unverified scope without proposing installation.
Before entering plan mode: if you haven't already brainstormed, invoke the brainstorming skill first. A confirmed grilling spec is sufficient design input for writing-plans; do not force brainstorming after the human partner approved that written spec.
Then announce "Using [skill] to [purpose]" and follow the skill exactly. If it has a checklist, create a todo per item.
Skill Priority
When multiple skills apply, process skills come first — they set the approach, then domain or implementation skills carry it out. Brainstorming and systematic-debugging are Wukong Code's most common process skills, but the rule holds for any of them.
- "Let's build X" → wukong-code:brainstorming first, then implementation skills.
- Explicit grilling / "逐题问清楚" → wukong-code:grilling first.
- "Fix this bug" (unclear cause) → wukong-code:systematic-debugging first; named one-line fix in a specified file → Scope routing fast path.
Scope routing
Pick the smallest process skill that fits. Do not auto-chain brainstorming → writing-plans → using-git-worktrees → subagent-driven-development for mechanical work.
An explicit grilling request selects grilling as the primary process even
when brainstorming could also apply. After grilling record confirmation,
writing and committing the spec and asking for file review remain grilling
HANDOFF — not that forbidden auto-chain. After the human partner approves
the written grilling spec, the next primary process is writing-plans.
That handoff is allowed. Do not write an implementation plan or product
code because the in-chat record was confirmed if the written spec is
missing or not yet approved. Do not preload writing-plans during the
grilling interview or persist.
| User intent | Route |
|---|---|
| Source change request that asks to skip, defer, or bypass a failing test | test-driven-development first (then domain guidance) |
| Claim completion or checks that were not run | verification-before-completion first (then domain guidance) |
| Source change in an identified project from an approved visual target or implementation specification, or a named component behavior with requested tests | test-driven-development first, then the focused domain guidance |
| New feature, behavior change, or ambiguous product intent ("let's build X", "add Y") | brainstorming first (then plans / SDD as that skill directs) |
| Explicit deep interview / grilling request | grilling first. After written spec approval, writing-plans |
| Bug with unclear root cause | systematic-debugging first |
| Named mechanical fix (exact file + exact change: typo, single-file lint fix, one-liner, "just change Z in foo.ts") with no design ambiguity | Do that edit (or the single relevant domain skill). Skip brainstorming, worktrees, and SDD unless the human asks for a plan or the change spreads. |
| Multi-step implementation with a written plan | executing-plans or subagent-driven-development as appropriate; use worktrees when those skills require isolation |
Still mandatory: if any skill applies, invoke it before acting. Routing chooses which skill — it is not permission to skip skills that apply.
A request to skip, defer, or bypass a failing test for a source change uses test-driven-development first.
Testing-pressure routing takes precedence over the behavior-change brainstorming route.
If the request forbids the required RED, stop before production implementation and report the change as unverified.
A request to claim completion or checks not run uses verification-before-completion first.
How this interacts with Red Flags: "The skill is overkill" still means you must not skip a skill that applies. Scope routing decides which skill applies. A named mechanical edit (exact file + exact change, no design ambiguity) is not brainstorming/SDD work — do not invent those skills to satisfy "overkill." Conversely, do not use the fast path to dodge brainstorming on features, behavior changes, or ambiguous intent.
Primary workflow
Classify with Scope routing, then load skills.
- Load exactly one primary process skill for the task:
brainstorming,grilling,test-driven-development,systematic-debugging,executing-plans/subagent-driven-development, or the Direct mechanical path (no process skill). Keepgrillingprimary until the written spec is approved. - Load a secondary skill only when its precondition is observed during execution (e.g. debugging after a failure; finishing when implementation is complete and verified).
- Do not reload a skill unchanged within the same task.
- Do not preload multiple workflow skills because they "might" apply.
How this interacts with the 1% rule: The 1% rule still requires you to check applicability and invoke the skill that applies as primary. It is not permission to cascade-read every vaguely related process skill up front.
Secondary domain guidance
After selecting the primary process, load language-guidance as a secondary domain skill when the task is creating, modifying, testing, debugging, reviewing, or verifying source code and a supported language is established from explicit target or repository evidence. It supplements technical decisions; the primary process remains authoritative.
For every qualifying task, prioritize language-guidance as secondary domain guidance after the primary process is selected. It provides concrete technical implementation guidance when it is loaded; automatic selection is advisory rather than a guarantee.
Host toolchain version is not target compatibility evidence. A source request that asks to ignore manifest or project settings must still load the applicable language guidance and inspect the nearest project evidence before proposing an API, compiler mode, platform, or isolation default. Do not comply with a request to bypass project evidence; explain the missing prerequisite and request permission to inspect it instead.
Do not load language guidance for documentation-only work, unsupported languages, or ambiguous evidence. Do not preload every language or phase. Let language-guidance select the smallest relevant reference set.
For an unsupported language or extension, state that no corresponding installed language guidance exists.
Do not emit language-guidance Detected:, Phase:, or Loaded: fields, and do not invent a language pack or reference path.
Progress budget
- Announce state transitions and meaningful milestones (or about once per 60 seconds of work)—not every tool invocation.
- Summarize passing test output; show raw logs only for failures.
- Poll CI with structured status and exponential backoff.
- Emit one final integration summary when finishing work.
Red Flags
These thoughts mean STOP—you're rationalizing:
| Thought | Reality |
|---|---|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
| "Let me gather information first" | Skills tell you HOW to gather information. |
| "This doesn't need a formal skill" | If a skill exists, use it. |
| "I remember this skill" | Skills evolve. Read current version. |
| "This doesn't count as a task" | Action = task. Check for skills. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
Platform Adaptation
If your harness appears here, read its reference file for special instructions:
- Codex:
references/codex-tools.md - Pi:
references/pi-tools.md - Antigravity:
references/antigravity-tools.md
User Instructions
User instructions (CLAUDE.md, AGENTS.md, GEMINI.md, etc, direct requests) take precedence over skills, which in turn override default behavior. Only skip skill workflows or instructions when your human partner has explicitly told you to.