From customer-insight
Use when research, analysis, evaluation, diagnosis, discovery, insight, or study-design tasks require deciding between qualitative, quantitative, or mixed-methods approaches, especially when the user does not specify a method or the work needs both measurement and explanation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/customer-insight:orchestrating-mixed-methodsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill is a routing and orchestration skill for research and analysis work.
This skill is a routing and orchestration skill for research and analysis work.
It prevents false qualitative vs quantitative either-or framing and chooses the
smallest valid route:
qualitative-onlyquantitative-onlymixed-qual-firstmixed-quant-firstmixed-parallel這個 skill 是研究方法的協調器,不是固定報告格式。 它的工作是先判斷「該用哪種方法、先後順序怎麼排、兩軌怎麼整合」, 而不是每次都硬做成對稱的雙軌輸出。
Use this skill as the default entrypoint when the task involves:
what is happening, how much, why, how, what changed, or what should we testsurvey + interviews, metrics + support tickets, experiment + user quotesqualitative, quantitative, mixed methods, triangulation, interviews, survey, or statistical significanceDo not use this skill when:
If this skill triggers on a clearly single-method task, route it to the proper single method. Do not force mixed methods just because this skill loaded.
Respect explicit user constraints first.
Do not make the user pick between qual and quant when the actual question is
asking for both what/how much and why/how.
Before doing downstream analysis, emit a MethodRoutingDecision.
If the method context is too incomplete to choose safely, emit
MissingMethodContextOutput first.
MethodRoutingDecision:
route: qualitative-only | quantitative-only | mixed-qual-first | mixed-quant-first | mixed-parallel
primary_need: exploration | explanation | measurement | estimation | validation | triangulation
rationale: string
qualitative_capabilities_needed: []
quantitative_capabilities_needed: []
first_pass_outputs: []
second_pass_outputs: []
integration_rule: string
why_not_other_routes: []
MissingMethodContextOutput:
missing_context: []
why_it_matters: []
recommended_default_route: qualitative-only | quantitative-only | mixed-qual-first | mixed-quant-first | mixed-parallel
assumption_if_forced: string
Classify the task on five dimensions in this order:
Read the task through all five dimensions before picking a route. Do not shortcut from one keyword.
Use references/01-routing-rules.md for the full route-selection matrix and tie-breakers.
qualitative-only
quantitative-only
mixed-qual-first
mixed-quant-first
mixed-parallel
This skill must stay capability-based, not skill-name-based. Do not hard-code downstream skill names.
Qualitative capability classes:
Quantitative capability classes:
Map available skills at runtime to these capability classes and choose the smallest set that can complete the route.
MethodRoutingDecision.If the task is broad but only one evidence type is available:
Example:
why did retention drop and how large is the drop but only
gives metrics, route to mixed-quant-first with a quantitative first pass and
a qualitative follow-up recommendation.mixed-qual-first and keep the quantitative phase as a downstream
validation step.Never do the following:
mixed methods as always output two equal sectionsWhen mixed evidence conflicts, report the contradiction directly and test likely causes such as sample mismatch, timeframe mismatch, construct mismatch, measurement artifact, or segment heterogeneity.
Use $orchestrating-mixed-methods to choose the right qualitative,
quantitative, or mixed-methods route for this research task, emit a
MethodRoutingDecision, and explain the sequencing without forcing a false
either-or choice.
Guides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.
npx claudepluginhub timlai666/skills --plugin customer-insight