القائمة
Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when implementing any feature or bugfix, before writing implementation code
Use when executing implementation plans with independent tasks in the current session
Use when creating new skills, editing existing skills, or verifying skills work before deployment
You MUST use this before creative or behavior-changing work — creating features, building components, adding functionality, modifying behavior, or ambiguous product intent. Explores user intent, requirements and design before implementation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
استنادا إلى تصنيف SOC المهني
| name | using-wukong-code |
| description | Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions |
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.
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.
Before entering plan mode: if you haven't already brainstormed, invoke the brainstorming skill first.
Then announce "Using [skill] to [purpose]" and follow the skill exactly. If it has a checklist, create a todo per item.
When multiple skills apply, process skills come first — they set the approach, then implementation skills (frontend-design, etc.) carry it out. Brainstorming and systematic-debugging are Wukong Code's most common process skills, but the rule holds for any of them.
Pick the smallest process skill that fits. Do not auto-chain brainstorming → writing-plans → using-git-worktrees → subagent-driven-development for mechanical work.
| User intent | Route |
|---|---|
| New feature, behavior change, or ambiguous product intent ("let's build X", "add Y") | brainstorming first (then plans / SDD as that skill directs) |
| 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.
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.
Classify with Scope routing, then load skills.
brainstorming, systematic-debugging, executing-plans / subagent-driven-development, or the Direct mechanical path (no process skill).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.
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. |
If your harness appears here, read its reference file for special instructions:
references/codex-tools.mdreferences/pi-tools.mdreferences/antigravity-tools.mdUser 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.