Skip to main content

Notes And Timer Prompt Pack

Purpose​

Turn the audit in notes-and-timer-follow-through-audit.md into implementation-ready AI prompts.

These prompts are intended to be used in slices. They should still preserve the cross-feature moral of the audit.

Source Of Truth​

Before using any prompt below, treat these as the source of truth:

Prompt 1: Simplify Note Actions And Make Timer State Truthful​

Use this prompt when implementing the first high-value fix around Notes and Timer.

Use docs/app/development/notes-and-timer-follow-through-audit.md as the source of truth.

Implement the first Notes/Timer cleanup slice as a cross-feature fix, not a page-only tweak.

Goals:
1. Simplify the note action model so it is clearer whether a note is linked or not linked.
2. Remove or rename confusing note actions so the UI does not imply a link when none exists.
3. Make linked notes visibly distinct from suggested notes.
4. Make Save and stop on the timer route clear the timer surface into a truthful idle state.

Must preserve:
- quick-action dock stays separate from pinned work
- v1 pinned work remains in the topbar
- notes opened from the topbar should still be treated as shell-first behavior
- Continue timer is out of scope for this slice

Must inspect before editing:
- timer route
- active timer popover
- note linking UI
- suggestion wording wherever timer-note reuse appears
- sibling surfaces that show linked or suggested note state

Validation should prove:
- linked notes are visible
- suggested notes are clearly labeled as suggestions
- stopping a timer does not leave stale client/note context behind
- the user no longer has to guess what a note action actually does

Prompt 2: Standardize Create-Flow Handoff And Action Toast Behavior​

Use this prompt when addressing project creation and related post-create flows.

Use docs/app/development/notes-and-timer-follow-through-audit.md as the source of truth.

Implement a create-flow handoff cleanup pass.

Current leaning from the audit:
- stay in place after create
- show a clear Open action in the toast
- when a toast has an action, it should likely remain visible longer

Goals:
1. Apply the current leaning to the touched create flows.
2. Add an explicit Open action where the user would reasonably want to go straight into the created record.
3. Avoid dead-end success toasts for meaningful new records.

Important:
- do not silently assume that every record type should redirect
- if behavior differs by record type, make that difference explicit in code and UI

Must inspect before editing:
- project creation
- any nearby create dialogs using the same success-toast pattern
- create flows for related records where inconsistency would be obvious to the user

Validation should prove:
- newly created records have a clear next move
- action toasts are visible long enough to actually be used
- the touched flows no longer feel arbitrary compared with one another

Prompt 3: Make Notes Open Shell-First From The Topbar​

Use this prompt when implementing the topbar utility behavior more directly.

Use docs/app/development/notes-and-timer-follow-through-audit.md as the source of truth.

Implement a shell-first Notes opening model from the topbar.

Confirmed direction:
- when a note is opened from the topbar Notes popup, it should open back into that same topbar working layer first
- this should feel more like opening a tab or shell state than immediately routing to the full Notes page

Goals:
1. Let notes opened from the topbar stay in the topbar working layer first.
2. Keep the full Notes page available as the deeper workspace.
3. Preserve the distinction between shell utility behavior and full-page editing behavior.

Must preserve:
- topbar is allowed to act as both utility layer and tab-like area in v1
- horizontal scrolling in the topbar is acceptable
- quick-action dock remains unrelated to this behavior

Must inspect before editing:
- notes launcher
- quick note behavior
- topbar shell composition
- any working-note shell persistence already in place

Validation should prove:
- opening a note from the topbar no longer feels route-heavy
- the shell state remains understandable when more than one item is open
- the full Notes route still works as the deeper workspace

Prompt 4: Add V1 Pinned Work To The Topbar Without Breaking The Shell​

Use this prompt when implementing the first pinned-work slice.

Use docs/app/development/notes-and-timer-follow-through-audit.md as the source of truth.

Implement the v1 pinned-work model in the topbar.

Confirmed direction:
- pinned work stays in the topbar in v1
- the topbar may be horizontally scrollable
- quick-action dock stays separate

Goals:
1. Support pinned work in the topbar as current working state, not permanent favorites.
2. Keep the topbar usable when multiple items are pinned or open.
3. Make it easy for the user to unpin or close topbar work items.

Suggested first-slice item types:
- notes
- projects
- clients

Must preserve:
- utilities remain identifiable as utilities
- active timer remains identifiable as active timer
- pinned work should not turn the topbar into a second sidebar

Must inspect before editing:
- topbar composition
- notes launcher
- any existing working-note or shell-state persistence
- project/client surfaces that could supply pinned items
- try not to change the ui too much, the developer likes the genearl look. 

Validation should prove:
- pinned items are easy to reopen and easy to clear
- the topbar still reads as one shell bar
- the implementation behaves like current working memory, not archival favorites

Prompt 5: Cross-Feature Consistency Audit For The Same Pattern​

Use this prompt when you want the AI to avoid fixing only one visible symptom.

Use docs/app/development/notes-and-timer-follow-through-audit.md as the source of truth.

Before making changes, audit all sibling surfaces that share the same pattern being fixed.

Do not stop at the first page where the issue was noticed.

If fixing any of these patterns:
- create-flow handoff
- linked vs suggested state
- timer stop aftermath
- shell-first utility opening
- pinned-work rendering

then inspect the related sibling surfaces and either:
- fix them in the same pass
- or explicitly explain why they are intentionally out of scope

The goal is to prevent route-by-route drift and preserve one coherent product model.

Usage Note​

These prompts are meant to be combined carefully.

Do not ask one prompt to solve every open decision at once. Use the audit doc to confirm what is already decided first, then use the smallest prompt that matches the next implementation slice.