product-memory

The Product memory is the shortest of the three documents a Run reads. The Foundation doc says who the Product is, the Growth plan says what it is trying this quarter, the Loop's own instructions say how a channel must behave — the memory says only what past approvals and results taught, with the evidence that backs each line. Everything without evidence belongs in one of the other three; leave it out.

This Skill rewrites the whole block once a week from the material the runtime hands you in the task, and saves it with write_memory. It proposes nothing and publishes nothing.

Gather

1. read_context — the Foundation doc, the Growth plan and the Product memory as it stands. Read all three: a line that restates any of them is a line wasted.
2. The task message carries the evidence, already collected:
   • Daily notes — one line per Run since the last distillation, dated and tagged by Loop: what each Run did and saw.
   • Proposals the User edited before approving — the original the Run wrote next to the text the User approved. This is the strongest signal Kwern has: the difference between the two is what the User actually wants.
   • Proposals the User rejected — noisy on their own, informative when several rejects share a subject, a channel or a shape.
   • Proposals that were published, and the latest Connector snapshots — what the published work did afterwards, as far as the numbers reach.

Weigh

A line earns its place only if the evidence supports it:

• One explicit edit pattern, or three events. A single reject, a single post that did well, a single note — not enough. Say a thing when the User has changed the same aspect of several Proposals, or when at least three events point the same way.
• Correlation, not attribution. A published post's metrics have many causes and a small sample. Write those under ## Observed, with the count and the window, never as a rule.
• Nothing already written elsewhere. If the Foundation doc gives the voice, the Growth plan the bet, or the Loop's instructions the channel rule, that lesson is already applied — drop it.
• A lesson that holds on every channel is not a memory line. Say so in your closing message so the User can move it into the Foundation doc themselves; do not write it here.
• Lines expire. Drop a line older than 60 days that this week's evidence does not confirm again. That is what keeps the block under its cap without losing anything live.

Write

Call write_memory once, with the complete block. It replaces the previous one, so carry forward every line that still holds.

## Do
- Keep X posts under 200 characters — the User cut 6 of the 7 posts they approved (x, Aug 2026).
## Don't
- Don't propose r/startups threads — 4 of 4 rejected (reddit, Aug 2026).
## Observed
- Posts opening on a question got about twice the replies of statements (x, Aug 1–28, n=11).

Rules the block must respect:

• The three headings above, in that order, and nothing else. One dash line per lesson.
• Every line names the Loop it belongs to and the counts and dates that back it, in brackets at the end.
• Written to the Product's owner, in plain words: they read this block and correct it by hand.
• Lines marked (you) are the User's own. Keep them exactly as they are, in the section they are in. The runtime puts back any you drop, so rewriting or "improving" one only makes the block inconsistent.
• The block is trimmed to its character cap after you save it, by dropping the last machine-written lines. Stay under it yourself so the trimming never has to choose for you.

Finish with one line saying what changed: how many lines you added, kept and dropped, and any lesson you found that belongs in the Foundation doc instead.