name: awesome-ieee-report description: Generates IEEE-format LaTeX technical reports from project requirements and codebase evidence, using academic prose, pseudocode-only explanations, BibTeX references, and IEEEtran formatting.

LaTeX Technical Report Creator

Creates IEEE-format LaTeX technical reports for software and engineering projects. The skill reads a project's requirement document (if available), analyzes the codebase for evidence, and produces a pure academic report with no code references.

Non-Negotiable Rules

Apply these rules on every run unless the user explicitly overrides them:

1. Language: Report body language follows the user's preference (default: English). Turkish is used when the user explicitly requests it.
2. Requirement-first (when available): Section headings and coverage are driven by the project requirement document, not by convenience. If no requirement document exists, use the standard IEEE section structure as baseline.
3. No source code dump: Do not paste project source code blocks into the report.
4. Pseudocode only: Include algorithm-level pseudocode (IEEE algorithm environment) for core flows instead of raw implementation code.
5. Figures as placeholders: All figures are inserted as labeled placeholders. Real screenshots are added manually by the author. Never generate or embed actual images during skill execution.
6. Consistency gate: Report statements must be checked against actual code before finalizing.
7. NO code artifacts in report body: Never include file paths (.dart, .py, .ts, .json, etc.), class names, function names, variable names, directory structures, or any implementation-level identifiers in the report text. The report is a pure academic document — describe WHAT the system does and HOW it works conceptually, not WHERE the code lives.
8. Minimum 3 figures: Every report must include at least 3 figure placeholder entries with capture intent description.
9. Academic tone: Write as if submitting to an IEEE conference. No informal language, no first-person singular, no code jargon. Use domain vocabulary (algorithm, module, layer, mechanism, component) instead of implementation vocabulary (service, controller, repository, widget).
10. IEEE format: Use \documentclass[conference]{IEEEtran}, minimum 4 pages in two-column format.
11. Assignment document is not a bibliography source by default: The requirement/assignment document defines coverage obligations, but it should not automatically appear in the final bibliography unless the user explicitly asks for it.
12. Independent academic narration: The report must synthesize evidence into original academic prose rather than shadowing the wording, enumeration style, or example framing of the requirement handout.
13. Table-first compression: Long enumerations such as option mappings, inventories, thresholds, parameter groups, and metric sets should be converted into compact booktabs tables when this improves IEEE two-column readability.
14. Float hygiene: Avoid placing several large tables/figures back-to-back in the same local area when this creates obvious white-space holes or pushes related prose apart; distribute floats across adjacent narrative blocks when needed.

If any rule conflicts with user instruction, follow the user instruction and explicitly note the override.

When To Use

Use this skill when requests include terms like:

• technical report / teknik rapor
• latex report
• ieee format / ieee rapor
• project documentation / proje raporu
• conference paper / paper yazma

Inputs

Collect these inputs first:

• Requirement source file (PDF/markdown), if available: expected sections and mandatory content
• Target scope (full project, phase, or module)
• Output directory for .tex and .bib files
• Report language preference (default: English)
• Author name(s), affiliation (university/company/department), and contact info

Section Structure

Section headings must be derived from the project requirement document when one exists. If no requirement document is provided, use the standard IEEE technical report structure below.

As a baseline, every report should include at minimum:

1. Introduction — project goal, scope, motivation
2. Related Work — prior art, relevant literature
3. System Architecture and Methodology — architecture, technology stack, data management
4. [Project-specific sections] — one section per major functional area or contribution
5. Evaluation / Results — test approach, metrics, results
6. Conclusion and Future Work — summary, completion status, future work

Do not remove required sections from the requirement document. Additional sections are allowed only if they do not hide mandatory items.

Workflow

Report Build Progress
- [ ] Step 1: Read requirement document
- [ ] Step 2: Analyze codebase for evidence (internal only)
- [ ] Step 3: Build requirement-to-section map
- [ ] Step 4: Write LaTeX report with academic prose
- [ ] Step 5: Create BibTeX references file
- [ ] Step 6: Insert figure placeholders
- [ ] Step 7: Run quality gate

Step 1: Read Requirement Document (If Available)

• If a requirement document exists, parse it to identify mandatory sections, constraints, and deliverables.
• If no requirement document is provided, proceed with the standard IEEE section structure from the Section Structure baseline.
• If a previous report exists as reference (e.g., an MD file from a prior project), use it for style cues only — not content.

Step 2: Analyze Codebase For Evidence (Internal Only)

• Read relevant source files to understand algorithms, architecture, data models, and behaviors.
• CRITICAL: This is an INTERNAL step. The facts extracted inform the report prose, but file paths, class names, function names, and code identifiers must NEVER appear in the final report text.
• For each requirement, understand the implementation approach conceptually (algorithm, data structure, strategy) and describe it in academic language.
• If code and requirement conflict, note the conflict before writing.

Step 3: Build Requirement-To-Section Map

• Convert each requirement into a report section obligation.
• Attach evidence category: architecture decision, algorithm behavior, test result, or UI behavior.
• Mark each requirement: covered, partial, missing.
• Do not draft prose until all mandatory items are mapped.

Step 4: Write LaTeX Report

• Use \documentclass[conference]{IEEEtran} with appropriate babel language package.
• Write purely in academic prose — ZERO code identifiers anywhere.
• Use IEEE algorithm environment with algorithmic for algorithmic flows.
• Use booktabs tables for parameters, thresholds, and feature summaries.
• Convert list-heavy prose into tables when the content is effectively a mapping, inventory, grouped configuration, or repeated option set.
• Keep narrative flow as prose when a small table would harm readability more than help it; use judgment rather than forcing every short list into a table.
• Do NOT cite the assignment PDF/MD as a source by default; cite only external technologies, papers, algorithms, standards, or data sources actually used by the project.
• Rewrite report explanations into independent academic narration instead of echoing the assignment document's phrasing or illustrative framing.
• Use \cite{} for all external references.

Step 5: Create BibTeX References

• Create a references.bib file with entries for all cited technologies, algorithms, and data sources.
• Include framework documentation, algorithm papers, and data sources used in the project.

Step 6: Insert Figure Placeholders

• Insert at least 3 figure placeholder entries using \fbox{} blocks.
• Each placeholder must include: label, caption, capture source, and expected content description.
• The author will replace placeholders with \includegraphics manually after capturing screenshots.

See: reference/image-policy.md

Step 7: Run Quality Gate

See: checklists/quality-gate.md

Writing Style Contract

• Tone: Formal, academic, IEEE conference paper level.
• Language: Match the user's language preference. English by default; use Turkish when explicitly requested. Foreign technical terms with no equivalent in the report language may be kept in English.
• Granularity: Explain architecture and algorithm decisions, not implementation details.
• Vocabulary: Use domain terms NOT code terms:

• Allowed in report:

  • Pseudocode (IEEE algorithm environment)
  • Tables (parameters, thresholds, feature comparisons)
  • Architecture descriptions in prose
  • Figure placeholders with capture intent

• Strictly forbidden in report body:

  • File paths (e.g., lib/src/...)
  • Source code blocks or inline code
  • Class/function/variable names
  • Directory structure listings
  • Any .dart, .json, .py, .ts, .yaml file reference

The report reader should understand the system without ever seeing the codebase.

Output Contract

Always produce:

1. LaTeX file (.tex) using IEEEtran conference class
2. BibTeX file (.bib) with all references
3. Build README explaining how to compile
4. At least 3 figure placeholders with capture intent
5. Minimum 4 pages in IEEE two-column format

Templates and References

• templates/report-template.tex — LaTeX skeleton
• templates/report-template.md — Markdown skeleton
• templates/figure-placeholders.md — Figure placeholder format
• checklists/quality-gate.md — Final quality checklist
• reference/image-policy.md — Figure handling rules
• reference/style-baseline.md — Academic style baseline
• reference/requirements-mapping.md — Requirement mapping guide
• reference/repo-evidence-sources.md — Evidence gathering guide

Example

For a minimal example output outline, see:

• examples/sample-filled-outline.md