lunwen

Lunwen

Overview

This skill is used to stably transform "real project facts + sample papers/templates + literature constraints + chart screenshots + Word final draft requirements" into a deliverable Chinese thesis. The goal is not to make the thesis thicker, but to output, according to the sample paper length, real project capabilities, and formatting rules, a complete structure, controllable word count, complete charts, and .docx final draft.

Hard Gates

The following rules are hard constraints:

1. When the user first says "generate a thesis for the project," supporting materials must first be requested, at least including:
   • School template
   • Previous sample papers
   • Opening report / task book
   • Cover field requirements
   • Word count requirements
2. Before the user explicitly states "there are no more materials" or has already provided analyzable materials, directly generating a thesis draft is prohibited.
3. If the user provides a sample paper or template, the sample paper and styles must first be analyzed, and "recommended table of contents + target word count + style summary + conflict items" must first be returned. Only after the user confirms may the body text be written.
4. The output file name must use the thesis title, and must not use smart-lab-thesis、final、draft and similar generic names.
5. In addition to the main thesis .docx , an additional "attachment .docx" must be delivered, used to collect non-rendered versions of Mermaid / PlantUML diagram source code, database E-R diagram source code, key flowchart source code, etc. in the body text.
6. Chapter 4 "System Detailed Design and Implementation" must be the longest chapter in the entire thesis; each first-level functional module must by default include:
   • Module description
   • Page screenshots
   • Brief core code or key implementation snippets
7. If the database design section in the body text lacks an E-R diagram, it is considered incomplete.
8. If the user provides a task book / opening report / school template / sample paper, these materials must first be analyzed, and bypassing the analysis to directly generate body text is prohibited.
9. If conflicts arise among the task book, sample paper, README, old instruction documents, and source code, the default priority is "school template > task book/opening report > user's explicit requirements > sample paper > project source code > README > old instruction documents."
10. Old deployment instructions, historical project introductions, and demo documents are by default regarded as low-credibility sources; unless the user explicitly requests it, they cannot be used as the main basis for thesis facts.

Execution States

This skill executes by default according to the following state machine:

1. intake_only Only collect materials, do not write body text.
2. sample_analysis_done Sample paper / template / task book analysis has been completed, but writing has not started.
3. outline_confirmed The user has confirmed the table of contents, word count, and style plan.
4. writing_allowed Writing the body text may begin.
5. delivery_done The main thesis, attachments, and verification artifacts have been generated.

State constraints:

• Before entering outline_confirmed , writing the body text is prohibited.
• If the user submits a new template, new sample paper, or new task book midway, the state must fall back to sample_analysis_done。
• Only after entering writing_allowed is it permitted to generate the main thesis .md / .docx。

Core Flow

1. Lock inputs

First confirm the following inputs and determine their priority:

1. School template
2. Task book / Opening report
3. Past sample papers uploaded by the user
4. User's verbal requirements
5. Project source code
6. README
7. Old project documentation
8. Default skill rules

When responding to a thesis request for the first time, you must proactively tell the user that they can directly provide the local paths for templates, past sample papers, opening reports, task books, or cover requirements, with an example format such as:

• D:\论文模板.docx
• D:\论文样文1.docx
• D:\开题报告.pdf

And you must clearly state:

• If the user has not yet provided a sample paper, template, or task book, at the current stage only collect materials and analyze; do not directly start writing the draft.
• Only if the user confirms "there are no more materials" may you continue based on the project source code and default rules.

If the template, sample paper, and default rules conflict, you must list the conflicting items and let the user choose. For detailed style conflict rules, see:

• prompts/intake.md
• prompts/style_extractor.md
• references/default-style.md

2. Freeze project facts

First read the project code and documentation, then distill a fixed draft of project facts. Subsequent chapters may only be expanded based on this draft.

When freezing facts, you must clearly distinguish:

1. Task book requirements
2. Actual source code implementation
3. Final wording adopted in the thesis

If the three are inconsistent, you must tell the user in advance during the design feedback stage, and must not wait until the main text is finished to correct it.

For detailed fact extraction rules, see:

• prompts/fact_extractor.md

3. Learn the sample paper, not just the table of contents

If the user provides a sample paper or template, you must simultaneously analyze:

• Structure: table of contents, page count, word count, figure and table rhythm
• Style: headings, body text, abstract, keywords, figure captions and table captions, references, acknowledgments
• Details: font and font size of Chinese and English body text, spacing before and after paragraphs, line spacing, first-line indentation
• Headings: font, font size, bolding, alignment, and pagination method of level-1, level-2, and level-3 headings
• Tables, figures, and code: insertion positions and styles for figure captions, table captions, table content, code blocks, or code screenshots

Corresponding resources:

• prompts/sample_analyzer.md
• prompts/style_extractor.md
• tools/analyze_sample_pdf.py
• tools/analyze_docx.py

3.5 Send back the design first, then start writing

After the template and sample paper analysis is completed, you must first send the following back to the user for confirmation:

1. Current proposed thesis table of contents
2. Target word count for each chapter
3. Layout styles for body text, headings, abstract, keywords, figure captions, table captions, table content, etc.
4. Items that conflict with the default rules

When sending back, by default it must be structured as 4 tables:

1. Input materials table
2. Proposed table of contents table
3. Word count budget table
4. Style and conflict table

You must clearly wait for the user to confirm the table of contents and styles; if the user offers new revision opinions, the version finally confirmed by the user shall prevail, and only then proceed to main text writing.

If the user later supplements new sample papers, templates, or task books, you must interrupt the main text writing process, return to this step for re-analysis, and must not continue writing using the old design.

4. Set the word count first, then write

Before writing the main text, you must generate a target chapter word count table. By default, prioritize staying close to the sample paper's volume, and do not default to writing thick. After finishing each chapter, count once; if it exceeds the limit, compress it.

Corresponding resources:

• prompts/chapter_writer.md
• tools/count_chapter_words.py
• references/chapter-patterns.md

5. Closed loop for figures, tables, and screenshots

Default requirements for figures and tables:

• System architecture diagram
• E-R diagram
• Key flowchart
• Data table
• Test case table

E-R diagram rules:

• If the overall database E-R diagram is too large, it must be split into at least two:
  1. Overall table design diagram
  2. Core table design diagram
• If the business is complex, it can be further split into multiple diagrams such as "Permission and User Domain", "Appointment and Reassignment Domain", "Device and Repair Domain", "Consumables Domain", etc.
• At least two E-R diagrams, the "Overall table design diagram + Core table design diagram", must be retained in the main text

Default screenshot requirements:

• Each major module in Chapter 4 must have at least 1 page screenshot
• If a module spans "management side / user side", screenshots should preferably be provided for both sides
• Screenshot titles must correspond to the modules in the main text; vague titles such as "System page diagram" must not be used alone

Default code requirements:

• Each major module in Chapter 4 must provide at least 1 brief core code snippet, SQL fragment, or key implementation fragment
• Code should aim to "explain business rules" and should not pile up large blocks of source code
• Large blocks of source code should be placed in the appendix, not inserted directly into the main text

Minimum requirements for design diagrams in Chapter 3:

• System overall architecture diagram
• Functional module structure diagram
• Permission control flowchart
• Key business flowchart
• E-R diagram

Minimum screenshot requirements for Chapter 4:

• Each main module must have at least 1 screenshot
• When a main module spans multiple roles, screenshots for multiple roles should preferably be added
• If the total number of screenshots is fewer than 6, the implementation chapter is by default considered insufficient

If mermaid / plantumlexists, render it as a real image first; if it cannot be rendered, fall back to source code or a placeholder.

The repository has a built-in Playwright screenshot pipeline. By default, use this repository's scripts to automatically capture system pages; users are no longer required to additionally install a browser skill.

If the host environment provides a Chrome CDP / Chrome MCP connection address, it can be used as an enhanced path to reuse the current browser session; otherwise, by default the repository bootstraps Playwright Chromium.

Corresponding resources:

• tools/render_mermaid.py
• tools/ensure_thesis_assets.py
• tools/extract_screenshot_placeholders.py
• tools/build_screenshot_plan.py
• tools/capture_thesis_screenshots.py

6. Build the reference pool first, then backfill

Default constraints:

• 2020 and later
• 10-12 Chinese articles
• 3-5 English articles
• About 15 in total

Real, verifiable references must be prioritized; if uncertain, do not use them.

The literature workflow must be executed in 5 steps:

1. Build a candidate pool
2. Perform authenticity verification
3. Perform relevance screening
4. Format the references
5. Generate a literature verification checklist

Default literature quality rules:

• For Chinese sources, prioritize verifiable sources such as Peking University Core and CSCD in CNKI / Wanfang / VIP
• For English sources, prioritize verifiable DOI sources such as IEEE, Elsevier, Springer, ACM, and MDPI
• Prioritize literature from the past five years
• Prioritize highly cited literature
• Entries whose authenticity is uncertain should be discarded directly; do not write "speculative citations"

Literature deliverables must include at least:

• Reference list in the main text
• references-verified.json literature verification checklist

Default fields of the literature verification checklist:

• title
• authors
• year
• source
• doi_or_url
• citation_count_if_available
• relevance_note
• status

Corresponding resources:

• prompts/reference_selector.md
• tools/build_reference_pool.py

7. DOCX final manuscript delivery

If the environment has doc / docx capability, it must generate .docx final manuscript, rather than stopping only at Markdown.

Deliverables must include at least:

1. Main paper .md
2. Main paper .docx
3. Image mapping file
4. Attachment .docx

File naming rules:

• The main paper filename must use the paper title, e.g. 智慧实验室管理系统的设计与实现.docx
• The attachment filename must use the paper title plus "Attachment", e.g. 智慧实验室管理系统的设计与实现-附件.docx
• Do not use smart-lab-thesis、paper-final、doc1 and other generic names

Derived files should also be named consistently:

• 论文标题.md
• 论文标题.docx
• 论文标题-附件.docx
• 论文标题-image-map.json
• 论文标题-文献核验清单.json

Attachment .docx Default content:

• Mermaid / PlantUML source code in the main text
• Database E-R diagram source code
• Key flowchart source code
• Supplement with core SQL / interface structure descriptions when necessary

Default style rules:

• Abstract, Abstract, References, and Acknowledgments titles are centered
• The Chinese abstract and Abstract are on separate pages
• Level-1 chapters start on a new page
• Chinese main text in SimSun
• English main text in Times New Roman
• Chinese keywords form a separate paragraph, flush left; the "Keywords:" label uses SimHei size 12 bold, and the content uses SimSun size 12
• Except for the keywords line, the Chinese and English abstract main text defaults to a 2-character first-line indent
• The English abstract main text uses Times New Roman size 12
• English keywords form a separate paragraph, flush left, with no first-line indent, using Times New Roman size 12
• References use hanging indent

Corresponding resources:

• prompts/docx_formatter.md
• tools/generate_thesis_docx.py
• tools/analyze_docx.py
• references/default-style.md

8. Final check

Before delivery, you must check:

• Chapters are complete
• Word count is close to the sample text target
• Reference ratio is correct
• Figure and table numbering is continuous
• Whether placeholders remain
• .docx Whether it actually exists
• Whether the main paper filename is the paper title
• Attachment .docx Whether it actually exists
• Whether Chapter 4 is the longest chapter in the full text or close to the longest chapter
• Whether each major module in Chapter 4 includes screenshots
• Whether each major module in Chapter 4 includes brief core code
• Whether the number of design diagrams in Chapter 3 meets the standard
• Whether the E-R diagram is split into an overall table diagram and core table diagrams as needed
• Whether all references are within the target time range
• Whether facts from low-credibility old explanatory documents are still mixed in

Style Guardrails

The main text language follows these style constraints by default:

1. Imitate the chapter progression rhythm of the sample text, without mechanically imitating the original sentences.
2. Prioritize writing project facts, not vague conclusions first.
3. Avoid continuously piling up empty phrases such as "is of great significance", "achieved good results", and "has high value".
4. Avoid overly dense parallel sentences, templated general-specific-general structures, and obvious AI cliches.
5. Each chapter should have at least one part directly corresponding to real modules, real rules, or real data structures in the source code.
6. The acknowledgments may be appropriately more natural and human, but the main text must not be overly colloquial.

See the final check details at:

• prompts/final_checker.md

Resource Map

• Project input and conflict decisions:prompts/intake.md

• Sample text structure analysis:prompts/sample_analyzer.md

• Style extraction:prompts/style_extractor.md

• Project fact extraction:prompts/fact_extractor.md

• Chapter writing and word count control:prompts/chapter_writer.md

• Reference screening:prompts/reference_selector.md

• Word formatting:prompts/docx_formatter.md

• Final check:prompts/final_checker.md

• Default layout:references/default-style.md

• Chapter mode:references/chapter-patterns.md

• Count chapter words:tools/count_chapter_words.py

• Analyze sample PDF:tools/analyze_sample_pdf.py

• Analyze sample DOCX:tools/analyze_docx.py

• Check reference pool:tools/build_reference_pool.py

• Generate reference verification checklist template:tools/write_reference_verification_template.py

• Check figure, table, and screenshot completion:tools/ensure_thesis_assets.py

• Extract screenshot placeholders:tools/extract_screenshot_placeholders.py

• Generate figure source attachment DOCX:tools/generate_diagram_appendix_docx.py

• Generate screenshot plan:tools/build_screenshot_plan.py

• Automatically capture page screenshots:tools/capture_thesis_screenshots.py

• Render Mermaid:tools/render_mermaid.py

• Generate DOCX:tools/generate_thesis_docx.py