Research Writing Guardrails

View saved version →

---
name: compag-elsevier-paper-editing
description: Use when drafting, revising, shortening, polishing, or auditing technical manuscript text for an Elsevier Computers and Electronics in Agriculture style. Prioritize precision, concision, evidence-bounded claims, terminology consistency, and high information density while preserving frozen technical content. Avoid colons and italic emphasis in manuscript prose and use hyphens only where technically or grammatically standard.
---

Use this skill for paper text, captions, method descriptions, result interpretation, abstracts, introductions, discussions, conclusions, and reviewer-response prose when the requested style is Elsevier or COMPAG-like.

Preservation rules

- Do not change frozen numerical values, definitions, equations, metrics, experimental protocols, task groupings, baselines, symbols, or evaluation scope.
- Preserve technical meaning unless the user explicitly requests a conceptual change.
- Do not silently strengthen claims.
- If a statement exceeds the available evidence, weaken it to the strongest defensible form or identify the gap.

Writing rules

- Prefer precise, compact, evidence-driven sentences.
- Use natural forward logic.
- Minimize rhetorical contrast constructions such as "not ... but", "rather than", and unnecessary "whereas" clauses.
- Remove redundancy and repeated explanations.
- Keep one technical purpose per sentence when possible, while maintaining paragraph flow.
- Use terminology, symbols, metric names, capitalization, and tense consistently.
- Prefer mechanism-level explanations over generic claims such as "improves robustness" or "enhances performance".
- State comparisons only when the underlying data directly support them.
- Keep causal interpretations narrower than the experimental manipulation.
- Do not use colon punctuation in manuscript prose or headings unless the user explicitly permits it or the syntax is technically mandatory.
- Do not use italic emphasis.
- Avoid em dashes and decorative hyphenation.
- Use hyphens only in standard compounds, established technical terms, variable names, ranges, or syntax where omission would be incorrect or ambiguous.
- Do not introduce defensive wording, inflated novelty claims, or broad generalizations.

Paragraph logic

Build paragraphs around a necessary question.

- Establish the concrete technical need.
- Introduce the definition, model, equation, or design that is needed to address it.
- Explain what the design changes in the system and why that change is relevant.
- State only the consequence supported by theory, implementation, diagnostics, or experiments.
- End by identifying the next unresolved technical question when a transition is needed.

Do not force every paragraph into a single causal chain. When multiple technical problems are parallel, state the common objective and develop the branches separately.

Method sections

When technically valid, use design-reason-driven progression. Connect each mechanism to the concrete issue that motivates it, explain the operational change made by the mechanism, and avoid manual-like sequences of disconnected definitions.

Results and discussion

- Report the measured result first.
- Interpret only the factor isolated by the experiment.
- Keep ablation, comparison, and diagnostic evidence conceptually separate.
- Do not infer causality from correlated metric changes alone.
- Use exact scopes such as evaluated cases, matched cases, tested operating conditions, or the stated dataset when generalization is not demonstrated.

Final editing pass

1. Verify all numbers and frozen definitions against the source text or supplied data.
2. Check every comparative and causal claim against direct evidence.
3. Unify terminology, symbols, metrics, and tense.
4. Remove redundant sentences and repeated rationale.
5. Remove prohibited colon punctuation and italic emphasis.
6. Normalize hyphen usage.
7. Reduce contrast-heavy constructions.
8. Check that each equation, figure reference, and experiment has a clear argumentative function.

Read `references/style-audit.md` when a stricter manuscript-level audit is required.

Referenced files: 1

View saved version →

---
name: research-problem-mechanism-evidence
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.
---

Apply this skill whenever the task involves research reasoning, technical design, method development, experiment interpretation, or scientific claims.

Core rule

Real problem → mechanistic intervention → observable consequence → evidence-bounded conclusion.

Workflow

1. Identify the real technical problem before discussing a module, formula, loss, cost, constraint, algorithm, or experimental result.
2. 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.
3. Explain why the existing design is insufficient for that specific behavior.
4. Describe the intervention mechanistically. State what variable, relation, decision freedom, constraint set, time scale, or information flow changes.
5. Explain the intermediate consequence expected from that change before making a performance claim.
6. Match every conclusion to the strongest evidence that directly supports it.
7. Preserve all user-declared frozen data, definitions, metrics, experimental protocols, terminology, and interfaces.

Evidence discipline

- Theory supports only conclusions that follow from the stated assumptions and derivation.
- Implementation evidence establishes what the system actually computes, constrains, schedules, or executes.
- Ablations support the incremental effect of the factor that was actually changed.
- Method comparisons support performance differences between complete methods under the stated protocol.
- Diagnostic metrics support whether an intended mechanism behaved as expected.
- If multiple factors change together, do not attribute the outcome to a single factor without an additional control.
- 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.

Structural discipline

- Separate shared backbone, paper-specific innovation, and adaptive mechanisms.
- Attribute experimental effects to the interface that actually changes.
- Do not invent a linear causal chain merely for narrative smoothness.
- When accuracy, feasibility, computation, continuity, or prediction consistency are parallel problems, establish the higher-level objective and treat them as parallel branches.
- Advance sections and paragraphs by cognitive increment. Each part should add information needed to answer a previously unresolved question.
- 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.

Before finalizing, verify that the argument can answer all five questions below.

1. What is the real technical problem?
2. Why is the current or prior design insufficient?
3. What exactly does the new mechanism change?
4. Why could that change mitigate the problem?
5. What do the available data, definitions, implementation, theory, and experiments actually support?

If any link is missing, weaken the claim or flag the evidence gap instead of filling it with an invented explanation.

Read `references/evidence-guide.md` when detailed claim-strength or experiment-attribution rules are needed.

Referenced files: 1