refactor(skills): separate Expected Outcome from Example Instance and add alias check

Split the combined "example with known optimal solution" into distinct
Example Instance (problem data only) and Expected Outcome (solution/value)
sections across issue templates, check-issue, add-model, propose, and
final-review skills. Differentiates satisfaction (valid config + justification)
from optimization (optimal config + objective value) throughout. Also adds
an alias sanity check to final-review's model completeness checklist.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: GiggleLiu

.claude/skills/add-model/SKILL.md

@@ -26,9 +26,15 @@ Before any implementation, collect all required information. If called from `iss
 | 9 | **Best known exact algorithm** | Complexity with variable definitions | "O(1.1996^n) by Xiao & Nagamochi (2017), where n = \|V\|" |
 | 10 | **Solving strategy** | How it can be solved | "BruteForce works; ILP reduction available" |
 | 11 | **Category** | Which sub-module under `src/models/` | `graph`, `formula`, `set`, `algebraic`, `misc` |
+| 12 | **Expected outcome from the issue** | Concrete outcome for the issue's example instance | Optimization: one optimal solution + optimal value. Satisfaction: one valid/satisfying solution + why it is valid |
 
 If any item is missing, ask the user to provide it. Do NOT proceed until the checklist is complete.
 
+The issue's **Expected Outcome** section is the source of truth for the implementation-facing example.
+- For optimization problems, use the issue's optimal solution and optimal objective value.
+- For satisfaction problems, use the issue's valid / satisfying solution and its justification.
+- Do not invent or replace the expected outcome during implementation unless the issue is corrected first.
+
 ### Associated Rule Check
 
 Before implementation, verify that at least one reduction rule exists or is planned for this problem — otherwise it will be an orphan node in the reduction graph.
@@ -185,14 +191,14 @@ Required tests:
 - `test_<name>_direction` -- verify optimization direction (if optimization problem)
 - `test_<name>_serialization` -- round-trip serde test (optional but recommended)
 - `test_<name>_solver` -- verify brute-force solver finds correct solutions
-- `test_<name>_paper_example` -- **use the same instance from the paper example** (Step 6), verify the claimed solution is valid/optimal and the solution count matches
+- `test_<name>_paper_example` -- **use the same instance from the paper example** (Step 6), verify the issue's expected outcome is valid/optimal and the solution count matches
 
 The `test_<name>_paper_example` test is critical for consistency between code and paper. It must:
 1. Construct the exact same instance shown in the paper's example figure
-2. Evaluate the solution shown in the paper and assert it is valid (and optimal for optimization problems)
+2. Evaluate the solution from the issue's **Expected Outcome** section as shown in the paper and assert it is valid (and optimal for optimization problems)
 3. Use `BruteForce` to find all optimal/satisfying solutions and assert the count matches the paper's claim
 
-This test should be written **after** Step 6 (paper entry), once the example instance and solution are finalized. If writing tests before the paper, use the same instance you plan to use in the paper and come back to verify consistency.
+This test should be written **after** Step 6 (paper entry), once the example instance and expected outcome are finalized. If writing tests before the paper, use the issue's Example Instance + Expected Outcome as the source of truth and come back to verify consistency.
 
 Link the test file via `#[cfg(test)] #[path = "..."] mod tests;` at the bottom of the model file.
 

.claude/skills/check-issue/SKILL.md

@@ -306,7 +306,8 @@ Check all template sections are present and substantive:
 | Schema | Type name, variants, field table |
 | Complexity | Best known algorithm with citation **and** a concrete complexity expression in terms of problem parameters (e.g., `q^n`, `2^{0.8765n}`) |
 | How to solve | At least one solver method checked |
-| Example Instance | Concrete instance with known solution |
+| Example Instance | Concrete instance that exercises the core structure |
+| Expected Outcome | Satisfaction: one valid / satisfying solution with brief justification. Optimization: one optimal solution with the optimal objective value |
 
 Missing or placeholder sections → list them as **Fail** items.
 
@@ -328,7 +329,9 @@ The formal definition must be **precise and implementable**:
 
 - **Non-trivial**: Enough vertices/variables to exercise constraints meaningfully (not just a triangle)
 - **Exercises core structure**: Examples must use the defining features of the problem. For instance, a "MultivariateQuadratic" example that only has linear terms does not exercise the quadratic structure → **Fail**. If the problem's name or definition highlights a specific structural feature (quadratic, k-colorable, bipartite, etc.), at least one example must exercise that feature.
-- **Known optimal solution provided**: Must state the optimal value, not just the instance
+- **Expected outcome provided**:
+  - Satisfaction problems must include a concrete valid / satisfying solution and say why it is valid
+  - Optimization problems must include a concrete optimal solution and the optimal objective value
 - **Detailed enough for paper**: This example will appear in the paper — it needs to be illustrative
 - **Round-trip testable**: The example must be complex enough that a round-trip test (construct instance → solve → verify) can catch implementation bugs. A too-simple instance (e.g., 2 vertices, a single clause) may have a trivially correct solution that passes even with a wrong implementation. The example should have multiple feasible configurations with different objective values (for optimization) or a mix of satisfying and non-satisfying configurations (for satisfaction problems), so that correctness is meaningfully tested. Rule of thumb: the instance should have at least 2 suboptimal feasible solutions in addition to the optimal one.
 

.claude/skills/final-review/SKILL.md

@@ -184,6 +184,7 @@ Verify the PR includes all required components. Check:
 - [ ] Paper section in `docs/paper/reductions.typ` (`problem-def` entry)
 - [ ] `display-name` entry in paper
 - [ ] `trait_consistency.rs` entry in `src/unit_tests/trait_consistency.rs` (`test_all_problems_implement_trait_correctly`, plus `test_direction` for optimization)
+- [ ] Aliases: if provided, verify they are standard literature abbreviations (not made up); if empty, confirm no well-known abbreviation is missing; check no conflict with existing aliases
 
 **For [Rule] PRs:**
 - [ ] Reduction implementation (`src/rules/...`)

.claude/skills/propose/SKILL.md

@@ -312,7 +312,9 @@ Work through these topics in order, using `AskUserQuestion` where multiple-choic
 
    If the user picks "Generate new batch", create 3 new examples with different sizes/structures and re-present.
 
-   After the user picks a concrete example, provide a complete instance with its known optimal solution.
+   After the user picks a concrete example, provide a complete instance with its expected outcome.
+   - For optimization problems: give at least one optimal solution and the optimal objective value
+   - For satisfaction problems: give at least one valid / satisfying solution and explain briefly why it is valid
    - Must exercise the problem's core structure
    - Must be small enough to verify by hand
 
@@ -488,7 +490,7 @@ If the reduction is well-known, use the literature to **pre-fill** answers in St
    - Must define all symbols before using them
    - Must be detailed enough that someone could implement it
 
-3. **Explanation** — Present a correctness argument explaining why the reduction preserves optimal solutions, then ask for feedback via `AskUserQuestion`:
+3. **Explanation** — Present a correctness argument explaining why the reduction preserves feasibility (for satisfaction problems) or optimality (for optimization problems), then ask for feedback via `AskUserQuestion`:
    ```
    AskUserQuestion:
      question: "How does this explanation look?"
@@ -525,7 +527,8 @@ If the reduction is well-known, use the literature to **pre-fill** answers in St
 
    If the user picks "Generate new batch", create 3 new examples with different sizes/structures and re-present.
 
-   After the user picks a concrete example, fully work out the example: show source instance, each construction step, resulting target instance, and the optimal solution.
+   After the user picks a concrete example, fully work out the example: show source instance, each construction step, and the resulting target instance.
+   - Do not ask the user to provide solved witnesses manually
    - Must be non-trivial but hand-verifiable
    - Must exercise the core structure of the reduction
 
@@ -637,14 +640,17 @@ If proposing a model + rules, present all drafts together:
 - Reduction Rule Crossref (linking to companion rule issues or noting planned rules)
 - How to solve (brute-force, ILP, or other — if ILP/QUBO, must cross-reference rule issue)
 - Example Instance
+- Expected Outcome
+  - Optimization problems: optimal solution + optimal objective value
+  - Satisfaction problems: valid / satisfying solution + brief justification
 - BibTeX (include the BibTeX entry for the complexity/definition reference at the end of the issue)
 
 **For rules**, the draft must include:
 - Source, Target, Motivation, Reference (with BibTeX)
 - Reduction Algorithm (numbered steps, all symbols defined)
 - Size Overhead (table with target metrics and formulas)
 - Validation Method
-- Example (fully worked)
+- Example (fully worked: source instance, construction, target instance)
 - BibTeX (include the BibTeX entry for the reference at the end of the issue)
 
 ---
@@ -665,7 +671,7 @@ Apply all 4 checks from `/check-issue` against the draft content:
 1. **Usefulness:** `pred show <name>` must fail (problem doesn't exist). At least one reduction planned.
 2. **Non-trivial:** Not isomorphic to existing problem.
 3. **Correctness:** Complexity expression verified against literature.
-4. **Well-written:** All template sections present, symbols consistent, example exercises core structure.
+4. **Well-written:** All template sections present, symbols consistent, example exercises core structure, and Expected Outcome matches the problem type (valid solution for satisfaction, optimal solution/value for optimization).
 
 **If any check fails:** Fix the draft automatically if possible. If user input is needed, ask. Loop back to Step 4 with the corrected draft.
 

.github/ISSUE_TEMPLATE/problem.md

@@ -83,13 +83,20 @@ Solver is required for reduction rule verification purpose.
 ## Example Instance
 
 <!--
-A small but non-trivial instance with known optimal solution, for testing and the paper.
+A small but non-trivial instance for testing and the paper.
 Should be large enough to exercise the problem's constraints meaningfully (avoid trivial cases like triangle graphs).
-E.g. "Petersen graph: |V|=10, |E|=15, 3-regular. Optimal IS size = 4, and more details.."
+E.g. "Petersen graph: |V|=10, |E|=15, 3-regular."
 
 This example will be shown in our paper, where you could find some references.
 -->
 
+## Expected Outcome
+
+<!--
+Optimization: provide one optimal configuration and its objective value.
+Satisfaction: provide one valid / satisfying configuration and a brief justification.
+-->
+
 ## BibTeX
 
 <!-- Machine-readable citation for the definition/complexity references. E.g.

.github/ISSUE_TEMPLATE/rule.md

@@ -62,12 +62,11 @@ Structure your example as follows:
 1. **Source instance:** Describe the input (e.g. graph, formula, sequence).
 2. **Construction:** Show how each step of the reduction algorithm transforms it.
 3. **Target instance:** Show the resulting target problem data (e.g. QUBO matrix, ILP constraints).
-4. **Optimal solution:** Solve the target, extract back to source, verify optimality.
 
 Must be small enough for brute-force solving, but large enough to exercise the reduction meaningfully.
 Please provide as many details as possible, because
 1. this example will appear in the paper.
-2. AI needs this information to generate example code, run it, and try to compare with what you provided.
+2. AI needs this information to generate example code and derive round-trip tests from it. You do **not** need to provide a solved witness manually.
 
 Please check existing examples in our paper for references.
 -->