@design-intelligence/ghost 0.28.0 → 0.30.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/README.md +2 -2
- package/dist/cli.js +2 -2
- package/dist/cli.js.map +1 -1
- package/dist/commands/command-discovery.d.ts.map +1 -1
- package/dist/commands/command-discovery.js +10 -3
- package/dist/commands/command-discovery.js.map +1 -1
- package/dist/commands/gather-command.js +5 -5
- package/dist/commands/gather-command.js.map +1 -1
- package/dist/commands/init-command.d.ts.map +1 -1
- package/dist/commands/init-command.js +2 -2
- package/dist/commands/init-command.js.map +1 -1
- package/dist/commands/pull-command.d.ts.map +1 -1
- package/dist/commands/pull-command.js +8 -7
- package/dist/commands/pull-command.js.map +1 -1
- package/dist/commands/review-command.d.ts.map +1 -1
- package/dist/commands/review-command.js +1 -2
- package/dist/commands/review-command.js.map +1 -1
- package/dist/commands/skill-command.d.ts.map +1 -1
- package/dist/commands/skill-command.js +8 -1
- package/dist/commands/skill-command.js.map +1 -1
- package/dist/commands/stats-command.d.ts +3 -0
- package/dist/commands/stats-command.d.ts.map +1 -0
- package/dist/commands/{pulse-command.js → stats-command.js} +59 -39
- package/dist/commands/stats-command.js.map +1 -0
- package/dist/commands/stats-observations.d.ts +10 -0
- package/dist/commands/stats-observations.d.ts.map +1 -0
- package/dist/commands/stats-observations.js +47 -0
- package/dist/commands/stats-observations.js.map +1 -0
- package/dist/embed/gather.d.ts.map +1 -1
- package/dist/embed/gather.js +3 -4
- package/dist/embed/gather.js.map +1 -1
- package/dist/embed/pull.d.ts.map +1 -1
- package/dist/embed/pull.js +1 -3
- package/dist/embed/pull.js.map +1 -1
- package/dist/embed/types.d.ts +2 -6
- package/dist/embed/types.d.ts.map +1 -1
- package/dist/ghost-core/catalog/assemble.d.ts.map +1 -1
- package/dist/ghost-core/catalog/assemble.js +1 -5
- package/dist/ghost-core/catalog/assemble.js.map +1 -1
- package/dist/ghost-core/catalog/closest.d.ts +1 -1
- package/dist/ghost-core/catalog/closest.js +1 -1
- package/dist/ghost-core/catalog/menu.d.ts +7 -9
- package/dist/ghost-core/catalog/menu.d.ts.map +1 -1
- package/dist/ghost-core/catalog/menu.js +4 -6
- package/dist/ghost-core/catalog/menu.js.map +1 -1
- package/dist/ghost-core/catalog/types.d.ts +2 -6
- package/dist/ghost-core/catalog/types.d.ts.map +1 -1
- package/dist/ghost-core/node/schema.d.ts +4 -4
- package/dist/ghost-core/node/schema.d.ts.map +1 -1
- package/dist/ghost-core/node/schema.js +10 -4
- package/dist/ghost-core/node/schema.js.map +1 -1
- package/dist/ghost-core/node/serialize.d.ts +5 -7
- package/dist/ghost-core/node/serialize.d.ts.map +1 -1
- package/dist/ghost-core/node/serialize.js +9 -18
- package/dist/ghost-core/node/serialize.js.map +1 -1
- package/dist/ghost-core/node/types.d.ts +5 -7
- package/dist/ghost-core/node/types.d.ts.map +1 -1
- package/dist/init-payloads/median/cliche.median.md +1 -1
- package/dist/init-payloads/skeleton/brand.md +1 -1
- package/dist/init-payloads/skeleton/context.conversation.md +1 -1
- package/dist/init-payloads/skeleton/foundation.color.md +4 -1
- package/dist/init-payloads/skeleton/foundation.composition.md +4 -1
- package/dist/init-payloads/skeleton/foundation.controls.md +4 -1
- package/dist/init-payloads/skeleton/foundation.layout.md +4 -1
- package/dist/init-payloads/skeleton/foundation.motion.md +4 -1
- package/dist/init-payloads/skeleton/foundation.type.md +4 -1
- package/dist/init-payloads/skeleton/foundation.voice.md +4 -1
- package/dist/init-payloads/skeleton/glossary.md +3 -3
- package/dist/init-payloads/vessel-light/anti-goal.median.md +1 -1
- package/dist/init-payloads/vessel-light/anti-goal.tells.md +1 -1
- package/dist/init-payloads/vessel-light/checks/shape-matches-job.md +2 -2
- package/dist/init-payloads/vessel-light/glossary.md +3 -3
- package/dist/init-payloads/vessel-light/grammar.color-roles.md +1 -1
- package/dist/init-payloads/vessel-light/grammar.conversation.md +2 -2
- package/dist/init-payloads/vessel-light/grammar.deletion.md +1 -1
- package/dist/init-payloads/vessel-light/grammar.hierarchy.md +2 -2
- package/dist/init-payloads/vessel-light/grammar.job.md +14 -14
- package/dist/init-payloads/vessel-light/grammar.motion.md +1 -1
- package/dist/init-payloads/vessel-light/grammar.rhythm.md +1 -1
- package/dist/init-payloads/vessel-light/grammar.surfaces.md +2 -2
- package/dist/init-payloads/vessel-light/index.md +7 -12
- package/dist/init-payloads/vessel-light/materials/{ref → examples}/composition.conversation.html +3 -3
- package/dist/init-payloads/vessel-light/materials/{ref → examples}/composition.editorial.html +3 -3
- package/dist/init-payloads/vessel-light/materials/{ref → examples}/composition.form.html +3 -3
- package/dist/init-payloads/vessel-light/materials/{ref → examples}/composition.overlay.html +3 -3
- package/dist/init-payloads/vessel-light/materials/{ref → examples}/composition.table.html +3 -3
- package/dist/init-payloads/vessel-light/materials/{ref → examples}/email.html +3 -3
- package/dist/init-payloads/vessel-light/materials/tokens.css +1 -1
- package/dist/init-payloads/vessel-light/register.data-density.md +2 -2
- package/dist/init-payloads/vessel-light/register.editorial.md +2 -2
- package/dist/init-payloads/vessel-light/register.email.md +2 -2
- package/dist/init-payloads/vessel-light/signature.palette.md +1 -1
- package/dist/init-payloads/vessel-light/signature.shape.md +1 -1
- package/dist/init-payloads/vessel-light/signature.temperature.md +1 -1
- package/dist/init-payloads/vessel-light/signature.type.md +1 -1
- package/dist/observability-events.js +2 -2
- package/dist/review/baseline.d.ts +1 -1
- package/dist/review/baseline.d.ts.map +1 -1
- package/dist/review/baseline.js +2 -2
- package/dist/review/baseline.js.map +1 -1
- package/dist/review/review-packet.d.ts +2 -1
- package/dist/review/review-packet.d.ts.map +1 -1
- package/dist/review/review-packet.js +6 -4
- package/dist/review/review-packet.js.map +1 -1
- package/dist/scan/fingerprint-package-lint.d.ts.map +1 -1
- package/dist/scan/fingerprint-package-lint.js +9 -17
- package/dist/scan/fingerprint-package-lint.js.map +1 -1
- package/dist/scan/templates.d.ts +1 -1
- package/dist/scan/templates.js +1 -1
- package/dist/scan/templates.js.map +1 -1
- package/dist/skill-bundle/SKILL.md +30 -50
- package/dist/skill-bundle/references/authoring.md +145 -0
- package/dist/skill-bundle/references/ground.md +57 -0
- package/dist/skill-bundle/references/making.md +71 -104
- package/dist/skill-bundle/references/materials.md +131 -0
- package/dist/skill-bundle/references/nodes.md +139 -0
- package/dist/skill-bundle/references/schema.md +50 -58
- package/dist/skill-bundle/references/steering-audit.md +9 -24
- package/dist/untrusted-framing.d.ts +9 -0
- package/dist/untrusted-framing.d.ts.map +1 -0
- package/dist/untrusted-framing.js +15 -0
- package/dist/untrusted-framing.js.map +1 -0
- package/package.json +1 -1
- package/dist/commands/pulse-command.d.ts +0 -3
- package/dist/commands/pulse-command.d.ts.map +0 -1
- package/dist/commands/pulse-command.js.map +0 -1
- package/dist/skill-bundle/references/adapting-a-starter.md +0 -110
- package/dist/skill-bundle/references/authoring-scenarios.md +0 -187
- package/dist/skill-bundle/references/blocks.md +0 -179
- package/dist/skill-bundle/references/brief.md +0 -50
- package/dist/skill-bundle/references/capture.md +0 -422
- package/dist/skill-bundle/references/concrete-tiers.md +0 -95
- package/dist/skill-bundle/references/distill.md +0 -205
- package/dist/skill-bundle/references/recall.md +0 -36
- package/dist/skill-bundle/references/self-check.md +0 -65
|
@@ -1,50 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: brief
|
|
3
|
-
description: Build a compact pre-generation packet from pulled ghost guidance.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Recipe: Brief Work From ghost Package
|
|
7
|
-
|
|
8
|
-
A brief is an ephemeral steering packet for the generating pass. It is not a new
|
|
9
|
-
schema and is never written back into `.ghost/`.
|
|
10
|
-
|
|
11
|
-
1. Run `ghost gather <ask> --format json` and select against contexts.
|
|
12
|
-
2. The cover is already in context and outside selection. Pull every applicable
|
|
13
|
-
node with `ghost pull <id> [<id>…]`; skip nodes whose stated situation does
|
|
14
|
-
not apply. Topic overlap alone is not applicability.
|
|
15
|
-
3. Note gather payload labels where present: `materials`, substantial fenced
|
|
16
|
-
examples, or a `## Skeleton`. If there is no concrete material for this
|
|
17
|
-
surface, the readiness ceiling is **Yellow**.
|
|
18
|
-
4. If no node applies, name the package's silence, follow the cover silence
|
|
19
|
-
posture, and keep provisional reasoning separate from ghost-backed claims.
|
|
20
|
-
|
|
21
|
-
## The packet: five sections only
|
|
22
|
-
|
|
23
|
-
Return this shape:
|
|
24
|
-
|
|
25
|
-
```markdown
|
|
26
|
-
## Grounded in
|
|
27
|
-
- `node.id` — why it was selected
|
|
28
|
-
|
|
29
|
-
## Non-negotiables
|
|
30
|
-
- ≤5 lines, each cited to a node id
|
|
31
|
-
|
|
32
|
-
## Materials inline
|
|
33
|
-
- concrete locators, inlined snippets, inspect-pointers, and what to view/use
|
|
34
|
-
|
|
35
|
-
## Skeleton
|
|
36
|
-
- matching pulled Skeleton, or "none pulled"
|
|
37
|
-
|
|
38
|
-
## Silent / provisional
|
|
39
|
-
- what ghost does not cover and what local evidence carries
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
Rules:
|
|
43
|
-
|
|
44
|
-
- Do not add sections for every kind. Sections dilute instruction weight.
|
|
45
|
-
- Treat `ghost pull` ordering as packet structure: stance first, concrete-material
|
|
46
|
-
nodes next, prose rules, Skeletons dead last.
|
|
47
|
-
- If a pulled Skeleton matches the surface, begin the artifact from it verbatim
|
|
48
|
-
before filling.
|
|
49
|
-
- Anti-goals are review-critical: state the positive replacement, not just the
|
|
50
|
-
rejected pattern.
|
|
@@ -1,422 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: capture
|
|
3
|
-
description: Author repo-local ghost packages as a flat set of prose nodes.
|
|
4
|
-
handoffs:
|
|
5
|
-
- label: Inspect the package
|
|
6
|
-
command: ghost validate
|
|
7
|
-
prompt: Does this ghost package validate, and what is absent?
|
|
8
|
-
---
|
|
9
|
-
|
|
10
|
-
# Recipe: Author ghost Package
|
|
11
|
-
|
|
12
|
-
**Goal:** record durable brand guidance in `.ghost/` as a flat set of prose
|
|
13
|
-
**nodes**. If a change is uncommitted, it is draft work. If it is checked in,
|
|
14
|
-
ghost treats the `.ghost/` package as canonical.
|
|
15
|
-
|
|
16
|
-
```text
|
|
17
|
-
.ghost/
|
|
18
|
-
manifest.yml # schema + id
|
|
19
|
-
glossary.md # the kind vocabulary + what each kind means
|
|
20
|
-
principle.trust.md # guidance of kind `principle`
|
|
21
|
-
pattern.invoice.md # a pattern with an optional ## Skeleton
|
|
22
|
-
anti-goal.generic.md # a review-critical replacement rule
|
|
23
|
-
voice.md # guidance without a kind
|
|
24
|
-
```
|
|
25
|
-
|
|
26
|
-
A **node** is a markdown file: a `context`, optional `materials`, and a
|
|
27
|
-
prose body. The package is **flat** — no hierarchy, no inheritance, no edges. A
|
|
28
|
-
node's kind comes from its filename prefix; the glossary declares the kinds.
|
|
29
|
-
|
|
30
|
-
## Lead with an annotated exemplar over a complete artifact
|
|
31
|
-
|
|
32
|
-
The strongest steering artifact is not a summary; it is a complete on-brand
|
|
33
|
-
artifact with annotation. Capture the whole thing, then name what the agent
|
|
34
|
-
should preserve and what is incidental.
|
|
35
|
-
|
|
36
|
-
`exemplar.status-card.md`:
|
|
37
|
-
|
|
38
|
-
````markdown
|
|
39
|
-
---
|
|
40
|
-
context: Building or reviewing a status card.
|
|
41
|
-
materials:
|
|
42
|
-
- src/components/status-card.tsx
|
|
43
|
-
---
|
|
44
|
-
|
|
45
|
-
Normative for the opening fact, square edge, evidence placement, and accountable
|
|
46
|
-
action. The exact invoice count and dates are incidental.
|
|
47
|
-
|
|
48
|
-
```tsx
|
|
49
|
-
<section className="border-l border-[#D8DED8] bg-[#F7F5EF] p-6 text-[#17201B]">
|
|
50
|
-
<p className="text-xs uppercase tracking-[0.14em] text-[#2F6F4F]">Bank sync</p>
|
|
51
|
-
<h1 className="mt-3 text-2xl font-semibold">3 deposits need matching</h1>
|
|
52
|
-
<p className="mt-2 max-w-prose text-sm">
|
|
53
|
-
They total $8,410 and arrived between Jul 12 and Jul 15.
|
|
54
|
-
</p>
|
|
55
|
-
<button className="mt-6 border border-[#17201B] px-4 py-2 text-sm">
|
|
56
|
-
Match deposits — about 4 minutes
|
|
57
|
-
</button>
|
|
58
|
-
</section>
|
|
59
|
-
```
|
|
60
|
-
|
|
61
|
-
What makes it ours: the surface opens with an accountable fact, keeps evidence
|
|
62
|
-
next to the claim, uses square structure instead of floating cards, and prices
|
|
63
|
-
the user's next action in time. Do not copy the exact amounts, dates, or class
|
|
64
|
-
names unless the implementation path confirms them.
|
|
65
|
-
````
|
|
66
|
-
|
|
67
|
-
The annotation is load-bearing. A bare sample teaches form; the annotation
|
|
68
|
-
teaches which features of the form are intentional, which stops an agent from
|
|
69
|
-
copying incidental details.
|
|
70
|
-
|
|
71
|
-
An exemplar should identify eight things in prose:
|
|
72
|
-
|
|
73
|
-
1. the rendered artifact the agent should inspect;
|
|
74
|
-
2. the implementation, fixture, or source that produced it;
|
|
75
|
-
3. what is intentional and load-bearing;
|
|
76
|
-
4. what is incidental and should change with task facts;
|
|
77
|
-
5. the observable conditions where it applies;
|
|
78
|
-
6. the content, viewport, or state conditions that challenge or break it;
|
|
79
|
-
7. the current materials it demonstrates;
|
|
80
|
-
8. provenance, owner, review date, or compatibility signal when freshness
|
|
81
|
-
matters.
|
|
82
|
-
|
|
83
|
-
Put locators in `materials`: render, implementation, assets, source, or external
|
|
84
|
-
reference. Put interpretation in the body. Ownership and freshness also live in
|
|
85
|
-
prose, the exemplar artifact, or a repo-owned system; they are not structured
|
|
86
|
-
`materials` metadata.
|
|
87
|
-
|
|
88
|
-
A rendered exemplar proves one solution under stated conditions. It is not a
|
|
89
|
-
universal visual target. Provide one exemplar for each distinct,
|
|
90
|
-
composition-critical surface shape that earns one, and say which details may be
|
|
91
|
-
reused. If unrelated tasks start converging on the same composition, section
|
|
92
|
-
order, or decoration, tighten applicability, add a shape-appropriate exemplar,
|
|
93
|
-
or remove the exemplar.
|
|
94
|
-
|
|
95
|
-
Protect exact voice artifacts the same way. A real on-brand error message
|
|
96
|
-
out-steers a paragraph about error-message voice:
|
|
97
|
-
|
|
98
|
-
`exemplar.error-voice.md`:
|
|
99
|
-
|
|
100
|
-
```markdown
|
|
101
|
-
---
|
|
102
|
-
context: Writing or reviewing an error message.
|
|
103
|
-
---
|
|
104
|
-
|
|
105
|
-
Normative for rhythm and stance at failure moments; match its form, not its words.
|
|
106
|
-
|
|
107
|
-
> We couldn't save your changes. Your work is still here — try again, and if it
|
|
108
|
-
> keeps failing, we'll hold onto everything while you sort it out.
|
|
109
|
-
|
|
110
|
-
What makes it ours: leads with what happened, not with apology. States what is
|
|
111
|
-
safe before what to do. One calm next step. No "Oops," no exclamation points,
|
|
112
|
-
no blame on the user or the network.
|
|
113
|
-
```
|
|
114
|
-
|
|
115
|
-
## Write patterns as bound and open
|
|
116
|
-
|
|
117
|
-
A pattern node binds part of a reusable structure and leaves the rest open.
|
|
118
|
-
State both explicitly:
|
|
119
|
-
|
|
120
|
-
- **Bound** — what the agent should not redecide: the structural moves fixed
|
|
121
|
-
regardless of task (what renders first, what appears exactly once, what may
|
|
122
|
-
never compete for attention).
|
|
123
|
-
- **Open** — where the agent may choose, within limits (which evidence shape
|
|
124
|
-
fits, how tone flexes, where secondary content may go).
|
|
125
|
-
|
|
126
|
-
If everything is bound, the node is a template, not a pattern. If nothing is
|
|
127
|
-
bound, it is vibes, not steering. A pattern may also `Refines:` a broader
|
|
128
|
-
principle by id; when the two conflict, the principle wins.
|
|
129
|
-
|
|
130
|
-
## Add Skeletons when the opening structure matters
|
|
131
|
-
|
|
132
|
-
A `## Skeleton` section contains the literal opening structure the agent should
|
|
133
|
-
start from. Use it on a pattern node when the first tokens determine whether the
|
|
134
|
-
surface lands in the right shape.
|
|
135
|
-
|
|
136
|
-
Rules:
|
|
137
|
-
|
|
138
|
-
- Put exactly one fenced block in each `## Skeleton` section. `ghost validate`
|
|
139
|
-
warns when there are zero or multiple fences.
|
|
140
|
-
- Make the block complete enough to begin from, but not so complete that it
|
|
141
|
-
invents task-specific facts.
|
|
142
|
-
- Keep explanation above the `## Skeleton`; `ghost pull` extracts skeleton
|
|
143
|
-
fences and emits them dead last under the banner to begin from this structure.
|
|
144
|
-
- If a pulled skeleton matches the requested surface, write it first verbatim,
|
|
145
|
-
then fill it with the task's facts and materials.
|
|
146
|
-
|
|
147
|
-
## Write rules only after concrete artifacts
|
|
148
|
-
|
|
149
|
-
Rules are useful when they name the decision that survives across examples.
|
|
150
|
-
Keep them short, specific, and attached to concrete objects whenever possible:
|
|
151
|
-
|
|
152
|
-
- exact values when the agent keeps inventing values;
|
|
153
|
-
- never/always invariants when a hard line is crossed;
|
|
154
|
-
- conditions in prose when guidance applies only in a situation;
|
|
155
|
-
- decision traces when two plausible choices keep competing.
|
|
156
|
-
|
|
157
|
-
Do not turn every observation into a rule. Stale or generic rules average
|
|
158
|
-
against the exemplars and pull the packet back toward the median.
|
|
159
|
-
|
|
160
|
-
## Write anti-goals as replacement, not as blacklist
|
|
161
|
-
|
|
162
|
-
An anti-goal is ordinary node prose whose kind the glossary defines as a
|
|
163
|
-
review-critical replacement rule.
|
|
164
|
-
|
|
165
|
-
A good anti-goal states **not X; instead Y; recognize the switch by Z**. The
|
|
166
|
-
replacement matters because negation alone raises the salience of the rejected
|
|
167
|
-
thing.
|
|
168
|
-
|
|
169
|
-
`anti-goal.generic-ui.md`:
|
|
170
|
-
|
|
171
|
-
```markdown
|
|
172
|
-
---
|
|
173
|
-
context: Building or reviewing an AI dashboard.
|
|
174
|
-
---
|
|
175
|
-
|
|
176
|
-
Not: rounded-xl cards on gray-50, indigo primary buttons, gradient hero text,
|
|
177
|
-
emoji headings, and "You're crushing it" optimism.
|
|
178
|
-
|
|
179
|
-
Instead: flat paper surfaces, one restrained accent, square alignment, and a
|
|
180
|
-
next action backed by the number or source that justifies it.
|
|
181
|
-
|
|
182
|
-
Recognize the switch: if removing the logo would make the surface look like any
|
|
183
|
-
SaaS template, the anti-goal failed even when every token is technically valid.
|
|
184
|
-
```
|
|
185
|
-
|
|
186
|
-
The strongest anti-goal is silent: purged from exemplars, absent from starter
|
|
187
|
-
structures, and reinforced by a check in review. Use anti-goal prose to name the
|
|
188
|
-
replacement; use checks to catch regressions.
|
|
189
|
-
|
|
190
|
-
## The node shape
|
|
191
|
-
|
|
192
|
-
A node at `principle.trust.md` (id `principle.trust`, kind `principle`):
|
|
193
|
-
|
|
194
|
-
```markdown
|
|
195
|
-
---
|
|
196
|
-
context: A person is about to pay. # the retrieval payload
|
|
197
|
-
# optional: materials, audience, stage, or other free-form keys
|
|
198
|
-
---
|
|
199
|
-
|
|
200
|
-
Near the moment of payment, reduce felt risk. Proximity of reassurance to the
|
|
201
|
-
action beats completeness...
|
|
202
|
-
```
|
|
203
|
-
|
|
204
|
-
- **`context`** tells the agent when to gather the node. Name the observable
|
|
205
|
-
condition under which it applies, and nothing else. Put the guidance and what
|
|
206
|
-
the node contributes in the body. State the condition directly; use “gather
|
|
207
|
-
when” only when the direct condition cannot carry a necessary routing
|
|
208
|
-
constraint. `ghost gather` emits id, kind, context, concrete coverage, payload
|
|
209
|
-
labels, and material count; the agent matches the ask against applicability.
|
|
210
|
-
- **Kind is the filename prefix** and must be a kind the glossary declares. A
|
|
211
|
-
bare name (`voice.md`) has no kind.
|
|
212
|
-
- **Altitude lives in the prose.** State universal guidance plainly; give a
|
|
213
|
-
narrower guidance a **condition** — the situation it applies in — in the prose
|
|
214
|
-
and usually in the context. Do not use broad universal imperatives unless
|
|
215
|
-
universal retrieval is intended. Never file a node by destination
|
|
216
|
-
(`for-emails.md`).
|
|
217
|
-
- **Concreteness is derived.** A node carries concrete material when it has
|
|
218
|
-
`materials`, a substantial fenced example, or a `## Skeleton`. You do not
|
|
219
|
-
declare a separate type.
|
|
220
|
-
|
|
221
|
-
## What a node body answers
|
|
222
|
-
|
|
223
|
-
While drafting, ask three questions of every node — *why* (the stance), *with
|
|
224
|
-
what* (the materials), and *how it is assembled* (the patterns). These are
|
|
225
|
-
drafting prompts, never frontmatter keys, node types, or required sections, and
|
|
226
|
-
a node may answer only one. Each answer lands as a steering dimension the
|
|
227
|
-
machinery already scores:
|
|
228
|
-
|
|
229
|
-
- **why** lands as stance prose — read first in `ghost pull`, weakest at
|
|
230
|
-
moving output form on its own; it is the yardstick every later selection is
|
|
231
|
-
measured against.
|
|
232
|
-
- **with what** lands as `materials` and concreteness — affects pull packet
|
|
233
|
-
order and `ghost review` matching. See [blocks.md](blocks.md) for authoring
|
|
234
|
-
material-backed nodes.
|
|
235
|
-
- **how it is assembled** lands as patterns and `## Skeleton` sections — the
|
|
236
|
-
strongest steering; Skeleton fences are extracted and emitted dead last so
|
|
237
|
-
generation starts from them.
|
|
238
|
-
|
|
239
|
-
Keep a node **purpose-coherent**: one coherent decision, any length. Split only when it
|
|
240
|
-
contains a separate decision with different applicability.
|
|
241
|
-
|
|
242
|
-
## Node prose stances
|
|
243
|
-
|
|
244
|
-
Node prose is steering payload. A generic sentence in a node body averages every
|
|
245
|
-
future generation toward the median, so hold drafts to these stances before the
|
|
246
|
-
human sees them.
|
|
247
|
-
|
|
248
|
-
Two carve-outs come first, because they invert ordinary prose advice:
|
|
249
|
-
|
|
250
|
-
- **Anti-goals keep their negation.** "Not X; instead Y; recognize the switch
|
|
251
|
-
by Z" is the required anti-goal form. Naming the rejected thing is the
|
|
252
|
-
anti-goal's job; never "improve" one by stating only the replacement.
|
|
253
|
-
- **Invariants keep their absolutes.** "Never" and "always" are correct in an
|
|
254
|
-
invariant when the hard line is real and human-ratified. Absolutes are lazy
|
|
255
|
-
only when they stand in for an uncurated stance.
|
|
256
|
-
|
|
257
|
-
Everywhere else:
|
|
258
|
-
|
|
259
|
-
- **No aspirational abstractions.** "We value clarity and trust" steers
|
|
260
|
-
nothing. Name the decision the guidance forces: what gets picked when two goods
|
|
261
|
-
compete, and what gets given up.
|
|
262
|
-
- **Contexts must discriminate.** Read the context alone. If it also
|
|
263
|
-
fits a competitor's brand, it is retrieval-dead; rewrite it until it could
|
|
264
|
-
belong to no one else.
|
|
265
|
-
- **Cut unratified hedges.** "Generally," "where possible," and "consider" in a
|
|
266
|
-
node body mean the human never picked a side. Get the ratification or cut the
|
|
267
|
-
sentence.
|
|
268
|
-
- **Ban brand-deck filler.** "Elevate," "delight," "seamless," "best-in-class,"
|
|
269
|
-
"empower." When a brand doc supplies these words, they are testimony to
|
|
270
|
-
distill, never prose to keep.
|
|
271
|
-
- **Settle the altitude on purpose.** Every node is either claimed universal
|
|
272
|
-
or given its condition in the prose. A node body that does neither was never
|
|
273
|
-
curated for altitude; ask the human which it is.
|
|
274
|
-
|
|
275
|
-
## Score drafts before curation
|
|
276
|
-
|
|
277
|
-
Before handing drafts to the human (step 5), rate each node 1 to 5 per
|
|
278
|
-
dimension:
|
|
279
|
-
|
|
280
|
-
| Dimension | Question |
|
|
281
|
-
| --- | --- |
|
|
282
|
-
| Testimony | Can you quote the human words or artifact this node came from? |
|
|
283
|
-
| Discrimination | Does the context fit only this brand? |
|
|
284
|
-
| Force | Does the node body decide something, or merely describe something? |
|
|
285
|
-
| Altitude | Is it universal on purpose, or given its condition? |
|
|
286
|
-
| Residue | Is it free of starter-demo prose and brand-deck filler? |
|
|
287
|
-
|
|
288
|
-
Below 20 of 25, the node goes back to the interview, not into the package. The
|
|
289
|
-
score is a drafting gate for the agent; the human's keep/soften/reject verdict
|
|
290
|
-
in curation still decides what becomes canonical.
|
|
291
|
-
|
|
292
|
-
## Author through steering jobs
|
|
293
|
-
|
|
294
|
-
The steering jobs are questions, not mandatory fields. Encode the guidance in the
|
|
295
|
-
strongest form that fixes the observed failure.
|
|
296
|
-
|
|
297
|
-
| If the agent keeps... | Author... |
|
|
298
|
-
| --- | --- |
|
|
299
|
-
| missing the guidance | sharper `context`; move universal guidance to the cover |
|
|
300
|
-
| inventing values | `asset.*` node with materials and exact names |
|
|
301
|
-
| producing generic output | `anti-goal.*` replacement plus annotated `exemplar.*` |
|
|
302
|
-
| choosing the wrong structure | `pattern.*` with bound/open and a `## Skeleton` |
|
|
303
|
-
| crossing hard lines | invariant prose plus a review check |
|
|
304
|
-
| applying guidance too broadly | condition in prose |
|
|
305
|
-
| making bad tradeoffs | `decision.*` trace |
|
|
306
|
-
| producing correct but forgettable work | scoped `concept.*` |
|
|
307
|
-
|
|
308
|
-
A `concept.*` node holds a one-time creative move — a launch hook, a
|
|
309
|
-
campaign idea, a specific non-median leap the corpus would not have produced
|
|
310
|
-
by recombining its other guidance. Scope it explicitly to the task or surface
|
|
311
|
-
it was written for, keep it distinct from invariants, and do not generalize
|
|
312
|
-
it into permanent brand law. If it proves reusable later, promote it into an
|
|
313
|
-
exemplar or pattern deliberately; do not let a one-off default into durable
|
|
314
|
-
guidance through accumulation.
|
|
315
|
-
|
|
316
|
-
Ask while authoring:
|
|
317
|
-
|
|
318
|
-
- What complete artifact shows the brand at its best?
|
|
319
|
-
- What should be copied from this exemplar, and what is incidental?
|
|
320
|
-
- What generic output would an agent probably produce?
|
|
321
|
-
- What does this brand refuse, and what replaces it?
|
|
322
|
-
- What real material should the agent inspect?
|
|
323
|
-
- What opening structure should be preserved?
|
|
324
|
-
- What hard line would you block in review?
|
|
325
|
-
- When would this guidance reverse?
|
|
326
|
-
|
|
327
|
-
## Steps
|
|
328
|
-
|
|
329
|
-
### 1. Classify the authoring scenario
|
|
330
|
-
|
|
331
|
-
Decide which posture fits before scaffolding. Follow
|
|
332
|
-
[authoring-scenarios.md](authoring-scenarios.md) when setting up or substantially
|
|
333
|
-
revising a ghost package. Human intent anchors the guidance; what the human says and
|
|
334
|
-
shows — words, images, links, exemplars — is the evidence; agent synthesis is
|
|
335
|
-
draft work until a human curates it and Git review accepts it.
|
|
336
|
-
|
|
337
|
-
Monorepos and product suites run **one contract per package**.
|
|
338
|
-
|
|
339
|
-
### 2. Initialize
|
|
340
|
-
|
|
341
|
-
```bash
|
|
342
|
-
ghost init # scaffolds the steering starter
|
|
343
|
-
ghost validate
|
|
344
|
-
```
|
|
345
|
-
|
|
346
|
-
`ghost init` seeds the skeleton starter: the manifest, a starter
|
|
347
|
-
`glossary.md`, a `brand.md` cover, foundation chapters with open questions, and
|
|
348
|
-
the model cliche floor. Replace open questions with real product guidance before
|
|
349
|
-
using it to steer generation.
|
|
350
|
-
|
|
351
|
-
Write the manifest-declared cover as the human-curated front door:
|
|
352
|
-
non-negotiables that apply to every task, what the package covers, and any
|
|
353
|
-
stricter silence posture. `ghost gather` inlines it before the menu, so anything
|
|
354
|
-
that must never be missed belongs there.
|
|
355
|
-
|
|
356
|
-
Nodes may carry a `materials` list in frontmatter: explicit repo-relative file
|
|
357
|
-
paths or supported external locators (see [schema.md](schema.md)) for the
|
|
358
|
-
concrete materials the prose governs. Name each file; glob patterns are not
|
|
359
|
-
supported and fail validation, because in a live repo a glob can capture
|
|
360
|
-
unintended files into pulls. Use a bare locator when it explains itself. Use
|
|
361
|
-
`{ locator, note }` when an opaque locator needs a short retrieval cue. The
|
|
362
|
-
external locator tells the host how to connect;
|
|
363
|
-
ghost does not fetch or authenticate. Put brand-owned materials that should
|
|
364
|
-
survive export or refactors under `materials/`; point at living app code where
|
|
365
|
-
the implementation itself should stay in place. Optional review checks live
|
|
366
|
-
under `.ghost/checks/` (`ghost checks init`) and are feed-back only; they are
|
|
367
|
-
never gathered.
|
|
368
|
-
|
|
369
|
-
### 3. Shape the glossary
|
|
370
|
-
|
|
371
|
-
Declare the kinds you will use in `glossary.md` — the frontmatter `kinds` list
|
|
372
|
-
plus a `#` section per kind explaining its meaning and normative weight. Kinds
|
|
373
|
-
are your choice; ghost ships no fixed vocabulary. A node's filename prefix must
|
|
374
|
-
match a declared kind (or the node has no kind).
|
|
375
|
-
|
|
376
|
-
The glossary is a dictionary of every term with defined meaning in the corpus.
|
|
377
|
-
A root `voice.md` with a `voice` glossary entry declares the scope for future
|
|
378
|
-
`voice.<slug>.md` nodes; declaring a kind with zero or one users is good
|
|
379
|
-
hygiene, not over-structure.
|
|
380
|
-
|
|
381
|
-
### 4. Orient
|
|
382
|
-
|
|
383
|
-
Elicit the brand from the human, not from a codebase. Interview for stance,
|
|
384
|
-
audience, anti-goals, and exemplars; ask for the material they can show —
|
|
385
|
-
screenshots, links, exemplar products, brand docs, copy they love or hate. Treat
|
|
386
|
-
every artifact as evidence to curate, never guidance to copy verbatim. When
|
|
387
|
-
supplied artifacts are the starting point or must be reconciled with existing
|
|
388
|
-
guidance, follow [distill.md](distill.md). Repo-bound reality can be recorded as
|
|
389
|
-
`materials` on the node whose prose explains its purpose.
|
|
390
|
-
|
|
391
|
-
### 5. Write sparse nodes
|
|
392
|
-
|
|
393
|
-
Add the smallest useful set of nodes, each carrying purpose-coherent prose guidance
|
|
394
|
-
answering why, with what, or how it is assembled, named `<kind>.<slug>.md` or a
|
|
395
|
-
bare slug. Draft only what the
|
|
396
|
-
human said or showed. State conditions as situations in the prose. Prefer a small amount of focused, well-grounded guidance over a noisy catalog. Hold each draft to the node prose
|
|
397
|
-
stances and score it before curation; a node below the gate returns to the
|
|
398
|
-
interview. Ask the human to keep, soften,
|
|
399
|
-
reject, or re-title important claims before treating draft nodes as durable.
|
|
400
|
-
|
|
401
|
-
### 6. Validate
|
|
402
|
-
|
|
403
|
-
```bash
|
|
404
|
-
ghost validate .ghost
|
|
405
|
-
```
|
|
406
|
-
|
|
407
|
-
`validate` checks artifact shape, per-node validity, glossary kind prefixes,
|
|
408
|
-
material locators, check references, and Skeleton fence counts.
|
|
409
|
-
Undeclared kind prefixes and malformed Skeleton sections are warnings.
|
|
410
|
-
|
|
411
|
-
## Never
|
|
412
|
-
|
|
413
|
-
- Never describe any file outside `.ghost/` as canonical package input.
|
|
414
|
-
- Never derive brand guidance from repo code alone; what a codebase repeats may
|
|
415
|
-
be legacy, not stance. Use repo paths as `materials` only when the prose guidance
|
|
416
|
-
has been curated.
|
|
417
|
-
- Never draft a node the human neither said nor showed.
|
|
418
|
-
- Never invent a hierarchy, inheritance, or cross-node edges — the package is
|
|
419
|
-
flat.
|
|
420
|
-
- Never file a node by destination; state its condition in the prose.
|
|
421
|
-
- Never ship a blacklist-only anti-goal; state the replacement and enforce the
|
|
422
|
-
hard line in review.
|
|
@@ -1,95 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: concrete-tiers
|
|
3
|
-
description: Decide which concrete code tiers a ghost package carries — tokens, skeletons, components, exemplars — and justify every absence.
|
|
4
|
-
handoffs:
|
|
5
|
-
- label: Audit what the package carries today
|
|
6
|
-
command: ghost gather
|
|
7
|
-
prompt: Which nodes carry concrete material, and which of the four tiers does the package cover?
|
|
8
|
-
---
|
|
9
|
-
|
|
10
|
-
# Recipe: Choose The Concrete Code Tiers
|
|
11
|
-
|
|
12
|
-
**Goal:** decide, deliberately, which tiers of concrete code material a
|
|
13
|
-
package carries — and be able to say why any tier is absent. Absence
|
|
14
|
-
should be a decision, not a default.
|
|
15
|
-
|
|
16
|
-
Prose states guidance; concrete code makes it the cheapest continuation. A
|
|
17
|
-
package can carry code at four tiers, and each does a different job during
|
|
18
|
-
generation:
|
|
19
|
-
|
|
20
|
-
| Tier | Form | What it buys |
|
|
21
|
-
| --- | --- | --- |
|
|
22
|
-
| Tokens | `materials/tokens.css`, linked from nodes | Named values — the agent stops inventing colors, sizes, and durations. |
|
|
23
|
-
| Skeletons | `## Skeleton` HTML blocks inside pattern nodes | The opening structure — layout is committed before the generic default can win the first tokens. |
|
|
24
|
-
| Components | primitive classes or a class vocabulary in `materials/` | Reusable styling decisions — padding, variants, and states compress into names. |
|
|
25
|
-
| Exemplars | a complete surface with load-bearing moves annotated | Cross-node interactions — the constraints no single node states, demonstrated working together. |
|
|
26
|
-
|
|
27
|
-
Two properties decide whether a tier steers, and they are not the same thing:
|
|
28
|
-
|
|
29
|
-
- **Scope** — what the tier constrains: a token constrains one value, a
|
|
30
|
-
skeleton one block, an exemplar one whole surface.
|
|
31
|
-
- **Delivery** — whether the material is guaranteed to reach the agent.
|
|
32
|
-
Skeleton blocks live in node bodies, so `ghost pull` delivers them with the
|
|
33
|
-
guidance. Files behind `materials:` locators reach only agents that spend a
|
|
34
|
-
turn reading them. A tier the agent never sees contributes nothing;
|
|
35
|
-
presence in the package is not presence in context.
|
|
36
|
-
|
|
37
|
-
## The floor and the earned tiers
|
|
38
|
-
|
|
39
|
-
**Tokens are the floor.** Every package that steers visual output carries a
|
|
40
|
-
token vocabulary, and every other tier repeats those token names. That
|
|
41
|
-
repetition is the one redundancy worth keeping: the same name appearing in
|
|
42
|
-
prose, skeleton, and exemplar is what stops the agent from inventing
|
|
43
|
-
plausible near-miss values.
|
|
44
|
-
|
|
45
|
-
The other three tiers are earned by the package's shape:
|
|
46
|
-
|
|
47
|
-
- **Skeletons** pay when the package specifies few, composition-critical
|
|
48
|
-
surfaces — where the first structural commitment decides everything
|
|
49
|
-
downstream — and when consuming agents may read only pulled bodies.
|
|
50
|
-
- **Components** pay when the package covers many diverse surfaces generated
|
|
51
|
-
often, and the consuming agent reads material files. A class vocabulary
|
|
52
|
-
amortizes across surfaces; for a single surface shape it is dead weight.
|
|
53
|
-
- **Exemplars** pay almost everywhere: they are the cheapest way to show
|
|
54
|
-
tiers interacting. One per distinct surface shape; a package with one
|
|
55
|
-
exemplar and many surface shapes pulls every task toward the demonstrated
|
|
56
|
-
shape.
|
|
57
|
-
|
|
58
|
-
## Every tier is a copy that can drift
|
|
59
|
-
|
|
60
|
-
Each tier repeats the token decision, and a stale copy steers harder than the
|
|
61
|
-
prose that corrects it. A hardcoded value in an exemplar where a token
|
|
62
|
-
exists is a lie waiting for a rename. Before adding a tier, accept its
|
|
63
|
-
maintenance bill; after any token change, sweep every tier for stranded
|
|
64
|
-
literals.
|
|
65
|
-
|
|
66
|
-
A tier can also fight the package's stance. A package whose guidance is
|
|
67
|
-
"compose each surface fresh from the tokens" contradicts itself by shipping
|
|
68
|
-
a component kit; a package whose guidance is "compose from the grammar, the
|
|
69
|
-
refs are examples not a framework" hardens toward template convergence if
|
|
70
|
-
every pattern carries a mandatory skeleton. When a tier and the stance
|
|
71
|
-
conflict, the stance wins — that absence is the package expressing itself.
|
|
72
|
-
|
|
73
|
-
## Annotate whatever code ships
|
|
74
|
-
|
|
75
|
-
Un-annotated code teaches content along with structure. Whatever tier the
|
|
76
|
-
package carries, split the annotation two ways: name the load-bearing moves
|
|
77
|
-
(what makes it this brand — copy these) and mark the incidental content
|
|
78
|
-
(domain, figures, labels — swap these). An exemplar without this split
|
|
79
|
-
teaches the agent that the example's subject matter is the brand.
|
|
80
|
-
|
|
81
|
-
## The self-check
|
|
82
|
-
|
|
83
|
-
For any package, answer four questions:
|
|
84
|
-
|
|
85
|
-
1. Where does the value vocabulary live? (If not a token file: why?)
|
|
86
|
-
2. What forces the opening structure of the package's most
|
|
87
|
-
composition-critical surface? (If nothing: is that surface's structure
|
|
88
|
-
genuinely open?)
|
|
89
|
-
3. What demonstrates the cross-node constraints working together? (If
|
|
90
|
-
nothing: which interactions is the agent left to infer?)
|
|
91
|
-
4. For every tier present: will the consuming agent actually have it in
|
|
92
|
-
context when it generates?
|
|
93
|
-
|
|
94
|
-
Any answer may legitimately be "absent, because" — the recipe's only
|
|
95
|
-
requirement is that the "because" exists.
|