a-green-hand-jack/feedback-synthesizer

Feedback Synthesizer

Convert unstructured inbound feedback into durable project memory. This skill answers: given what an advisor, collaborator, or reviewer said, what should change in claims, risks, experiments, writing, or decisions?

Use this skill when:

• an advisor meeting produced suggestions, concerns, or directions that need to become action items
• a collaborator sent comments on a draft, method, or results that need to be classified
• an informal reviewer or colleague shared pre-submission feedback
• committee meeting notes need to be turned into a structured decision record
• feedback is scattered across emails, documents, and notes and needs to be consolidated
• you want to update project memory after feedback without losing or misinterpreting the signal

Do not use this skill for formal review responses after a submission decision — use rebuttal-strategist. Do not use this skill to write the feedback update reply — use advisor-update-writer.

Pair this skill with:

• rebuttal-strategist for formal reviewer responses after an acceptance/rejection decision
• advisor-update-writer to write the follow-up update or reply after synthesis is done
• research-project-memory to propagate synthesized decisions to memory boards
• experiment-design-planner or result-diagnosis when feedback calls for new experiments or reinterpretation

Skill Directory Layout

<installed-skill-dir>/
├── SKILL.md
└── templates/
    └── feedback-record.md

Progressive Loading

• Read memory/claim-board.md, memory/risk-board.md, and memory/action-board.md before synthesizing — feedback must be checked against existing project state.
• Read paper/.agent/paper-evidence-board.md when feedback touches paper claims or results.
• Read templates/feedback-record.md before writing a feedback record.

Core Principles

• Not all feedback is equal: distinguish must-address from should-address from noted.
• Feedback that challenges a core claim requires a stronger response than feedback about presentation.
• Scope matters: advisor feedback about direction is different from collaborator feedback about a figure.
• Record the source and date of every synthesized feedback item.
• Avoid over-promising: only commit to experiments or rewrites that are in scope for the current phase.
• Incoherent or contradictory feedback should be flagged, not silently resolved.

Step 1 — Gather Feedback Source

Collect:

• the raw feedback: meeting notes, email text, document comments, or voice memo
• the source: advisor, collaborator, committee member, informal reviewer
• the date
• the context: draft reviewed, result presented, meeting type

Identify what artifact or claim the feedback is responding to.

Step 2 — Triage Feedback Items

For each distinct feedback point, classify:

| Field | Value | |---|---| | Feedback item | (quoted or paraphrased) | | Source | advisor / collaborator / informal-reviewer / committee | | Target | claim / experiment / writing / method / data / framing / scope | | Tone | concern / suggestion / direction / question / praise | | Priority | must-address / should-address / noted / disagree | | Affects submission | yes / no / unclear |

Priority rules:

• must-address: core claim is challenged, fatal weakness identified, or advisor/supervisor explicitly directed a change
• should-address: valid concern that weakens the paper or wastes compute if ignored
• noted: stylistic preference, minor suggestion, or nice-to-have
• disagree: feedback that conflicts with existing evidence, is based on a misunderstanding, or the team has deliberated and decided not to follow

Step 3 — Link to Project Memory

For each must-address or should-address item:

• Claim impact: Does this feedback challenge or support an existing claim in memory/claim-board.md? Update claim strength, wording, or evidence requirements.
• Risk: Does this create or heighten a risk? Add or update memory/risk-board.md.
• Action: Does this require an experiment, rewrite, data collection, or analysis? Add to memory/action-board.md with priority.
• Decision: Does this change a design or scope decision? Add to memory/decision-log.md.
• Evidence: Does this identify a missing evidence slot? Add to memory/evidence-board.md with status missing or planned.

For disagree items: record the disagreement and the rationale for not acting. This protects the project if the same concern reappears.

Step 4 — Write the Feedback Record

Use templates/feedback-record.md.

Save to:

memory/feedback/<YYYY-MM-DD>-<source>-<topic>.md

The record should include:

• meeting / feedback context
• triage table with all items classified
• memory updates made
• open decisions or experiments triggered
• disagreements logged with rationale
• follow-up actions and owner

Step 5 — Route Follow-Ups

• advisor-update-writer: draft the reply or follow-up update after synthesis
• experiment-design-planner: plan experiments triggered by must-address feedback
• result-diagnosis: reinterpret existing results in light of new concerns
• paper-evidence-board: update claim/evidence alignment when feedback changes what the paper needs to prove
• paper-writing-assistant: revise specific sections flagged by feedback
• rebuttal-strategist: if formal reviews arrive with an acceptance/rejection decision

Final Sanity Check

Before finishing:

• every must-address item has an action, risk entry, or decision
• every claim-level challenge has been checked against existing evidence
• disagreements are documented with rationale, not silently dropped
• feedback record is saved in memory/feedback/ with date and source
• next action is clear