update skills

Author: GiggleLiu

.claude/skills/find-problem/SKILL.md

@@ -33,9 +33,13 @@ Step 3: Rank and Present (table ranked by effective complexity, web search for a
 Step 4: Generate Solution Doc (docs/solutions/<name>.md)
 ```
 
+## Prerequisites
+
+Build the CLI tools before starting: `make cli` (builds `pred` and `pred-sym`). All commands below assume `pred` and `pred-sym` are available via `cargo run -p problemreductions-cli --bin pred --` and `cargo run -p problemreductions-cli --bin pred-sym --` respectively.
+
 ## CRITICAL: Output Visibility
 
-Bash tool results are hidden from the user in the Claude Code UI. **After every `pred` command, you MUST copy-paste the full stdout/stderr into your response as text.** The pattern for every command is:
+Bash tool results are hidden from the user in the Claude Code UI. **After every `pred` / `pred-sym` command, you MUST copy-paste the full stdout/stderr into your response as text.** The pattern for every command is:
 
 1. Announce the command and why: "Let me run `pred to MIS --hops 3` to discover all problems that can reduce to MIS:"
 2. Run the command via the Bash tool
@@ -73,20 +77,23 @@ Never skip step 1 or 3.
 
 2. **For each discovered problem**, run:
    - `pred path <source> <model>` — get the cheapest witness-capable reduction path
+   - **IMPORTANT:** Use the exact variant-qualified name from `pred to` output (e.g., `SpinGlass/SimpleGraph/f64`, not bare `SpinGlass`). Bare names resolve to the default variant, which may differ from the reachable variant and cause false "no path" errors.
    - `pred show <source>` — get best-known brute-force complexity
 
 3. **Compute effective complexity** for each source problem:
    - Take the user's solver complexity expression (e.g., `O(1.1996^num_vertices)`)
    - Substitute the overhead expressions from the reduction path into the solver's variables
    - Example: if MVC→MIS has overhead `num_vertices = num_vertices`, then solving MVC via MIS costs `O(1.1996^num_vertices)` — same as MIS
    - Example: if overhead is `num_vertices = num_clauses * 3`, then effective complexity is `O(1.1996^(3 * num_clauses))`
+   - **Use `pred-sym` to verify:** after manual substitution, run `pred-sym big-o "<effective_expr>"` to normalize the expression. Use `pred-sym eval --vars <bindings> "<expr>"` at a concrete size (e.g., n=20) to numerically verify the simplification.
 
 4. **Compare to best-known**: for each source, compare effective complexity to the source's own best-known complexity from `pred show`. Classify as:
    - **Better** — effective complexity has a smaller base or exponent than best-known
    - **Similar** — comparable asymptotic behavior
    - **Worse** — effective complexity exceeds best-known (reduction overhead makes it impractical)
+   - **When effective and best-known use different variables** (e.g., `O(1.5^num_subsets)` vs `O(2^universe_size)`): this happens when a problem has multiple independent size fields and the best-known algorithm's dominant variable differs from the reduction overhead's. In this case, use `pred-sym eval` at representative concrete values to determine the comparison. State the result conditionally: "Better when num_subsets ≤ c·universe_size" with the crossover ratio.
 
-5. **Web search** each discovered source problem + "applications" or "real-world" to find practical use cases. Use `WebSearch` tool.
+5. **Web search** only the **Better** and **Similar** candidates for real-world applications (not the Worse ones). Use `WebSearch` tool with query "<problem name> real-world applications".
 
 **If `--hops 3` returns more than 15 results:** present only the top 10 by effective complexity and mention the rest are available if the user wants to see them.
 
@@ -98,12 +105,12 @@ Never skip step 1 or 3.
 
 **Goal:** Show all discovered problems ranked by practical usefulness.
 
-Present a ranked table (most practical first):
+Present a ranked table (most practical first). **Mark a recommendation** — highlight the "Better" entries as the most valuable discoveries:
 
 | # | Problem | Hops | Overhead | Effective Complexity | vs Best-Known | Applications |
 |---|---------|------|----------|---------------------|---------------|--------------|
-| 1 | MinimumVertexCover | 1 | same size | O(1.1996^n) | Better | Network monitoring |
-| 2 | MaximumClique | 2 | complement graph | O(1.1996^n) | Better | Social network cliques |
+| 1 | **MinimumVertexCover** | 1 | same size | O(1.1996^n) | **Better** | Network monitoring |
+| 2 | **MaximumClique** | 2 | complement graph | O(1.1996^n) | **Better** | Social network cliques |
 | 3 | GraphColoring | 3 | n^2 vars | O(1.1996^(n^2)) | Worse | Register allocation |
 
 Ask using `AskUserQuestion`: "Which problems would you like included in the solution doc? Pick numbers, or 'all practical' for only the Better/Similar ones."
@@ -124,6 +131,8 @@ Where:
 
 Ask the user to confirm the filename before writing.
 
+**Before writing the doc**, run `pred create <Source> --help` for each selected problem to verify the correct CLI flag names. Use the flags exactly as shown in the help output.
+
 **Doc template — write all sections:**
 
 ```markdown
@@ -168,16 +177,19 @@ pred solve bundle.json --solver ilp --timeout 60
 **After writing the doc:**
 
 1. Show the user the generated filename and a brief summary of what's in it.
-2. Ask if they want to make any changes before finishing.
+2. **If a built-in solver covers the model** (brute-force or ILP), offer to run a live demo with one of the "Better" problems: "Want me to run an example end-to-end so you can see it in action?"
+3. Ask if they want to make any changes before finishing.
 
 ---
 
 ## Key Behaviors
 
 - **One question at a time.** Never ask multiple questions in one message. Use `AskUserQuestion` for every decision point.
-- **Web search before presenting applications.** In Step 2, web search each discovered problem for real-world use cases. Never guess applications from internal knowledge alone.
+- **Web search only Better/Similar candidates.** In Step 2, web search only the problems classified as Better or Similar for real-world use cases. Skip Worse ones unless the user asks for all. Never guess applications from internal knowledge alone.
 - **Show full output.** After every Bash tool call, copy-paste the COMPLETE output into your text response as a fenced code block. Bash tool results are hidden in the UI.
 - **Announce every command.** Before running, say what command you're using and why.
+- **Always use variant-qualified names in `pred path`.** When `pred to` returns names like `SpinGlass/SimpleGraph/f64`, use that exact string in subsequent `pred path` calls. Bare names (e.g., `SpinGlass`) resolve to the default variant, which may differ from the reachable variant and cause false "no path" errors.
+- **Recommend, don't just list.** When presenting the ranked table in Step 3, bold the "Better" entries as the most valuable discoveries. The user can still pick freely.
 - **Compact formatting.** Write explanations as plain paragraphs. Do not use blockquote `>` syntax for explanations. Keep tight: command announcement, code block output, 1-3 sentence explanation.
 - **Conversational tone.** Guided consultation, not a lecture.
 - **Live execution.** Every `pred` command runs for real. No fake output.

.claude/skills/find-solver/SKILL.md

@@ -96,9 +96,16 @@ Use `AskUserQuestion` for each question. Format options as **(a)**/**(b)**/**(c)
 | 2 | ... | ... | ... |
 | 3 | ... | ... | ... |
 
+**Include a recommendation:** Bold or mark the option you think is the best fit, with a brief reason why.
+
 4. For each candidate, run `pred show <model>` and show the output — fields, complexity, available reductions. This helps the user see what data they would need to provide.
 
-5. **Ask the user to pick one** using `AskUserQuestion`. If none fit, ask the user for more detail and re-run the web search with refined keywords.
+5. **Check optimization vs decision mismatch.** If the user's goal is "minimize X" or "maximize X" but the matched model is a decision/feasibility problem (Value = `Or`, fields include a `deadline`/`bound`), explain the gap:
+   - "This model checks feasibility ('can it be done within bound D?'), not optimization directly."
+   - "To find the optimum, we'll binary search on the bound parameter."
+   - This is common for scheduling problems (deadline), knapsack (bound), etc.
+
+6. **Ask the user to pick one** using `AskUserQuestion`. If none fit, ask the user for more detail and re-run the web search with refined keywords.
 
 **Proceed to Step 3 with the chosen model.**
 
@@ -114,17 +121,20 @@ Use `AskUserQuestion` for each question. Format options as **(a)**/**(b)**/**(c)
 
 2. **For each reachable problem**, gather info:
    - Run `pred path <model> <target>` to get the cheapest witness-capable reduction path and composed overhead
+   - **IMPORTANT:** Use the exact variant-qualified name from `pred from` output (e.g., `SpinGlass/SimpleGraph/f64`, not bare `SpinGlass`). Bare names resolve to the default variant, which may differ from the reachable variant and cause false "no path" errors.
    - Run `pred show <target>` to get its best-known complexity
    - Check if it's a solver-ready target (ILP, QUBO, SAT) or has a path to one via `pred path <target> ILP`
 
-3. **Present a ranked table** (most practical paths first — fewest hops, lowest overhead):
+3. **Present a ranked table** (most practical paths first — fewest hops, lowest overhead). **Mark a recommendation** for the most practical path:
 
    | # | Target | Hops | Composed Overhead | Target Complexity | Solver-Ready? |
    |---|--------|------|-------------------|-------------------|---------------|
    | 1 | ILP | 2 | num_vars = 2*n + m | O(2^num_vars) | Yes (is ILP) |
    | 2 | QUBO | 1 | num_vars = n | O(2^num_vars) | Yes (is QUBO) |
    | 3 | MaxSetPacking | 1 | num_sets = n | O(2^num_sets) | Yes (ILP in 2 steps) |
 
+   When overhead grows significantly between options (e.g., linear vs quadratic), note the practical implication: "QUBO adds quadratic variable blowup — prefer this only if targeting quantum/annealing hardware."
+
 4. **Ask the user** using `AskUserQuestion`: "Which reduction path would you like to use? Pick a number."
 
 **If `pred from --hops 3` returns more than 15 results:** present only the top 10 by overhead and mention the rest are available.
@@ -222,7 +232,23 @@ pred solve step_N.json --solver ilp --timeout 60
 ```
 
 <Explain what the output means for the user's original problem.
-E.g., "Max(3) means the maximum independent set has 3 vertices.">
+E.g., "Max(3) means the maximum independent set has 3 vertices."
+For decision problems: "Or(true) means a feasible solution exists within the bound.">
+
+## Finding the Optimum (decision models only)
+
+<Include this section when the matched model is a decision/feasibility problem (Value = Or)
+with a bound parameter like `deadline`, `bound`, or `capacity`.>
+
+The model checks feasibility ("can it be done within bound D?"), not optimization directly.
+To find the minimum/maximum, binary search on the bound parameter:
+
+```bash
+# Binary search for minimum deadline
+# Upper bound: sum of all task lengths (trivially feasible with 1 processor)
+# Lower bound: max(longest task, ceil(total / num_processors))
+# Try midpoint, narrow based on Or(true)/Or(false)
+```
 
 ## Solution Extraction
 
@@ -269,7 +295,8 @@ pred evaluate input.json --config <solution_vector>
 **After writing the doc:**
 
 1. Show the user the generated filename and a brief summary of what's in it.
-2. Ask if they want to make any changes before finishing.
+2. **If a built-in solver covers the chosen path** (brute-force or ILP), offer to run a live demo with the example instance: "Want me to run the example end-to-end so you can see it in action?"
+3. Ask if they want to make any changes before finishing.
 
 ---
 
@@ -279,9 +306,12 @@ pred evaluate input.json --config <solution_vector>
 - **Web search before recommendations.** In Step 2 (model matching) and Step 4 (solver recommendation), always web search first. Never rely on internal knowledge alone.
 - **Show full output.** After every Bash tool call, copy-paste the COMPLETE output into your text response as a fenced code block. Bash tool results are hidden in the UI.
 - **Announce every command.** Before running, say what command you're using and why.
+- **Always use variant-qualified names in `pred path`.** When `pred from` returns names like `SpinGlass/SimpleGraph/f64`, use that exact string in subsequent `pred path` calls. Bare names (e.g., `SpinGlass`) resolve to the default variant, which may differ from the reachable variant and cause false "no path" errors.
+- **Recommend, don't just list.** When presenting options (models in Step 2, paths in Step 3, solvers in Step 4), always bold or mark your recommended choice with a brief reason. The user can still pick freely.
 - **Compact formatting.** Write explanations as plain paragraphs. Do not use blockquote `>` syntax for explanations. Keep tight: command announcement, code block output, 1-3 sentence explanation.
 - **Conversational tone.** Guided consultation, not a lecture.
 - **Live execution.** Every `pred` command runs for real. No fake output.
 - **Graceful fallbacks.** If a path doesn't exist or a command fails, explain what happened and suggest alternatives (try another model, use brute-force, backtrack).
 - **Adapt to user level.** If the user gives a formal problem name, skip clarification. If they describe a fuzzy real-world problem, ask follow-ups one at a time.
 - **Use `--timeout 30`** with `pred solve` in any live demos during the session.
+- **Doc template sections are conditional.** "Finding the Optimum" only applies to decision models. "External Solver Alternatives" only applies when external solvers were chosen. "Solution Extraction" can be folded into "Solving" when the bundle workflow handles it automatically.

.gitignore

@@ -93,3 +93,4 @@ docs/superpowers/
 docs/src/reductions/*.json
 .claude/projects/
 docs/research/
+docs/solutions/

README.md

@@ -42,6 +42,10 @@ make cli    # builds target/release/pred
 
 See the [Getting Started](https://codingthrust.github.io/problem-reductions/getting-started.html) guide for usage examples, the reduction workflow, and [CLI usage](https://codingthrust.github.io/problem-reductions/cli.html).
 
+**Have a problem and looking for a solver?** Run `/find-solver` — it matches your real-world problem to a library model, explores reduction paths, and recommends solvers.
+
+**Have a solver and wondering what it can solve?** Run `/find-problem` — given a solver for a specific model, it discovers all other problems reachable via incoming reductions, ranked by effective complexity.
+
 Try a model directly from the CLI:
 
 ```bash