Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Classify any user request into a structured format for prompt generation. Use this skill whenever you need to understand what type of task a request represents, determine complexity, decide whether planning is needed, or route a request to the right skills and agent strategy. Trigger on: any request that needs to be analyzed before generating a Claude Code prompt, when someone says 'classify this', 'what kind of task is this', when the prompt-generator or prompt-router skills need input classifi
.claude/skills/majiayu000-request-classifier/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-03 | ✗→✓ | ▲ Improved | 326% | 0% |
| case-01 | ✗→✓ | ▲ Improved | 247% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 282% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 299% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 226% | 0% |
Classify a user request into a structured JSON object that downstream skills (prompt-router, prompt-generator) use to decide: what type of task this is, how complex it is, and whether to enter plan mode before generating a Claude Code prompt.
Read the full taxonomy at references/taxonomy.md before classifying. It contains the complete keyword lists, scoring rules, and decision tree. The sections below give you the process and worked examples.
Extract the raw text of the user's request. If the request is embedded in a longer conversation, focus on the most recent action request, not background context.
Read references/taxonomy.md. Pay attention to:
Match keywords and signals against the 8 types in priority order:
When multiple types match, use the priority order above. pipeline beats feature; bug-fix beats improvement.
Use the four scoring dimensions from the taxonomy:
Add any amplifiers (contains "across", "all", "entire", cross-backend+frontend). Cap at 10.
Map to level: 1–3 = simple, 4–6 = medium, 7–10 = complex.
Check for explicit overrides first ("no plan" → off; "plan first" → on). Then:
Select the plan type from the type→plan_type mapping in the taxonomy.
Emit the JSON using the schema in references/taxonomy.md. Every field must be present. Use null (not "") for absent optional values.
If two types are plausible and the priority ordering doesn't resolve them clearly, explain your reasoning briefly before the JSON, and optionally ask the user to confirm. Do not silently guess when both interpretations would lead to meaningfully different outcomes.
"Fix AND improve" — When a request bundles a bug fix with an enhancement, pick the primary action. If the fix is driving the request ("the page is broken, and while you're there clean up the CSS"), classify as bug-fix. If improvement is primary ("refactor the grid and also fix that one null check"), classify as improvement. Note both in keywords_matched.
"Investigate then fix" — A request that asks for root-cause analysis before fixing is research (the research is the deliverable; the fix is implied future work). Example: "Figure out why extractions are timing out and document your findings" = research, not bug-fix.
"Frontend feature with new API" — A feature that requires both a new endpoint and new UI is feature, not frontend. frontend is reserved for UI-only changes with no backend modification.
"Rename all occurrences across the codebase" — The word "all" and "across" are amplifiers, but if the action is still mechanical (find/replace a symbol name), it remains quick-task with a higher complexity score (score 4–5). A rename is still a rename even if it touches many files.
"Add docs for X" — documentation even if X is technically complex. The task itself is writing, not engineering.
"Investigate and then implement" — Two-part requests: if both parts are non-trivial, classify by the heavier phase. Investigation + implementation = research if framed as "figure out the right approach first," or feature if the implementation is the dominant concern.
Explicit user preferences in the request text always take precedence over automatic detection.
| User says | Effect | |-----------|--------| | "no plan", "skip planning", "just do it", "don't plan" | Force plan_mode: false, plan_type: null | | "with planning", "plan first", "plan mode", "think this through" | Force plan_mode: true, set plan_type by type | | "treat this as a quick task" | Override type to quick-task | | "this is complex, treat it accordingly" | Add +2 to complexity score |
Set override: "on" or override: "off" in the output JSON when an override is detected. Set override: null otherwise.
Each example shows the request, the classification reasoning, and the output JSON.
Request: "Rename extract_items to extract_acm_items"
Reasoning:
quick-task — "rename" is a primary keyword; 5-word request; single action on a function namejson{ "request_type": "quick-task", "complexity": { "score": 1, "level": "simple", "reasoning": "Single mechanical rename action, one function name across likely 1-2 files." }, "plan_mode": false, "plan_type": null, "keywords_matched": ["rename"], "files_mentioned": [], "domain_signals": ["extraction"], "override": null }
Request: "The correction node is running on every extraction even when confidence is 100%. Fix it — it's wasting tokens and slowing things down."
Reasoning:
bug-fix — "fix" is primary; "running when it shouldn't" is a classic should-but-doesn't signal; "wasting tokens/slowing down" are symptomsjson{ "request_type": "bug-fix", "complexity": { "score": 3, "level": "simple", "reasoning": "Clear bug with a known symptom; likely 2-3 files in the pipeline layer." }, "plan_mode": true, "plan_type": "debug", "keywords_matched": ["fix", "running when it shouldn't"], "files_mentioned": [], "domain_signals": ["pipeline", "langgraph", "extraction"], "override": null }
Request: "Add a CSV export button to the item grid that calls a new /api/acm/export endpoint and streams the file download using SSE."
Reasoning:
feature — "add" + new capability + new endpoint mentionedjson{ "request_type": "feature", "complexity": { "score": 9, "level": "complex", "reasoning": "Cross-cutting: new frontend component, API hook, and new backend endpoint with SSE streaming." }, "plan_mode": true, "plan_type": "full", "keywords_matched": ["add", "new", "endpoint", "streams"], "files_mentioned": ["frontend/src/components/acm/", "api/routers/"], "domain_signals": ["frontend", "fastapi", "extraction"], "override": null }
Request: "Investigate why the orchestrator is making 3 LangGraph LLM calls when the structure stage should only need 1. Check Langfuse traces for the last 10 runs and document findings."
Reasoning:
research — "investigate", "why", "check traces", "document findings" all point to knowledge-gathering, not implementationjson{ "request_type": "research", "complexity": { "score": 7, "level": "complex", "reasoning": "Open-ended investigation spanning graph code, observability traces, and a written deliverable." }, "plan_mode": true, "plan_type": "research", "keywords_matched": ["investigate", "why", "check", "document findings"], "files_mentioned": [], "domain_signals": ["langgraph", "pipeline", "observability"], "override": null }
Request: "Refactor the pre-extraction stages to reduce LLM calls. The structure and preflight nodes are making redundant calls — consolidate them."
Reasoning:
improvement — "refactor", "reduce", "consolidate" are primary; no broken behavior impliedjson{ "request_type": "improvement", "complexity": { "score": 4, "level": "medium", "reasoning": "Refactor within the pipeline layer; 2-3 node files, no cross-layer changes." }, "plan_mode": true, "plan_type": "refactor", "keywords_matched": ["refactor", "reduce", "consolidate"], "files_mentioned": [], "domain_signals": ["pipeline", "langgraph"], "override": null }
Request: "Add a caching layer to the extraction graph so that if the same PDF has been processed before, we skip Docling and return cached results from SurrealDB."
Reasoning:
pipeline — "extraction graph", caching within the graph, affects ExtractionState flow; pipeline takes priority over featurejson{ "request_type": "pipeline", "complexity": { "score": 5, "level": "medium", "reasoning": "Graph-layer change with cache lookup logic; touches extraction state and DB layer." }, "plan_mode": true, "plan_type": "full", "keywords_matched": ["extraction graph", "caching", "skip", "cached results"], "files_mentioned": ["open_notebook/graphs/acm_extraction.py"], "domain_signals": ["pipeline", "langgraph", "surrealdb"], "override": null }
Request: "Change the Export button color in ItemGrid to match the Tailwind blue-600 design token."
Reasoning:
frontend — component, CSS, Tailwind; no backendjson{ "request_type": "frontend", "complexity": { "score": 1, "level": "simple", "reasoning": "Single CSS color change in one component file." }, "plan_mode": false, "plan_type": null, "keywords_matched": ["button", "color", "Tailwind"], "files_mentioned": ["frontend/src/components/acm/ItemGrid"], "domain_signals": ["frontend"], "override": null }
Request: "Update CLAUDE.md to document the new plan mode decision tree and add a section explaining how the request-classifier skill works."
Reasoning:
documentation — "update", "document", ".md" file, "explaining how" are all documentation signalsjson{ "request_type": "documentation", "complexity": { "score": 1, "level": "simple", "reasoning": "Single markdown file update with two new sections." }, "plan_mode": false, "plan_type": null, "keywords_matched": ["update", "document", "explaining"], "files_mentioned": ["CLAUDE.md"], "domain_signals": ["configuration"], "override": null }
Request: "Add error boundary components to every page in the app — just do it, no plan needed."
Reasoning:
feature — "add" + new componentsjson{ "request_type": "feature", "complexity": { "score": 7, "level": "complex", "reasoning": "Touches every page file in the app; 5+ components to update." }, "plan_mode": false, "plan_type": null, "keywords_matched": ["add", "every", "no plan needed"], "files_mentioned": ["frontend/src/app/"], "domain_signals": ["frontend"], "override": "off" }
Request: "The building sidebar is slow to render when there are 50+ buildings — fix the performance issue and while you're at it, refactor it to use React.memo and virtualization."
Reasoning:
bug-fixjson{ "request_type": "bug-fix", "complexity": { "score": 4, "level": "medium", "reasoning": "Performance bug in one component; fix is primary, refactor is secondary work bundled in." }, "plan_mode": true, "plan_type": "debug", "keywords_matched": ["fix", "slow", "performance", "refactor"], "files_mentioned": ["frontend/src/components/acm/BuildingSidebar"], "domain_signals": ["frontend"], "override": null }
This skill's JSON output is consumed by:
request_type, plan_mode, and complexity.level to route to the correct prompt templateThe classification must be accurate because downstream skills do not re-classify; they trust this output.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-03 | fail→pass | 12,464 | 15,848 | +27% | 1 | 1 | 0% | 1,472 | 6,277 | +326% | 0 | 0 | — |
case-01 | fail→pass | 13,142 | 11,445 | -13% | 1 | 1 | 0% | 1,557 | 5,409 | +247% | 0 | 0 | — |
case-02 | fail→pass | 12,942 | 16,374 | +27% | 1 | 1 | 0% | 1,582 | 6,044 | +282% | 0 | 0 | — |
case-04 | pass→fail | 19,997 | 14,596 | -27% | 1 | 1 | 0% | 2,471 | 6,026 | +144% | 0 | 0 | — |
case-05 | pass→fail | 21,442 | 9,514 | -56% | 1 | 1 | 0% | 3,570 | 4,961 | +39% | 0 | 0 | — |
case-06 | pass→fail | 22,100 | 18,260 | -17% | 1 | 1 | 0% | 3,015 | 6,669 | +121% | 0 | 0 | — |
case-07 | fail→pass | 11,864 | 12,598 | +6% | 1 | 1 | 0% | 1,396 | 5,576 | +299% | 0 | 0 | — |
case-08 | fail→pass | 13,955 | 12,248 | -12% | 1 | 1 | 0% | 1,717 | 5,605 | +226% | 0 | 0 | — |
case-09 | fail→pass | 12,586 | 10,483 | -17% | 1 | 1 | 0% | 1,388 | 5,156 | +271% | 0 | 0 | — |
case-10 | fail→pass | 11,295 | 10,649 | -6% | 1 | 1 | 0% | 1,268 | 5,249 | +314% | 0 | 0 | — |
case-11 | fail→pass | 11,379 | 13,137 | +15% | 1 | 1 | 0% | 1,210 | 5,473 | +352% | 0 | 0 | — |
case-12 | fail→pass | 12,912 | 12,175 | -6% | 1 | 1 | 0% | 1,369 | 5,567 | +307% | 0 | 0 | — |
case-13 | fail→pass | 11,777 | 10,778 | -8% | 1 | 1 | 0% | 1,221 | 5,390 | +341% | 0 | 0 | — |
case-14 | fail→pass | 12,388 | 12,864 | +4% | 1 | 1 | 0% | 1,363 | 5,719 | +320% | 0 | 0 | — |
case-15 | fail→pass | 10,178 | 12,370 | +22% | 1 | 1 | 0% | 902 | 5,655 | +527% | 0 | 0 | — |
case-16 | fail→pass | 13,964 | 28,315 | +103% | 1 | 1 | 0% | 1,603 | 8,846 | +452% | 0 | 0 | — |
case-17 | fail→pass | 10,032 | 7,642 | -24% | 1 | 1 | 0% | 900 | 5,617 | +524% | 0 | 0 | — |
case-18 | fail→pass | 13,880 | 14,353 | +3% | 1 | 1 | 0% | 1,549 | 5,962 | +285% | 0 | 0 | — |
case-19 | fail→pass | 8,116 | 5,236 | -35% | 1 | 1 | 0% | 1,563 | 5,197 | +233% | 0 | 0 | — |
case-20 | fail→pass | 6,940 | 12,834 | +85% | 1 | 1 | 0% | 1,336 | 5,586 | +318% | 0 | 0 | — |
case-21 | fail→pass | 7,679 | 12,831 | +67% | 1 | 1 | 0% | 1,427 | 6,668 | +367% | 0 | 0 | — |
case-22 | fail→pass | 9,955 | 10,762 | +8% | 1 | 1 | 0% | 876 | 5,283 | +503% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +71 percentage points is the difference between those two pass rates over the 22 comparable cases. 3 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.