关于 feedback
feedback 是一项技能,用于记录关于工具、技能或其他操作界面的具体可复现案例,供维护者处理。它会核对已安装版本、搜索目标图谱中的既有报告,并指导案例分类、关联和分派。
主要功能
- 01区分工具反馈与项目观察
- 02核对已安装技能版本
- 03写入前搜索相关案例
- 04按类型和证据组织案例
- 05将案例关联至图谱并分派
适用场景
- 01报告技能规则遗漏的情况
- 02记录工具描述与实际行为不符
- 03为既有报告补充证据
- 04向维护者提交可复现问题
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ iskron-ai/ skills --skill feedback安装后在 Claude Code 中输入/feedback确认已加载。
README 原文English
来自项目 READMEREADME 暂无中文译文,以下为英文原文;中文介绍见上方。
Feedback — опыт сессии, записанный там, где по нему можно действовать
Скилл, уведший не туда, описание тула, обещавшее то, чего поверхность не делает, верное правило, пропустившее случай, — ничто из этого не достигает держателя инструмента, если не записано: сессия кончается и уносит всё с собой.
Единица — случай, не мнение. «Скилл запутанный» — не повод действовать. «Правило говорит X, я сделал Y, и ничто меня не отклонило» — повод. Случай пригоден, как контрпример: конкретен и воспроизводим настолько, что с ним можно спорить.
Когда срабатывает
Сам, на нетривиальном опыте — не жди, пока попросят. Нетривиально значит: одно из этого действительно случилось с тобой:
- правило существует, ты его читал, и случай всё равно ускользнул;
- описание обещало поведение, которого у поверхности нет, — ты узнал это попыткой хода;
- починка сработала, и ты не можешь сказать, что она достала причину;
- у шага не было собственного знака, и ничто не сказало бы, что он пропущен;
- ты потянулся за инструментом, и он вернул пустоту там, где вещь существовала под другим именем.
И пользователь зовёт его напрямую — /feedback, своими словами. Предложи это, когда он говорит об инструментах что-то, что стоит сохранить и чему больше некуда лечь. Жалоба человека — уже случай; твоя работа — форма, проверка и размещение, никогда не суд о том, считается ли она.
Что его не запускает: сработавшее как задокументировано; трудность, которая была твоей, а не инструмента; предпочтение. Поле, полное «мне бы хотелось», — поле, которого никто не читает.
Об инструменте или о своём предмете — различи прежде всего. Фидбэк — только об инструменте: скилл, тул, поверхность, поставка. Признак: починить случай может тот, кто держит инструмент, а не ты в своём проекте. Наблюдение о работе своего проекта — его решениях, коде, людях — фидбэком не бывает: оно ложится в граф проекта по writing, как любое знание о предмете.
Прежде чем писать: которую редакцию ты держишь
Скилл не несёт на себе метки своей версии, а установленная копия может отставать от сопровождаемой на несколько выпусков; протухший текст читается так же авторитетно, как текущий, и его дефекты предстают дефектами метода. Сверку редакции установленной поставки несёт iskronify — прогони её прежде, чем докладывать инструкцию скилла неверной, и назови версию поставки первой строкой случая.
Прежде чем писать: не сказано ли это уже
Граф работы долгоживущий и общий для всех делателей контура, поэтому первый ход — не запись, а взгляд. Второй узел, говорящий то, что один уже говорит, раскалывает ответ — и игнорируют именно второй.
Сначала выбери граф назначения — по разделу «Клади туда, где держат инструмент» ниже: граф работы, если в нём есть контур инструмента, иначе @nks/feedback. И поиск, и запись идут в нём.
iskron_semantic_search(realm=<граф назначения>, q=<случай одной фразой>) — одно понятие на запрос, естественной фразой: строка из нескольких смыслов не близка ни к одному. Два понятия — два запроса, никогда не один длиннее. Лексический iskron_search здесь не годится: многословный запрос возвращает пустоту ровно тогда, когда тебе есть что сказать.
На попадании — допиши новизну в стоящий узел, не открывай второй. Скажи, что ново: ещё один контур, где воспроизвелось, механизм, которого первый рассказ не называл, случай, сужающий или расширяющий. Второе свидетельство превращает случайность в образец — но только дописанное, не дублем.
Почти-попадание — не промах. Узел, покрывающий тот же дефект с другого угла, — попадание. Новый узел открывай только тогда, когда твоё сделало бы существующий узлом о двух вещах.
Форма
Сначала жанр — он решает, как случай будет прочитан:
| Что несёшь | Жанр |
|---|---|
| Правило существует, и случай ускользнул | vyabhichara |
| Описание или обоснование само неверно | hetu-dosha |
| Наблюдение, которое стоит нести, без заявки о дефекте | hint |
| Настоящий вопрос о том, как должно быть | samshaya |
Затем тело, на языке графа, в этом порядке:
- Случай. Где и что на самом деле произошло — конкретно настолько, чтобы с этим можно было спорить (когда и кем — не в теле, ниже).
- Правило, которое должно было поймать, — процитированное дословно, если оно есть. Это несущая часть и самая пропускаемая. «Правила нет» и «правило верно, но его всё равно проскочили» зовут противоположные починки, и различает их только цитата. Случай, подтверждающий правило в четвёртый раз, всё равно стоит записи: он говорит, что проблема не в правиле.
- Где промах на самом деле — что часто не там, где показалось сначала.
- Механизм. Почему это случается, а не что случилось. Шаг без собственного подтверждения пропускается по построению, не по невнимательности; починка, снявшая симптом, учит сама себя. Назови форму — и случай перестанет быть одним инцидентом.
- Что бы это закрыло — критерий, не решение. Чинить будешь не ты.
Кто и откуда — контур, харнес, дата — идёт в reasoning записи и остаётся в истории узла; posed_by — только короткий адрес спрашивающего, не проза. Случай, чьё происхождение не проследить, не воспроизвести.
Пиши модус честно. pratyakshita — для того, что видел происходящим; anumita — для выведенного из чтения кода или прозы. Разница — то, что говорит держателю: воспроизводить это или спорить с этим.
Клади туда, где держат инструмент — адресно
Куда — решает, есть ли в графе твоей работы контур инструмента со стюардом:
- Есть (ты работаешь в графе, где эту поставку и её поверхность разрабатывают) — случай кладётся туда, к тому, кто держит: скилл — в контуре своей поставки, тул — в контуре своей поверхности, дисциплина канала — в своей под-границе. Отдельный граф, где нет ни контура, ни стюарда, тут не адрес: там случай никто из способных починить не увидит.
- Нет (ты работаешь в графе своего проекта, а поставку держат другие) — случай о самой поставке, её скиллах, мосте или тулах кладётся в граф
@nks/feedback: он открыт всем, и его читают те, кто поставку держит. Ни в граф своего проекта, ни на «ближайшую границу» в нём такой случай не клади — стюарда поставки там нет.
Эту работу делают два ребра, и отвечают они на разные вопросы:
- Якорь (
vimarsha_of→ узел инструмента или его контур) решает, где случай находят. Ориентирующийся на этом контуре собирает всё заякоренное под ним; случай, не заякоренный нигде, находим лишь тем, кто читает весь граф. Есть узел самого скилла или тула — якорь на него, не на контур: фокус на контуре и так собирает вопрошания своего охвата. - Адрес (
posed_to→ роль) решает, в чью очередь он входит. Служебное значениеposed_to="steward"само находит стюарда контура от якоря; несколько кандидатов — отказ с перечислением, выбери по нему. Случай о методе вообще, не об одной поставке, адресуется роли владельца продукта.
Одно не заменяет другого: адресованный, но не заякоренный — никогда не всплывает там, где предмет пересматривают; заякоренный, но не адресованный — его никто не держит.
Прочти контур прежде, чем класть. iskron_orient(realm=<граф назначения>, focus=<контур инструмента>) показывает узлы и роли, существующие сегодня; узел скилла или тула ищи iskron_search(realm=<граф назначения>, q=<имя скилла или тула>). В графе, где поставку разрабатывают, а контура для инструмента нет — якорь на ближайшую границу, в которой он применяется, и это верно, а не лениво. Якорь на узле, которого нет, хуже отсутствия якоря.
Ты должен случаю рассказ, не починку. Напиши так, чтобы читатель, которого там не было, мог воспроизвести и решить. В сессии, где по нему действуют, тебя не будет. Случай входит в очередь роли (её читают по «Старту» двери iskron); разговор о починке, если он нужен, — словом в деле на узле инструмента (iskron_case(action="talk", about=<предмет>)). Не припиской в тело случая: тело переписывается под нынешнее знание, а не растёт перепиской.