pneuma-preferences

Name: pneuma-preferences
Author: pandazki

152stars15forks

How to install pneuma-preferences?

pandazki/pneuma-skills/pneuma-preferences

$npx -y skills add pandazki/pneuma-skills --skill pneuma-preferences

Installs into the current project.

Summary

Persistent user preference memory across sessions. Consult this skill BEFORE making any design, style, or aesthetic decisions — choosing colors, themes, layouts, fonts, tone of voice, content density, or visual direction. Also consult when starting a new creative task in any mode

Files · 1

View on GitHub

SKILL.md

1	# User Preferences
2
3	You have persistent memory about this user stored in `~/.pneuma/preferences/`. This is your external memory — it survives across sessions, across workspaces, across modes.
4
5	## Why This Matters
6
7	Every session starts from zero. Without preferences, you guess at style choices, repeat mistakes the user already corrected, and miss patterns you've seen before. Preferences solve this:
8
9	- The user corrected you three sessions ago about font sizes → that's recorded, you won't repeat it
10	- The user always chooses muted colors → you start there instead of guessing
11	- The user prefers Chinese when writing content → you know before they have to say it again
12
13	Preferences are not instructions. They're your understanding of who this user is and how they work. The better your understanding, the less friction in collaboration.
14
15	## Files
16
17	\| File \| What goes in it \|
18	\|------\|----------------\|
19	\| `~/.pneuma/preferences/profile.md` \| Cross-mode: aesthetics, language, collaboration style, cognitive patterns, deep profile \|
20	\| `~/.pneuma/preferences/mode-{name}.md` \| Mode-specific: slide layout habits, doc formatting style, color choices, etc. \|
21
22	Files are created by you as needed. An absent file means no profile exists yet — not an error.
23
24	Project sessions carry a parallel set of preference files at `<projectRoot>/.pneuma/preferences/` — same schema, but scoped to one project. Those belong to the `pneuma-project` skill, not this one. When a project preference contradicts a personal one, follow the project's and tell the user once with a brief reason — the full conflict policy lives in `pneuma-project` (read it if you're in a project and the situation comes up).
25
26	## Three-Layer Model
27
28	Preferences organize into three layers, each requiring different levels of evidence:
29
30	Layer 1 — Observable preferences (profile.md): Surface patterns you can see directly. Language, aesthetic tendencies, collaboration style, cognitive approach. A few sessions of observation is enough.
31
32	Layer 2 — Deep profile (profile.md, deeper section): What drives the surface patterns. Capability boundaries, value anchors (efficiency vs. craft, innovation vs. stability), latent habits, contradictions. This layer requires substantial observation — premature deep profiles are worse than none, because they create false confidence.
33
34	Layer 3 — Per-mode preferences (mode-{name}.md): Concrete habits in a specific mode. "Always uses light themes in slides", "prefers two-column layouts for comparison content". Distinguish what the user explicitly stated from what you inferred through observation.
35
36	The layers exist because surface preferences are easy to spot but shallow, while deep patterns are powerful but require evidence. Jumping to Layer 2 from one session is the classic mistake — it produces labels, not understanding.
37
38	## Living Document Philosophy
39
40	Preference files are living documents, not label databases. This distinction matters:
41
42	- Full rewrite, not append — each update is a fresh look at the whole portrait, not a new line at the bottom. Reread everything, reconsider, rewrite what changed.
43	- Preserve contradictions — people are not consistent. If behavior contradicts itself, record both sides. Forcing coherence is a lie that degrades your model.
44	- Everything is deletable — any entry can be overturned by later observation. Nothing is permanent.
45	- Temporary vs. stable — "this project needs dark theme" is not a preference. "Consistently chooses dark themes across projects" is.
46	- Describe, don't label — "tends to request minimal text per slide" not "is a minimalist". Patterns, not personality types.
47
48	Why full rewrite? Because appending creates a pile of contradictory observations. A living document forces you to reconcile or explicitly preserve tension. The result is a coherent portrait, not a changelog.
49
50	Size discipline — keep each preference file under ~2KB. Preference files are read into your working context; bloated files waste the token budget you need for actual work. Full rewrite naturally controls growth, but if a file feels long, tighten prose and drop stale entries. A concise portrait is more useful than an exhaustive one.
51
52	## When to Read
53
54	Read preferences silently. Do not announce it.
55
56	- Start of creative work — before your first design decision in a session
57	- Before style choices — colors, themes, layouts, density, typography, tone
58	- **When the user

People who liked this also viewed

6 picks

Type

pneuma-preferences

152stars15forks

View on GitHub

How to install pneuma-preferences?

pandazki/pneuma-skills/pneuma-preferences

$npx -y skills add pandazki/pneuma-skills --skill pneuma-preferences

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# User Preferences
2
3	You have persistent memory about this user stored in `~/.pneuma/preferences/`. This is your external memory — it survives across sessions, across workspaces, across modes.
4
5	## Why This Matters
6
7	Every session starts from zero. Without preferences, you guess at style choices, repeat mistakes the user already corrected, and miss patterns you've seen before. Preferences solve this:
8
9	- The user corrected you three sessions ago about font sizes → that's recorded, you won't repeat it
10	- The user always chooses muted colors → you start there instead of guessing
11	- The user prefers Chinese when writing content → you know before they have to say it again
12
13	Preferences are not instructions. They're your understanding of who this user is and how they work. The better your understanding, the less friction in collaboration.
14
15	## Files
16
17	\| File \| What goes in it \|
18	\|------\|----------------\|
19	\| `~/.pneuma/preferences/profile.md` \| Cross-mode: aesthetics, language, collaboration style, cognitive patterns, deep profile \|
20	\| `~/.pneuma/preferences/mode-{name}.md` \| Mode-specific: slide layout habits, doc formatting style, color choices, etc. \|
21
22	Files are created by you as needed. An absent file means no profile exists yet — not an error.
23
24	Project sessions carry a parallel set of preference files at `<projectRoot>/.pneuma/preferences/` — same schema, but scoped to one project. Those belong to the `pneuma-project` skill, not this one. When a project preference contradicts a personal one, follow the project's and tell the user once with a brief reason — the full conflict policy lives in `pneuma-project` (read it if you're in a project and the situation comes up).
25
26	## Three-Layer Model
27
28	Preferences organize into three layers, each requiring different levels of evidence:
29
30	Layer 1 — Observable preferences (profile.md): Surface patterns you can see directly. Language, aesthetic tendencies, collaboration style, cognitive approach. A few sessions of observation is enough.
31
32	Layer 2 — Deep profile (profile.md, deeper section): What drives the surface patterns. Capability boundaries, value anchors (efficiency vs. craft, innovation vs. stability), latent habits, contradictions. This layer requires substantial observation — premature deep profiles are worse than none, because they create false confidence.
33
34	Layer 3 — Per-mode preferences (mode-{name}.md): Concrete habits in a specific mode. "Always uses light themes in slides", "prefers two-column layouts for comparison content". Distinguish what the user explicitly stated from what you inferred through observation.
35
36	The layers exist because surface preferences are easy to spot but shallow, while deep patterns are powerful but require evidence. Jumping to Layer 2 from one session is the classic mistake — it produces labels, not understanding.
37
38	## Living Document Philosophy
39
40	Preference files are living documents, not label databases. This distinction matters:
41
42	- Full rewrite, not append — each update is a fresh look at the whole portrait, not a new line at the bottom. Reread everything, reconsider, rewrite what changed.
43	- Preserve contradictions — people are not consistent. If behavior contradicts itself, record both sides. Forcing coherence is a lie that degrades your model.
44	- Everything is deletable — any entry can be overturned by later observation. Nothing is permanent.
45	- Temporary vs. stable — "this project needs dark theme" is not a preference. "Consistently chooses dark themes across projects" is.
46	- Describe, don't label — "tends to request minimal text per slide" not "is a minimalist". Patterns, not personality types.
47
48	Why full rewrite? Because appending creates a pile of contradictory observations. A living document forces you to reconcile or explicitly preserve tension. The result is a coherent portrait, not a changelog.
49
50	Size discipline — keep each preference file under ~2KB. Preference files are read into your working context; bloated files waste the token budget you need for actual work. Full rewrite naturally controls growth, but if a file feels long, tighten prose and drop stale entries. A concise portrait is more useful than an exhaustive one.
51
52	## When to Read
53
54	Read preferences silently. Do not announce it.
55
56	- Start of creative work — before your first design decision in a session
57	- Before style choices — colors, themes, layouts, density, typography, tone
58	- **When the user

People who liked this also viewed

6 picks

Type