An open-source toolkit for creating presentations using a spec-driven approach. Design "what to communicate" first, then let AI build "how to present it."
Traditional slide creation follows a "open a blank slide and figure it out as you go" approach. Without a clear structure, time is spent tweaking visuals while the core message gets diluted.
Spec-driven presentation applies the concept of Spec-Driven Development from software engineering to presentation creation.
| Traditional | Spec-Driven | |
|---|---|---|
| Starting point | Blank slide | Source materials and requirements |
| Design | Think while building | Define logical structure as a spec first |
| Build | Manual layout | AI builds automatically following the template |
| Quality | Ad hoc | Reviewable process based on the spec |
Beyond creating a new deck from scratch, the agent is routed to these workflows automatically — just describe what you want:
| Ask | What happens |
|---|---|
| "Make slides about …" | New presentation (brief → art direction → outline → parallel slide composition → review) |
| "Edit this PPTX" | Imports an existing PPTX into an editable deck |
| "I hand-edited the PPTX, continue from it" | Syncs your PowerPoint edits back into the deck |
| "Create a style like …" | Builds a reusable style guide (colors, typography, decoration) |
| "Translate this deck to English" | Creates a language-variant deck next to the original (source deck untouched) |
One command installs everything into ~/.sdpm — the MCP server your AI agent talks to
and, if you want it, a browser Web UI. Both run from the same checkout and update together.
(Claude Desktop is the one exception: it takes a downloadable bundle instead, see below.)
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/aws-samples/sample-spec-driven-presentation-maker/main/scripts/install/dist/install.sh | bash# Windows (PowerShell; verified in CI only)
irm https://raw.githubusercontent.com/aws-samples/sample-spec-driven-presentation-maker/main/scripts/install/dist/install.ps1 | iexThe installer asks two things — whether to add the browser Web UI (needs Node.js) and, as a checklist of the MCP clients it finds, which to connect — and ends with a table of what it registered. Then:
| You want to | Do this |
|---|---|
| Use your own AI agent (Claude Code, Cursor, VS Code, Codex) | Said yes when the installer offered to register it? Ask the agent “Make slides about …”. Otherwise, or for another client later: sdpm register |
| Use Kiro CLI | The installer creates a dedicated sdpm agent (its own tools and trust settings, nothing added to other sessions): kiro-cli chat --agent sdpm |
| Use a browser | sdpm webui |
| Use Claude Desktop | Download sdpm.mcpb and double-click it (no installer needed) |
| Give a team a shared server or Web UI | Deploy on AWS |
sdpm alone shows what is installed and connected; sdpm update upgrades both surfaces;
sdpm uninstall removes everything. Slide previews (PNG) need LibreOffice and poppler — the
installer offers them, and a build without them still produces the PPTX and tells the agent
what is missing. See Getting Started for options, manual
client configuration, and the developer setup.
Many people hand this repository's URL to a coding agent and say "install this". If that is you (or the agent), the non-interactive form is:
curl -fsSL https://raw.githubusercontent.com/aws-samples/sample-spec-driven-presentation-maker/main/scripts/install/dist/install.sh | bash -s -- --mcp-only --non-interactive --register--mcp-only skips the browser Web UI (drop it, or use --full, to include it — needs
Node.js 20+); --register connects every MCP client found on the machine without asking
(--no-register prints the configuration instead). Then verify with sdpm (status) and
python3 ~/.sdpm/checkout/scripts/install/mcp_smoke.py ~/.local/bin/sdpm mcp. Full option
list: Getting Started.
Breaking change for agents migrating an older setup (before the installer): the Claude Code / Codex plugins, the Kiro Power,
make install-kiro, theskills/directory and anyuvx … sdpm-mcpclient entry no longer exist. Remove them as listed in Migration: onboarding — in particular a leftover~/.kiro/agents/sdpm-composer.jsonor a global~/.kiro/settings/mcp.jsonentry, both of whichsdpm register kiro-clidetects and offers to remove. Tool names, prompts and deck files are unchanged.
Picking a mode. Just asking for slides is enough — the agent calls start_presentation
and follows it. To choose explicitly, use the server's prompts where your client shows them:
sdpm-vibe (build from material, no questions), sdpm-spec (shape the deck in dialogue
first), sdpm-style (a reusable style guide), sdpm-translate (a language variant of a deck) — Claude
Desktop's "+" menu, Claude Code /mcp__sdpm__sdpm-vibe, VS Code /mcp.sdpm.sdpm-vibe, Kiro CLI
/sdpm-vibe. Each prompt only names the role's entry tool; the behavior itself still lives in
sdpm/references/workflows/, in one place.
Upgrading from an older release? See the breaking-change note above and Migration: onboarding. Older changes: v0.5, role workflows.
| Region | Launch |
|---|---|
| Tokyo (ap-northeast-1) |  |
| N. Virginia (us-east-1) | |
| Oregon (us-west-2) | |
See the Deploy Guide for parameter details and alternative deployment methods.
A hands-on workshop is available with sample data for various real-world scenarios. Practice generating slides from URLs, PDFs, CSVs, meeting minutes, and more — with industry-specific scenarios for manufacturing, financial services, healthcare, IT, and others.
📖 Workshop
sdpm/ Engine (json <-> pptx) + Knowledge (references, assets, templates)
references/workflows/ — role documents (orchestrator, composer, style,
translate), delivered to any MCP client by the start_* entry tools
servers/ local (stdio, no AWS) / remote (HTTP, S3 + DynamoDB) — thin binds of one tool contract
local/client_config.py wires the server into MCP clients (sdpm register)
scripts/install/ installer + `sdpm` launcher for macOS / Linux / Windows; scripts/mcpb/ the Claude Desktop bundle
agent/ api/ infra/ web-ui/ Optional AWS cloud stack (Strands Agent, REST API, CDK, React UI)
Everything an agent needs — tools, workflows, guides, and role behavior — is served by
the MCP server. Nothing lives on the client side: a client only holds the one line that
starts the server, and sdpm register writes that line for you.
See Architecture for the full picture.
| Document | Description |
|---|---|
| Getting Started | Setup for every environment, from bare CLI to full AWS stack |
| Architecture | Layer design, data flow, auth model, MCP tool reference |
| Migration to v0.5 | Upgrading from v0.4 (paths, skills removal) |
| Migration: role workflows | Upgrading from v0.5 (workflow consolidation and renamed tools/skills) |
| Migration: onboarding | Upgrading from plugins / skills / make install-kiro / uvx to the installer |
| Recommended Deploy | AWS deployment via CloudShell (no CDK/Docker required) |
| Connecting Agents | MCP client connection guide |
| Teams & Slack Integration | Chat platform integration |
| Custom Templates & Assets | Adding custom templates and icons |
| Cost Estimates | Monthly cost breakdown and optimisation tips |
| Measuring Usage | Per-user token & slide-count measurement for PoC operators |
| Uninstall | Clean up deployed AWS resources |
| Web UI (Local Mode) | Run the Web UI locally against a Kiro CLI ACP backend (no AWS) |
make all # Lint + unit tests
make test # Unit tests only
make lint # ruff lint onlyContributions are welcome.
See CONTRIBUTING.md for details.
This project has adopted the Amazon Open Source Code of Conduct.
This is sample code for demonstration and educational purposes only, not for production use. You should work with your security and legal teams to meet your organizational security, regulatory and compliance requirements before deployment.
- S3 Buckets: Public access blocked, server-side encryption (SSE-S3), versioning enabled
- DynamoDB: Encryption at rest enabled, point-in-time recovery enabled
- Data in transit: All traffic encrypted via TLS
- IAM: Least-privilege roles scoped per service; no wildcard resource permissions
- API Gateway: Cognito JWT authorizer on all endpoints
- CloudFront: Origin Access Identity (OAI), HTTPS-only, security headers
- Secrets: No hardcoded credentials; all secrets via environment variables or IAM roles
- AI/GenAI: Model outputs labeled as AI-generated; dataset compliance documented
- Logging: CloudWatch Logs with configurable retention; Bedrock invocation logging optional
The following controls depend on your organization's environment, network topology, or security policy — they cannot be safely defaulted in a sample stack. Evaluate each before production use.
- AWS CloudTrail — account-level setting; enable separately to avoid disrupting existing CloudTrail configurations
- VPC endpoints for S3 and DynamoDB — only relevant if you deploy inside a VPC (this stack does not)
- AWS WAF IP restrictions — built-in support, but IP ranges are environment-specific: set
waf.allowedIpV4AddressRanges/waf.allowedIpV6AddressRangesinconfig.yaml, or pass--waf-ipv4/--waf-ipv6todeploy.sh - CORS tightening — depends on your domain
- S3 access logging — log destination bucket and retention are your choice
- Cognito advanced security (MFA, compromised-credentials detection) — omitted by default to keep the demo frictionless
- Bedrock model / region selection — avoid cross-region inference profiles if data sovereignty is a concern
- Snapshot-safe cryptographic libraries — only relevant if you opt the AgentCore runtimes into
platformVersionV2, which this stack does not do (CloudFormation and the CDK cannot set that field, so a deployment of this sample runs V1). V2 restores every instance from one snapshot, so a userspace RNG seeded before the snapshot is shared across instances. Values this stack derives from the kernel are unaffected —uuid.uuid4()andsecretsreadgetrandom(2)per call, and SigV4 signing is HMAC-based and deterministic — so the exposure is limited to OpenSSL's own DRBG behind outbound TLS. If you enable V2, replace the MCP runtime's OpenSSL with a snapshot-safe build (openssl-snapsafe-libson Amazon Linux 2023, which conflicts withopenssl-libsand therefore needs--allowerasing), or use an AWS-provided base image that already ships one.
Found a potential vulnerability? Please do not file a public GitHub issue — follow the process in CONTRIBUTING.md.
This project is licensed under the MIT-0 License.