Beautiful Article
Background Principles
The more complex the AI-generated content, the more important the output medium. The value of HTML lies in simultaneously enhancing information density, visual clarity, sharing convenience, and interactivity: tables, SVG, CSS, code snippets, adjustable controls, copy and export buttons allow readers not just to "finish reading", but to compare, locate, adjust, review, and continue using the content. The purpose of Beautiful Article is to transform originally dull, linear, hard-to-digest textual materials into single-file web articles with better visual experience, clearer reading rhythm, and easier review and sharing.
Boundaries (First Judge Whether to Enter This Skill)
- The final main product is a single HTML article, not a web application.
- The article can have a free layer (any HTML / CSS / JS / React: interactions, layout typesetting, animations, small tools, on-demand SVG / canvas illustrations), but it must serve reading, explanation, argumentation, rhythm, or aesthetics.
- Do not generate: backends, forms, drag-and-drop workbenches, complete dashboards, product prototypes, or general web apps.
- Information density is confirmed by the user; 100% information retention is default, producing long-form web articles.
If the user wants an application instead of an article, stop and clarify, do not enter this Skill.
Workflow Overview
Phase 0 Intake Judge whether to enter this Skill + preliminary article type
▼
Phase 1 Source → Markdown URL/PDF/DOCX/MD/text → source.md + extraction-notes.md
└ Main Agent inline 5 checklist items for self-inspection (only upgrade to SubAgent for complex/low-confidence sources)
▼
Phase 2 Editorial Planning A plan.md (four sections: Brief / Outline / Theme / Assets)
└ Main Agent inline self-inspection (no SubAgent, no review files)
▼
Phase 3 Plan Checkpoint ★Checkpoint 1 Must stop. Confirm 5 items one by one: article type (including standard retention ratio) / theme / layout / image mode / cover
▼
Phase 4 First Spread First screen + first section + one representative visual block (scaffold created here)
└ First Spread Reviewer SubAgent (write review/first-spread-review.md)
└ ★Checkpoint 2 Must stop. Confirm 2 items one by one: acceptance conclusion / development mode A/B
▼
Phase 5 Full Article Build Generate complete web article (default single Agent, can be isolated by Section for extra-long articles)
└ Section Reviewer SubAgent (return pass/fail via message, no need to write review files)
▼
Phase 6 Final Review Three-perspective final review: Editorial / Visual / Technical (write review/final-review.md)
▼
Phase 7 Repair Minimal slice repair, write repair-log.md only if there are repairs
▼
Phase 8 Delivery ★Checkpoint 3 Must stop. Confirm delivery decisions one by one → deliver article.html + brief editing instructions
Workspace structure (created by scaffold; these files are the long-term memory of the Skill, do not rely only on chat context to remember decisions):
text
<workspace>/
source/ original.* source.md source.<lang>.md(when translation is needed) extraction-notes.md
plan/ plan.md # Single planning file: four sections of Brief / Outline / Theme / Assets
article/ Cover.tsx(default) Article.tsx sections/ raw-blocks/ assets/ article.html(product)
review/ first-spread-review.md final-review.md # Only these two are regular products
source-review.md(only for complex sources) repair-log.md(only when there are repairs)
index.html package.json vite.config.ts tsconfig*.json (build tools)
Rigid Quality Inspection Protocol (Throughout the Skill)
Quality inspection methods vary by node —— not all inspections require starting a SubAgent, nor do all require writing files.
Incorrectly starting a SubAgent / incorrectly writing files is the primary performance issue, strictly follow the table below:
| Node | Inspection Method | Product | Reason |
|---|
| Phase 1 Source (Default) | Main Agent inline 5 checklist items | No files | The Main Agent has to read source.md anyway |
| Phase 1 Source (Only for complex/low-confidence sources) | Source Reviewer SubAgent (diff against ) | | Silent loss can only be caught via diff |
| Phase 2 Plan / Before Checkpoint 1 | Main Agent inline self-inspection (Prohibit starting SubAgent) | No files | The plan is a text-based decision with 200-400 lines, the context is hot, cold-starting a SubAgent is slower |
| Phase 4 First Spread / Before Checkpoint 2 | First Spread Reviewer SubAgent | review/first-spread-review.md
| The first screen sets the tone, an extra independent check is more reliable |
| Phase 5 Each Section | Section Reviewer SubAgent | Return pass/fail + repair points via message (no files) | An article may have 5-15 sections, N review files will not be read again |
| Phase 6 Final Review / Before Checkpoint 3 | Editorial + Visual + Technical Reviewer SubAgent | | It is part of the deliverable, valuable for archiving |
Iron Rules:
- Plan Checkpoint (Phase 2 → Checkpoint 1) Prohibit starting SubAgent for quality inspection. After the Main Agent finishes writing plan.md, on-site check against the 5-item checklist (see the Plan self-inspection section in
references/review-checklist.md
- First Spread / Final Review must use SubAgent (the value of SubAgent at these two nodes > cost); only if the SubAgent environment is not detectable, the Main Agent will take over, and note "No SubAgent environment, Main Agent takes over" at the top of the file.
- Section Reviewer uses SubAgent, but the return value is a message (pass / fail + repair points); when receiving fail items, the Main Agent directly fixes them, do not let SubAgent write
review/section-NN-review.md
- After receiving any quality inspection conclusion —— first revise the output according to the fail items, then report "completed + self-inspection conclusion + changes made". Reporting the original conclusion directly without fixing = violation.
- Iron Rule for Decision Collection · Prohibit Silent Selection for Users: At each Checkpoint (1 / 2 / 3), all decision items requiring user confirmation must be listed independently + wait for user reply. The Agent can make recommendations ("I recommend X because …"), but cannot say "I've already decided X for you, let me know if it's wrong" —— this deprives the user of the right to choose.
- Priority: If the environment has the tool, each decision item is treated as an independent question (multiple questions can be passed in one call), and the user can confirm each item via selection cards.
- Otherwise: Stop and list all questions numbered in the message (each question occupies a separate paragraph, clearly stating the recommended option + reason + alternatives), explicitly say "I will wait for your item-by-item reply before continuing", do not proceed with any subsequent work.
- Never: Package multiple decisions into a single "Accept all my recommendations / All OK?" yes/no question; also do not proceed to the next step by default after a "recommendation sentence".
Checklists and SubAgent prompt templates for each node can be found in
references/review-checklist.md
.
File Reading Guide for Each Phase (Progressive Loading, Do Not Read All at Once)
| Phase | Must Read | Read On Demand |
|---|
| Phase 0 Intake | | —— |
| Phase 1 Source→MD | references/source-to-markdown.md
| scripts/source-to-markdown-markitdown.py
scripts/source-to-markdown.py
|
| Phase 2 Planning | references/article-types.md
references/information-density.md
references/plan-template.md
references/theme-selection.md
references/asset-policy.md
| references/article-types/<type>.md
|
| Phase 4 First Spread / Phase 5 Build (Review before each section) | references/section-build.md
references/component-policy.md
| (once when creating the project) · references/html-output.md
|
| Phase 6/7 Review & Repair | references/review-checklist.md
references/repair-policy.md
| —— |
| Phase 8 Delivery | references/html-output.md
| (only if the user selects PDF export) |
Agents tend to forget principles in long sessions —— Phase 5 will implement N Sections repeatedly,
review +
+ current theme
before starting each time.
Phase 0 —— Intake
Judge whether to enter this Skill, give preliminary article type and output mode (default single HTML).
| User Provided Content | Actions to Take |
|---|
| One or more materials (URL/PDF/DOCX/MD/text/screenshot) | Enter Phase 1 |
| Only says "Help me write an X article" but no materials | Ask back: Request materials or outline first. The Skill does not create content out of thin air for users |
| Clearly wants an application / tool / dashboard | Stop and clarify, do not enter this Skill |
Capture Target Language: Record the user's expected final article language at the beginning (e.g., if the user mentions "use Chinese / make it English version").
- User specified language → Record in the "Target Language" section of the Brief in . If it is inconsistent with the source material language, Phase 1 needs to first produce a natural translation of the source text, and subsequent work will be based on the translated version (see Phase 1).
- User did not specify → Default to final article language follows source material language, no translation.
Self-inspection: Does the user want an article or a web application? Is full information retention required? Do you need to request more materials first? Did the user specify the final language? Is it consistent with the source language?
Phase 1 —— Source → Markdown
Unify any input into
, write uncertain items into
source/extraction-notes.md
.
Rules and processing for various inputs can be found in
references/source-to-markdown.md
; you can use the MarkItDown main path or lightweight fallback scripts for PDF/DOCX/HTML extraction.
After saving to disk, the
Main Agent performs inline self-inspection (5 checklist items in
references/source-to-markdown.md
), fixes according to the conclusion, then enters Phase 2;
only when marks low-confidence / complex sources, upgrade to an independent Source Reviewer SubAgent and perform diff-based inspection against
(write
).
Language Processing (Immediately after extraction): Determine the language of
.
- User did not specify target language, or target language is consistent with source → No translation, subsequent work is directly based on , final article language = source language.
- User specified target language and it is inconsistent with source → First produce a natural translation (e.g., / ), which serves as the fact base for subsequent Phase 2+; keep the original for reference. Translation requirements: Use natural target language, eliminate translation腔 (restructure sentences according to the expression habits of the target language, do not translate word-for-word, avoid rigid foreign language word order / passive stacking / non-standard punctuation), keep terms / numbers / code / formulas / references accurate, and maintain the same structure and information retention ratio. Write translation instructions into .
Phase 2 —— Editorial Planning
Formulate an editorial plan,
do not write HTML directly.
Only produce one (four sections: Brief / Outline / Theme / Assets), template can be found in
references/plan-template.md
:
- Brief: Target readers / article type / information retention ratio / must retain / can delete / tone / main viewpoints / reading goals / target language / layout width / TOC / image strategy.
- Outline: Hero / Lead / Summary / Section list / information to retain in each section / whether each section needs Raw·Table·CodeBlock·Formula·Image / ending method.
- Theme: Selected theme + reason + conflict explanation (see
references/theme-selection.md
- Assets: Image strategy and item-by-item image plan (see
references/asset-policy.md
Article type routing can be found in
references/article-types.md
; information density and component ratio can be found in
references/information-density.md
.
Self-inspection Method · Strong Constraint: After writing
, the
Main Agent inline checks against the 5-item Plan self-inspection checklist (see the Plan self-inspection section in
references/review-checklist.md
), revises
according to the conclusion,
directly enter Checkpoint 1, prohibit starting SubAgent, prohibit writing .
Phase 3 —— Plan Checkpoint (★Hard Node · Checkpoint 1, Must Stop)
Iron Rule: Prohibit Silent Selection for Users. Each decision item must be listed independently and wait for user reply independently.
You can make recommendations ("I recommend X because …"), cannot say "I've already decided X for you, let me know if it's wrong" —— the latter sneaks in the default value and deprives the user of the right to choose.
Collection Methods (Choose One According to Environment):
- Priority Tool: Pass each item as an independent question (multiple questions can be passed in one call), and the user confirms each item via selection cards.
- No Tool: Stop and list each question numbered + in a separate paragraph + clearly stating recommended option + reason + alternatives in the message, explicitly say "I will wait for your item-by-item reply before continuing", do not proceed with any subsequent work.
Regardless of the method: Each independent decision corresponds to one independent question, do not package into "All OK?" yes/no.
5 Items That Must Be Confirmed Independently (No Exceptions):
| # | Decision Item | Options (Semantic Tags · Include Standard Information Retention Ratio) | Notes |
|---|
| 1 | Article Type (information retention ratio is included) | Full long-form / archive ／ Research report / formal analysis ／ Teaching steps / getting started guide ／ Concept / system explanation ／ Dialogue / interview / podcast ／ PR / proposal / accident review ／ Opinion / comment / narrative ／ Interactive learning / understand a concept interactive-explainer · ~25% original excerpt + 75% AI reconstruction
| AI recommends one and writes a reason. The ratio is bound to the type option, no separate question (otherwise pseudo-combinations like will appear). If the user wants to deviate from the standard, override with a free-text sentence ("I want longform + 60%"), see "How to Deviate from Standard" below |
| 2 | Theme | tufte / press / other registered themes (read theme-profiles/index.json
| AI recommends one and writes a reason |
| 3 | Layout Width | narrow / regular / wide / full | AI recommends one; default |
| 4 | Image Mode (Mandatory · "Default pass" is not allowed) | none / user-assets / placeholders / ai-generated | One sentence: "Only decides whether to use external ; is not affected" |
| 5 | Cover (3:4 book-style cover image, located above TOC + main text) | On (default) / Off | AI recommends "On", and gives a composition idea (which main visual + which cover template A/B/C/D/E to choose). / can recommend "Off". See for details |
TOC is On by Default: Since it only has one switch + almost all articles should have it on, you can mention it in the opening explanation of the Plan Checkpoint with "TOC is on by default, let me know if you want to turn it off", no need for a separate question.
Items That Follow Default Values and Do Not Need Separate Questions (still need to explicitly state "Let me know if you want to change" in the opening explanation to give the user a chance to change their mind, cannot hide completely):
- Final article language: Follows source language (unless the user has specified it earlier / translation has been completed).
- Whether editing, deleting, reorganizing, and rewriting tone is allowed: Allowed by default (implemented according to the above information retention ratio).
- Whether to preview the first screen sample first: Yes by default (this is Phase 4).
- TOC: On by default.
If the user says "You decide" for the theme → Select your first recommendation, still list it alongside other candidates in the options, mark "Default · AI Recommended", leave room for regret, cannot skip the theme question directly.
How to Deviate from the "Standard" Information Retention Ratio: Each article type has a recommended retention ratio (see the table above). Most cases can follow the standard. If the user wants to refine (e.g., "longform but only 60%" → a deeply edited long article), let the user
write a sentence in the free text after the opening explanation "I want <type> + <X%>" to override. After receiving the override, the AI must record "type / standard retention / user overrides to X%" in the Brief section of
, and remind the user that this is a "non-standard combination" —— such combinations require the Main Agent to manually adjust the main text/visual ratio when writing each section.
Plan Checkpoint Opening Message Template (Send a Short Explanation Before Collecting Decisions):
plan/plan.md has been written (self-inspection passed). I will confirm 5 items with you one by one: article type / theme / layout width / image mode / cover.
My recommendations are provided for reference (I will not choose for you):
- Type: <X> (includes standard information retention <Y%>. Reason: …)
- Theme: <theme> (Reason: …)
- Layout Width: <width> (Reason: …)
- Image Mode: <strategy> (Reason: …)
- Cover: On / Off (Reason: …; if On, composition idea: …)
Default settings that you can override: Language follows source language; editing, deleting, and reorganizing are allowed; TOC is on; the first screen sample will be made next. If you want to deviate from the standard information retention ratio for the type, tell me the specific percentage directly after answering the questions below (e.g., "longform but only 60%").
Please confirm each item below.
After sending the above explanation,
immediately pass 5 questions via AskQuestion (or list 5 numbered questions in a non-tool environment and wait for replies).
Only enter Phase 4 after receiving all 5 replies; if the user provides a "non-standard retention ratio" in free text, first confirm that the AI has recorded it in
before entering Phase 4.
Phase 4 —— First Spread ("Chapter 1 Acceptance" for Articles)
First create "Cover (if On) + first screen + first section + one representative visual block". Scaffold creates the workspace here:
bash
# Cover is On by default
bash <path-to-beautiful-article>/scripts/scaffold.sh ./my-article --theme=<id>
# User selected "Cover · Off" in Checkpoint 1
bash <path-to-beautiful-article>/scripts/scaffold.sh ./my-article --theme=<id> --no-cover
bash <path-to-beautiful-article>/scripts/scaffold.sh --list-themes
It creates a Vite + React + TS workspace (installs the latest released version of
from npm) +
memory directories + assembler
+ a sample section component (+ default
, unless
). See
for details.
Write the first screen (Hero / Lead) into the assembler
;
the first Section must be written as an independent component article/sections/01-*.tsx
(this is the code anchor for subsequent parallel development, see
references/section-build.md
).
Cover (if On) replaces
in
with a customized image-text composition based on the theme + article主旨,
do not modify the shell (3:4 container + print pagination). Cover design guidelines can be found in
.
Preview with
. It determines the title temperament / font size / content density / Raw style / image mode / whether the theme is appropriate.
After completing the first Section, create First Spread Reviewer SubAgent according to the Rigid Quality Inspection Protocol, write
review/first-spread-review.md
(
includes 5 self-inspection items for cover, see
), fix before entering Checkpoint 2.
Checkpoint 2 · First Spread (★Hard Node, Must Stop)
Let the user accept the first screen + first Section, and select the subsequent development mode. The decision collection iron rule of Checkpoint 1 also applies: Two items must be confirmed independently, prohibit packaging; priority AskQuestion, list numbered questions and wait for replies if no tool.
First send a short message:
The first screen + first Section is ready, preview with npm run dev on localhost.
Quality inspection conclusion can be found in review/first-spread-review.md (already fixed according to fail items, list of changes made is included).
Please confirm two items independently: 1) Acceptance conclusion 2) Subsequent development mode.
Then pass two independent questions via AskQuestion (or list two numbered questions and wait for replies):
- Acceptance Conclusion —— Options:
Pass · Enter full generation
Partial modification · I will specify changes in another message
Theme or layout is inappropriate · Return to Checkpoint 1
- Subsequent Development Mode —— Options:
A · Single Agent sequential (default · most stable · most consistent style)
B · Multiple Agent parallel (fastest · slight style differences)
Do not package these two items into "Pass + A, OK?" —— The user may "pass acceptance but want to use B" or vice versa.
Enter Phase 5 after receiving replies to both questions.
Phase 5 —— Full Article Build
Generate the complete article according to the development mode selected in Checkpoint 2. See
references/section-build.md
+
references/component-policy.md
+
for details.
Iron Rule · Each Section must be an independent component file (
article/sections/NN-*.tsx
),
坚决不允许把多个 Section 直接写进一个组件（坚决不允许 translates to "strictly prohibit writing multiple Sections directly into one component"）.
is only an
assembler: import and sort each Section, owned by the
Main Agent. Large Raw blocks are also isolated into
article/raw-blocks/NN-*.tsx
. File-level isolation is the prerequisite for multiple Agent parallel development.
Development Modes (Selected in Checkpoint 2):
- A · Single Agent sequential (default): Main Agent writes each sequentially, most stable and consistent in style.
- B · Multiple Agent parallel: Subagents each own one file for parallel development; Main Agent is responsible for merging and stability —— maintains the import and order of , runs / , ensures theme and style consistency, resolves conflicts. Subagent prompt templates can be found in
references/section-build.md
Other Principles: Main text is the main body; all Raw blocks use
theme tokens, prohibit wild styles; 100% information retention focuses on long-form structure, with Raw / images as enhancements; low information density can increase the proportion of visual blocks, but it must still be in
article form.
After completing each Section, must follow the Rigid Quality Inspection Protocol to use Section Reviewer SubAgent: Whether the outline task is completed / whether it meets the information retention ratio / whether it connects with previous and subsequent sections / whether it is over-componentized / whether there is enough main text / whether Raw blocks and images have clear purposes / whether the section number is consistent.
SubAgent returns pass/fail + repair points via message (pass = one line OK; fail = list repair points),
do not write review/section-NN-review.md
. After receiving fail items, the
Main Agent directly fixes the corresponding section file, then reports the delivery of this section.
Phase 6 —— Final Review (Three-Perspective Final Review)
Accept from three perspectives: reader / theme / technical, produce
+ repair list.
Complete rigid checklist can be found in
references/review-checklist.md
. It is recommended to use three Reviewers (at least one independent SubAgent if no Teams):
- Editorial Reviewer: Article nature, information selection, structure.
- Visual Reviewer: Theme, Raw blocks, images, mobile adaptation.
- Technical Reviewer: Build, console, code / formulas, accessibility.
Core Red Lines: It is still an article (not an application) · Information retention ratio conforms to the Plan · No key information from the source material is lost unexpectedly · Theme temperament is consistent · Raw blocks have no wild styles · No obvious AI flavor · Readable on desktop + mobile · HTML can be built, opened, and shared.
Phase 7 —— Repair (Minimal Slice)
Repair according to minimal units, rules can be found in
references/repair-policy.md
.
Prohibit: Rewriting the entire article just to fix one issue / modifying the confirmed article structure for visual fixes / deleting content specified by the user to be retained for information compression.
Write only if there are repairs (no repairs / one-pass = no need to write).
Checkpoint 3 · Final (★Delivery Confirmation)
After fixing according to the final review, stop and let the user independently confirm the delivery decision (do not skip directly with "I plan to export HTML, no problem so I'll proceed"). Priority AskQuestion, list numbered questions in the message and wait for replies if no tool.
- Delivery Decision —— Options:
Pass · Export HTML for delivery
Pass · Export HTML + PDF simultaneously
Partial repairs needed · I will list specific changes
Pause · I want to review again
There is only one decision item, but still actively stop and ask, do not silently export HTML by default.
Phase 8 —— Delivery
Build and deliver (commands can be found in
references/html-output.md
):
- (self-contained single page, CSS + JS inline, accessible offline) —— Main deliverable.
- Optional : Only generate if the user selects "Pass · Export HTML + PDF simultaneously" in Checkpoint 3. Command:
bash
bash <path-to-beautiful-article>/scripts/html-to-pdf.sh
- Brief editing instructions: Article type / information retention ratio / theme / image strategy / main editing choices.
Default Strategies
- Output single HTML; article type ; 100% information retention.
- Language: If user did not specify, follow source material language; if specified and inconsistent with source, first produce a natural translation then write based on it (eliminate translation腔, see Phase 1).
- Theme: Prioritize for technical / evidence-focused content, prioritize for narrative / comment-focused content (recommend based on source material).
- Layout: Width defaults to , TOC is on by default (decoupled from theme, see , both confirmed in Checkpoint).
- Images: Image mode is a mandatory option in Checkpoint 1 ( / / / ), only decides whether to use external , do not actively generate AI images.
- Raw: Orthogonal to images, always enabled by default, encourage frequent use, but must serve specific paragraphs and use theme tokens. Selecting does not affect Raw.
- Self-inspection: Plan inline self-inspection (no SubAgent, no files); First Spread and Final Review use SubAgent + write files; Section uses SubAgent + message return (no files). See "Rigid Quality Inspection Protocol" section.
- Decision Collection: Checkpoint 1 / 2 / 3 confirm each item independently · Prohibit silent selection for users. Can recommend, cannot skip. Priority tool (each item as an independent question); if no tool, stop and list numbered questions to wait for user replies.
- Repair: Minimal slice, write only if there are repairs.
- Colophon · Cannot Be Removed: The scaffold comes with a colophon Raw block at the end of (
Made with [beautiful-article](github repo) · <theme> theme
<ThemeProvider theme="...">
- Cover · On by default · Must have both image and text: The scaffold creates a 3:4 screen / PDF first-page exclusive book-style cover shell + placeholder in by default ( turns it off). The cover is located above TOC + Hero + main text, exists independently. In Phase 4 First Spread, the Main Agent replaces with a customized image + text composition based on theme + article主旨. Hard Constraints: Shell ratio / print pagination cannot be modified, must have visual elements + text, only use tokens, no remote images, no duplicate Hero content. Visual Technology Fully Open: SVG / CSS / Canvas / complex React components / any mix can be chosen by the Agent, as long as the effect is good. See for details (includes 5 self-inspection items + 5 composition templates + starting points for covers of each theme). PDF export will automatically make the cover occupy the first page alone, and TOC starts from the second page.
- PDF Export · Optional: The main deliverable is always . Only if the user selects "Pass · Export HTML + PDF simultaneously" in Checkpoint 3, run
bash <skill>/scripts/html-to-pdf.sh
Success Criteria
- It is first and foremost an article.
- The final article language conforms to the user's intention (unspecified = follows source language; specified = unified to target language throughout, natural, no translation腔, no residual source language fragments).
- The user-confirmed information density is respected; no key content from the source material is lost unexpectedly.
- Theme temperament is consistent; images and Raw blocks all serve reading.
- The page is more worth reading than Markdown; HTML can be directly opened and shared.
- At 40% information, it reads like an edited article, not a shortened summary; at 100% information, it reads like a polished long article, not a copy of the original text.
Related Resources (Marked by "When to Read")
| File | When to Read | Content |
|---|
| Phase 0 | Harness perspective of the Skill, six questions, state file conventions |
references/source-to-markdown.md
| Phase 1 | Rules for converting various inputs to source.md, extraction self-inspection, script usage |
references/article-types.md
| Phase 2 | Overview of article type routing (includes links to each type) |
references/article-types/<type>.md
| After selecting type in Phase 2 | Single type structure / components / Raw boundaries / image tendencies / self-inspection |
references/information-density.md
| Phase 2 | Information density levels, relationship with component / visual ratios |
references/plan-template.md
| Phase 2 | Template for single (four sections of Brief / Outline / Theme / Assets) and writing methods |
references/theme-selection.md
| Phase 2 | Theme selection, decoupling of density and theme, constraints for adding new themes |
| Phase 2 / Checkpoint | Layout: width modes (decoupled from theme) + TOC, confirmation and usage |
references/asset-policy.md
| Phase 2 | Four sources of images, principles for AI image prompts, image self-inspection |
| Phase 2 / When writing cover in Phase 4 | Book-style cover design guidelines (3:4 screen / PDF first-page exclusive): hard constraints, fully open visual technology, composition templates, starting points for covers of each theme, 5 self-inspection items |
references/section-build.md
| Phase 4/5 | Iron rule of one file per section, single/multiple Agent modes, parallel subagent prompt, Main Agent merging |
references/component-policy.md
| Phase 4/5 Before each section | reacticle component protocol, prose-first, relationship between information density and component ratio |
| Phase 4/5 Before each section | Raw allowed / prohibited, token-driven, Raw self-inspection |
references/html-output.md
| When building / delivering | dev / build / single-file HTML commands and products |
| Phase 8 Delivery when user selects PDF export | Usage of , TOC layout principles, performance of Raw in PDF, troubleshooting |
references/review-checklist.md
| Phase 6 | Reviewer checklists and prompt templates for each phase |
references/repair-policy.md
| Phase 7 | Minimal slice repair comparison table |
| When creating project in Phase 4 | What the scaffold does, usage, workspace structure, theme switching |
theme-profiles/index.json
| When selecting theme in Phase 2 / Writing in Phase 5 | Theme authoring profile (for AI reading, not CSS) |
| Run once in Phase 4 | One-click creation of article workspace |
| Phase 8 Delivery only if user selects PDF | HTML → PDF (headless browser + inject print CSS, zero npm dependencies) |
scripts/pdf-print-overrides.css
| When modifying PDF styles | overrides injected into by : A) TOC collapses to top-bottom layout; B) Pagination behavior (undo atomicization of , no orphaned titles, widow control, etc.); C) Cover occupies first page alone |
scripts/source-to-markdown-markitdown.py
| Phase 1 | MarkItDown main path, suitable for complex PDF / DOCX / HTML |
scripts/source-to-markdown.py
| Phase 1 | Lightweight fallback, suitable for Markdown / TXT / simple HTML or when MarkItDown is unavailable |