/retail-trading-manual-writer

name: retail-trading-manual-writer
description: Write and save Chinese beginner-friendly paid manual subsections for "全品种操盘手册", a retail-investor education/subscription product covering the full 17-chapter + appendix outline from digoal's 2026-05-28 article. Use when the user provides a subsection title or asks to continue/complete the manual for 投资小白/散户, especially with triggers like 每次写一小节, 全品种操盘手册, 操盘手册, 知识付费, SVG图解, 第一性原理, markdown目录, 进度跟踪, or 散户金融工具.

Retail Trading Manual Writer

Core Contract

Write exactly one subsection per invocation unless the user explicitly asks for an outline or revision batch. Save the finished subsection as Markdown under the current project's `markdown/` directory and save all diagrams as standalone SVG files referenced by that Markdown.

Treat every output as investment education, not personalized investment advice.

Each subsection must present its main view as a single reasoning chain, not as scattered conclusions plus separate evidence. Start from explicit premises, derive the view step by step in novice-friendly language, state how conclusions change if key premises change, then use authoritative data and representative cases to test, prove, or limit the derived view. Treat this as a combined theoretical-science and empirical-science method: logic first, evidence second, revision when premises fail.

Always load `references/manual-outline.md` before drafting a new subsection.

Treat `references/manual-outline.md` as the source-of-truth chapter map.

When the user asks to continue, complete the whole manual, or write the next subsection, maintain a progress file at `markdown/manual-progress.md`. Use it only to track chapter/subsection status, saved file paths, and short notes; do not merge multiple subsections into one article.

Inputs

Accept these inputs from the user:

• `小节标题`: required. Use it as the article's main title.
• `其他参考信息`: optional. Incorporate user-provided notes, data, links, constraints, examples, or intended readers.
• `目标读者`: default to mainland China novice retail investors with limited financial knowledge.
• `输出文件名`: optional. If absent, derive a concise pinyin/English slug from the subsection title plus date.
• `已写稿件路径`: optional. If provided, inspect it to avoid repeated content and preserve series continuity.
• `进度文件路径`: optional. If absent and continuation is implied, use `markdown/manual-progress.md`.

If the title is missing, ask one concise clarification question. If references are missing, continue with the manual outline and current authoritative sources, but say which assumptions you used.

Output Files

Use this file layout:

<current project>/markdown/
  <slug>.md
  manual-progress.md
  assets/
    <slug>/
      01-*.svg
      02-*.svg

Rules:

• Create `markdown/` and `markdown/assets/<slug>/` if they do not exist.
• Write the final article to `markdown/<slug>.md`.
• When continuation or whole-manual progress is relevant, create or update `markdown/manual-progress.md`.
• Put all SVG diagrams in `markdown/assets/<slug>/`.
• Reference diagrams with relative Markdown image links, for example:

``

• Do not inline raw `<svg>` blocks in the Markdown body.
• At the end of the response to the user, report the saved Markdown path and SVG asset directory.

Workflow

1. Resolve scope.

• Identify the requested chapter and subsection from the title.
• Inspect `references/manual-outline.md` and any user-provided references.
• Match the requested title to exactly one chapter/subsection in the full 17-chapter + appendix map when possible.
• If the user asks for "下一小节", "继续", or "完成所有章节", inspect `markdown/manual-progress.md` and existing `markdown/*.md` files, then choose the first unwritten subsection in outline order.
• If the requested title does not appear in the outline, either map it to the closest subsection and state the mapping, or ask one concise clarification question when the mapping is ambiguous.
• If the subsection is a continuation, inspect the existing manuscript when available.

2. Build the evidence base.

• Verify current facts when the subsection depends on changing rules, product availability, fees, taxes, trading hours, eligibility thresholds, margin rules, or recent market data.
• Prefer official exchanges, regulators, fund prospectuses, fund companies, brokerage rule pages, central banks, statistical agencies, and reputable academic/industry research.
• Use broad data or representative historical evidence. Do not use one anecdote to prove a general rule.
• Cite sources in the Markdown with source name, date if available, and URL when web-sourced.

3. Run first-principles reasoning before drafting.

• State the core claim.
• List every premise that must hold for the claim to be true.
• Classify each premise as `常量`, `慢变量`, or `关键变量`.
• Build a numbered derivation from premises to conclusion. Each step must answer: `因为哪个前提成立 -> 所以产生什么机制 -> 因此小白该得到什么判断`.
• Translate abstract finance terms into beginner language before using them in the derivation.
• For each key variable, explain what would overturn it and what conclusion follows after re-reasoning.
• Only after the derivation is complete, attach authoritative data, rules, research, or representative cases to test which premises are reliable and where the conclusion has boundaries.

4. Design SVG diagrams before writing the body.

• Use SVG aggressively for explanation, normally 3-6 diagrams per subsection.
• At minimum include: one premise-to-conclusion logic chain, one decision tree for changed premises, and one risk boundary/checklist visual.
• Make SVGs GitHub Markdown renderable: standalone `.svg`, explicit `xmlns`, `viewBox`, `width`, `height`, no JavaScript, no external assets, no `foreignObject`, no remote fonts.
• Keep all text inside SVG large enough to read in GitHub preview. Prefer simple shapes, arrows, labels