Linwheel Source Optimizer

• "Optimize this for LinWheel"
• "Write this as a LinkedIn source note"
• "Prepare this buildlog for LinkedIn"
• "Turn today's work into a vault note for LinWheel"
• "Source-optimize this"

Vault Output Path

/Users/peleke/Library/Mobile Documents/iCloud~md~obsidian/Documents/ClawTheCurious/Buildlog/

Filename: YYYY-MM-DD-{slug}.md (e.g., 2026-02-27-github-watcher-shipped.md)

The Anatomy of High-Quality LinWheel Input

What Reshape Needs

Each of the 7 angles looks for different raw material in the source text:

The Source Note Structure

A good source note contains 3-5 beats (discrete story units). Each beat is 2-4 sentences that capture one moment, decision, or insight. Reshape picks different beats for different angles.

BAD source note (generic, no beats):

Today I worked on the GitHub Watcher responder. It scans repos and generates LinkedIn content.
I also fixed some bugs. The tests pass now. Overall productive day.

GOOD source note (beat-rich, angle-ready):

The GitHub Watcher shipped today — 14 files, 1500 lines, 33 tests.

It runs on a cron, scans every Peleke/* repo for the day's PRs and buildlog entries,
then synthesizes a narrative via LLM. The output is a ::linkedin-tagged Obsidian note.
The existing pipeline carries it the rest of the way: ObsidianWatcher detects the file,
LinWheel reshapes it into 21 drafts, Telegram pings me to review.

The hardest part wasn't the code — it was the overlay mount. Writing to the upper dir
directly bypasses inotify on the merged mount. Chokidar never sees the file. I burned
2 hours before realizing the write path matters more than the write content.

Every dependency is injectable: GitHub client, file writer, clock, LLM. The tests
mock everything. No network calls in CI. This is the pattern I wish every framework
taught instead of "just mock the module."

Here's the thing nobody talks about: most "content creation tools" require you to
stop working and start creating content. What if the content was a side effect of
the work itself? That's what this pipeline does. Ship code → content appears.

Count the beats:

1. Shipping stats (field_note material)
2. Architecture walkthrough (demystification material)
3. The overlay debugging story (identity_validation material)
4. The testing philosophy (contrarian material)
5. The "content as side effect" insight (provocateur/synthesizer material)

Reshape can pull from any of these to generate posts for different angles.

Source Note Template

---
linkedin_angles:
  - field_note
  - contrarian
  - demystification
---

::linkedin

# {Title — Descriptive, Not Clickbait}

{Beat 1: The headline fact. What shipped, what changed, what happened.
Include numbers: PRs merged, lines written, tests passing, hours spent.}

{Beat 2: The "how" — architecture, approach, or process. One specific
technical decision explained simply enough for a senior non-specialist.}

{Beat 3: The struggle or surprise. Something that went wrong, took longer
than expected, or challenged an assumption. Be specific about the failure.}

{Beat 4: The insight or lesson. What you'd tell someone starting this
from scratch. Frame as "the thing nobody tells you" or "what I wish I knew."}

{Beat 5 (optional): The bigger picture. Connect this work to a trend,
a contrarian position, or an open question in the industry.}

Frontmatter: Angle Hints

The linkedin_angles frontmatter tells the LinWheel publisher which angles to use instead of the defaults (field_note, demystification, contrarian).

Choose angles based on the strongest beats:

• Lots of concrete "I did this" material → field_note
• A clear "conventional wisdom is wrong" thread → contrarian
• A complex topic explained simply → demystification
• A relatable struggle → identity_validation
• A deliberately provocative take → provocateur
• Cross-domain connections → synthesizer
• Genuine open questions → curious_cat

Pick 2-4 angles maximum. More angles = thinner material per angle.

Prose Constraints

These rules produce source material that reshape handles well:

1. Specifics over abstractions. "3 PRs across 2 repos" not "made good progress."
2. Active voice. "I shipped" not "the feature was shipped."
3. First person. This is going to LinkedIn. Write as the author.
4. One idea per sentence. Reshape needs to pick apart your beats.
5. No LinkedIn formatting. No short lines, no whitespace hacks, no emojis. Reshape handles all formatting. Write natural prose.
6. No hashtags or CTAs. Reshape adds these if appropriate.
7. Include the failure. The best LinkedIn posts have a struggle. If everything went perfectly, it's boring. Find the tension.
8. Name the tools/technologies. "TypeScript" not "a language." "Obsidian" not "a note-taking app." Technical credibility matters.
9. Under 1500 words. LinWheel's reshape works best with 300-800 word source notes. Over 1500 words, use split instead of reshape.
10. End with an open thread. A question, a "what's next," or an unresolved tension. This gives reshape material for hooks and closers.

Workflow: Raw Input → Optimized Source Note

From a buildlog entry or GH Watcher synthesis:

1. READ the raw input (buildlog entry, GH synthesis, session notes)
2. IDENTIFY the 3-5 strongest beats:
   - What's the most concrete thing that happened?
   - What was surprising or counterintuitive?
   - What would a technical peer find interesting?
   - What's the relatable human moment?
   - What's the bigger industry connection?
3. SELECT 2-4 angles that match the beats
4. WRITE the source note following the template
5. ADD frontmatter with linkedin_angles
6. WRITE to vault: {vaultPath}/Buildlog/YYYY-MM-DD-{slug}.md

From a conversation or brainstorm session:

1. EXTRACT the key claims, decisions, or insights from the session
2. PICK the single strongest thread (don't try to cover everything)
3. FIND the tension: what was the debate? what was counterintuitive?
4. WRITE 3-4 beats around that single thread
5. ADD frontmatter, write to vault

From raw code or PR descriptions:

1. READ the PR title, description, and diff summary
2. TRANSLATE technical changes into impact: "what does this enable?"
3. FIND the story: why was this built? what problem existed before?
4. INCLUDE one specific technical detail that demonstrates craft
5. WRITE 3-4 beats, add frontmatter, write to vault

Anti-Patterns (What Makes Bad Source Notes)

Quality Check

Before writing the note to the vault, verify:

• Has ::linkedin marker (line 1 after frontmatter, or line 2 if H1 on line 1)
• Has linkedin_angles in frontmatter with 2-4 angles
• Contains 3-5 distinct beats
• Each beat has at least one specific detail (number, name, tool, outcome)
• At least one beat contains tension, surprise, or failure
• Written in first person, active voice
• Under 1500 words (ideally 300-800)
• No LinkedIn formatting (no short-line tricks, no emojis)
• Ends with an open thread (question, "what's next", unresolved tension)
• Filename follows YYYY-MM-DD-{slug}.md convention

Example: Optimizing a GH Watcher Output

Raw GH Watcher synthesis (input):

Today's GitHub activity focused on the OpenClaw sandbox project. PR #100 was merged,
adding the GitHub Watcher responder to the cadence pipeline. This responder scans all
Peleke/* repos nightly, collects merged PRs, open PRs, and buildlog entries, then
synthesizes them via LLM into a narrative engineering log. The output is tagged with
::linkedin and written to the Obsidian vault, where the existing pipeline processes it.

Optimized source note (output):

---
linkedin_angles:
  - field_note
  - contrarian
  - synthesizer
---

::linkedin

# The Code That Writes Its Own LinkedIn Posts

PR #100 shipped today: a GitHub Watcher that scans every repo I own, collects the day's
PRs and buildlog entries, and synthesizes them into a LinkedIn-ready note via Opus. 14
files, 1500 lines, 33 tests. Merged on the first review.

The architecture is boring on purpose. A cron fires at 9 PM. The watcher subscribes to
that signal, scans repos sequentially (rate limits), and writes one markdown file to the
Obsidian vault. The existing pipeline — ObsidianWatcher, LinWheel publisher, Telegram
notifier — carries it from there. No new infrastructure. No new dashboards. Just one
more subscriber on the signal bus.

The part that almost broke me: overlay mounts. I wrote to the upper directory and
Chokidar never saw the file. Turns out overlayfs inotify only fires on the merged mount.
Two hours of "why isn't this working" before I realized the write PATH matters more than
the write CONTENT.

Every dependency is injectable — GitHub client, filesystem, clock, LLM provider. The
test suite mocks all of them. Zero network calls in CI. I've written enough untestable
code in my career to know: if you can't test the happy path without a network connection,
the architecture is wrong.

Here's what I keep coming back to: most content tools ask you to stop working and start
creating content. But what if content was a side effect of the work itself? I ship code.
The pipeline notices. Drafts appear in my queue. I approve the good ones over coffee.
That's it. What other workflows could work this way?

Notice: same facts, completely different source quality. The optimized version has 5 clear beats, tension (the overlay debugging), a contrarian position (injectable deps), and an open question at the end. Reshape will produce dramatically better posts from this input.