deck-iteration-workflow
Skill4 starsChanged 3 months agoMITView on GitHub
The Lossless Group's workflow for developing slides-only Astro sites for fundraise processes, aligned with the calmstorm-decks project patterns and the iterative approach from the "Develop a Slides-only Astro Site for a Fundraise Process" specification. Use when creating or modifying slide decks, managing slide variants, or implementing the structured iteration workflow for fundraise material development.
We split this skill into the rules it gives an agent
25 rules. About 0 are common, 23 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈23
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
When the user mentions "deck iteration", "slide variants", or fundraise slide development workflows
- Distinctive: line 35
Holistic before piecewise: - Start with the whole narrative on one page so the agent can reason about it as a coherent arc.
- Distinctive: line 38
Variant generation: - Create multiple variants to explore design options quickly
- Distinctive: line 39
Phase-based development: - Follow the structured progression: single-page narrative → individual slides → cleanup/componentization → …
- Distinctive: line 50
Use built-in Tailwind tokens only (no custom palettes yet)
- Distinctive: line 82
Keep a running list of all properties created to dedupe and reason about
- Distinctive: line 83
Only make components from consistently used design elements
- Distinctive: line 88
Add dynamic features and interactions one slide at a time
- Distinctive: line 90
Use JavaScript when necessary, but avoid unnecessary frameworks
- Distinctive: line 94
Avoid the neverending frustration of trying to make complex features work
- Distinctive: line 95
Keep focus on clean, stable rendered output
- Distinctive: line 96
Only adopt advanced features when clear necessity is demonstrated
- Distinctive: line 108
Create variants of components, layouts, and pages rather than iterating on working files
- Distinctive: line 109
Add advanced animations and transitions
- Very specific: line 119
Base slide landing page: Use slug string like overview to create /overview/index.astro for navigating variants
- Distinctive: line 149
Start simple and evolve navigation system over time
- Distinctive: line 151
Only complex features added after basic functionality is established
- Distinctive: line 157
Only add to design system after achieving aesthetic harmony
- Distinctive: line 161
Avoid the delays and struggles of creating robust design systems up front
- Distinctive: line 169
Cross-platform Compatibility: Ensure decks work across different browsers and devices
- Very specific: line 177
Reveal.js Avoidance: Avoid repeated iterations with Reveal.js due to CSS conflicts and debugging issues
- Distinctive: line 178
Complex JavaScript: Avoid premature use of JavaScript or animations that cause problems
- Distinctive: line 179
Design System Overhead: Avoid getting stuck in design system creation without clear benefit
- Distinctive: line 185
Use 2-3 minute bursts for creative generation
- Distinctive: line 189
Follow existing patterns from calmstorm-decks project
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Deck Iteration Workflow
A structured approach to developing slide decks for fundraise processes using the iterative methodology established in the calmstorm-decks project.
When to use this skill
- Creating a new slides-only Astro site for fundraise processes
- Managing slide variants and iterations during development
- Implementing the phased workflow for slide deck development
- Working with the calmstorm-decks project patterns
- When the user mentions "deck iteration", "slide variants", or fundraise slide development workflows
Overview
flowchart LR
A[Single-Page Narrative] --> B[Individual Slides]
B --> C[Cleanup / Componentization]
C --> D[Features]
D --> E[Full Deck]
E --> F[Advanced Interactivity]This workflow provides a structured approach to developing slide decks for fundraise processes based on the patterns and workflows discovered in the calmstorm-decks project. It emphasizes starting from the whole narrative as a single-page Astro scroll deck, then splitting to individual slides, then cleaning up and componentizing — followed by feature enhancement, full-deck completion, and advanced interactivity.
Why holistic-first: coding agents (Claude Code and generative AI generally) produce better creative flow and more coherent design when they can reason about the entire deck at once. An earlier version of this workflow started with plain wireframe HTML on a per-slide basis; that produced fragmented design and slow iteration. Building the whole narrative as one Astro page where each slide is a section component lets the agent improvise around theme/layout boundaries with the full arc visible.
Core Principles
- Holistic before piecewise - Start with the whole narrative on one page so the agent can reason about it as a coherent arc; split to individual slides only after the through-line is right
- Start fresh - Break from established patterns that have proven arduous and time-consuming
- Iterative perfection - Get something playable and clean before adding complexity
- Variant generation - Create multiple variants to explore design options quickly
- Phase-based development - Follow the structured progression: single-page narrative → individual slides → cleanup/componentization → features → full deck → advanced interactivity
- Design system foundation - Build explicit design systems only after achieving aesthetic harmony
Workflow Phases
Phase 1: Single-Page Scroll Deck with Astro Sections and Tailwind
Approach:
- Build the entire deck as one Astro page with each slide as a section component
- Section components named by sequence and topic/role
- Inline Tailwind utilities only — let the agent improvise around theme/layout boundaries
- Use built-in Tailwind tokens only (no custom palettes yet)
- No JavaScript
Why this comes first: the agent reasons about the full narrative at once. Inline Tailwind keeps styling decisions local to each section and avoids premature lock-in. Calm/Storm visual defaults:
- Background: Pure white (
bg-white/#FFFFFF) - Borders: Thin (1px), mid grey (
border-gray-300orborder-gray-400) - Primary text: Darker grey (
text-gray-800ortext-gray-900) - Detail text: Lighter grey (
text-gray-500ortext-gray-600) - Corner radius: Boxy-leaning,
roundedorrounded-sm(2-4px)
Goal: a clean playable single-page scroll deck where the narrative arc reads end-to-end with aesthetic harmony.
Phase 2: Individual HTML Slides with Inline Tailwind
Approach:
- Generate per-slide HTML pages by importing or referencing the Phase 1 section components
- Build a navigable menu so human clients can browse options on a per-slide basis
- Reason about vertical scroll vs. horizontal click/keyboard rendering animations — create variants where appropriate
- Deliver: a Table of Contents page and a dynamic variant selection page per slide
Goal: the deck is now navigable both as a continuous scroll (Phase 1) and as a click-through experience, with a menu surface for client review.
Phase 3: Astro Conversion Cleanup
Approach:
- Extract remaining text values from inline content into frontmatter or content collection files
- Componentize repeating design elements into Astro components without changing rendered output
- Build the initial design-system and brand-kit pages
- Iterate toward stable use of semantic tokens
Key Practices:
- Move text values displayed in tags to frontmatter variables
- Keep a running list of all properties created to dedupe and reason about
- Only make components from consistently used design elements
Phase 4: Feature Enhancement
Approach:
- Add dynamic features and interactions one slide at a time
- Prioritize advanced CSS features over JavaScript or libraries
- Use JavaScript when necessary, but avoid unnecessary frameworks
- Adopt libraries (GSAP) only with intention and purpose
Key Constraints:
- Avoid the neverending frustration of trying to make complex features work
- Keep focus on clean, stable rendered output
- Only adopt advanced features when clear necessity is demonstrated
Phase 5: Full Deck Completion (Priority Theme / Chosen Slides)
Approach:
- Apply the same methodology to the full deck
- Leverage learnings from the teaser deck to inform full deck development
- Maintain consistency in design and approach across all slides
Phase 6: Advanced Interactivity, Animations, and Data Visualization
Approach:
- Create variants of components, layouts, and pages rather than iterating on working files
- Add advanced animations and transitions
- Implement data visualization components
- Enhance user interaction patterns
- Current stack preferences: Svelte, GSAP, D3.js
- Exploring: ObservableHQ libraries, Vega-Lite
Variant Management
Naming Conventions:
- Base slide landing page: Use slug string like
overviewto create/overview/index.astrofor navigating variants - Slide variants:
pages/drafts/{slug}-{variant}.astro- Example:
pages/drafts/overview/overview-v1.astro
- Example:
Theme Organization:
When establishing themes:
pages/theme/{theme}/{slug}-{variant}-{theme}.astro- Example:
pages/modern/overview-v1-modern.astro
Canonical Promotion:
- Promote best variants to canonical status by removing variant suffix from filename
- Example:
overview-v1-modern.astrobecomesoverview-modern.astro
Variant Lifecycle:
- Generate multiple variants without getting stuck (2-3 min creative burst)
- Most variants shelved, but may be reused in client review processes
- Promote best variants to canonical status
- Prune "total losers" but preserve viable elements for future iterations
Navigation System
Core Requirements:
- Next/previous buttons positioned in bottom right corner, low opacity by default, changes on hover
- Key bindings for next/previous navigation
- Slide counter (7 / 17)
Implementation Guidelines:
- Start simple and evolve navigation system over time
- Maintain focus on getting something playable and functional first
- Only complex features added after basic functionality is established
Design System & Brand Kit
Timing:
- Begin building Design System and Brand Kit pages slowly
- Only add to design system after achieving aesthetic harmony
- Build it incrementally, not from the start
Key Principle:
- Avoid the delays and struggles of creating robust design systems up front
- Build it in a way that doesn't cause delays and struggles during iteration
Constraints & Considerations
Technical Constraints:
- Performance Focus: Focus on clean, functional decks rather than features
- Accessibility: Maintain accessible navigation and content structure
- Cross-platform Compatibility: Ensure decks work across different browsers and devices
Business Constraints:
- Private Content: Implement proper access controls for private decks
- Client Requirements: Client needs "playable" decks that are clean and error-free
- Technology Savvy: Balance complex authentication with simplicity for less tech-savvy users
Avoiding Common Pitfalls:
- Reveal.js Avoidance: Avoid repeated iterations with Reveal.js due to CSS conflicts and debugging issues
- Complex JavaScript: Avoid premature use of JavaScript or animations that cause problems
- Design System Overhead: Avoid getting stuck in design system creation without clear benefit
AI Assistance Guidelines
Creative Generation:
- Generate 2-10 variants per slide without getting stuck
- Use 2-3 minute bursts for creative generation
- Most variants will be shelved but may be useful in client reviews
Pattern Application:
- Follow existing patterns from calmstorm-decks project
- Adapt patterns to each site's needs
- Copy and adapt rather than import and constrain
Related Context
- [[context-v/specs/Develop-a-Slides-only-Astro-Site-for-a-Fundraise-Process]] - Core specification this workflow implements
- [[context-v/prompts/New-Site-Quickstart-Guide]] - New site setup guide for Astro-Knots projects
- [[astro-knots]] - Astro development conventions
- [[context-vigilance]] - Context management framework
In this repository36 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- astro-knotsSkill
- augment-speakers-panelistsSkill
- changelog-conventionsSkill
- cloudflare-artifacts-interfaceSkill
- competitive-analysisSkill
- context-vigilanceSkill
- crawl-fetch-ingestSkill
- create-contact-list-from-image-or-spreadsheetSkill
- decile-hub-connectorSkill
- event-prepSkill
- expense-report-generationSkill
- generate-consistent-og-imagesSkill
- gh-cli-projects-tasks-conventionsSkill
- git-conventionsSkill
- graphifySkill
- hubspot-interfaceSkill
- lossless-crm-interface-guidelinesSkill
- lossless-flavored-markdownSkill
- maintain-design-mdSkill
- maintain-filemapSkill
- maintain-splash-pagesSkill
- market-capture-analysisSkill
- obsidian-vault-hygieneSkill
- open-graph-share-seo-geoSkill
- openpanel-analyticsSkill
- overlay-svg-textSkill
- prep-images-for-embedSkill
- pseudomonoreposSkill
- remake-deckSkill
- search-lossless-corpusSkill
- slide-targetSkill
- study-repos-firstSkill
- surrealdb-canonical-layerSkill
- theme-systemSkill
- timeline-scenario-analysisSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

