update

Author: GiggleLiu

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

@@ -39,12 +39,18 @@ digraph check_issue {
 ### Step 0: Fetch and Parse Issue
 
 ```bash
-gh issue view <NUMBER> --json title,body,labels
+gh issue view <NUMBER> --json title,body,labels,comments
 ```
 
 - Detect issue type from title: `[Rule]` or `[Model]`
 - If neither, stop with message: "This skill only checks [Rule] and [Model] issues."
 
+#### Duplicate Check Detection
+
+Before running checks, scan existing comments for a previous `## Issue Quality Check` heading. If found:
+- **Default:** Skip and report: "Already checked (comment from YYYY-MM-DD). Use `/check-issue <NUMBER> --force` to re-check."
+- **`--force` flag:** Proceed with re-check. Post the new report as "Re-check" and note any changes from the previous report (e.g., "Previously: 2 warnings → Now: 0 warnings after issue edits").
+
 ---
 
 # Part A: Rule Issue Checks
@@ -200,12 +206,16 @@ Applies when the title contains `[Model]`.
    ```
    If it succeeds, the problem **already exists** → **Fail** ("Problem already implemented").
 
-3. Check **Motivation** field:
+3. Check **planned reductions** — the issue must mention at least one concrete reduction rule connecting this problem to the existing graph:
+   - Look for explicit statements like "reduces to/from X", "interreducible with Y", or references to planned `[Rule]` issues
+   - If **no reduction is mentioned at all** → **Fail** ("Orphan node — a problem without any planned reduction rule has no value in the reduction graph. Add at least one planned reduction to/from an existing problem.")
+   - If reductions are mentioned but vague ("can be connected to other problems") → **Warn**
+
+4. Check **Motivation** field:
    - Is there a concrete use case? (quantum computing, network design, scheduling, etc.)
-   - Does it mention what reductions this problem enables? A problem without any planned reduction rules is an orphan node.
    - If motivation is empty, placeholder, or vague → **Warn**
 
-4. Check **How to solve** section:
+5. Check **How to solve** section:
    - At least one solver method must be checked (brute-force, ILP reduction, or other)
    - If no solver path is identified → **Warn** ("No solver means reduction rules can't be verified")
 
@@ -240,6 +250,13 @@ If the problem has a genuinely different feasibility constraint or objective fun
 - Check that feasibility constraints and objective are clearly separated
 - Verify the variable domain matches the problem semantics (binary for selection, k-ary for coloring, etc.)
 
+### 3e: Representation Feasibility
+
+Verify that the proposed data types in the Schema can represent the stated problem domain:
+- If the Schema proposes a data type but the Definition or Variants mention domains that exceed that type's range (e.g., proposing integer coefficients for a finite field larger than any fixed-width integer can hold) → **Fail** ("Proposed data type cannot represent the stated domain")
+- If multiple variants are listed, check that the proposed schema handles all of them or explicitly restricts scope
+- If the issue acknowledges a limitation and restricts scope (e.g., "initial implementation targets small fields only"), this is acceptable → **Pass** with a note
+
 ### 3b: Complexity Verification
 
 The issue claims a best-known exact algorithm with a specific time bound. Verify:
@@ -278,7 +295,7 @@ Check all template sections are present and substantive:
 | Definition | Formal: input, feasibility constraints, objective |
 | Variables | Count, per-variable domain, semantic meaning |
 | Schema | Type name, variants, field table |
-| Complexity | Best known algorithm with citation |
+| 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 |
 
@@ -301,9 +318,14 @@ The formal definition must be **precise and implementable**:
 ### 4d: Example Quality
 
 - **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
 - **Detailed enough for paper**: This example will appear in the paper — it needs to be illustrative
 
+### 4e: Representation Feasibility
+
+Same check as Correctness 3e — if the proposed data types cannot represent the stated domain, this is also a **Fail** here (the schema is not implementable as written).
+
 ---
 
 # Step 2: Compose and Post Report
@@ -387,7 +409,8 @@ gh issue edit <NUMBER> --add-label "Trivial"      # if Check 2 failed
 gh issue edit <NUMBER> --add-label "Wrong"        # if Check 3 failed
 gh issue edit <NUMBER> --add-label "PoorWritten"  # if Check 4 failed
 
-# If ALL checks passed (no failures), add the "Good" label
+# "Good" label requires: zero failures AND zero warnings on Usefulness or Correctness.
+# Warnings on Non-trivial or Well-written alone do NOT block "Good".
 gh issue edit <NUMBER> --add-label "Good"
 
 # If re-checking after fixes, remove stale failure labels and add "Good" if now passing