Address FeedbackCAUTION

A framework for building agentic apps

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: address-feedback
description: >-
  Triage feedback from docs, issues, Slack threads, or pasted notes into
  verified bugs, UX proposals, unclear questions, and skipped noise. Use when a
  user asks you to address product feedback or investigate a reported workflow.
scope: dev
metadata:
  internal: true
---

# Address Feedback

Use this skill when the user shares a feedback document, issue, thread, or pasted notes and asks you to address the feedback.

The default posture is judgment plus action: fix clear, verified bugs and
handle concrete design/UX feedback about existing surfaces. In a Slack sweep,
new capability requests still need the invoking identity's `:upvote:`; praise,
status updates, merge/review requests, bot forwards, duplicates, and noise stay
out of scope. Do not exclude Design feedback just because it is visual or
subjective. Before leaving a report with another owner, confirm current thread
status or linked work; an eye alone is not active ownership. If a previous run
claimed an out-of-scope item, keep `👀` and record **Skipped** once in the
thread. Never remove reactions; newer thread evidence determines its status.

## Choose the fix altitude

Before coding, name the smallest invariant that explains the report and the
boundary that owns it. Use the evidence to choose the altitude:

- One isolated report -> fix the local seam and add a focused regression check.
- Repeated or cross-surface reports -> consider the shared primitive or
  contract, but only after confirming the reports share the same failure mode.
- Missing capability or wrong tool -> fix discovery, the registry, or the
  action contract rather than coaching the agent around the gap.
- Source behavior differs from the reported live behavior -> check the build,
  deploy, and version state before changing code.

Do not turn one data point into a global agent rule. For subjective feedback,
state the underlying invariant and wait for repeated evidence before broadening
it. Keep a concrete local fix when it solves the reported boundary; the goal is
the right abstraction, not the most general one.

## Prerequisites

- If no link or feedback text is provided, ask for it.
- Read the repo `AGENTS.md` before touching code.
- Use the relevant connector/plugin/skill for the source when available, instead of scraping authenticated pages.
- For Slack, use the connected identity contract in
  `address-feedback-with-replies`; verify the invoking user's profile and use
  that same identity for all reads, reactions, replies, and read-backs.
- Before starting work, search available task history and local Git/PR metadata for the exact feedback link or issue identifiers. Reuse existing work instead of creating a duplicate fix.

## Steps

1. Read the feedback source.

   | Source | Reader |
   | --- | --- |
   | Notion link | Notion connector or Notion skill |
   | Google Docs/Drive link | Google Drive connector or Google Docs skill |
   | Linear link | Linear connector if installed; otherwise ask for pasted content |
   | GitHub issue or PR | GitHub connector or `gh issue view` / `gh pr view` |
   | Slack thread | Slack connector with the invoking user's identity |
   | Public URL | Web browsing |
   | Pasted text | Read directly |

   Use web browsing only for public URLs. Auth-gated docs usually need their matching connector. For Slack threads, use the invoking user's connected Slack identity for the parent, replies, reactions, and Slack metadata; fetch linked external artifacts through their owning connector or public URL.

2. Check whether this defect has already been reported.

   A feedback channel holds months of reports and nobody remembers all of them,
   so the same defect gets filed by different people weeks apart and every
   filing reads as new. One recorded case: the same Clips recording bug was
   filed almost word-for-word 29 days apart by the same reporter, and neither
   message mentions the other. Another defect was reported fifteen times by
   nine people across three months, was announced as fixed once in the middle,
   and was reported again two weeks later.

   Search before fixing, going back at least three months: the source channel
   in the reporter's words and in your own, Sentry, first-party Agent-Native
   Analytics error issues, and merged PR titles. Search the feature name, the
   error text, and the surface separately - repeat reports rarely share
   vocabulary.

   - **No prior report** — proceed normally.
   - **Prior report, no fix landed** — say how long it has been open. The person
     forwarding it to you is likely seeing it for the second time too.
   - **Prior report, fix landed** — this is a regression, and the bar is now
     different. Patching it again and reporting done is exactly how it returns a
     third time. Find why the first fix stopped holding, and leave behind
     something that fails when it breaks again: a test that reproduces the
     user's path, or an assertion in the flow the report names.

   Report the repeat explicitly, with dates and reporters. A defect on its third
   report is not a bug ticket, it is a missing check — and the missing check is
   the deliverable, not the patch.

## Clarification gate

Before asking a reporter for clarification, read the complete parent thread,
every reply, and every accessible linked artifact. Build a short ledger of the
surface, URL, repro, exact error, screenshots or files, run or request IDs, and
answers already present. A detail found anywhere in that evidence is available
context - never ask the reporter to repeat it.

Look for resolution or ownership signals before classifying an item as missing
evidence. A substantive reply from the invoking Slack identity, a legacy
`@agent-native` message, or any participant that identifies the cause, supplies
the repro, links a fix, or says the issue is fixed, landed, or being fixed is
evidence, not a clarification gap. Verify the claim when needed and record the
item as alread

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

.agents/skills/an

.agents/skills/content-product-development

.agents/skills/design-exploration

.agents/skills/turn-into-app

.agents/skills/visual-edit

Gates applied: no_behavioural_pass.

[![ModelsAtlas audit: Address Feedback](https://modelsatlas.com/skills/builderio/address-feedback/badge.svg)](https://modelsatlas.com/skills/builderio/address-feedback/)

Not your listing, or something out of date? Claim or update your listing.