new-entry

name	new-entry
description	Use when Daniel wants to add a new journal entry to Project-Flow from dictated/voice notes. Shapes raw notes into a dated entry under entries/YYYY/MM/ and updates the README index.

new-entry

Convert Daniel's raw, freeform dictated notes into a polished journal entry. The job is light editorial conversion — from stream-of-thought into structured, digestible prose — without rewriting Daniel's voice or inventing material.

Inputs

• Raw notes (dictated, voice-typed, or pasted). Expect transcription artifacts — infer through them.
• Optional date override. Default to today (Israel time).

Steps

1. Determine the date (today unless Daniel specifies otherwise) and a short slug from the content.

2. Identify any projects, repos, tools, or external resources Daniel mentions — these become a References section at the bottom with links.

3. Create entries/YYYY/MM/YYYY-MM-DD-slug.md with this shape:

   # {Title}
   
   **Date:** DD/MM/YY
   
   *Note: this entry was lightly edited by an AI agent from its original dictated form.*
   
   {Lead paragraph — sets context. No heading above it.}
   
   ## {Subheading, only if needed to break up a long section}
   
   {Body — short paragraphs, bullet lists where appropriate.}
   
   ## References
   
   - [Project / Resource Name](URL)
   - ...
   

4. Add an entry to the index table in README.md under the ## Index heading. Insert at the top (newest first):

   | DD/MM/YY | [Title](entries/YYYY/MM/YYYY-MM-DD-slug.md) | One-line summary |
   

5. Show Daniel the drafted entry and the index row before committing. Only commit/push if he says so.

Style

This is the most important section — the conversion job hinges on getting tone right.

• Polish, don't rewrite. Convert freeform dictation into clean prose: tighten sentences, fix run-ons, remove filler ("essentially", "basically", "you know"), but keep Daniel's voice and phrasing where it works.
• Structure for digestibility. The reader should be able to skim and get the gist. Use:
  • A short lead paragraph (no heading) that sets the context.
  • ## subheadings only to break up genuinely long sections — don't over-segment. A short entry needs no subheadings at all.
  • Bullet lists to break up dense prose when Daniel is enumerating principles, choices, components, or examples. Prefer bullets over a wall of text.
• Always include the italicised AI-edit disclaimer immediately under the date line.
• Always include a ## References section at the bottom when Daniel mentions any project, repo, tool, or resource. Use github.com/danielrosehill/ for his own repos when the URL isn't given. If nothing was referenced, omit the section.
• Don't invent details. If notes are sparse, the entry is short. Don't pad.
• Date format: DD/MM/YY.
• No emoji unless Daniel uses them in the notes.
• Tongue-in-cheek "order out of chaos" framing is welcome — this is a journal, not a changelog.