Creative Method Selector

Creative Method Selector

Goal

Choose the minimum useful creative method or method sequence for the current problem.

The job of this skill is not to dump frameworks. The job is to classify the problem, pick the right route, and explain why that route fits better than the alternatives.

This skill selects methods. It does not execute the full downstream methodology unless explicitly asked or paired with the selected child skill. It also does not decide whether the whole proposal should proceed; if a proceed / revise / stop verdict is needed, use quality-gate.

Default Posture

• classify before ideating
• prefer one method before many
• prefer staged routing over method pile-up
• match method to problem type, not to taste
• keep the route minimal and explainable

When To Use

Run this skill when:

• the user wants a creative solution but the right method is unclear
• several methodologies could apply and a choice is needed
• the task mixes framing, ideation, contradiction, and systems effects
• the team is stuck and needs a better thinking mode
• a phase transition changes which method should lead

This is a mandatory routing gate before:

• invoking a creativity-related skill family
• combining multiple creative methods in one task
• escalating from simple ideation to a structured innovation workflow

Scope Boundaries

In scope:

• classify the problem
• choose the minimum useful route
• name the next best method or sequence
• explain why competing methods were not chosen

Out of scope by default:

• running the full selected methodology
• generating the final solution itself
• combining many methods "just in case"

Problem Types

Classify the task into one primary type first:

• problem_is_unclear
• need_more_options
• has_contradiction
• thinking_is_stuck
• system_effects_dominate
• need_full_process

Add a secondary type only if it materially changes routing.

Phase Types

Identify the current phase:

• framing
• divergence
• resolution
• validation

If phase is unclear, default to framing.

Core Routing Map

• problem_is_unclear -> jtbd
• need_more_options -> scamper
• has_contradiction -> triz
• thinking_is_stuck -> lateral-thinking
• system_effects_dominate -> systems-thinking
• need_full_process -> creative-problem-solving

Routing Modes

Use one of:

• single
  • one primary method only
• paired
  • one primary method plus one support method
• staged
  • an ordered sequence across phases
• hold
  • pause routing and send the task back to clarification

Decision rule:

• use single when one problem type dominates
• use paired when one secondary type clearly blocks progress
• use staged when the task must move through distinct phases
• use hold when the problem cannot be classified with enough confidence

Pairing Rules

Allowed examples:

• jtbd + scamper
• triz + systems-thinking
• lateral-thinking + creative-problem-solving

Disallowed by default:

• three or more methods at once
• methods with overlapping roles and no order
• any pair without a clear primary method

Staged Routing Rules

Use staged routing when:

• the problem is still vague
• ideation must follow reframing
• contradiction solving must happen after option generation
• systems validation must happen after a candidate solution exists

Example routes:

• jtbd -> scamper
• jtbd -> triz
• jtbd -> scamper -> triz
• triz -> systems-thinking
• lateral-thinking -> creative-problem-solving

Hold Examples

Use hold for cases like:

• Make it more creative somehow.
• Give me a genius solution.
• We need innovation.

In these cases the job, phase, or problem type is too weak to route responsibly.

Non-Creative Exit

If the best next move is not a creativity method at all, say so explicitly.

Examples:

• the problem is mainly implementation and should go to execution
• the issue is missing evidence and should go to validation
• the request is mostly scoping and should go to a non-creative planning path

Method Selection Heuristics

Prefer jtbd when the user is naming a solution before naming the underlying need.

Prefer scamper when a baseline solution exists and the goal is variation or improvement.

Prefer triz when the user wants two conflicting qualities at once or the problem is trapped in a trade-off.

Prefer lateral-thinking when current ideas are all near-duplicates or reasoning is overly linear.

Prefer systems-thinking when local changes create cross-system effects, bottlenecks, or feedback loops.

Prefer creative-problem-solving when the task needs an end-to-end guided process rather than a single tactic.

Fallback Rules

• If the ideal child skill does not exist yet, return the route anyway and mark the missing skill explicitly.
• If two methods seem equally plausible, choose the narrower one first.
• If the task is still underdefined, route to jtbd before anything else.
• If the task is urgent and ambiguity remains high, choose single over paired or staged.

Hold Conditions

Return hold instead of forcing a route when:

• the job to be done is still vague
• the apparent problem is only a proposed solution
• multiple problem types compete and none clearly leads
• the route would require three or more methods immediately
• the requested output is not creativity/method selection but direct execution

Output Contract

Always return:

1. job_to_be_done
2. problem_type
3. secondary_type (none if absent)
4. current_phase
5. routing_mode (single, paired, staged, hold)
6. selected_methods
7. missing_skills (none if absent)
8. why_this_route
9. why_not_others
10. next_action

Guardrails

• Do not pick methods by familiarity or fashion.
• Do not send the task into ideation if the problem is still undefined.
• Do not send the task into triz unless the contradiction is real.
• Do not recommend many methods when one is enough.
• Do not leave the route unordered when using multiple methods.
• Prefer reversible, low-complexity routes first.
• Do not hide uncertainty; use hold when classification quality is weak.

Anti-Patterns

Watch for these failure modes:

• framework dumping
• forcing a creative route when the best next step is non-creative
• using scamper for a root-cause problem
• using triz before the contradiction is named
• using lateral-thinking when the issue is simply poor framing
• using systems-thinking for a purely local design tweak
• choosing a method without naming the problem type
• pretending confidence when the route should have been hold

Example

User request:

We need a better product idea for busy parents, but we're not even sure what problem matters most yet.

Expected shape of response:

1. job_to_be_done: identify the real unmet need before generating solutions
2. problem_type: problem_is_unclear
3. secondary_type: need_more_options
4. current_phase: framing
5. routing_mode: staged
6. selected_methods: jtbd -> scamper
7. missing_skills: none
8. why_this_route: first clarify the job, then generate options against the validated need
9. why_not_others: triz is premature because no contradiction is defined; systems-thinking is unnecessary at this stage
10. next_action: run jtbd to define the user job, desired outcome, and hiring criteria