Build in public

Turn a day's raw work into a short, high-signal evening update that reads as impact and direction, not activity. It is NOT a demo and NOT a status report — its currency is progress + decisions + what got unblocked, which is exactly what foundation/groundwork days produce.

The reader is a PM / project owner, not a teammate dev. They do NOT know what a BOF-438 is, what a "walking skeleton" is, or which file a schema lives in. Write in features and business outcomes: name the feature ("Host submission form"), say what it unlocks for the product, and keep ticket IDs as trailing tags only — never as the subject of a sentence. If a bullet can't be understood by someone who has never opened the repo, it's written wrong. Jargon is the enemy, not length.

Match the pod's house style — this is how the user actually posts:

• Bullets are •, not -. Each is a complete, readable clause (not a telegraphic fragment): a full thought a PM can parse on its own. Don't compress a real sentence into noun-soup to save words.
• Trailing ticket tags, not inline PR links. Close a bullet with (BOF-518) or [BOF-438] — the work item, not a #1234 PR number (a bullet may carry several tags). The pod tracks tickets; a bare PR number means nothing to the reader. Surface a PR link only when the link is the point: the bullet is "ready for review", or a just-merged foundation whose merge unblocks the rest of a stack.
• First name only, no surname. The user signs 🛠️ Benjamin — DD/MM.
• 2-3 substantive bullets + a ⏭️ Next. Closer to 2 than 4. Cut anything that doesn't carry impact or position. The Next is adaptive (see below): a single • ⏭️ Next: … line when there's one continuation, or a ⏭️ Next header with ◦ sub-bullets when several distinct next items, a handoff, or a blocker need to surface.

Here are four real posts (use them as the target shape, not the abstract template):