version: "1.0.0" name: "shelah-compact-en" description: "Use only when explicitly invoked as $shelah-compact-en. Give concise explanations and rewrites: merge broadly equivalent concepts, define the general form once, and state only variant differences."

Shelah Compact (English)

Prefer mathematical notation and formulas unless prose is more concise.

Apply these rules only when the user explicitly invokes this skill in the current request, and only for that request and the steps needed to complete it. Do not carry them over to later requests without invocation. Do not activate this skill merely because a task involves mathematics, conceptual explanations, or concise writing.

A personal concise adaptation of the Saharon Shelah writing guide, usable on its own for AI explanations, reading assistance, and rewriting. Preserve mathematical density, stable notation, and explicit dependencies while minimizing prose and repetition.

1. Prioritize correctness, readability, then brevity. Preserve necessary assumptions, quantifiers, domains, key inferences, and exceptions. Distinguish proofs, assumptions, heuristics, and numerical observations. Never change meaning or invent facts to save words.

1. At the level of abstraction needed for the current question, distinguish synonymy, strict equivalence, broad conceptual equivalence, inclusion, and separate alternatives. Broad conceptual equivalence covers the same underlying mechanism expressed through different terminology, notation, parameterizations, or implementations: define and explain one primary formulation, then state only correspondences, conditions, and substantive differences. A shared mechanism does not establish mathematical equivalence; explicitly identify one-way implications, approximations, and analogies. Keep names and symbols stable and refer back to them; necessary reuse of names and symbols is allowed.

1. When methods share a structure, give the smallest general formulation that covers the current discussion, then list variants. For a special case, state only parameter values, additional conditions, or substitutions; do not reintroduce, rederive, or expand the general formula. State shared budgets, processing steps, and evaluation metrics once.

1. Call something a special case only after checking its conditions and verifying that it follows by substitution or restriction. If normalization, objectives, assumptions, or operators also change, state that difference. Do not force similar methods into equivalence or introduce an abstraction that makes them harder to read.

1. Answer directly and proceed in logical dependency order. When a new object is needed, identify the specific obstacle it resolves. Each sentence adds necessary information; each paragraph serves one purpose. Do not impose background, roadmaps, sections, or summaries on a short answer.

1. Reuse existing notation and state necessary types, dimensions, and domains at first use. Use a common base symbol with parameters or subscripts for variants. Do not name a quantity used once when its expression is already clear. Number items only for later reference.

1. Use formulas for precise definitions and key calculations. Prose adds only roles, conditions, or differences that the formulas leave unstated. Combine related equalities; omit mechanical substitutions, intermediate rewrites, and numerical expansions that do not aid comparison. Retain the reasoning needed to understand or verify the conclusion.

1. Default to the shortest sufficient answer. Remove pleasantries, commentary about the response itself, paraphrases, closing recaps, and unnecessary examples. Do not present successive intuitive, formal, and summary versions of the same content. When the user requests detail, expand only the relevant steps.

Before answering, silently merge repeated explanations, replace repeated special cases with their differences, and delete sentences that do not help understanding, verification, or use. Deliver only the requested content, not this check.