@natjswenson/devlog 0.1.8 → 0.3.1

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/preview/demo.js CHANGED
@@ -25,31 +25,33 @@ function offsetDate(daysAgo) {
25
25
 
26
26
  const ENTRIES = [
27
27
  {
28
+ version: 'v0.4.0',
28
29
  date: offsetDate(0),
29
30
  title: 'You are looking at fake data',
30
- summary: "Hi. These aren't your entries. Your entries are 30 seconds away.",
31
- body: `## What I Built
31
+ summary: "Hi. These aren't your releases. Your releases are 30 seconds away.",
32
+ body: `## What Shipped
32
33
 
33
34
  Nothing. I'm a placeholder. A handsome one, but still a placeholder.
34
35
 
35
36
  You're seeing this screen because the preview app couldn't find env vars
36
37
  pointing at your dev-log repo. Once that's fixed, this entire feed gets
37
38
  replaced with real entries, generated by the \`/devlog\` skill from your
38
- actual git commits.
39
+ actual version releases — written in your voice.
39
40
 
40
41
  ## What's Next
41
42
 
42
43
  You. Setting things up. Probably while half-watching a YouTube tutorial
43
44
  about something unrelated. We believe in you.
44
45
 
45
- ## Public Commits
46
+ ## Commits
46
47
 
47
- - [demo] make placeholder more passive-aggressive ([abcd123](#))
48
- - [demo] add a tiny bit of charm ([def4567](#))
48
+ - make placeholder more passive-aggressive ([abcd123](#))
49
+ - add a tiny bit of charm ([def4567](#))
49
50
  `,
50
51
  },
51
52
  {
52
- date: offsetDate(1),
53
+ version: 'v0.3.0',
54
+ date: offsetDate(2),
53
55
  title: 'How to make this screen go away',
54
56
  summary: 'Two paths: the lazy one (recommended) and the manual one (also fine).',
55
57
  body: `## The lazy path
@@ -58,7 +60,7 @@ about something unrelated. We believe in you.
58
60
  npx @natjswenson/devlog init
59
61
  \`\`\`
60
62
 
61
- Answer four prompts. The CLI creates your dev-log repo on GitHub, installs
63
+ Answer a few prompts. The CLI creates your dev-log repo on GitHub, installs
62
64
  the Claude Code skill, and writes your config. Run \`npx @natjswenson/devlog preview\`
63
65
  again. This entry vanishes. You feel powerful.
64
66
 
@@ -75,18 +77,20 @@ VITE_DEVLOG_PROJECTS=[{"key":"myproject","label":"My Project"}]
75
77
 
76
78
  ## What's Next
77
79
 
78
- The real preview, with your real entries. Try it.
80
+ The real preview, with your real releases. Try it.
79
81
  `,
80
82
  },
81
83
  {
82
- date: offsetDate(3),
84
+ version: 'v0.2.0',
85
+ date: offsetDate(5),
83
86
  title: "Why you'd actually want this",
84
- summary: 'Build in public, but with style. And without remembering to write blog posts.',
85
- body: `## What I Built
87
+ summary: 'Build in public, by release — with style, and without remembering to write blog posts.',
88
+ body: `## What Shipped
86
89
 
87
- The whole point: you commit code as usual. You run \`/devlog\` in Claude Code.
88
- The skill reads today's commits and writes a *narrative* entry — not "fix typo,
89
- fix typo again, ok actually fix it" but real prose about what you built and why.
90
+ The whole point: you tag a release as usual. You run \`/devlog\` in Claude Code.
91
+ The skill finds tags that don't have an entry yet and writes a *narrative*
92
+ release note — not "fix typo, fix typo again, ok actually fix it" but real
93
+ prose about what shipped and why, in your voice.
90
94
 
91
95
  That entry gets pushed to your dev-log repo. Your site (or this preview app,
92
96
  deployed to Vercel/Netlify/Cloudflare) renders it.
@@ -95,29 +99,30 @@ The result: you ship in public without ever opening a blog post editor.
95
99
 
96
100
  ## What's Next
97
101
 
98
- You'll set this up. You'll ship something on day one. You'll feel slightly
102
+ You'll set this up. You'll tag a release on day one. You'll feel slightly
99
103
  smug about it on the train tomorrow. We're rooting for you.
100
104
 
101
- ## Public Commits
105
+ ## Commits
102
106
 
103
- - [demo] write hopeful pep talk ([eeee101](#))
107
+ - write hopeful pep talk ([eeee101](#))
104
108
  `,
105
109
  },
106
110
  {
107
- date: offsetDate(7),
111
+ version: 'v0.1.0',
112
+ date: offsetDate(9),
108
113
  title: "Things this is not",
109
114
  summary: 'A short list, for the avoidance of disappointment.',
110
115
  body: `## Not features
111
116
 
112
117
  - A blog CMS. There are sixty of those. Use one if you want one.
113
118
  - A social network. Please don't.
114
- - An AI ghostwriter for marketing copy. The narratives come from *your*
115
- commits. Garbage in, garbage out.
119
+ - A marketing-copy generator. The narratives come from *your* releases, in
120
+ *your* voice. Garbage in, garbage out.
116
121
  - A way to make your past coding choices look better in retrospect. Sorry.
117
122
 
118
123
  ## Is features
119
124
 
120
- - A way to ship dev log entries without context-switching out of Claude Code.
125
+ - A way to ship release notes without context-switching out of Claude Code.
121
126
  - A static, no-backend pipeline (manifest.json + markdown on GitHub).
122
127
  - Components you can drop into your own React site, or the preview app you
123
128
  can deploy as a standalone dev log.
@@ -132,9 +137,10 @@ Replace this fake entry with a real one. It's right there. Just go.
132
137
  const MANIFEST = {
133
138
  entries: ENTRIES.map((e) => ({
134
139
  date: e.date,
135
- file: `${e.date}.md`,
140
+ file: `${e.version}.md`,
136
141
  title: e.title,
137
142
  summary: e.summary,
143
+ version: e.version,
138
144
  })),
139
145
  };
140
146
 
@@ -143,6 +149,7 @@ function entryMarkdown(entry) {
143
149
  title: "${entry.title.replace(/"/g, '\\"')}"
144
150
  date: ${entry.date}
145
151
  project: ${DEMO_PROJECT_KEY}
152
+ version: ${entry.version}
146
153
  summary: "${entry.summary.replace(/"/g, '\\"')}"
147
154
  ---
148
155
 
@@ -156,9 +163,9 @@ function demoResponse(url) {
156
163
  headers: { 'content-type': 'application/json' },
157
164
  });
158
165
  }
159
- const m = url.match(/(\d{4}-\d{2}-\d{2})\.md$/);
166
+ const m = url.match(/\/([a-zA-Z0-9._-]+)\.md$/);
160
167
  if (m) {
161
- const entry = ENTRIES.find((e) => e.date === m[1]);
168
+ const entry = ENTRIES.find((e) => e.version === m[1]);
162
169
  if (entry) {
163
170
  return new Response(entryMarkdown(entry), {
164
171
  status: 200,
@@ -0,0 +1,16 @@
1
+ # Voice notes — recent corrections
2
+
3
+ This file overrides `voice-profile.md` wherever they conflict. Put your most recent,
4
+ explicit corrections here — the things you keep having to fix in generated entries. Keep
5
+ it short and specific; it is read every time an entry is generated.
6
+
7
+ ## Defaults (safe to keep)
8
+ - Write for the reader, not as a diary. Lead with the change and its impact, not "I".
9
+ - No em dashes; use a comma or semicolon.
10
+ - No tacked-on punchy filler lines and no rhetorical fragment lists for rhythm.
11
+ - Never invent metrics, motivations, or outcomes the commits don't support.
12
+ - A release entry is a release note, not a changelog dump — group commits into the
13
+ handful of changes that actually matter and explain why.
14
+
15
+ ## Your corrections
16
+ (Append your own as they come up.)
@@ -0,0 +1,37 @@
1
+ # Voice profile — (your name)
2
+
3
+ This is the fallback voice profile devlog uses when no other profile is found. It is
4
+ generic. Replace it with your own — or, better, point `voicePath` in `config.json` at a
5
+ richer profile you already maintain (e.g. ghostwriter's `voice/`). **`voice-notes.md` in
6
+ the same directory overrides this file wherever they conflict.**
7
+
8
+ devlog reads only `voice-profile.md` and `voice-notes.md`. It never reads `algorithm.md`
9
+ (LinkedIn reach tuning) — a dev log is not a LinkedIn feed, so reach rules do not apply.
10
+
11
+ ## Voice & tone
12
+ Warm, practical, honest. A builder writing release notes for people who follow along — no
13
+ hype, no doom, no marketing gloss. Explain what shipped and why it matters in plain terms.
14
+
15
+ ## Sentence rhythm & structure
16
+ - Short sentences, generous white space, one idea per line or per tiny paragraph.
17
+ - Lead with the change, then the reason. Build to a crisp takeaway.
18
+ - A short bullet list is fine to enumerate "what changed."
19
+
20
+ ## Openers (how to start a release entry)
21
+ - A sharp statement of what shipped: "v0.3.0 makes the log release-driven."
22
+ - A short framing of the problem the release solves.
23
+
24
+ ## Closers
25
+ - A reframe or a genuine forward-looking line about what's next. Not a forced question.
26
+
27
+ ## Vocabulary & tics
28
+ - Plain, modern, conversational; contractions; no corporate jargon or buzzwords.
29
+ - Name real things: features, files, versions. Specifics over abstractions.
30
+
31
+ ## Emoji & hashtags
32
+ - Emoji: sparing or none. Hashtags: none.
33
+
34
+ ## Never do
35
+ - No hype words ("game-changer", "revolutionary"), no doom, no cynicism.
36
+ - No corporate jargon, no fake humility, no fabricated metrics or motivations.
37
+ - Don't pad. If a line isn't carrying weight, cut it.