Academic Paper Strategist

Inputs To Gather

• Repository root
• Existing draft thesis (.docx, .md, or both)
• School template or format sample (.doc, .docx, or .pdf)
• Core evidence files such as:
  • build file (pom.xml, package.json, etc.)
  • architecture docs
  • business logic docs
  • SQL schema / migration files
  • entities / DTOs / controllers / services
• Detection reports when available (.pdf, .docx, screenshots, extracted text)
• Required deliverable path(s)

Workflow

Step 1: Ingest Constraints

Record:

• target school and thesis type
• final deliverable format
• whether the task is planning only or full finalization
• whether the task must continue from a hand-edited working draft
• whether the user wants original figures/tables preserved
• whether real running screenshots are required
• required output paths

If the user gives explicit source and destination paths, treat them as binding.

Step 2: Load School Format Authority

When a school sample is present, read references/zjkj-undergrad-thesis-format.md and extract:

• required front-matter order
• heading hierarchy
• body typography and spacing
• figure and table caption rules
• reference formatting
• appendix and acknowledgement rules
• any page-numbering constraints visible in the sample

If the sample contains instructional text boxes or placeholder hints, mark them as "remove from final manuscript".

Step 3: Audit The Existing Draft

Classify each section into:

• keep with minor edits
• keep but downgrade claims
• rewrite from project evidence
• delete entirely
• preserve as a legacy asset and restore if lost later

Always flag for removal:

• process notes
• template prompts
• instructional text boxes
• unsupported novelty claims
• unsupported metrics or deployment claims
• colored headings or hyperlink-styled text
• diagrams that do not match engineering-paper style

Also mark:

• original E-R figures the user wants to keep
• original database per-table field-description blocks
• user manual edits that must not be overwritten
• sections where only a partial range should be replaced

Step 3A: Triage Detection Reports When Present

When the user asks to lower similarity or AIGC risk and provides reports, read references/detection-report-rewrite-playbook.md.

At this stage, the strategist should:

• extract the headline score and hotspot pages
• map hotspots back to thesis sections
• classify causes and rewrite intensity
• tell the composer where to perform heavy structural rewrites versus light cleanup

Step 4: Build An Evidence Map

For each chapter, map every major claim to repo evidence:

• Background / system positioning -> docs and project summary
• Architecture -> package structure, config, controllers, services
• Database design -> SQL schema and entities
• Business workflows -> controllers, services, docs
• Security / consistency mechanisms -> config, service logic, transactional code, locking, signatures, validation
• Testing chapter -> only real screenshots, test classes, manual verification records, or observable system behavior

If a claim cannot be mapped to an evidence source, it cannot appear in the final thesis.

Step 5: Produce The Thesis Plan

Output a handoff package for the composer containing:

• cleaned chapter outline
• per-chapter evidence sources
• claims allowed
• claims forbidden
• figures to redraw
• legacy figures/tables to retain or restore
• exact section ranges to replace if the user only wants partial rewriting
• risky items requiring manual verification
• runtime screenshot capture plan when screenshots are needed
• when detection reports exist: a page-to-section rewrite matrix and a rewrite-priority list

When the handoff will drive a live DOCX revision, make it explicit enough that the composer can execute without re-deciding replacement boundaries, preserve lists, or screenshot targets.

The outline should normally include:

• cover / declarations / abstracts / TOC
• chapter 1 introduction
• chapter 2 requirements analysis
• chapter 3 overall design
• chapter 4 detailed implementation
• chapter 5 testing
• chapter 6 conclusion
• references
• acknowledgements
• appendices if needed

Step 6: Produce A Figure And Screenshot Plan

Only the following figure types are allowed when the user asks for a software engineering undergraduate thesis:

• system architecture diagram
• functional module diagram
• business process diagram
• sequence diagram
• E-R diagram
• use case diagram
• real running-system screenshots tied to actual thesis sections

For every planned figure or screenshot, define:

• chapter placement
• source basis in code/docs/runtime
• labels that must appear
• labels or components that must not appear
• whether an old figure can be retained or must be redrawn
• whether the screenshot needs seeded demo data first

All redrawn figures must use engineering-paper visual style:

• white background
• black or gray lines
• no decorative icons
• no infographic styling
• no color-dependent meaning

Existing-Draft Rework Mode

When the user asks for a final thesis from an existing draft:

• do not start from a blank paper unless the draft is unusable
• identify what to preserve and what to rewrite
• create a section-by-section rewrite brief for academic-paper-composer
• explicitly note any unsupported content that must be deleted rather than softened
• require the composer to operate on a copied draft or user-designated working draft, never the wrong file

When the user specifically asks to continue on a hand-edited draft:

• record the working draft path and the protected backup/original path separately
• plan replacement anchors by body heading style only
• forbid TOC-based anchor matching in the handoff
• identify which old figures/tables must survive the rewrite

When the user specifically asks to lower similarity or AIGC:

• identify the smallest set of sections that dominates the score
• prioritize Chinese narrative paragraphs over low-yield formal sections
• prefer a few high-impact structural rewrites over broad shallow edits
• use the rewrite modes defined in references/detection-report-rewrite-playbook.md

References To Load As Needed

• references/zjkj-undergrad-thesis-format.md - school format authority
• references/project-grounding-rules.md - anti-fabrication and evidence rules
• references/finalization-task-rules.md - mandatory workflow for final DOCX delivery
• references/detection-report-rewrite-playbook.md - how to triage plagiarism / AIGC reports into a rewrite brief
• references/draft-salvage-handoff-playbook.md - how to plan partial replacement, legacy-asset retention, and runtime screenshots
• references/chinese-call-prompt-templates.md - copy-paste Chinese prompts for planning and handoff tasks

Example Prompts

• 根据当前仓库和学校模板，先给我做一个本科论文定稿规划，只保留代码里能证实的内容。
• 我已经手改初稿到正文 2.3 前了，帮我做 keep/rewrite/delete 矩阵，要求保留原数据库 E-R 图和每张表的字段说明。
• 这是查重报告和 AIGC 报告，先别直接改正文，先把热点页映射到章节并给出重写优先级。
• 继续在我现在的 working draft 上做规划，只替换 2.4 之后的正文内容，前面手改部分不要动。
• 帮我给论文补一个运行截图规划，说明每张截图对应哪个角色、哪个页面、哪个章节。

Output Expectations

Produce:

• a thesis outline with up to 3 heading levels
• a chapter-by-chapter evidence map
• a keep / rewrite / delete matrix for the current draft
• a figure/table/screenshot rebuild plan
• a list of unsupported claims to remove
• a handoff package for academic-paper-composer
• when reports are supplied: a detection-report triage summary with hotspot pages, mapped sections, and recommended rewrite intensity

Do not claim that the paper is submission-ready at this stage. That decision belongs to the composer + drawio + playwright + doc flow.