Initial commit: Beyond the Prompt workshop presentation by Scott Scoble
- Reveal.js presentation on Skills and Subagents pattern - Nix flake with Caddy-based HTTP server and process-compose orchestration - ADRs documenting architectural decisions - Skills for AI implementation guidance - Full Scott Scoble author attribution in README
This commit is contained in:
Scott Scoble
commit
d2da71e53a
33 changed files with 4865 additions and 0 deletions
197
skills/README.md
Normal file
197
skills/README.md
Normal file
|
|
@ -0,0 +1,197 @@
|
|||
# Skills Directory
|
||||
|
||||
This directory contains Claude Code skills that provide AI implementation guidance for this project.
|
||||
|
||||
## Purpose: AI Context
|
||||
|
||||
**Skills are for AI, not humans.** They encode HOW to implement architectural decisions with step-by-step procedures, templates, and validation scripts. Claude Code automatically loads skill metadata and selects relevant skills based on the task.
|
||||
|
||||
**For human-readable architectural rationale**, see the `/docs/adr` directory.
|
||||
|
||||
## Available Skills
|
||||
|
||||
### 1. nix-http-server
|
||||
**Description**: Create HTTP servers for Nix flake projects. NEVER suggest Python dependencies.
|
||||
|
||||
**Use when**: Serving static files, creating dev servers, running multi-service environments.
|
||||
|
||||
**Key constraints**:
|
||||
- All dependencies from nixpkgs only
|
||||
- Use Caddy, never Python http.server
|
||||
- Generate configs at runtime for dev flexibility
|
||||
- Use process-compose for orchestration
|
||||
|
||||
**Corresponds to**: ADR 002 (Nix Flake Architecture)
|
||||
|
||||
### 2. revealjs-presentation
|
||||
**Description**: Create and style Reveal.js presentations for technical talks. Optimized for large screens.
|
||||
|
||||
**Use when**: Building slide decks, HTML-based presentations, technical talks.
|
||||
|
||||
**Key patterns**:
|
||||
- CDN-hosted Reveal.js (no build process)
|
||||
- Large screen optimization (38px base font for 100" @ 15ft)
|
||||
- Custom theme system with CSS variables
|
||||
- Code highlighting with language-specific classes
|
||||
|
||||
**Corresponds to**: ADR 001 (Presentation Technology Choice)
|
||||
|
||||
### 3. adr-documentation
|
||||
**Description**: Create and maintain Architecture Decision Records for human documentation.
|
||||
|
||||
**Use when**: Documenting architectural decisions, explaining WHY to team members.
|
||||
|
||||
**Key patterns**:
|
||||
- ADRs are for humans, skills are for AI
|
||||
- Document rationale and alternatives
|
||||
- Preserve historical context
|
||||
- Immutable once accepted (create superseding ADR instead)
|
||||
|
||||
**Corresponds to**: ADR 003 (Demo Implementation Strategy)
|
||||
|
||||
## How Skills Work
|
||||
|
||||
### Progressive Disclosure
|
||||
|
||||
Skills use a three-tier loading system:
|
||||
|
||||
1. **Metadata** (~100 tokens/skill, always loaded)
|
||||
- Name and description for discovery
|
||||
- Claude scans all skills at session start
|
||||
|
||||
2. **Instructions** (<5k tokens, loaded when triggered)
|
||||
- Full SKILL.md content
|
||||
- Only loaded for relevant skills
|
||||
|
||||
3. **Resources** (unlimited, on-demand)
|
||||
- Scripts, templates, reference files
|
||||
- Accessed via filesystem when needed
|
||||
|
||||
### Context Efficiency
|
||||
|
||||
**Traditional approach** (loading ADRs):
|
||||
```
|
||||
3 ADRs × 1,500 tokens = 4,500 tokens
|
||||
Doesn't scale beyond ~10-20 documents
|
||||
```
|
||||
|
||||
**Skills approach**:
|
||||
```
|
||||
3 skills × 100 tokens metadata = 300 tokens
|
||||
+ ~2 triggered skills × 5k instructions = 10,300 tokens total
|
||||
Scales to 100s of skills
|
||||
```
|
||||
|
||||
## The Skills + ADRs Pattern
|
||||
|
||||
```
|
||||
Architectural Decision
|
||||
↓
|
||||
┌────┴────┐
|
||||
▼ ▼
|
||||
ADR Skill
|
||||
(Human) (AI)
|
||||
↓ ↓
|
||||
Explains Implements
|
||||
WHY HOW
|
||||
```
|
||||
|
||||
### Integration Example
|
||||
|
||||
**ADR 002**: "Use Caddy for HTTP serving, not Python"
|
||||
- Location: `docs/adr/002-nix-flake-architecture.md`
|
||||
- Audience: Human developers
|
||||
- Purpose: Explain WHY (dependency management, nixpkgs-only)
|
||||
|
||||
**Skill**: `nix-http-server`
|
||||
- Location: `skills/nix-http-server/SKILL.md`
|
||||
- Audience: Claude AI
|
||||
- Purpose: Enforce HOW (never suggest Python, use Caddy)
|
||||
|
||||
## Creating New Skills
|
||||
|
||||
### When to Create a Skill
|
||||
|
||||
After writing an ADR, create a skill if:
|
||||
- [ ] Decision involves repetitive implementation patterns
|
||||
- [ ] AI should automatically enforce constraints
|
||||
- [ ] Pattern can be automated with templates/scripts
|
||||
- [ ] You want perfect consistency
|
||||
|
||||
### Skill Structure
|
||||
|
||||
```
|
||||
skills/
|
||||
└── my-skill/
|
||||
├── SKILL.md # Required: metadata + instructions
|
||||
├── scripts/ # Optional: executable scripts
|
||||
│ └── validate.sh
|
||||
└── templates/ # Optional: code templates
|
||||
└── example.template
|
||||
```
|
||||
|
||||
### SKILL.md Format
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: skill-identifier
|
||||
description: When to use this skill (max 1024 chars). Be specific about triggers.
|
||||
---
|
||||
|
||||
# Skill Name
|
||||
|
||||
## When to Use
|
||||
|
||||
Be specific about what triggers this skill.
|
||||
|
||||
## Implementation Pattern
|
||||
|
||||
Step-by-step procedures, examples, templates.
|
||||
|
||||
## Anti-Patterns (DO NOT DO)
|
||||
|
||||
What NOT to do, with examples.
|
||||
|
||||
## Related Documentation
|
||||
|
||||
Link to corresponding ADR for human context.
|
||||
```
|
||||
|
||||
### Best Practices
|
||||
|
||||
✅ **Do**:
|
||||
- Write clear descriptions that help Claude select the skill
|
||||
- Provide concrete examples and templates
|
||||
- Document anti-patterns explicitly
|
||||
- Keep instructions under 5k tokens
|
||||
- Link to corresponding ADR
|
||||
|
||||
❌ **Don't**:
|
||||
- Duplicate WHY explanations (that's in ADRs)
|
||||
- Write overly generic descriptions
|
||||
- Include unnecessary context in metadata
|
||||
- Exceed 5k tokens for instructions
|
||||
|
||||
## Skill Discovery
|
||||
|
||||
Claude Code automatically:
|
||||
1. Scans `skills/*/SKILL.md` at session start
|
||||
2. Loads metadata (100 tokens per skill)
|
||||
3. Selects relevant skills based on task
|
||||
4. Loads full instructions only for selected skills
|
||||
5. Accesses resources on-demand via filesystem
|
||||
|
||||
**You don't need to manually invoke skills** - Claude does it automatically based on task recognition.
|
||||
|
||||
## Examples
|
||||
|
||||
See existing skills in this directory:
|
||||
- `nix-http-server/SKILL.md`
|
||||
- `revealjs-presentation/SKILL.md`
|
||||
- `adr-documentation/SKILL.md`
|
||||
|
||||
## Resources
|
||||
|
||||
- Anthropic Skills Documentation: https://docs.claude.com/en/docs/agents-and-tools/agent-skills
|
||||
- Skills Repository: https://github.com/anthropics/skills
|
||||
- This project's ADRs: `docs/adr/`
|
||||
227
skills/adr-documentation/SKILL.md
Normal file
227
skills/adr-documentation/SKILL.md
Normal file
|
|
@ -0,0 +1,227 @@
|
|||
---
|
||||
name: adr-documentation
|
||||
description: Create and maintain Architecture Decision Records (ADRs) for human documentation. Use when documenting architectural decisions, not for AI implementation guidance.
|
||||
---
|
||||
|
||||
# ADR Documentation Skill
|
||||
|
||||
## Purpose
|
||||
|
||||
ADRs (Architecture Decision Records) are **human documentation** that explain WHY architectural decisions were made. They are NOT for AI implementation guidance - that's what skills are for.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Documenting a significant architectural decision
|
||||
- Explaining technology choices to team members
|
||||
- Creating governance artifacts for reviews
|
||||
- Preserving historical context for future maintainers
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
❌ Don't create ADRs for AI to consume as implementation guidance
|
||||
✅ Instead, create a **skill** that encodes the decision as executable instructions
|
||||
|
||||
## ADR Structure
|
||||
|
||||
```markdown
|
||||
# ADR NNN: Title
|
||||
|
||||
## Status
|
||||
|
||||
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
|
||||
|
||||
## Context
|
||||
|
||||
What is the issue/situation that motivates this decision?
|
||||
- What problems are we trying to solve?
|
||||
- What constraints exist?
|
||||
- What is the current state?
|
||||
|
||||
## Decision
|
||||
|
||||
What did we decide to do?
|
||||
|
||||
Be specific and concrete. This should be implementable.
|
||||
|
||||
## Rationale
|
||||
|
||||
Why did we make this decision?
|
||||
|
||||
### Alternatives Considered
|
||||
|
||||
What other options did we evaluate and why were they rejected?
|
||||
|
||||
1. **Alternative A**
|
||||
- Pros: ...
|
||||
- Cons: ...
|
||||
- Reason for rejection: ...
|
||||
|
||||
2. **Alternative B**
|
||||
- Pros: ...
|
||||
- Cons: ...
|
||||
- Reason for rejection: ...
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
- What benefits does this decision provide?
|
||||
- What problems does it solve?
|
||||
|
||||
### Negative
|
||||
- What are the downsides or trade-offs?
|
||||
- What new problems might this create?
|
||||
|
||||
### Mitigations
|
||||
- How can we address the negative consequences?
|
||||
- What can we do to minimize downsides?
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
(Optional) High-level guidance for implementation, but detailed procedures belong in skills, not ADRs.
|
||||
|
||||
## Related
|
||||
|
||||
- Links to related ADRs
|
||||
- Links to corresponding skills
|
||||
- External documentation
|
||||
```
|
||||
|
||||
## ADR Numbering
|
||||
|
||||
Use sequential zero-padded numbers:
|
||||
- `001-first-decision.md`
|
||||
- `002-second-decision.md`
|
||||
- `010-tenth-decision.md`
|
||||
|
||||
## ADR Lifecycle
|
||||
|
||||
1. **Proposed** - Under discussion, not yet accepted
|
||||
2. **Accepted** - Decision is made and active
|
||||
3. **Deprecated** - No longer recommended but not superseded
|
||||
4. **Superseded** - Replaced by a newer ADR (reference it)
|
||||
|
||||
**Important**: Never delete ADRs. They preserve historical context.
|
||||
|
||||
## Directory Structure
|
||||
|
||||
```
|
||||
docs/
|
||||
└── adr/
|
||||
├── README.md # Index and overview
|
||||
├── 001-first.md
|
||||
├── 002-second.md
|
||||
└── 003-third.md
|
||||
```
|
||||
|
||||
## Relationship to Skills
|
||||
|
||||
**The Modern Pattern**:
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────┐
|
||||
│ Make Architectural Decision │
|
||||
└────────────┬─────────────────────────┘
|
||||
│
|
||||
┌────────┴────────┐
|
||||
▼ ▼
|
||||
┌──────────┐ ┌─────────┐
|
||||
│ ADR │ │ Skill │
|
||||
│ (Human) │ │ (AI) │
|
||||
└──────────┘ └─────────┘
|
||||
│ │
|
||||
▼ ▼
|
||||
Explains WHY Implements HOW
|
||||
For humans For AI
|
||||
In docs/adr/ In skills/
|
||||
```
|
||||
|
||||
### Example Integration
|
||||
|
||||
**ADR 002**: "Use Caddy for HTTP serving, not Python"
|
||||
- Location: `docs/adr/002-nix-flake-architecture.md`
|
||||
- Purpose: Explain WHY we chose Caddy
|
||||
- Audience: Human developers
|
||||
- Document: Rationale, alternatives, consequences
|
||||
|
||||
**Skill**: `nix-http-server`
|
||||
- Location: `skills/nix-http-server/SKILL.md`
|
||||
- Purpose: Automate Caddy server creation, enforce no-Python constraint
|
||||
- Audience: Claude AI
|
||||
- Contains: Step-by-step procedures, templates, validation scripts
|
||||
|
||||
## ADR Template
|
||||
|
||||
See `docs/adr/template.md` for a starter template (if it exists), or use the structure above.
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Writing Effective ADRs
|
||||
|
||||
✅ **Do**:
|
||||
- Focus on WHY, not HOW
|
||||
- Document alternatives considered
|
||||
- Be honest about trade-offs
|
||||
- Use clear, simple language
|
||||
- Include concrete examples
|
||||
- Link to related decisions
|
||||
|
||||
❌ **Don't**:
|
||||
- Document implementation details (use skills instead)
|
||||
- Write ADRs that AI should consume
|
||||
- Delete old ADRs (mark as Superseded instead)
|
||||
- Make decisions in ADRs that should be skills
|
||||
- Use jargon without explanation
|
||||
|
||||
### Context Window Efficiency
|
||||
|
||||
**Old pattern** (inefficient):
|
||||
- ADR contains both WHY and detailed HOW
|
||||
- AI must load entire ADR into context (500-2000 tokens)
|
||||
- Doesn't scale beyond ~10-20 ADRs
|
||||
|
||||
**New pattern** (efficient):
|
||||
- ADR contains only WHY (for humans)
|
||||
- Skill contains HOW (for AI, ~100 tokens metadata)
|
||||
- Scales to hundreds of patterns
|
||||
|
||||
## Validation
|
||||
|
||||
When creating or updating an ADR, ensure:
|
||||
|
||||
- [ ] Status is one of: Proposed, Accepted, Deprecated, Superseded
|
||||
- [ ] All sections are present and filled out
|
||||
- [ ] Alternatives are documented with pros/cons
|
||||
- [ ] Consequences (positive AND negative) are listed
|
||||
- [ ] Related ADRs/skills are linked
|
||||
- [ ] Decision is specific and actionable
|
||||
- [ ] Language is clear and accessible
|
||||
|
||||
## Examples
|
||||
|
||||
See existing ADRs in this repository:
|
||||
- `docs/adr/001-presentation-technology.md` (→ corresponds to `revealjs-presentation` skill)
|
||||
- `docs/adr/002-nix-flake-architecture.md` (→ corresponds to `nix-http-server` skill)
|
||||
- `docs/adr/003-demo-implementation-strategy.md` (→ corresponds to this skill)
|
||||
|
||||
## Creating a Corresponding Skill
|
||||
|
||||
After creating an ADR, ask:
|
||||
|
||||
**"Should this have a corresponding skill?"**
|
||||
|
||||
If YES to any:
|
||||
- Does this decision involve repetitive implementation patterns?
|
||||
- Should AI automatically apply these standards?
|
||||
- Can this be automated with scripts/templates?
|
||||
- Do we want perfect consistency in implementation?
|
||||
|
||||
Then create a skill in `skills/<name>/SKILL.md` that:
|
||||
- References the ADR for context
|
||||
- Provides step-by-step implementation procedures
|
||||
- Includes templates and examples
|
||||
- Enforces the constraints from the ADR
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- `docs/adr/README.md` - Index of all ADRs
|
||||
- `skills/` - Corresponding AI implementation skills
|
||||
163
skills/nix-http-server/SKILL.md
Normal file
163
skills/nix-http-server/SKILL.md
Normal file
|
|
@ -0,0 +1,163 @@
|
|||
---
|
||||
name: nix-http-server
|
||||
description: Create HTTP servers for Nix flake projects. Use when serving static files or running development servers. CRITICAL CONSTRAINT - Never suggest Python dependencies.
|
||||
---
|
||||
|
||||
# Nix HTTP Server Skill
|
||||
|
||||
## Core Constraint
|
||||
|
||||
**NEVER suggest Python-based HTTP servers** (python -m http.server, etc.)
|
||||
All dependencies MUST come from nixpkgs only.
|
||||
|
||||
## When to Use
|
||||
|
||||
- User needs to serve static files from a Nix project
|
||||
- User wants to create development servers
|
||||
- User needs process orchestration for multiple services
|
||||
- Project has a flake.nix file
|
||||
|
||||
## Implementation Pattern
|
||||
|
||||
### 1. Use Caddy for HTTP Serving
|
||||
|
||||
Caddy is the approved HTTP server because:
|
||||
- Available in nixpkgs
|
||||
- Supports configuration as code
|
||||
- Better features than simple Python server
|
||||
- Works with process-compose orchestration
|
||||
|
||||
### 2. Configuration Generation
|
||||
|
||||
Generate configurations at build time using Nix expressions:
|
||||
|
||||
```nix
|
||||
makeCaddyConfig = pkgs: port: root: pkgs.writeText "Caddyfile" ''
|
||||
:${toString port} {
|
||||
root * ${root}
|
||||
file_server browse
|
||||
encode gzip
|
||||
log {
|
||||
output stdout
|
||||
format console
|
||||
}
|
||||
}
|
||||
'';
|
||||
```
|
||||
|
||||
OR generate at runtime for development flexibility:
|
||||
|
||||
```bash
|
||||
# Generate Caddyfile at runtime
|
||||
CADDY_CONFIG=$(mktemp)
|
||||
cat > "$CADDY_CONFIG" <<EOF
|
||||
:8000 {
|
||||
root * $PWD/presentation
|
||||
file_server browse
|
||||
encode gzip
|
||||
}
|
||||
EOF
|
||||
|
||||
caddy run --config "$CADDY_CONFIG" --adapter caddyfile
|
||||
```
|
||||
|
||||
### 3. Process Orchestration
|
||||
|
||||
For multiple services, use process-compose:
|
||||
|
||||
```nix
|
||||
makeProcessComposeConfig = pkgs: processes: pkgs.writeText "process-compose.yaml" (
|
||||
builtins.toJSON {
|
||||
version = "0.5";
|
||||
inherit processes;
|
||||
}
|
||||
);
|
||||
```
|
||||
|
||||
### 4. Flake App Pattern
|
||||
|
||||
Create apps in flake.nix that:
|
||||
- Check for required directories in $PWD
|
||||
- Generate configs at runtime (for dev flexibility)
|
||||
- Use --tui=false for process-compose (avoids /dev/tty errors)
|
||||
- Add --adapter caddyfile flag when using Caddyfile format
|
||||
|
||||
## Example Implementation
|
||||
|
||||
See `/Users/sscoble/Projects/beyond-the-prompt/flake.nix` for working examples:
|
||||
- `nix run .#present` - Single server
|
||||
- `nix run .#demo` - Multiple servers with process-compose
|
||||
|
||||
## Key Technical Details
|
||||
|
||||
### Caddy Flags
|
||||
- `--config <path>` - Path to config file
|
||||
- `--adapter caddyfile` - Parse as Caddyfile format (not JSON)
|
||||
- `run` - Run server (blocking)
|
||||
|
||||
### Process-Compose Flags
|
||||
- `--tui=false` - Disable TUI (required for non-interactive environments)
|
||||
- `-f <config>` - Config file path
|
||||
|
||||
### Runtime Config Pattern
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
# Validate directory exists
|
||||
CONTENT_ROOT="$PWD/presentation"
|
||||
if [ ! -d "$CONTENT_ROOT" ]; then
|
||||
echo "Error: presentation/ directory not found"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Generate config at runtime (allows serving from working directory)
|
||||
CADDY_CONFIG=$(mktemp)
|
||||
trap "rm -f $CADDY_CONFIG" EXIT
|
||||
|
||||
cat > "$CADDY_CONFIG" <<EOF
|
||||
:8000 {
|
||||
root * $CONTENT_ROOT
|
||||
file_server browse
|
||||
encode gzip
|
||||
}
|
||||
EOF
|
||||
|
||||
# Run server
|
||||
caddy run --config "$CADDY_CONFIG" --adapter caddyfile
|
||||
```
|
||||
|
||||
## Anti-Patterns (DO NOT DO)
|
||||
|
||||
❌ **Never** suggest `python -m http.server`
|
||||
❌ **Never** suggest `python3 -m http.server`
|
||||
❌ **Never** add Python to buildInputs/devShell for HTTP serving
|
||||
❌ **Never** suggest `npx http-server` (requires Node.js, use nixpkgs)
|
||||
❌ **Never** hardcode absolute paths in Nix expressions (breaks portability)
|
||||
|
||||
## Multi-Platform Support
|
||||
|
||||
Always use `forAllSystems` pattern for cross-platform compatibility:
|
||||
|
||||
```nix
|
||||
supportedSystems = [
|
||||
"x86_64-linux"
|
||||
"aarch64-linux"
|
||||
"x86_64-darwin"
|
||||
"aarch64-darwin"
|
||||
];
|
||||
|
||||
forAllSystems = f: nixpkgs.lib.genAttrs supportedSystems
|
||||
(system: f system (import nixpkgs { inherit system; }));
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
|
||||
Human-readable architectural rationale in: `docs/adr/002-nix-flake-architecture.md`
|
||||
|
||||
## Templates
|
||||
|
||||
See `templates/` directory for:
|
||||
- Caddyfile examples
|
||||
- process-compose.yaml examples
|
||||
- Flake app script templates
|
||||
91
skills/remark-presentation/SKILL.md
Normal file
91
skills/remark-presentation/SKILL.md
Normal file
|
|
@ -0,0 +1,91 @@
|
|||
---
|
||||
name: remark-presentation
|
||||
description: Create Remark.js markdown-based presentations for technical talks. Use when building slide decks from markdown files. Optimized for large screens and code-heavy content.
|
||||
---
|
||||
|
||||
# Remark.js Presentation Skill
|
||||
|
||||
## When to Use
|
||||
|
||||
- User needs to create a presentation or slide deck
|
||||
- User wants markdown-based presentations (easy to version control)
|
||||
- User needs technical presentations with lots of code
|
||||
- User wants simple, minimal presentation framework
|
||||
|
||||
## Technology Choice
|
||||
|
||||
**Use Remark.js** (markdown-driven slideshow) because:
|
||||
- Pure markdown content - extremely simple
|
||||
- No build process - just HTML + markdown file
|
||||
- Excellent code highlighting
|
||||
- Works perfectly with version control
|
||||
- Very lightweight
|
||||
|
||||
## Basic Structure
|
||||
|
||||
**index.html**:
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<title>Presentation Title</title>
|
||||
<link rel="stylesheet" href="assets/theme.css">
|
||||
</head>
|
||||
<body>
|
||||
<script src="https://remarkjs.com/downloads/remark-latest.min.js"></script>
|
||||
<script>
|
||||
var slideshow = remark.create({
|
||||
sourceUrl: 'slides.md',
|
||||
highlightStyle: 'monokai',
|
||||
highlightLines: true,
|
||||
ratio: '16:9'
|
||||
});
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
**slides.md**:
|
||||
```markdown
|
||||
class: center, middle
|
||||
|
||||
# Presentation Title
|
||||
|
||||
Subtitle
|
||||
|
||||
---
|
||||
|
||||
# Slide Title
|
||||
|
||||
Content
|
||||
|
||||
- Point 1
|
||||
- Point 2
|
||||
|
||||
---
|
||||
|
||||
# Code
|
||||
|
||||
\`\`\`nix
|
||||
{ apps.present = ...; }
|
||||
\`\`\`
|
||||
```
|
||||
|
||||
## Slide Separators
|
||||
|
||||
- `---` creates new slide
|
||||
- `--` creates incremental reveal
|
||||
- `???` adds presenter notes
|
||||
|
||||
## Large Screen Optimization (100" at 15ft)
|
||||
|
||||
```css
|
||||
body { font-size: 38px; }
|
||||
h1 { font-size: 3em; }
|
||||
h2 { font-size: 2.5em; }
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
|
||||
See: `docs/adr/001-presentation-technology.md`
|
||||
Loading…
Add table
Add a link
Reference in a new issue