ai-feedback-coder

name

ai-feedback-coder

description

Process app feedback marked as 'ai_code' status. Shows a shortlist of the queued feedback items (up to 4) and lets the user pick which one to take, loads all fields and comments as context, and treats admin guidance (admin_notes + internal comments) as authoritative fix directives that steer and can override the raw user request. Checks the item is clear enough to act on (asks for clarification instead of coding a vague request, unless the admin already specified the fix), presents an implementation plan for approval, then routes to the right implementation skill (systematic-debugging, frontend-design, admin-panel-builder, etc.) based on the feedback type. Use when asked to "process ai feedback", "code feedback", "ai-koodaa palaute", or any variation of implementing feedback marked for AI coding.

AI Feedback Coder

Automates coding feedback items marked as ai_code in public.app_feedback.

Workflow

1. Query the candidate shortlist

Use mcp__plugin_supabase_supabase__execute_sql with project ID iryqgmjauybluwnqhxbg. Fetch a short list (not one row) plus the total count, so the user can choose which item to take — not just the front of the queue:

SELECT id, feedback_type, system_id, subject,
       left(message, 140) AS preview, satisfaction_rating, created_at
FROM public.app_feedback
WHERE status = 'ai_code'
ORDER BY created_at ASC
LIMIT 4;

SELECT count(*) FROM public.app_feedback WHERE status = 'ai_code';

ORDER BY created_at ASC = oldest first (front of the FIFO queue). The oldest is the default pick, but the user may take any of the shown items.

2. If none found

Report "Ei ai_code-palautteita jonossa" and stop.

3. Let the user pick which feedback to take

MANDATORY — never silently grab the first row. Present the shortlist with AskUserQuestion (single-select) and use the preview field so the user can compare the candidates side by side:

• One option per feedback (up to 4). Label = [feedback_type] + subject (or message) truncated to ~40 chars. Preview = a monospace block with feedback_type, system_id, created_at (date), satisfaction_rating (as ★ if present), and the message/preview text.
• The oldest (front of queue) must be the first option so Enter takes it.
• Add a final "Lopeta" option.

Handle the response:

• A feedback option → that row becomes the active feedback; continue to step 4.
• "Lopeta" → stop.

Even if only one candidate exists, still show it (single option + "Lopeta") so the user confirms the target before any work begins.

4. Fetch the full record + comments

The shortlist query returned only summary columns. Re-select every field for the chosen id, and load the comments (they often carry the real detail):

SELECT * FROM public.app_feedback WHERE id = '<id>';

SELECT * FROM public.feedback_comments
WHERE feedback_id = '<id>'
ORDER BY created_at ASC;

admin_notes (field on app_feedback) and any comment with is_internal = true are admin directives — the admin's own instructions on how to fix the item. Treat them as authoritative (see step 5's "Admin directives" block). Regular non-internal comments are usually from the reporter; internal ones are admin.

5. Build context block

Assemble all feedback fields into a structured context:

• id, system_id, feedback_type, subject, message
• satisfaction_rating, email, allow_contact
• status, admin_notes, promoted_idea_id
• page_url, user_agent, browser_history
• kipina_id, created_at
• All comments (message, is_internal, created_at)

The system_id field tells which app the feedback concerns — see src/lib/systems.ts for the app registry.

Admin directives (authoritative)

Extract a separate Admin-ohjeet group from these two sources and treat it as the admin steering the fix — the admin uses these fields to tell the AI how to implement, not just what the reporter said:

• admin_notes — the admin's implementation instructions. These are frequently concrete and directive (real examples: "Tee ilman taustaa. Ikonityyppinen.", "Vasen yläkulma. Kun kipinäkortti on pienennetty, näytä pieni ikoni…").
• Internal comments (is_internal = true) — admin-only notes, often a threaded refinement of the instruction.

Priority rule: admin directives outrank the raw user message. When they add detail, follow it. When they conflict with the reporter's literal request, follow the admin and flag the conflict in the plan (step 7). If there are no admin directives, proceed from the user message as before.

6. Clarity gate — is the feedback actionable?

MANDATORY before planning or routing. Do NOT start coding on a vague item. Judge whether the feedback is specific enough to implement correctly. Treat it as UNCLEAR when any of these hold:

• The request is generic ("ei toimi", "korjaa tämä", "huono") with no specifics.
• The target is ambiguous — you cannot tell which page/component/flow from the message + page_url + comments.
• The desired outcome has multiple reasonable interpretations.
• For a bug, reproduction cannot be inferred.

Admin directives resolve ambiguity. Judge clarity from the combined picture: user message + admin directives (step 5). If admin_notes or an internal comment already names the target and the intended fix, treat the item as CLEAR and follow the admin's instruction — even when the raw user message is vague. Only fall through to the UNCLEAR path when both the user message and the admin directives are insufficient.

If the feedback IS clear, continue to step 7.

If UNCLEAR → use AskUserQuestion to resolve it BEFORE any plan. Ask one crisp, targeted question (what exactly is broken, on which page, what is the expected result) — not a barrage. Offer:

• "Tarkenna" (Other / free text) → user supplies the missing detail → re-run this gate with the new information.
• "Ohita" → mark the feedback read (see step 9's UPDATE, status read) so a human can triage it, then return to the picker (step 1).
• "Koodaa silti" → the user accepts a best-effort interpretation; proceed, but state your assumptions explicitly in the plan (step 7) and in the audit comment (step 10).

Never guess silently and start editing files — asking one question is cheap; shipping the wrong fix is not.

7. Announce and present plan

Tell the user:

Palaute: [subject or message truncated to ~80 chars] Tyyppi: [feedback_type] | Sovellus: [system_id] | Jaljella: N kpl

Admin-ohje: [admin_notes / internal-kommentti sanatarkasti — TAI "ei admin-ohjetta"]

Suunnitelma:

1. [Konkreettinen askel 1 — esim. "Muokkaa ComponentX.tsx: lisaa null-tarkistus"]
2. [Konkreettinen askel 2]
3. ...

Tiedostot joihin koskee: file1.tsx, file2.ts

The Admin-ohje line is mandatory: quote the admin directive verbatim (or state there is none). The plan steps must implement what the admin directed — if the admin's instruction and the reporter's literal request differ, follow the admin and add a short note in the plan (e.g. "Admin ohjaa X:ään, ei käyttäjän pyytämään Y:hyn").

MANDATORY — always present this plan and wait for user confirmation using the AskUserQuestion tool before proceeding.

Use AskUserQuestion with these options:

• "Jatka" (description: "Toteuta suunnitelma sellaisenaan")
• "Anna lisäohjetta" (description: "Muokkaa suunnitelmaa ennen toteutusta")
• "Peruuta" (description: "Ohita tämä palaute, merkitse luetuksi")

Handle the response:

• Jatka → proceed to step 8 (route to implementation)
• Anna lisäohjetta → user types instructions via "Other" → adjust plan and re-present with AskUserQuestion again
• Peruuta → mark feedback as read instead of fixed and stop
• Other (free text) → treat as instructions, adjust plan and re-present

To build a good plan, use the Explore agent or Grep/Glob to find the relevant files before presenting. The plan should be concrete enough that the user can judge if the approach is correct.

8. Route to the right implementation skill

After user approves the plan, invoke the appropriate skill(s) directly based on what the feedback requires. Do NOT delegate to using-superpowers — route directly.

Routing table

Feedback concerns	Invoke skill	Context to pass
Bug / unexpected behavior	systematic-debugging	Error description, reproduction steps, page_url
UI / layout / component issue	frontend-design	Component name, expected vs actual behavior
Admin panel issue	admin-panel-builder	Admin page, tab, what's broken/missing
Database / RLS / migration needed	supabase-migration-writer	Table, operation, expected behavior
Edge Function issue	edge-function-generator	Function name, error, expected behavior
AI feature / prompt issue	ai-prompt-manager	Feature name, prompt, expected behavior
Idea Machina specific	idea-machina	Evolution stage, component, issue
Practice / gamification	practice-gamification	Practice type, scheduling, completion
New feature (general)	brainstorming first, then implementation skill	Full feedback context + plan
Type errors / Supabase types	supabase-typing-architect	File, type error, schema
i18n / translation	language-specialist	Missing key, language, component
Performance	performance-auditor	Slow query, component, metric

Multiple skills may apply. For example, a feature request may need brainstorming → supabase-migration-writer → frontend-design. Run them in sequence.

If the feedback doesn't clearly match any skill, use code-guru for general implementation guidance.

9. Update feedback status

MANDATORY — always run after implementation, even if implementation was partial:

UPDATE public.app_feedback SET status = 'fixed' WHERE id = '<id>';

10. Add admin comment documenting what was done

MANDATORY — write a concise Finnish summary of every change made (files modified, features added, bugs fixed). This is the audit trail.

feedback_comments.user_id is uuid and NOT NULL, so the author must be a real uuid. Use the oldest auth user (an admin) — do NOT cast to text or fall back to a text literal (the column is uuid; a text expression errors with 42804: column "user_id" is of type uuid but expression is of type text). The feedback's own user_id is often NULL, so it is not a usable fallback.

INSERT INTO public.feedback_comments (feedback_id, user_id, message, is_internal)
VALUES (
  '<id>',
  (SELECT id FROM auth.users ORDER BY created_at ASC LIMIT 1),
  'AI-toteutettu: <1-3 lauseen yhteenveto tehdyistä muutoksista, esim. "Korjattu sidebar-komponentin renderöintiongelma. Muokattu sidebar.tsx: lisätty null-tarkistus props-arvoille.">',
  true
);

The comment message must include:

• What was changed (file names or component names)
• Why (link back to the feedback problem)
• If an admin directive steered the work, note it (e.g. "admin-ohjeen mukaan ikoni vasempaan yläkulmaan") — and, if the admin instruction overrode the reporter's literal request, say so
• Keep it under 300 characters

11. Report and continue

Report the final count, then use AskUserQuestion to offer continuing:

• "Seuraava" (description: "Hae ja käsittele seuraava ai_code-palaute") — this must be the first option so Enter accepts it
• "Lopeta" (description: "Lopeta palautekierros")

If user picks "Seuraava", go back to step 1. If "Lopeta", stop.

Data Models

app_feedback (public schema)

Field	Type	Notes
id	uuid	PK
user_id	uuid	nullable (often NULL — anon feedback)
system_id	text	e.g. 'raamattu-nyt', 'idea-machina'
feedback_type	text	'bug', 'feature', 'general', 'question'
subject	text	nullable
message	text	required
satisfaction_rating	int	1-5, nullable
email	text	nullable
allow_contact	boolean
status	text	'new', 'read', 'handled', 'fixed', 'ai_fix', 'ai_code', 'idea', 'idea_implemented'
admin_notes	text	nullable — admin directive: the admin's fix instructions (authoritative, see step 5)
promoted_idea_id	text	nullable, FK to feature_suggestions
kipina_id	text	nullable
page_url	text	nullable
user_agent	text	nullable
browser_history	jsonb	nullable
created_at	timestamptz

feedback_comments (public schema)

Field	Type	Notes
id	uuid	PK
feedback_id	uuid	FK to app_feedback.id
user_id	uuid	NOT NULL — use oldest auth.users id (see step 10)
message	text
is_internal	boolean	true = admin-only internal note → admin directive (see step 5). false = usually the reporter
created_at	timestamptz

Configuration

• Supabase project ID: iryqgmjauybluwnqhxbg
• Tool: mcp__plugin_supabase_supabase__execute_sql