Automated summary
Creates a Marp Markdown slide presentation for an existing XDRS document (policy, research, article, or plan) while following the framework's presentation standards.
Strengths
- Enforces a clear linear storytelling structure (context, problem, solution, next steps)
- Adjusts content to the target audience (executives, engineers, specialists, control)
- Handles naming conventions, .assets/ placement, and bidirectional links with the parent document
- Suggests varied slide formats (Mermaid, tables, bullets, ASCII art) and caps the deck under 30 slides
Limitations
- Rejects standalone presentations: a parent document must already exist
- Assumes the reference files .xdrs/_core/adrs/principles/009 and 001 are present
- Does not cover exporting or rendering through Marp, only writing the Markdown file
Use this skill when an XDRS document already exists and you want to produce a slide deck for it tailored to a specific audience.
Don't use it to build a presentation without a source document, or to draft an article or policy from scratch.
Security analysis
SafeThe skill is purely editorial: it reads existing XDRS documents, plans Marp slide content, writes a new Markdown file into a `.assets/` folder, adds a link to the parent doc, and runs a documented lint command. There is no obfuscation, no destructive command, no secret/token handling, and no outbound data transmission. The only execution surface is the `npx -y xdrs-core lint .` call, which is a normal (if unpinned) tooling invocation, so overall risk is minimal.
- •Phase 8 runs `npx -y xdrs-core lint .`, which downloads and executes an unpinned npm package from the network; legitimate lint step for the framework but is a supply-chain surface if the package name is ever squatted or the skill is run in an untrusted repo.
- •Phases 6-7 instruct modifying the parent document in place (adding a References link), so the skill writes to files outside the `.assets/` output folder; edits are additive and low risk but not confined to a single output path.
Examples
Create a slide deck for the policy document 005-rail-standards.md, aimed at executives.Generate slides for the article 001-xdrs-overview.md targeted at engineers.Make both an executive and a technical slide set for 003-naming-conventions.md.name: _core-adr-skill-007-write-presentation description: > Creates a Marp slide presentation for an existing XDRS document (policy, research, article, or plan). Activate this skill when the user asks to create slides, a presentation, or a slide deck for an XDRS document. metadata: author: flaviostutz version: "1.0"
Overview
Guides the creation of a Marp Markdown slide presentation that supports an existing XDRS document. The skill ensures the slides follow presentation standards (_core-adr-policy-009), are correctly placed in the .assets/ folder, and maintain bidirectional links with the parent document.
Instructions
Phase 1: Identify the Parent Document
- Read
.xdrs/_core/adrs/principles/009-presentation-standards.mdin full to internalize all presentation rules. - Read
.xdrs/_core/adrs/principles/001-xdrs-core.mdfor.assets/placement rules and general framework structure. - Identify the parent document (policy, research, article, or plan) that the slides will support. The parent document must already exist. If no parent document exists, inform the user that slides cannot be standalone and suggest creating the parent document first.
- If the user wants slides covering content from multiple documents, check whether an article already exists that synthesizes those documents. If not, suggest creating an article first (using the 004-write-article skill) and then creating slides for that article.
Phase 2: Define the Presentation Scope
- Read the parent document in full.
- Define the central message or objective of the presentation. If the objective is ambiguous or there are multiple possible paths, ask the user before proceeding. Ask one question at a time.
- Identify the target audience. Check the parent document for audience indicators. If unclear, ask the user. Common audiences:
- Executives: high-level, strategic, outcome-focused
- Engineers: technical depth, implementation details, trade-offs
- Specialists: domain-specific depth, compliance, controls
- Control: risk, compliance, audit, governance focus
- Determine if multiple slide sets are needed for different audiences. If so, create separate files for each.
Phase 3: Plan the Slide Structure
- Extract the most important points from the parent document.
- Organize slides following a linear storytelling structure:
- Context: what is the situation, background, who is impacted
- Problem: what needs to be decided, addressed, or understood
- Solution/Decision: what was decided and why
- Actions/Next Steps: what happens now, who is responsible
- For each slide, identify the best format:
- Mermaid diagrams for flows, relationships, architecture
- Short bullet points for key decisions and trade-offs
- Tables for comparisons, options, criteria
- ASCII art for simple layouts or structures
- Key short statements for emphasis
- Longer text only when exact wording must be evaluated (policies, controls)
- Keep the total under 30 slides. If more content is needed, plan separate slide sets.
Phase 4: Determine the File Name
- Take the parent document file name (without
.mdextension). - Append
-slidesfor the primary set. - If multiple sets exist, append a context indicator:
-slides-overview,-slides-executive,-slides-technical, etc. - Verify the final file name (including
.md) is 64 characters or fewer. If it exceeds 64 characters, shorten the base name while keeping it recognizable. - Ensure the file name is entirely lowercase.
Examples:
- Parent:
003-naming-conventions.md->003-naming-conventions-slides.md - Parent:
005-rail-standards.md(executive audience) ->005-rail-standards-slides-executive.md - Parent:
001-xdrs-overview.md(article) ->001-xdrs-overview-slides.md
Phase 5: Write the Slides
Create the Marp Markdown file with this structure:
---
marp: true
---
# [Presentation Title]
[Subtitle or context line]
[Audience and date if relevant]
---
[Slide 2: Context/Background]
---
[Slide 3: Problem Statement]
---
[... additional slides ...]
---
# References
- [Parent document title](relative/path/to/parent.md)
- [Other related documents if applicable]
Rules:
- The first line of YAML frontmatter must be
marp: true. Additional Marp keys (theme,paginate,header,footer) may be added after. - Use
---as the slide separator (standard Marp syntax). - The last slide must contain links back to the parent document and any other related documents.
- Minimize text per slide. Prefer visual elements and short statements.
- Stress central questions, answers, doubts, decisions, and risks from the parent document.
- No emojis.
- Use relative paths for all links.
- Follow the audience-appropriate level of detail.
Phase 6: Update the Parent Document
- Add a link to the slide file in the parent document. Place it in the
## Referencessection or, for Policies, in the most appropriate section. - Use a descriptive link text such as "Presentation slides" pointing to the slide file in
.assets/.
Phase 7: Write Files
- Create the slide file at the correct
.assets/location:- Policies:
[xdrs-root]/[scope]/[type]/[subject]/.assets/[slide-file].md - Articles:
[xdrs-root]/[scope]/[type]/[subject]/articles/.assets/[slide-file].md - Research:
[xdrs-root]/[scope]/[type]/[subject]/researches/.assets/[slide-file].md - Skills:
[xdrs-root]/[scope]/[type]/[subject]/skills/[number]-[skill-name]/.assets/[slide-file].md - Plans:
[xdrs-root]/[scope]/[type]/[subject]/plans/.assets/[slide-file].md
- Policies:
- Update the parent document with the link to the slide file.
- Verify that the slide file name is <= 64 characters and lowercase.
Phase 8: Verify with Lint
- Run the CLI lint utility from the repository root:
npx -y xdrs-core lint . - Fix all reported errors before considering the task complete.
Constraints
- MUST follow presentation standards from
_core-adr-policy-009exactly. - MUST NOT create slides without an existing parent document.
- MUST NOT create standalone slides that reference multiple documents without an article as the parent.
- MUST maintain bidirectional links between slides and parent document.
- MUST keep slide file names under 64 characters.
- MUST include
marp: truein the slide frontmatter. - MUST keep presentations under 30 slides.
- MUST ask the user about audience and objective when not clear from context.
Examples
Input: "Create slides for our naming conventions decision"
- Locate the parent Policy (e.g.
003-naming-conventions.md) - Ask: "Who is the target audience for these slides?"
- Create:
.assets/003-naming-conventions-slides.md - Update: Add link in
003-naming-conventions.md
Input: "Create an executive presentation covering our security and data decisions"
- Check if an article synthesizing security + data decisions exists
- If not, suggest creating the article first
- Create slides for the article, not the individual Policies
Edge Cases
- If the parent document does not exist, do not create slides. Inform the user and suggest creating the parent first.
- If the slide file name would exceed 64 characters, shorten the base name while keeping it recognizable.
- If the content requires more than 30 slides, split into multiple slide sets with distinct audience or topic focus.
- If the parent document changes after slides are created, the slides must be reviewed and updated.
References
From the file to a first result
The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.
View the source and supporting filesThis download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.
1. Download the file
Download SKILL.mdFrom the root of a test project, save the file as .skill-downloads/write-presentation-slides-ms1aw5n6/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.
Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.
mkdir -p '.skill-downloads/write-presentation-slides-ms1aw5n6' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/write-presentation-slides-ms1aw5n6/download' --output '.skill-downloads/write-presentation-slides-ms1aw5n6/SKILL.md.part' && mv '.skill-downloads/write-presentation-slides-ms1aw5n6/SKILL.md.part' '.skill-downloads/write-presentation-slides-ms1aw5n6/SKILL.md'2. Check prerequisites
Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.
No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.
The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.
3. Load the skill
This file does not provide a usable name/description header for this native procedure. It remains available to download and inspect; use the manual method below.
Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.
4. Try a first task
Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:
Read .skill-downloads/write-presentation-slides-ms1aw5n6/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.
Supabase Docs Authoring
Documentation
Write, edit, and review Supabase documentation content including guides, tutorials, reference docs, and partials. Follow style guides and MDX/TOML validation rules.
Create Architecture Decision Record
Documentation
Create a new Architecture Decision Record with sequential numbering, register it in the AgentDB graph, and link related ADRs.
Plan update with deep research
Documentation
Updates a plan document by launching parallel subagents to analyze a topic across all compiler passes, then consolidates findings into the plan doc.