Academic Paper Strategist

Academic Paper Strategist

Overview

This is the planning skill for Codex-based software engineering theses. Use it before drafting or finalizing a thesis from a real repository. Its job is to reduce hallucination risk, map project evidence to chapters, and define only the claims, figures, tables, and tests that can be justified by the actual codebase and supplied school format sample.

Companion flow:

1. academic-paper-strategist - planning, evidence mapping, rewrite scope
2. academic-paper-composer - content rewrite and final manuscript assembly
3. drawio - redraw engineering-style thesis figures when required
4. playwright - capture real runtime screenshots when the thesis needs running-system evidence
5. doc - produce and visually check the final DOCX

Do not skip the strategist step when the user asks for a submission-ready undergraduate thesis from an existing project and draft.

Core Rules

• Read project evidence before outlining. Prefer repository files, SQL, config, docs, controllers, services, entities, and the existing draft.
• Treat the existing draft as untrusted input. Keep only what can be supported by project evidence.
• If the user has already hand-edited part of a draft, treat that working draft as a protected artifact and plan around it instead of blindly replacing the whole manuscript.
• If the user provides plagiarism, similarity, or AIGC detection reports, treat them as rewrite-priority signals, not as sources of truth about the project. Load references/detection-report-rewrite-playbook.md when this applies.
• If the user provides a school format sample, load references/zjkj-undergrad-thesis-format.md first and treat it as the highest authority for structure and formatting.
• If the task is to produce a final thesis from an existing draft, also load:
  • references/project-grounding-rules.md
  • references/finalization-task-rules.md
• Load references/draft-salvage-handoff-playbook.md when the user wants to continue a partially edited draft, keep original figures/tables, or add running-system screenshots.
• Never invent features, APIs, data tables, performance numbers, deployment scale, user scale, concurrency benchmarks, or test results.
• Reframe "innovation" conservatively as engineering highlights, implementation choices, integration value, or maintainability benefits.
• Only plan figures that are supported by code or project docs. Omit unsupported diagrams.
• Keep the thesis compatible with an automatic table of contents and school-required front matter.

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.