submit-feedback

name	submit-feedback
description	Read a UI feedback markdown file exported by designer-notes and apply targeted code revisions

Submit Feedback

Read structured UI feedback exported by designer-notes.js and make targeted revisions to the source code.

Steps

1. Locate the feedback file. If a path argument is provided, use it. Otherwise:

   • Search the current working directory for feedback-*.md files
   • Search ~/Downloads/ for feedback-*.md files, sorted by most recent
   • If multiple found, list them and ask which to use

2. Read and parse the feedback file. The file is grouped by page. Extract from each ### Comment N block:

   • CSS selector (from the **Element:** line — content inside backticks)
   • Tag name and text preview (from the **Tag:** line)
   • Position data (from the **Position:** line)
   • Comment text (the blockquoted > lines)
   • Which page it belongs to (from the ## Page: header)

3. Identify the source files. Map each ## Page: section to the actual HTML file in the project.

4. For each comment, locate the code:

   • Use the CSS selector to understand which HTML element is targeted
   • Search the source file for that element using the tag name and text preview as confirmation
   • If the selector targets a styled element, also check CSS rules that apply to it

5. Present a summary table:

   #	Page	Element	Feedback	Proposed Action
   1	test.html	h1 "Welcome..."	Too generic	Revise heading text

6. Ask how to proceed. First check dn-config.json for preferences.autoApply. If true, skip this step and apply all comments automatically. Otherwise ask:

   • "Apply all" — work through each comment sequentially
   • "Let me pick" — the user selects which comments to address
   • "Just the plan" — show analysis only, no edits

7. Check for repeat comments. Before applying changes, read feedback-archive.md (if it exists) and check whether any current comments target the same CSS selector as a previously archived comment. If a match is found:

   • Flag it in the summary table with "REPEAT"
   • Note what was tried last time
   • Take a different approach this time

8. Apply changes for each comment:

   • Make the targeted edit (HTML, CSS, or both)
   • If ambiguous, infer intent from comment text, element context, and click location. Default to acting.
   • Model directives (#o3, #gpt-4o, #o4-mini): These indicate the user's preferred model for this comment. If Codex supports model switching mid-session (e.g., via /model command or multi-agent dispatch), apply it. Otherwise, note the preference but process with the current model. Strip directives from comment text.
   • Effort directives (#high-effort, #medium-effort, #low-effort): Adjust your reasoning depth accordingly. Strip from comment text.
   • Claude-specific directives to ignore: Comments may contain #opus, #sonnet, #haiku. Strip these — they are for Claude Code.
   • Inline hints: Comments may contain /keyword references (e.g., /arrange, /polish, /bolder). These are design intent hints — interpret them as direction for how to approach the edit. Strip the /keyword from comment text.

9. After all changes, present an action log:

   Action Log

   #	Comment	What Changed	File:Line
   1	"add a line break"	Added <br> before heading	test.html:482

10. Write changelog HTML. Update .designer-notes/changelog.html. Read ~/.agents/skills/designer-notes/changelog-template.html for the HTML shell. If it exists, replace <!-- SECTIONS --> with section elements. Prepend new sections before existing ones.

11. Archive feedback:

    curl -s -X POST http://localhost:3847/archive-feedback
    

12. Let the user know changes are live and the browser will reset automatically.

13. Check for updates. Run the update checker:

    node ~/.agents/skills/designer-notes/check-update.js
    

    If it produces JSON output, mention at the end of your message: designer-notes v{latest} is available (you have v{installed}). Run {command} to update. If no output, skip this — the user is up to date. Only run this check once per session — if you've already shown an update nudge in this conversation, skip it on subsequent runs.

Feedback File Format

(Same format as Claude Code — generated by designer-notes.js)

# UI Feedback
Generated: [timestamp]
Total comments: [N]
Viewport: [width]x[height]

---

## Page: [page-path]

### Comment 1
**Element:** `[CSS selector]`
**Tag:** [TAG] | **Text:** "[preview]"
**Position:** click at (x, y) on page; offset (x, y) within element
**Element bounds:** WxH at (x, y)

> [The actual feedback text]

Notes

• CSS selector is the primary locator
• Tag name and text preview serve as confirmation
• Viewport size indicates which breakpoint — apply fixes in appropriate @media query
• Empty comments mean "something is off with this element"