/axiom-explainer

name: axiom-explainer
description: Write Chinese Markdown articles for university students and adults with social experience that explain one viewpoint, axiom, theorem, law, principle, or theory system through "求真讲法、求存讲法、思考", with text/Mermaid and standalone GitHub-renderable SVG files, assumptions, derivation or motivation, applicability boundaries, positive and negative examples, and save the result under the current project's markdown directory. Use when Codex is asked to generate 公理讲解文案、定理讲解、理论体系通俗解读、观点拆解、面向大学生和成年人的图文并茂 Markdown 文章.

Axiom Explainer

Overview

Generate a clear Chinese teaching article for university students and adults with social experience from a single viewpoint, axiom, theorem, law, principle, or theory system. The output must be Markdown, visually rich, and saved under the current project's `markdown/` directory.

Input Contract

Required input:

• One target concept: a viewpoint, axiom, theorem, law, principle, or theory system.

Optional input:

• Audience level. Default: university students and adults with social experience.
• Desired length. Default: 1800-3000 Chinese characters.
• Source material or references supplied by the user.
• Output filename or topic slug.

If the user gives several concepts, choose the central one only when the concepts clearly form one theory chain. Otherwise ask the user to pick one concept before writing.

Workflow

1. Identify the input type:

• Axiom or postulate: explain that it is not proven inside the system. Describe why people choose it, what problem it solves, what assumptions it introduces, and what changes if it is replaced.
• Theorem or proposition: trace the axioms, definitions, lemmas, and reasoning chain that support it. Give an intuitive proof first, then a concise formal skeleton when useful.
• Viewpoint, law, principle, or theory system: rewrite it as claims plus assumptions, then explain its evidence chain, mechanism, scope, and failure cases.

2. Scope the audience:

• Default to university students and adults with social experience unless the user specifies another level.
• Use concrete analogies before abstract notation.
• Prefer examples from investment and personal finance, product management, product operations, marketing, interpersonal relationships, and workplace scenarios unless the concept or user request clearly calls for another domain.
• Define specialized terms at first use.
• State any simplifications made for readability.

3. Verify the concept:

• Use reliable references when the derivation, history, statement, or applicability is uncertain.
• Prefer primary sources, standard textbooks, official course notes, or authoritative encyclopedia references.
• Do not invent historical stories, theorem proofs, or real-world applications.
• If a topic has multiple versions, name the version being explained.

🔴 CHECKPOINT: Before writing the article, confirm these internal decisions: input type, chosen version, audience level, central question, and the 3-5 named assumptions or boundaries. If any item is unclear and cannot be resolved from the user's prompt or reliable references, ask one concise clarification question.

Write this decision sheet before drafting, then use it as the article's control plan:

| Item | Required content | |---|---| | Input type | One of: axiom/postulate, theorem/proposition, viewpoint/law/principle, theory system | | Chosen version | Exact statement or named version being explained; mark "standard textbook version" or "user-supplied wording" when no narrower source is available | | Central question | One sentence in the reader's language, not a broad topic label | | Assumptions and boundaries | 3-5 named premises, each with "成立时" and "不成立时" consequences | | Evidence or derivation route | For axioms: motivation/model/independence route; for theorems: definition -> lemma -> conclusion route; for viewpoints: claim -> evidence -> counterevidence route | | Visual plan | Mermaid purpose, SVG purpose, and table/TXT/second-SVG purpose; each must map to one assumption, mechanism, proof step, or failure boundary |

4. Create visuals:

• Include at least one Mermaid diagram.
• Include at least one standalone SVG file for mechanism, structure, boundary, geometry, set, coordinate, timeline, or comparison visuals.
• Include at least one additional visual form: Markdown table, ASCII/TXT diagram, or another standalone SVG file.
• Use visuals to explain causal chains, assumption boundaries, proof structure, transfer paths, or failure cases.
• Do not use decorative visuals that do not teach anything.

5. Write and save:

• Create `markdown/` in the current project if it does not exist.
• Save the article as `markdown/YYYYMMDD-<topic-slug>.md`.
• Save SVG assets under `markdown/assets/<topic-slug>/`.
• Reference each SVG from Markdown with a relative image link: ``.
• Use a readable topic slug. Pinyin or short English is preferred; Chinese is acceptable when clearer.
• In the final response, report the saved file path and a short summary. Do not paste the full article unless the user asks.

🔴 CHECKPOINT: Before saving the final Markdown, run this quality gate. If any row fails, revise the article or asset before responding.

| Gate | Pass condition | |---|---| | Concept control | The article explains one target concept, or explicitly states why several concepts form one theory chain | | 求真/求存 separation | "求真讲法" explains truth, acceptance, proof, derivation, or evidence; "求存讲法" explains use, transfer, boundary, and decision value | | Assumption linkage | Every positive example and negative example names the assumption or boundary that makes it work or fail | | Visual usefulness | Mermaid, SVG, and the additional visual each teach a different mechanism, boundary, proof step, or comparison | | Asset integrity | Every SVG file exists under `markdown/assets/<topic-slug>/`, ha