Spec-Driven Presentation Maker
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."
What is Spec-Driven Presentation?
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 |
Workflow
workflow
Quick Start
One MCP server is the single integration surface. Connect your agent to it and ask for
slides — the server itself delivers the mode behavior via the start_presentation tool.
The repository is also a portable Agent Plugins package, so
clients that support that format load the MCP server and the mode entry points together.
| Environment | Setup |
|---|---|
| Claude Code | /plugin marketplace add aws-samples/sample-spec-driven-presentation-maker then /plugin install sdpm@sdpm |
| Kiro CLI | git clone this repo, then make install-kiro |
| Kiro IDE (Powers) | Install this checkout as a Power — it is an Agent Plugins package |
| Codex | codex plugin marketplace add ./ in the checkout, then install from the ChatGPT desktop app |
| Claude Desktop / any MCP client | Register servers/local as a stdio MCP server — see Getting Started |
| No MCP at all | Point your agent at sdpm/SKILL.md — it drives the CLI directly |
| Team / remote MCP / Web UI (AWS) | Deploy Guide |
Picking a mode. Just asking for slides is enough — the agent calls
start_presentation and picks. To choose explicitly, use the entry points:
sdpm-vibe (fast, from material you already have), sdpm-spec (dialogue-driven, with
approval at each step), sdpm-style (build a reusable style guide). In clients that turn
skills into slash commands, those are /sdpm-vibe, /sdpm-spec, /sdpm-style. Each one
only loads the matching persona from the server — the behavior itself still lives in
personas/, in one place.
Prerequisites for local use: uv on your PATH, plus
LibreOffice and poppler for slide previews (PNG rendering).
Keep the checkout in place for Claude Code / Kiro / local MCP: the server runs from it
(uv run --directory <checkout>/servers/local). Updating is git pull — persona and
knowledge files are read live from the checkout.
Upgrading from v0.4? Directory layout and install flows changed — see the v0.5 migration notes.
One-Click Deploy — Just an AWS Account to Get Started
| Region | Launch |
|---|---|
| Tokyo (ap-northeast-1) | Launch Stack |
| N. Virginia (us-east-1) | Launch Stack |
| Oregon (us-west-2) | Launch Stack |
See the Deploy Guide for parameter details and alternative deployment methods.
Workshop
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
Architecture
sdpm/ Engine (json <-> pptx) + Knowledge (references, assets, templates)
personas/ Mode behaviors — served to any MCP client via start_presentation(mode=...)
skills/ Mode entry points — thin dispatchers that load a persona from the server
plugin.json Agent Plugins manifest (+ mcp.json) — makes the root a portable plugin
servers/ local (stdio, no AWS) / remote (HTTP, S3 + DynamoDB) — thin binds of one tool contract
clients/ Per-client wiring (Claude Code / Codex manifests, Kiro installer)
agent/ api/ infra/ web-ui/ Optional AWS cloud stack (Strands Agent, REST API, CDK, React UI)
Everything an agent needs — tools, workflows, guides, and mode behavior — is served by the MCP server. Client-side files are minimal wiring: per-client manifests and entry points that name a mode without restating what it does. See Architecture for the full picture.
Documentation
| 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) |
| 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 |
| Uninstall | Clean up deployed AWS resources |
| Web UI (Local Mode — experimental) | Run the Web UI locally against a Kiro CLI ACP backend (no AWS) |
Testing
make all # Lint + unit tests
make test # Unit tests only
make lint # ruff lint only
Contributing
Contributions are welcome.
See CONTRIBUTING.md for details.
Code of Conduct
This project has adopted the Amazon Open Source Code of Conduct.
Security
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.
Security Measures Implemented
- 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
Environment-Dependent Settings (Not Applied by Default)
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
Reporting Security Issues
Found a potential vulnerability? Please do not file a public GitHub issue — follow the process in CONTRIBUTING.md.
License
This project is licensed under the MIT-0 License.