Guide an installing agent through a staged PPT or slide workflow without constraining its implementation choices. Use when the user wants a presentation, dec...
--- name: present-workflow description: >- Guide an installing agent through a staged PPT or slide workflow without constraining its implementation choices. Use when the user wants a presentation, deck, storyboard, or slide-ready structure from a topic, article, report, or brief, and success depends on some combination of: clarifying the brief, gathering facts when needed, building an outline, creating page-level planning, generating reviewable intermediate artifacts, and degrading gracefully when the environment lacks research, rendering, or delivery capabilities. --- # Present Workflow ## Overview Treat PPT creation as staged work, not one-shot generation. This skill should tell the agent **what must happen and when**, while leaving **how to execute** to the installing agent and its environment. Do not prescribe specific search tools, browsers, MCPs, renderers, or export paths unless a particular environment explicitly requires one. ## Core Principle Constrain the workflow, not the implementation. This skill should help the agent decide: - when the brief is still unclear - when fresh fact-finding is necessary - when to stop and let the user review an intermediate result - when to continue to a fuller draft - how to respond honestly when capabilities are limited ## Capability Awareness Before substantive work, determine at a high level whether the current environment can: - gather external facts or at least work from user-supplied materials - create structured outputs such as notes, outlines, or planning drafts - create reviewable artifacts - deliver files or artifacts back to the user Only use these findings to decide what layer is achievable. Do not turn this section into a tool-selection policy. ## Supported Inputs Accept any of these entry modes. ### 1. Topic-only Example: “帮我做一个 AI 安全体检中心的 PPT” If inputs are incomplete, ask for the minimum missing fields: - audience - purpose - page-count range - preferred scenario, tone, or style - whether fresh fact-finding is needed - whether the user wants intermediate review before full generation ### 2. Topic + brief Use when the user already provides audience, purpose, scenario, style, page count, and key messages. ### 3. Source-driven request Use when the user supplies URLs, reports, PDFs, notes, transcripts, or other primary material. Treat supplied material as the main context. Add external fact-finding only when it will materially improve the result. ### 4. Existing outline or partial draft Use when the user already has a structure, early deck, or page ideas and wants improvement rather than full regeneration. ## Supported Output Layers Stop at the layer the user needs. 1. **research-brief** - facts, evidence, open questions, risks, and source references where available 2. **outline** - deck structure, section logic, page titles, and page goals 3. **planning-draft** - page-by-page planning cards that describe intent, information hierarchy, evidence needs, and layout direction 4. **sample-artifact** - one or more reviewable intermediate outputs in any form the environment can actually produce 5. **full-deck-plan** - approved structure plus planning guidance sufficient for full production 6. **review-notes** - issues in logic, evidence, density, consistency, or emphasis ## Default Workflow ### 1. Clarify the brief Collect only the inputs necessary to avoid avoidable misfires: - topic - audience - purpose - page-count range - scenario, style, or tone - must-have sections - must-avoid claims or directions - whether the user wants fast rough output or staged confirmation ### 2. Decide whether fact-finding is needed Perform fact-finding before outlining if: - the topic depends on current events, market conditions, product details, statistics, or technical facts - the user explicitly asks for research-backed content - the user-provided material is obviously incomplete If fresh fact-finding is not necessary, proceed from the supplied context. ### 3. Gather or organize context Use whatever capabilities the installing agent has to gather or organize supporting material. If external fact-finding is not possible, be explicit that the result is source-limited and rely on user-provided material instead of inventing certainty. If needed, read `references/agent-integration.md` and `references/prompts.md` before doing this step. ### 4. Produce a research brief when research matters Before building the deck, summarize the working knowledge into a compact brief: - key facts - supporting evidence - audience-relevant context - risks, caveats, and unresolved questions This brief can be short, but it should make later outlining more grounded. ### 5. Generate the outline before design Create the deck structure only after the brief and context are good enough. Read `references/prompts.md` and use the “Outline Architect” prompt when appropriate. Requirements: - preserve logical structure - keep claims aligned with available evidence - make the deck suitable for explanation, not just reading - keep the outline easy for the user to review ### 6. Add the planning draft For non-trivial decks, do not jump straight from outline to polished pages. Create page-level planning cards that specify: - the point of the page - what the audience should remember - the supporting information or evidence needed - the information hierarchy - the recommended visual or structural treatment Read `references/prompts.md` and use the “Planning Draft / 策划稿” prompt when appropriate. ### 7. Generate a reviewable intermediate artifact when useful Before scaling up, produce something the user can react to. The form is intentionally open. It might be: - a research brief - an outline - a planning draft - a sample page representation - another reviewable intermediate output the environment can actually support Do not force one artifact type if the environment or task suggests another. ### 8. Pause for review on important decks Use explicit review gates for: - external-facing decks - management or board-style decks - customer or sales decks - decks based on uncertain or fast-moving facts - complex technical topics ### 9. Scale or finalize Only after direction is accepted should the agent expand toward a fuller deck plan or richer artifacts. ### 10. Review and disclose limitations Before delivery, check: - logic - factual confidence - evidence coverage - information density - emphasis and hierarchy - consistency across sections or pages If any capability limitations affected the result, say so plainly. ### 11. Save output to file Save the final approved deck plan (or whichever output layer was delivered) to `./output/<name>.md`. Create the `./output/` directory if it doesn't exist. This markdown file serves as the input for the next skill in the pipeline (e.g. `present-html`). ## Coordination Rules ### Research rule When the task depends on facts, the agent should gather or verify supporting material before speaking with confidence. ### Honesty rule If the environment cannot support the ideal workflow, the agent should state the limitation and continue at the highest-value reachable layer. ### Review-gate rule For complex or high-stakes tasks, the agent should present intermediate work before committing to a full draft. ### Non-assumption rule The skill should never assume a specific research, rendering, preview, or export implementation path. ## Resources - `references/method.md` — distilled method and the reasoning behind staged PPT work - `references/agent-integration.md` — abstract coordination rules for agents with different capabilities - `references/prompts.md` — reusable prompts for research, outlining, planning, review, and optional format-specific generation
don't have the plugin yet? install it then click "run inline in claude" again.