README

Notes

Informal notes, meeting records, feedback, and ideas. Date-prefixed filenames for chronological sorting.

Categories

meetings/

Meeting notes, syncs, and call summaries. Include attendees, key decisions, and action items.

Naming: YYYY-MM-DD <topic>.md (e.g., 2026-05-15 Isaac sync.md)

feedback/

Feedback from users, stakeholders, the dev team, or external reviewers. Include the source and context.

Naming: YYYY-MM-DD <source> - <topic>.md (e.g., 2026-05-15 Isaac - deplatforming concerns.md)

ideas/

Feature ideas, architectural explorations, and “what if” notes. Not committed to — just captured for later evaluation.

Naming: <topic>.md (e.g., Shot timer BLE protocol.md) — no date prefix needed since ideas are timeless until acted on.

---

AI Agent Instructions

When a human asks you to create or file a note, follow these rules:

1. Categorize by intent:

   • Someone said something about the product/codebase → feedback/
   • A meeting or conversation happened → meetings/
   • A speculative idea or future exploration → ideas/
   • If unclear, ask the human which category fits.

2. Use the naming conventions above. Always date-prefix meetings and feedback. Never date-prefix ideas.

3. Meeting note template:

   # <Topic>
   **Date:** YYYY-MM-DD
   **Attendees:** names
    
   ## Summary
   Brief overview of what was discussed.
    
   ## Key Decisions
   - Decision 1
   - Decision 2
    
   ## Action Items
   - [ ] Action item (owner)

4. Feedback note template:

   # <Topic>
   **Date:** YYYY-MM-DD
   **Source:** who gave the feedback
   **Context:** how/why this came up
    
   ## Feedback
   What was said or observed.
    
   ## Response / Resolution
   What was decided or what action was taken. Link to relevant docs if a decision was made.

5. Idea note template:

   # <Topic>
    
   ## Idea
   What the idea is.
    
   ## Motivation
   Why this might be worth pursuing.
    
   ## Open Questions
   - Question 1
   - Question 2

6. Cross-reference docs. If a note leads to a decision or doc change, link to the relevant doc (e.g., “See Flutter Evaluation for the decision”). If a doc change was prompted by a note, link back to the note.

7. Don’t over-polish. Notes are informal. Capture the substance, not perfect prose.