@tycoworks/tycoslide 0.7.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +73 -0
- package/SKILL.md +249 -0
- package/bin/tycoslide.js +2 -0
- package/dist/cli.d.ts +1 -0
- package/dist/cli.js +197 -0
- package/dist/engine/dom.d.ts +92 -0
- package/dist/engine/dom.js +354 -0
- package/dist/engine/fillers/filler.d.ts +22 -0
- package/dist/engine/fillers/filler.js +53 -0
- package/dist/engine/fillers/image.d.ts +19 -0
- package/dist/engine/fillers/image.js +105 -0
- package/dist/engine/fillers/table.d.ts +21 -0
- package/dist/engine/fillers/table.js +62 -0
- package/dist/engine/fillers/template.d.ts +27 -0
- package/dist/engine/fillers/template.js +221 -0
- package/dist/engine/fillers/text.d.ts +28 -0
- package/dist/engine/fillers/text.js +29 -0
- package/dist/engine/generate.d.ts +51 -0
- package/dist/engine/generate.js +161 -0
- package/dist/engine/index.d.ts +8 -0
- package/dist/engine/index.js +7 -0
- package/dist/engine/types.d.ts +128 -0
- package/dist/engine/types.js +22 -0
- package/dist/index.d.ts +46 -0
- package/dist/index.js +146 -0
- package/dist/manifest.d.ts +7 -0
- package/dist/manifest.js +88 -0
- package/dist/markdown/deckCompiler.d.ts +36 -0
- package/dist/markdown/deckCompiler.js +289 -0
- package/dist/markdown/index.d.ts +13 -0
- package/dist/markdown/index.js +13 -0
- package/dist/markdown/parsers.d.ts +32 -0
- package/dist/markdown/parsers.js +233 -0
- package/dist/markdown/resolvers/code.d.ts +17 -0
- package/dist/markdown/resolvers/code.js +44 -0
- package/dist/markdown/resolvers/mermaid.d.ts +14 -0
- package/dist/markdown/resolvers/mermaid.js +89 -0
- package/dist/markdown/resolvers/mermaidTheme.d.ts +27 -0
- package/dist/markdown/resolvers/mermaidTheme.js +113 -0
- package/dist/markdown/resolvers/resolver.d.ts +42 -0
- package/dist/markdown/resolvers/resolver.js +52 -0
- package/dist/markdown/slideParser.d.ts +14 -0
- package/dist/markdown/slideParser.js +196 -0
- package/dist/markdown/textTemplate.d.ts +15 -0
- package/dist/markdown/textTemplate.js +75 -0
- package/dist/markdown/types.d.ts +239 -0
- package/dist/markdown/types.js +40 -0
- package/package.json +41 -0
- package/syntax.md +291 -0
package/syntax.md
ADDED
|
@@ -0,0 +1,291 @@
|
|
|
1
|
+
# Markdown Syntax Reference
|
|
2
|
+
|
|
3
|
+
This document covers the detailed syntax for writing slide content in tycoslide deck files. For an overview of how to create slides, see [SKILL.md](SKILL.md).
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Global frontmatter
|
|
8
|
+
|
|
9
|
+
Every deck file starts with a global frontmatter block declaring the theme:
|
|
10
|
+
|
|
11
|
+
```markdown
|
|
12
|
+
---
|
|
13
|
+
theme: ./theme.json
|
|
14
|
+
output: my-deck.pptx
|
|
15
|
+
---
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
- **`theme`** (required) -- path to the theme config file, relative to the deck file.
|
|
19
|
+
- **`output`** -- output filename. Defaults to the deck filename with a `.pptx` extension.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Body content (body slots)
|
|
24
|
+
|
|
25
|
+
Everything after a slide's closing `---` and before the next slide separator is body content. It maps to the `body` slot as a string array.
|
|
26
|
+
|
|
27
|
+
```markdown
|
|
28
|
+
---
|
|
29
|
+
layout: Body
|
|
30
|
+
title: Key Achievements
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
We exceeded targets across all metrics.
|
|
34
|
+
|
|
35
|
+
- Revenue up 23% quarter-over-quarter
|
|
36
|
+
- Customer churn reduced to 1.2%
|
|
37
|
+
- Three major product launches completed
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Write body content as paragraphs and bullets:
|
|
41
|
+
- `- ` starts a **bullet**; indent **2 spaces per level** to nest (` - ` = level 1).
|
|
42
|
+
- A line with no marker is a **paragraph** (a lead-in / prose line).
|
|
43
|
+
- Blank lines are ignored (they're visual separators, not content).
|
|
44
|
+
- Do NOT put headings in body content -- the heading is the slide's `title` slot, and a subheading is the `subtitle` slot. Body is paragraphs + bullets only.
|
|
45
|
+
|
|
46
|
+
### Inline formatting
|
|
47
|
+
|
|
48
|
+
Inline formatting is supported in body content:
|
|
49
|
+
- `**bold**` -- bold text
|
|
50
|
+
- `*italic*` -- italic text
|
|
51
|
+
- `~~strikethrough~~` -- strikethrough text
|
|
52
|
+
- `++underline++` -- underlined text
|
|
53
|
+
- `[text](url)` -- hyperlink
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## Named slots with `::name::` markers
|
|
58
|
+
|
|
59
|
+
For layouts with multiple content regions (e.g., two-column layouts), use `::name::` markers to split body content into named slots.
|
|
60
|
+
|
|
61
|
+
```markdown
|
|
62
|
+
---
|
|
63
|
+
layout: TwoColumn
|
|
64
|
+
title: Before & After
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
::left::
|
|
68
|
+
|
|
69
|
+
- Manual deployments
|
|
70
|
+
- 4-hour release cycles
|
|
71
|
+
- Frequent rollbacks
|
|
72
|
+
|
|
73
|
+
::right::
|
|
74
|
+
|
|
75
|
+
- Automated CI/CD pipeline
|
|
76
|
+
- 12-minute releases
|
|
77
|
+
- Zero-downtime deploys
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Content before the first `::name::` marker goes to the `body` slot. Content after a marker goes to the slot matching that name. The marker names must match the layout's slot keys.
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
## Parameters and slots (in `manifest.json`)
|
|
85
|
+
|
|
86
|
+
A layout advertises two kinds of author-facing input, split by one rule: **a parameter is one value on a frontmatter line; a slot is a multi-line region in the body** (the default region, or a `::name::` region). In `manifest.json` each layout carries two lists, `parameters` and `slots`:
|
|
87
|
+
|
|
88
|
+
```jsonc
|
|
89
|
+
{
|
|
90
|
+
"name": "Feature with code",
|
|
91
|
+
"parameters": [
|
|
92
|
+
{ "key": "title", "type": "template" },
|
|
93
|
+
{ "key": "subtitle", "type": "template" },
|
|
94
|
+
{ "key": "logo", "type": "image", "fit": "contain", "required": true }
|
|
95
|
+
],
|
|
96
|
+
"slots": [
|
|
97
|
+
{ "key": "body", "type": "text" },
|
|
98
|
+
{ "key": "code", "type": "code", "codeTheme": "github-dark" }
|
|
99
|
+
]
|
|
100
|
+
}
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
### Parameter types (frontmatter lines)
|
|
104
|
+
|
|
105
|
+
Fill a parameter by putting a value under its key in the slide's frontmatter.
|
|
106
|
+
|
|
107
|
+
- **`template`** -- a shape whose existing runs are walked and replaced in place, preserving each run's style. Behind the scenes each text shape carries one `template` string with `{key}` placeholders (e.g. `{title}`, or `{name}\n{jobTitle}` for a two-line credits shape), but you never see the template: the manifest advertises **one key per placeholder**, and you fill each key as a plain scalar in frontmatter. A single-placeholder title shape gives you one key:
|
|
108
|
+
```yaml
|
|
109
|
+
title: Q3 Results
|
|
110
|
+
```
|
|
111
|
+
A multi-line credits shape whose template is `{name}\n{jobTitle}` surfaces as two keys -- fill each on its own frontmatter line (never a YAML array):
|
|
112
|
+
```yaml
|
|
113
|
+
name: Jane Smith
|
|
114
|
+
jobTitle: CEO, Acme Corp
|
|
115
|
+
```
|
|
116
|
+
The engine substitutes each value into the run that carries its style, so if the designer made the name bold and the job title grey, the filled name stays bold and the filled title stays grey.
|
|
117
|
+
- **`image`** -- a picture placeholder. Set it in frontmatter with the image path (from an asset catalog entry, or an absolute path). The parameter declares a `fit`: `contain` shows the whole image, `cover` fills the frame and center-crops overflow.
|
|
118
|
+
```yaml
|
|
119
|
+
hero: assets/diagrams/architecture.png
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
### Slot types (body regions)
|
|
123
|
+
|
|
124
|
+
Fill a slot by writing a region in the body: the default (unmarked) region maps to the `body` slot; a `::name::` marker maps to the slot of that name.
|
|
125
|
+
|
|
126
|
+
- **`text`** -- a body block, written as markdown paragraphs and bullets. Paragraphs are rebuilt from the template's specimen paragraph styles. Set it as body content after the closing `---`, or as a named slot with `::name::` markers.
|
|
127
|
+
- **`table`** -- a GFM table. Write it in the slot region between `|`-delimited headers and rows; cells inherit inline formatting (bold, italic, links).
|
|
128
|
+
- **`code`** -- a syntax-highlighted code block. Write a fenced code block with a language tag in the slot region:
|
|
129
|
+
````markdown
|
|
130
|
+
::code::
|
|
131
|
+
|
|
132
|
+
```sql
|
|
133
|
+
SELECT name, total
|
|
134
|
+
FROM orders
|
|
135
|
+
WHERE created_at > now() - INTERVAL '5 minutes';
|
|
136
|
+
```
|
|
137
|
+
````
|
|
138
|
+
The language tag (e.g. `sql`, `python`, `typescript`) is required -- it drives syntax highlighting. Colors are applied as native text runs in the output, not images.
|
|
139
|
+
- **`mermaid`** -- a mermaid diagram rendered as a themed PNG (see below). Written as a fenced `mermaid` region; the resulting PNG fills the slot with `contain` fit.
|
|
140
|
+
|
|
141
|
+
---
|
|
142
|
+
|
|
143
|
+
## Mermaid diagrams
|
|
144
|
+
|
|
145
|
+
Mermaid diagrams are rendered as themed PNGs and delivered to any slot declared with `type: mermaid`. Write a fenced code block with the `mermaid` language tag in a named slot whose layout declares that slot as `type: mermaid` (with a `mermaidVariant` naming the theme's color variant). The resulting PNG behaves like any other image in the slot -- always shown in its entirety (`contain` fit).
|
|
146
|
+
|
|
147
|
+
To let the same physical slide accept either an image or a diagram, the theme author declares two layouts with the same `slideNumber` -- one exposing the fill as an `image` parameter (frontmatter path), one as a `mermaid` slot (a fenced region). Authors pick between them by naming the layout in frontmatter; the compiler routes content based on the layout's declaration, so there is no ambiguity.
|
|
148
|
+
|
|
149
|
+
````markdown
|
|
150
|
+
---
|
|
151
|
+
layout: Full bleed image with title dark
|
|
152
|
+
title: System Architecture
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
::image::
|
|
156
|
+
|
|
157
|
+
```mermaid
|
|
158
|
+
flowchart LR
|
|
159
|
+
subgraph Sources
|
|
160
|
+
DB[(Postgres)]
|
|
161
|
+
API[REST API]
|
|
162
|
+
end
|
|
163
|
+
subgraph Processing
|
|
164
|
+
MV[Materialized View]
|
|
165
|
+
end
|
|
166
|
+
subgraph Consumers
|
|
167
|
+
App[Application]
|
|
168
|
+
end
|
|
169
|
+
DB --> MV
|
|
170
|
+
API --> MV
|
|
171
|
+
MV --> App
|
|
172
|
+
class DB,API sources
|
|
173
|
+
class MV processing
|
|
174
|
+
class App consumers
|
|
175
|
+
```
|
|
176
|
+
````
|
|
177
|
+
|
|
178
|
+
### Semantic grouping
|
|
179
|
+
|
|
180
|
+
Use `class` statements to group nodes by meaning. Nodes sharing a group name share a color, assigned automatically from the theme's accent color pool.
|
|
181
|
+
|
|
182
|
+
```
|
|
183
|
+
class DB,API sources # DB and API belong to the "sources" group
|
|
184
|
+
class MV processing # MV belongs to the "processing" group
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
Inline syntax also works: `A:::groupName`.
|
|
188
|
+
|
|
189
|
+
Group names are arbitrary -- they describe what nodes mean, not what color they get. Colors are assigned round-robin in encounter order. Unclassed nodes use the theme's primary color.
|
|
190
|
+
|
|
191
|
+
### Forbidden directives
|
|
192
|
+
|
|
193
|
+
The theme owns all styling. These directives are rejected at build time:
|
|
194
|
+
|
|
195
|
+
- `style` -- use `class` instead
|
|
196
|
+
- `linkStyle` -- link colors come from the theme
|
|
197
|
+
- `classDef` -- class definitions are auto-generated from the theme
|
|
198
|
+
- `%%{init}` -- theme configuration is set by the engine
|
|
199
|
+
|
|
200
|
+
---
|
|
201
|
+
|
|
202
|
+
## Image parameters
|
|
203
|
+
|
|
204
|
+
An image is a **parameter** -- one value (a path) on a frontmatter line. Reference it using the parameter key directly:
|
|
205
|
+
|
|
206
|
+
```yaml
|
|
207
|
+
---
|
|
208
|
+
layout: ImageSlide
|
|
209
|
+
title: Architecture Diagram
|
|
210
|
+
hero: assets/diagrams/architecture.png
|
|
211
|
+
---
|
|
212
|
+
```
|
|
213
|
+
|
|
214
|
+
Each parameter or slot in the layout definition may declare:
|
|
215
|
+
- **`type`** (required) -- parameters: `template`, `image`; slots: `text`, `table`, `code`, `mermaid`.
|
|
216
|
+
- **`required: true`** -- the slide has no usable default and the build fails if the parameter/slot has no value (e.g. team-member photos, icon-grid icons, the quote logo). If you don't have a suitable image, ask the user for one.
|
|
217
|
+
- **`fit`** -- image parameters only (required): `contain` shows the whole image inside the frame (letterboxed); `cover` fills the frame and center-crops overflow. Fit is a layout-designer decision baked into the parameter -- callers never override it per slide. Mermaid slots don't declare `fit`; mermaid always renders contained.
|
|
218
|
+
- **`codeTheme`** -- code slots only (required): the Shiki theme id used to syntax-highlight fenced code that lands in this slot (e.g. `"github-dark"`).
|
|
219
|
+
- **`mermaidVariant`** -- mermaid slots only (required): names the color variant from `theme.mermaid` (e.g. `"dark"`). See [Mermaid diagrams](#mermaid-diagrams) above.
|
|
220
|
+
|
|
221
|
+
Each layout also declares a `slideNumber` pointing at the physical slide in the theme's template. **`slideNumber` may repeat across layouts**: two (or more) manifest entries with the same `slideNumber` back a single physical slide, distinguished only by which parameter/slot types they declare -- e.g. an "image" variant and a "mermaid" variant on the same full-bleed slide. The compiler enforces that shared-`slideNumber` layouts agree on keys and shape names; the only allowed cross-type variation is `{image, mermaid}` on the same key.
|
|
222
|
+
|
|
223
|
+
---
|
|
224
|
+
|
|
225
|
+
## Slides with no body
|
|
226
|
+
|
|
227
|
+
Slides that have all their content in frontmatter (common for title slides, section dividers) need no body:
|
|
228
|
+
|
|
229
|
+
```markdown
|
|
230
|
+
---
|
|
231
|
+
layout: SectionDivider
|
|
232
|
+
title: Part Two
|
|
233
|
+
subtitle: Advanced Topics
|
|
234
|
+
---
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
---
|
|
238
|
+
|
|
239
|
+
## Full Example
|
|
240
|
+
|
|
241
|
+
```markdown
|
|
242
|
+
---
|
|
243
|
+
theme: ./theme.json
|
|
244
|
+
---
|
|
245
|
+
|
|
246
|
+
---
|
|
247
|
+
layout: Title
|
|
248
|
+
title: Engineering Onboarding
|
|
249
|
+
subtitle: Welcome to the team
|
|
250
|
+
---
|
|
251
|
+
|
|
252
|
+
---
|
|
253
|
+
layout: Body
|
|
254
|
+
title: Your First Week
|
|
255
|
+
---
|
|
256
|
+
|
|
257
|
+
Here is what to expect in your first week.
|
|
258
|
+
|
|
259
|
+
- Day 1: Laptop setup and HR orientation
|
|
260
|
+
- Day 2: Meet your team, shadow a standup
|
|
261
|
+
- Day 3-5: First starter task
|
|
262
|
+
- Pick from the "good first issue" board
|
|
263
|
+
- Pair with your onboarding buddy
|
|
264
|
+
|
|
265
|
+
---
|
|
266
|
+
layout: TwoColumn
|
|
267
|
+
title: Tools We Use
|
|
268
|
+
---
|
|
269
|
+
|
|
270
|
+
::left::
|
|
271
|
+
|
|
272
|
+
Development:
|
|
273
|
+
|
|
274
|
+
- GitHub for code
|
|
275
|
+
- Linear for tasks
|
|
276
|
+
- Slack for chat
|
|
277
|
+
|
|
278
|
+
::right::
|
|
279
|
+
|
|
280
|
+
Infrastructure:
|
|
281
|
+
|
|
282
|
+
- AWS for hosting
|
|
283
|
+
- Datadog for monitoring
|
|
284
|
+
- PagerDuty for on-call
|
|
285
|
+
|
|
286
|
+
---
|
|
287
|
+
layout: ImageSlide
|
|
288
|
+
title: Office Map
|
|
289
|
+
hero: assets/images/office-floor-plan.png
|
|
290
|
+
---
|
|
291
|
+
```
|