create-mode

Name: create-mode
Author: pandazki

152stars15forks

How to install create-mode?

pandazki/pneuma-skills/create-mode

$npx -y skills add pandazki/pneuma-skills --skill create-mode

Installs into the current project.

Summary

Author a new Pneuma mode end-to-end — manifest + viewer + skill + seed + showcase. Use this skill whenever the user says they want to create a new mode, fork an existing one for a different domain, scaffold mode files, design a new viewer, or asks "how should I build a mode for X

Files · 1

View on GitHub

SKILL.md

1	# Create Mode
2
3	A guided journey for adding a new mode to Pneuma Skills. The journey has three phases — Discovery (ask the right questions), Brief (write down every key choice with rationale and get the user's confirmation), Implementation (generate files). Each phase has a clear handoff to the next; never skip Brief. Pneuma already has twelve modes and a stable contract layer; the cost of a thoughtful 10-minute design brief is much smaller than the cost of building the wrong viewer.
4
5	The reference material in `references/` is where the knowledge lives — go read the relevant one whenever you're about to make a meaningful decision. SKILL.md is the journey, not the textbook.
6
7	---
8
9	## When to use
10
11	Trigger this skill when the user asks for any of:
12
13	- "create a new mode for X"
14	- "fork slide / webcraft / … for a different domain"
15	- "scaffold a mode"
16	- "add a [mindmap \| spreadsheet \| timeline \| annotator \| …] mode"
17	- "design the viewer for a mode that …"
18
19	If the user only asks about an existing mode's behavior, this skill is not the right tool — direct them to `docs/reference/viewer-agent-protocol.md` or the mode's own SKILL.md.
20
21	---
22
23	## Phase 1 — Discovery interview
24
25	Goal: extract enough signal that you can fill every field of the design brief without further interrogation. Ask one question at a time with `AskUserQuestion`; let each answer shape the next. Don't dump a 20-question survey on the user.
26
27	### Discovery questions (ask in this order, branch as noted)
28
29	1. Identity — name (kebab-case), one-line displayName, two-line description, intended icon style. This is the only question you can pose as a single multi-line form.
30	2. Domain in one sentence — what is the user creating with this mode? A document? A canvas of objects? A timeline? Let the user answer free-form before you offer Source-kind options. Read `references/domain-and-sources.md` while they think.
31	3. Inspiration vs original — does this mode borrow content (commands, references, design language, taxonomy) from an existing tool, library, or project? If yes, ask the upstream's name + URL + license. This determines whether you'll write `NOTICE.md` and set `inspiredBy`. Read `references/external-integrations.md` for the borrow-vs-inspiration line.
32	4. Source kind (branch on Q2 + Q3) — present `file-glob` / `json-file` / `aggregate-file` / `memory` with the one that fits Q2's domain pre-selected as "Recommended". Explain why it fits in the option's `description`. If `aggregate-file` wins, note that you'll also generate `domain.ts`.
33	5. Workspace model (when Q4 is not `memory`) — `"all"` / `"manifest"` / `"single"`; do users author many independent files, an ordered/structured set, or one main document? See `references/viewer-contract-patterns.md` for the FileWorkspaceModel matrix.
34	6. ViewerAddress vocabulary — "what's the smallest thing the user can point at?" Propose a draft `{ contentSet?, ... }` based on Q2's domain noun (slide / page / row / node / heading). Confirm with the user; explicitly name the coarse "where" key and any fine "within" key. See `references/viewer-contract-patterns.md::ViewerAddress`.
35	7. Initial action space — propose 2–5 actions with id / label / category / agentInvocable. Almost every viewer needs a `navigate-to` (navigate); add `ui` and `custom` only if the user names a concrete need. Don't list `capture` — it's framework-built-in.
36	8. External integrations (conditional — only ask if Q2 or Q3 implied an external API / SDK / CDN / library / API key) — does the viewer fetch external APIs (→ `proxy`)? does the agent or viewer need API keys (→ `init.params` with `sensitive: true` + `envMapping`)? does this need an MCP server (→ `skill.mcpServers`)? Read `references/external-integrations.md` for the proxy / Babel-JIT / NOTICE patterns.
37	9. Seed strategy — single file, multiple use-case content sets, or language×theme matrix? What's the first seed's narrative — what story does it tell to a brand-new user? See `references/seed-and-showcase.md`.
38	10. Evolution directive — give the evolve agent a one-sentence "what should it learn for this mode?" (e.g., "Learn the user's slide design preferences: typography, palette, density, structure"). This is what ma

People who liked this also viewed

6 picks

Type

create-mode

152stars15forks

View on GitHub

How to install create-mode?

pandazki/pneuma-skills/create-mode

$npx -y skills add pandazki/pneuma-skills --skill create-mode

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Create Mode
2
3	A guided journey for adding a new mode to Pneuma Skills. The journey has three phases — Discovery (ask the right questions), Brief (write down every key choice with rationale and get the user's confirmation), Implementation (generate files). Each phase has a clear handoff to the next; never skip Brief. Pneuma already has twelve modes and a stable contract layer; the cost of a thoughtful 10-minute design brief is much smaller than the cost of building the wrong viewer.
4
5	The reference material in `references/` is where the knowledge lives — go read the relevant one whenever you're about to make a meaningful decision. SKILL.md is the journey, not the textbook.
6
7	---
8
9	## When to use
10
11	Trigger this skill when the user asks for any of:
12
13	- "create a new mode for X"
14	- "fork slide / webcraft / … for a different domain"
15	- "scaffold a mode"
16	- "add a [mindmap \| spreadsheet \| timeline \| annotator \| …] mode"
17	- "design the viewer for a mode that …"
18
19	If the user only asks about an existing mode's behavior, this skill is not the right tool — direct them to `docs/reference/viewer-agent-protocol.md` or the mode's own SKILL.md.
20
21	---
22
23	## Phase 1 — Discovery interview
24
25	Goal: extract enough signal that you can fill every field of the design brief without further interrogation. Ask one question at a time with `AskUserQuestion`; let each answer shape the next. Don't dump a 20-question survey on the user.
26
27	### Discovery questions (ask in this order, branch as noted)
28
29	1. Identity — name (kebab-case), one-line displayName, two-line description, intended icon style. This is the only question you can pose as a single multi-line form.
30	2. Domain in one sentence — what is the user creating with this mode? A document? A canvas of objects? A timeline? Let the user answer free-form before you offer Source-kind options. Read `references/domain-and-sources.md` while they think.
31	3. Inspiration vs original — does this mode borrow content (commands, references, design language, taxonomy) from an existing tool, library, or project? If yes, ask the upstream's name + URL + license. This determines whether you'll write `NOTICE.md` and set `inspiredBy`. Read `references/external-integrations.md` for the borrow-vs-inspiration line.
32	4. Source kind (branch on Q2 + Q3) — present `file-glob` / `json-file` / `aggregate-file` / `memory` with the one that fits Q2's domain pre-selected as "Recommended". Explain why it fits in the option's `description`. If `aggregate-file` wins, note that you'll also generate `domain.ts`.
33	5. Workspace model (when Q4 is not `memory`) — `"all"` / `"manifest"` / `"single"`; do users author many independent files, an ordered/structured set, or one main document? See `references/viewer-contract-patterns.md` for the FileWorkspaceModel matrix.
34	6. ViewerAddress vocabulary — "what's the smallest thing the user can point at?" Propose a draft `{ contentSet?, ... }` based on Q2's domain noun (slide / page / row / node / heading). Confirm with the user; explicitly name the coarse "where" key and any fine "within" key. See `references/viewer-contract-patterns.md::ViewerAddress`.
35	7. Initial action space — propose 2–5 actions with id / label / category / agentInvocable. Almost every viewer needs a `navigate-to` (navigate); add `ui` and `custom` only if the user names a concrete need. Don't list `capture` — it's framework-built-in.
36	8. External integrations (conditional — only ask if Q2 or Q3 implied an external API / SDK / CDN / library / API key) — does the viewer fetch external APIs (→ `proxy`)? does the agent or viewer need API keys (→ `init.params` with `sensitive: true` + `envMapping`)? does this need an MCP server (→ `skill.mcpServers`)? Read `references/external-integrations.md` for the proxy / Babel-JIT / NOTICE patterns.
37	9. Seed strategy — single file, multiple use-case content sets, or language×theme matrix? What's the first seed's narrative — what story does it tell to a brand-new user? See `references/seed-and-showcase.md`.
38	10. Evolution directive — give the evolve agent a one-sentence "what should it learn for this mode?" (e.g., "Learn the user's slide design preferences: typography, palette, density, structure"). This is what ma

People who liked this also viewed

6 picks

Type