Awesome Ai Ppt

Awesome AI PPT

Use this skill to work with the awesome-ai-ppt curated list. Treat the list as a discovery index for AI-assisted presentation tools, not as a substitute for reading original projects.

First Step

Start from the remote awesome-ai-ppt list.

• Read the public docs/projects.json from https://github.com/ningzimu/awesome-ai-ppt or the raw GitHub URL.
• Before asking the user questions, read the already listed PPT tool entries and descriptions enough to understand the candidate space at a high level.
• Do not open every candidate's original repository before asking the user about their needs. Detailed original-repository inspection is only needed after the user's requirements narrow the shortlist.

Tool Selection Workflow

Use this workflow when the user wants recommendations, comparisons, or help choosing a PPT tool.

1. Read the existing tool entries and descriptions in the remote docs/projects.json first to understand the available candidate space. 2. Ask detailed questions about the user's real need before choosing: target audience, desired output format, editability, visual quality, automation depth, agent integration, input materials, local/cloud constraints, budget/time constraints, and tolerance for setup complexity. 3. Search docs/projects.json for a rough shortlist of 3-6 matching candidates based on the user's answers. 4. Visit the original repository for each serious candidate. Do not rely only on the awesome-list description, tags, or star count. 5. Compare the candidates on concrete evidence:

• Primary workflow and output format
• Editability of the resulting deck
• Agent skill, MCP, API, CLI, or library integration path
• Install/setup complexity
• Examples, docs, and active maintenance signals
• Known limitations or mismatches with the user's need

6. Recommend based on the user's specific constraints, not on popularity alone. In the answer, separate rough list metadata from original-repository findings. If the user explicitly asks for a quick coarse filter, say that the result has not been deeply verified.

Contribution Workflow

Enter contribution mode only when the user explicitly asks to report an issue, submit an issue, contribute a project, update the list, fix metadata, prepare a PR, or submit a PR.

Do not proactively open issues or PRs just because you notice a broken link, missing project, weak description, or possible misclassification. If the user is only choosing tools, at most mention that list problems can be reported through GitHub Issues.

When helping a third-party contributor:

1. Read references/curation-rules.md. 2. Read references/contribution-workflow.md. 3. Explain whether the project or issue appears to fit the list before editing. 4. Guide the contributor to collect evidence from the original repository: workflow, input/output formats, editability, skill/MCP support, license, stars, and maintenance. 5. If preparing a PR, describe the exact files to update and the checks to run. 6. If preparing an issue, keep it concise and include evidence links, expected category, and the requested change. 7. Do not imply that the contributor can skip the repository's bilingual and generated README requirements.

Output Style

• Keep recommendations short, evidence-based, and practical.
• Prefer canonical GitHub links.
• Say when a conclusion is based on original-repository inspection.
• Do not market projects; describe what they actually do.
• Preserve the repository's bilingual maintenance expectations when proposing or making user-facing changes.

Contribution Workflow

Use this workflow only when the user explicitly asks to contribute, modify the list, report a problem, prepare an issue, or submit a PR. Write guidance from the perspective of a third-party contributor.

Before Contributing

Help the contributor answer these questions first:

• What project or list problem are they contributing?
• Does it directly relate to AI-assisted presentation generation, PPTX editing, slide conversion, deck reconstruction, rendering, QA, or evaluation?
• Is there an existing entry in docs/projects.json with the same repo, url, name, or upstream project identity?
• Does the original repository provide enough evidence: README, docs, examples, install instructions, license, stars, and recent maintenance?

If the project does not clearly fit, explain why and suggest opening an issue for discussion instead of preparing a PR.

What A PR Should Change

For a project addition or metadata fix, tell the contributor to:

1. Fork the repository and create a focused branch. 2. Edit docs/projects.json. 3. Keep English and Chinese descriptions aligned. 4. Put the entry in the category that matches the primary workflow route, not merely the final export format. 5. Use tags and status fields for attributes such as Skill, MCP, editability, conversion, automation, or image-based output. 6. Run:

   python3 scripts/render_readme.py

7. Include the generated README.md and README_EN.md changes in the PR.

One PR should add, remove, or update one project. Do not add a new category or move unrelated entries in the same PR.

Checks To Run

Ask contributors to run:

git diff --check
python3 scripts/check_bilingual.py
python3 -m json.tool docs/projects.json

PR Description

Help the contributor include:

• The project link and canonical GitHub repository.
• Why it belongs in this curated list.
• Expected input and output formats.
• Proposed category and tags.
• Evidence for editability, skill/MCP support, and maintenance.
• Any checks run locally.

Issue Suggestions

For an issue instead of a PR:

• Keep the issue concise.
• Include evidence links from the original repository.
• State the requested change: add, update, remove, fix category, fix description, or fix link.
• Include proposed category, tags, editability, and skill status when relevant.
• Ask for confirmation before any real GitHub submission unless the user has already explicitly requested submission.

Curation Rules

Use these rules when evaluating projects for awesome-ai-ppt.

Categories

Assign the category by the source representation and primary workflow, not by the final export format.

• HTML-First Presentation Workflows: starts from HTML, web slides, DOM/CSS, Reveal.js, or page-style web presentations, then exports, screenshots, or converts to PPT/PDF/images.
• Image-First Presentation Workflows: centers on image generation or whole-slide images, then packages slides as PPTX, PDF, video, or web presentations.
• PPTX-Native Generation Workflows: directly creates editable native PPTX using PptxGenJS, python-pptx, Office XML, PowerPoint APIs, or similar.
• PPTX Libraries and Automation Infrastructure: foundational libraries, MCP servers, Office automation, backend services, conversion tooling, and editable reconstruction infrastructure.

Do not create a new top-level category for one project.

Tags And Status

Treat these as attributes, not categories:

• Skill
• MCP
• Agent
• Editable
• Partially editable
• Image-based
• Source editable
• PPTX export
• Conversion
• Automation

A project that exports PPTX is not automatically PPTX-native. A project with a skill is not automatically a generation workflow. Decide by reading the original repository's real workflow.

Inclusion

• Main-list GitHub repositories should usually have at least 10 stars.
• Research papers, official directories, or foundational resources may be included below 10 stars only when clearly useful.
• Prefer canonical GitHub repository URLs.
• Avoid duplicate entries. Check by repo, url, project name, and upstream project identity.
• Do not include generic AI writing tools without a presentation workflow.
• Do not include generic image generators without slide or deck output.
• Do not include template marketplaces without an open repository or technical workflow.
• Do not include archived, deprecated, empty, or unclear projects.

Description Style

• Keep descriptions short, factual, and non-marketing.
• Describe the project's actual workflow and output.
• Mention editability or skill/MCP support only when verified.
• Avoid claims that are not supported by the original repository.