Update to Research Writing Guardrails

{
  "description": "Use for scientific research analysis, technical system or algorithm design, method reasoning, experiment interpretation, claim auditing, and research-paper argumentation. Enforce consistency among the real technical problem, the mechanism introduced to address it, observable consequences, and the strength of available evidence. Do not use for casual nontechnical writing.",
  "included_files": [
    {
      "relative_path": "references/evidence-guide.md",
      "size_in_bytes": 2610
    }
  ],
  "name": "research-problem-mechanism-evidence",
  "skill_md_contents": "---\nname: research-problem-mechanism-evidence\ndescription: Use for scientific research analysis, technical system or algorithm design, method reasoning, experiment interpretation, claim auditing, and research-paper argumentation. Enforce consistency among the real technical problem, the mechanism introduced to address it, observable consequences, and the strength of available evidence. Do not use for casual nontechnical writing.\n---\n\nApply this skill whenever the task involves research reasoning, technical design, method development, experiment interpretation, or scientific claims.\n\nCore rule\n\nReal problem → mechanistic intervention → observable consequence → evidence-bounded conclusion.\n\nWorkflow\n\n1. Identify the real technical problem before discussing a module, formula, loss, cost, constraint, algorithm, or experimental result.\n2. Express the problem as a concrete system behavior or failure mode. Examples include increased error, insufficient response, excessive control action, prediction–execution mismatch, plan oscillation, infeasibility, solver instability, increased computation, reduced task efficiency, or sensitivity to operating conditions.\n3. Explain why the existing design is insufficient for that specific behavior.\n4. Describe the intervention mechanistically. State what variable, relation, decision freedom, constraint set, time scale, or information flow changes.\n5. Explain the intermediate consequence expected from that change before making a performance claim.\n6. Match every conclusion to the strongest evidence that directly supports it.\n7. Preserve all user-declared frozen data, definitions, metrics, experimental protocols, terminology, and interfaces.\n\nEvidence discipline\n\n- Theory supports only conclusions that follow from the stated assumptions and derivation.\n- Implementation evidence establishes what the system actually computes, constrains, schedules, or executes.\n- Ablations support the incremental effect of the factor that was actually changed.\n- Method comparisons support performance differences between complete methods under the stated protocol.\n- Diagnostic metrics support whether an intended mechanism behaved as expected.\n- If multiple factors change together, do not attribute the outcome to a single factor without an additional control.\n- If direct evidence is absent, use mechanism-level wording such as \"is used to\", \"is designed to\", \"enables\", \"allows\", or \"reduces the risk of\". Do not present an intended effect as a verified result.\n\nStructural discipline\n\n- Separate shared backbone, paper-specific innovation, and adaptive mechanisms.\n- Attribute experimental effects to the interface that actually changes.\n- Do not invent a linear causal chain merely for narrative smoothness.\n- When accuracy, feasibility, computation, continuity, or prediction consistency are parallel problems, establish the higher-level objective and treat them as parallel branches.\n- Advance sections and paragraphs by cognitive increment. Each part should add information needed to answer a previously unresolved question.\n- Treat equations, figures, and experiments as components of the argument. Equations explain implementation of a mechanism, figures clarify structure or relations, and experiments test expected consequences.\n\nBefore finalizing, verify that the argument can answer all five questions below.\n\n1. What is the real technical problem?\n2. Why is the current or prior design insufficient?\n3. What exactly does the new mechanism change?\n4. Why could that change mitigate the problem?\n5. What do the available data, definitions, implementation, theory, and experiments actually support?\n\nIf any link is missing, weaken the claim or flag the evidence gap instead of filling it with an invented explanation.\n\nRead `references/evidence-guide.md` when detailed claim-strength or experiment-attribution rules are needed.\n"
}