present-workflow (from mk-present)

SKILL.md

---
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