feat(query): generalize hybrid business wiki routing

.skills/wiki-query/SKILL.md

@@ -76,24 +76,33 @@ If it is a business facts query:
 4. If the template or guarded SQL returns an answer, answer from that JSON result as structured business facts. Do not cite wiki pages unless you also used wiki pages for business context. Mention stale sync warnings when `is_stale` is true.
 5. If the CLI/database is unavailable or the question is not a business facts query, continue with the normal wiki retrieval protocol below.
 
-### Step 1b: Hybrid Business + Wiki Route (subagent split)
+### Step 1b: Hybrid Business + Wiki Route (portable two-track)
 
 Do not use hybrid mode when filtered mode is active. In filtered mode, skip business facts entirely and continue with ordinary filtered wiki-query retrieval.
 
-Use hybrid mode when the user asks for an entity overview, situation, background, profile, current status, or "大体情况" where both wiki context and business facts would materially improve the answer. Common examples: customer overview with recent orders, customer relationship status, product situation with order signals, salesperson activity with related customers/projects, or "告诉我一下某某客户的大体情况".
+Use hybrid mode when the user's question needs both structured business facts and wiki context to answer well. This is not customer-specific. Treat these as common hybrid categories:
 
-For a hybrid query, spawn two subagents when the platform supports subagents:
+- customer/account health — orders, sales, trends, main products, relationship history, risks, and open opportunities
+- product/material situation — quantity, sales, customer spread, recent orders, specs, quality records, competitors, and application context
+- salesperson/team activity — sales amount, order count, active customers/products, related projects, and follow-up context
+- project progress with commercial signal — wiki project status plus related orders, products, customers, or delivery plans
+- delivery risk — planned delivery dates/quantities, order status, customer urgency, project milestones, and historical delay signals
+- anomaly explanation — business trend/ranking changes plus wiki evidence such as emails, complaints, quality issues, project pauses, or relationship changes
+- TOP ranking context — ranked customers/products/salespeople/projects plus wiki explanation of why they matter and what needs attention
+- quality or complaint impact — wiki quality/complaint records plus affected customers, products, orders, quantities, sales, or trends
 
-1. **ordinary wiki-query subagent** — run the normal wiki-query retrieval path only. Do not use business facts. Return concise narrative context with wiki citations: customer/project background, relationships, email-derived signals, risks, open questions, and pages consulted.
-2. **business facts query subagent** — run only the business facts route. Load `obsidian-wiki business schema --json`, prefer templates such as `customer_summary`, `customer_order_list`, `breakdown_by_product` with `--customer`, `order_trend`/`sales_trend` with customer filters, or guarded `business sql` when no template fits. Return structured metrics, rows, `last_sync`, and `is_stale`.
+For a hybrid query, run two independent tracks; parallel subagents are optional. Use them when the host platform supports reliable subagents; otherwise run the same tracks sequentially in this agent and then merge the results.
 
-The main agent must wait for both tracks, then fuse the two results into one answer:
+1. **ordinary wiki-query track** — run the normal wiki-query retrieval path only. Do not use business facts. Return concise narrative context with wiki citations: customer/project/product background, relationships, email-derived signals, quality or complaint history, risks, open questions, and pages consulted.
+2. **business facts query track** — run only the business facts route. Load `obsidian-wiki business schema --json`, prefer templates such as `customer_summary`, `product_summary`, `staff_summary`, `customer_order_list`, `product_order_list`, `staff_order_list`, `top_customers`, `top_products`, `top_staff`, `top_projects`, `delivery_plan_list`, `order_trend`, `sales_trend`, `breakdown_by_product`, `breakdown_by_customer`, `breakdown_by_staff`, or guarded `business sql` when no template fits. Return structured metrics, rows, `last_sync`, and `is_stale`.
 
-- Lead with the business snapshot when available: recent order count, sales amount, main products, latest orders, trend, and data freshness.
-- Then add wiki context: who the customer is, related projects/products, important relationship history, risks, and citations.
+The answering agent must wait for both tracks when they run in parallel, or finish both sequential tracks before answering. Then fuse the two results into one answer:
+
+- Lead with the business snapshot when available: relevant counts, sales amount, quantities, rankings, latest orders, delivery signals, trend, and data freshness.
+- Then add wiki context: entity background, related projects/products/customers, important relationship history, quality or complaint signals, risks, and citations.
 - Keep business numbers separate from narrative claims; cite wiki pages only for wiki-derived statements.
 - If one track fails or has no data, still answer from the other track and state that gap.
-- If subagents are not available, run the same two tracks sequentially and mention only material limitations, not internal tooling details.
+- Do not mention whether the tracks ran as subagents or sequentially; mention only material data limitations.
 
 ### Step 2: Index Pass (cheap)