Гайды

Как настроить навыки Qwen Code

13 октября 2026 · 21 минута чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

Материал редакции Зерокодера. Счёт по выдаче снят собственным прогоном 13 октября 2026 года; цитаты источников приведены дословно. Обновлено: октябрь 2026.

Настроить навыки Qwen Code — значит создать файл SKILL.md с инструкциями и положить его в папку обнаружения: личную ~/.qwen/skills/ или проектную .qwen/skills/. В официальной документации QwenLM сказано, что каждый навык состоит из файла SKILL.md с инструкциями, которые модель загружает по необходимости, плюс вспомогательные файлы вроде скриптов и шаблонов. Собственный прогон по этому запросу показал: текст отдали 9 из 10 страниц, а медиана объёма читаемого текста — 4546 слов. Мы скачали подборку результатов веб-поиска по запросу «Как настроить навыки Qwen Code»: текст отдали 9 из 10.

Устройство навыка и ручное создание

В QwenLM Agent Skills навык состоит из SKILL.md и дополнительных файлов. Личные навыки расположены в ~/.qwen/skills/, проектные — в .qwen/skills/. В примере заголовка указаны name, непустой description и priority: 10. Панель /skills позволяет найти, включить и запустить навык. Прямой вызов доступен через /<skill-name>; прежний /skills <skill-name> открывает панель и игнорирует хвост.

Выберите область для своего упражнения и создайте папку навыка. Запишите в description конкретную работу и условие применения. В теле задайте вход, порядок действий и способ проверки результата. Поддерживающий шаблон можно держать рядом. Для первого опыта возьмите безопасное чтение учебного проекта, в котором сами понимаете назначение файлов. Отдельно запишите, какие действия допускаете. Редакция пример не запускала.

Про подключение CLI к редактору есть материал Qwen в VS Code. Перед упражнением убедитесь, что сам клиент открывает сессию с выбранным провайдером. Создание навыка изучается после подготовки этого окружения.

Оригинальный учебный пример: навык безопасного чтения проекта

Ниже — учебный пример редакции. Это предлагаемое упражнение: мы описываем, что создать и как проверить, а выводы вы получите на своём проекте.

Задача навыка — задать порядок знакомства с незнакомым репозиторием: сначала обзор структуры, затем чтение ключевых файлов, затем отчёт. Смысл в том, чтобы агент не начинал с правок, а сначала собрал картину.

Создайте каталог:

mkdir -p .qwen/skills/read-project

Затем создайте файл .qwen/skills/read-project/SKILL.md со следующим содержимым:

---
name: read-project
description: Безопасный обзор незнакомого проекта. Применяй, когда нужно понять структуру репозитория перед изменениями.
priority: 10
---

# Обзор проекта

1. Покажи дерево каталогов верхнего уровня, пропуская служебные папки сборки.
2. Найди файлы описания проекта и прочитай их.
3. Найди точку входа приложения и опиши, с чего начинается выполнение.
4. Собери список зависимостей и выдели основные.
5. Составь отчёт: назначение проекта, структура, точка входа, риски.
6. Изменения в файлы не вноси. Дождись отдельной задачи.

Поля заголовка здесь соответствуют документации: name, description, priority. Описание сформулировано так, чтобы модель понимала условие применения — знакомство с незнакомым репозиторием.

Критерии самостоятельной проверки:

• Навык виден в панели. Откройте /skills и убедитесь, что read-project есть в списке и его можно включить.
• Навык срабатывает по описанию. Дайте задачу «разберись, что это за проект» без упоминания имени навыка. Проверьте сведения об активации и сопоставьте поведение с содержимым навыка. Похожая структура ответа сама по себе не доказывает вызов.
• Навык не срабатывает вне области. Дайте задачу, не связанную с обзором, и проверьте, что инструкция не подмешивается.
• Отчёт воспроизводим. Запустите обзор дважды и сравните структуру ответа: сравните соблюдение инструкции и фактические ссылки на файлы. Дословного совпадения ответов упражнение не требует.
• Правок нет. Убедитесь, что после обзора файлы проекта остались без изменений.

Такой навык подходит для первого учебного чтения. Его тело задаёт инструкции модели; соблюдение запрета изменений проверяйте по состоянию файлов и настройкам разрешённых инструментов. Когда порядок обзора устоялся, добавьте в тело правила для конкретного стека — например, какие файлы считать точкой входа.

Если вам нужен навык, который готовит релизные заметки, структура та же: место хранения, заголовок с конкретным описанием, тело с шагами, вспомогательный шаблон рядом с SKILL.md.

Готовый промпт и вариации

Когда навык создан, полезно попросить модель проверить и уточнить его формулировки. Ниже — промпт для этой задачи.

Промпт, чтобы отредактировать описание навыка под конкретную задачу:

Ты помогаешь мне настроить навык Qwen Code. Вот текущий SKILL.md:

[вставьте содержимое вашего SKILL.md]

Задача навыка: [ваша задача, например обзор незнакомого репозитория].
Стек проекта: [ваш стек].
Уровень строгости: [кратко или подробно].

Сделай следующее:
1. Перепиши поле description так, чтобы условие применения было однозначным.
2. Проверь, что тело инструкции задаёт порядок шагов и не допускает правок файлов без отдельной задачи.
3. Предложи, какие вспомогательные файлы стоит добавить рядом с SKILL.md.
4. Верни готовый SKILL.md целиком, чтобы я мог его скопировать.

Что менять под себя: [вставьте содержимое вашего SKILL.md], [ваша задача], [ваш стек], [кратко или подробно]. После ответа скопируйте файл и проверьте его в панели /skills.

Вариации той же задачи:

• Навык для код-ревью. Опишите правила проверки: на что смотреть в диффе, какие замечания считать блокирующими, в каком формате возвращать отчёт.
• Навык для релизных заметок. Задайте структуру заметки, источники сведений и тон изложения.
• Навык для тестов. Опишите, какие сценарии покрывать, как называть тесты, что делать при падении.
• Навык для документации. Задайте шаблон страницы, обязательные разделы и правила примеров.
• Навык для разбора ошибок. Опишите порядок диагностики: сбор симптомов, проверка гипотез, отчёт о причине.

Общий приём для всех вариаций: сначала опишите условие применения, затем порядок шагов, затем запреты. Такая последовательность делает вызов навыка предсказуемым.

Выбор отдельной процедуры под результат

Перед созданием следующего навыка назовите ожидаемый результат. Для знакомства с репозиторием нужен обзор по файлам и неизвестным сведениям. Для изменения нужна проверка конкретной правки и её последствий. Для заметки пользователю требуется описание поведения и честный статус проверки. Эти задачи используют часть общих материалов, но порядок принятия результата у них различается. Сначала выберите одну работу, затем задайте её вход и точку остановки.

Если новая инструкция повторяет старый обзор, сравните, что пользователь получит дополнительно. Возможно, нужен только новый шаблон для того же отчёта. Если результат самостоятельный, подготовьте отдельный контрольный вход. Например, заметка об изменении начинается с двух версий файла, а обзор начинается со структуры проекта. Эта разница должна быть видна в описании и теле инструкции. Обещание «помогать разработке» плохо объясняет её.

Для личного опыта выберите учебные материалы, которыми можете распоряжаться. Для передачи команды подготовьте обезличенный пример, шаблон и критерии. Путь распространения выбирается после проверки понятности процедуры. Если инструкция ссылается на вашу папку или предполагает знание прошлой задачи, сначала перепишите этот фрагмент. Получатель должен восстановить вход по доступным файлам и выполнить проверку без вашей устной подсказки.

Полезно держать обзор и изменение разными шагами. После обзора пользователь выбирает задачу и допустимые действия. После изменения он принимает diff и проверки. После принятия можно готовить заметку. Связать шаги поможет журнал фактов и неизвестных сведений. Каждый навык получает только нужный вход и возвращает проверяемый результат. Организация этих шагов — редакционная рекомендация для упражнений, а её пригодность вы оцениваете на собственном проекте.

Проверка файла и поведения навыка

При отказе вернитесь к сохранённой копии и сравните путь, заголовок и тело инструкции. Убедитесь, что редактировали нужный файл и сохранили изменения. Затем проверьте видимость и явный запуск. Если явный вызов прошёл, переходите к оценке результата на контрольном входе. Если навыка нет в списке, сначала изучите сообщение клиента; исправлять содержание задания на этом этапе рано.

Для содержательного расхождения запишите конкретную фразу ответа и основание из учебного файла. Меняйте один пункт инструкции и повторяйте тот же случай. После правки проверьте весь отчёт: исправление неизвестной даты не должно убрать сведения о функции. Если файлы были изменены за пределами разрешения, восстановите учебное состояние и уточните точку остановки в навыке.

Ошибка запуска клиента требует отдельного разбора. Когда обычная сессия не открывается, сначала восстановите окружение; примеры есть в материале о сбоях Qwen Code. Результат поведения навыка записывайте только после действительного выполнения своего опыта.

Учебный проект для проверки навыка

Дальше — оригинальный сценарий редакции. Его цель — проверить свою инструкцию на входе, который вы понимаете без помощи модели. Навык и запуск редакция не выполняла. Создайте отдельный учебный каталог с README, модулем app.py и папкой tests. Пример можно пройти в своём небольшом проекте, но сохраните исходное состояние до опыта. Для первого чтения исключите реальные пароли, переписку и клиентские выгрузки.

В README напишите назначение проекта простыми словами: программа принимает заметку о встрече и подготавливает короткое сообщение участникам. Укажите, что точное время встречи вводится пользователем и может оставаться неизвестным. В app.py создайте функцию clean_note, которая получает текст и убирает пробелы по краям. В папке tests оставьте описание ожидаемого поведения для пустой строки и строки с пробелами. Эти материалы созданы для упражнения; они не относятся к возможностям модели или к измерению качества Qwen.

Прочитайте материалы сами и составьте контрольную карточку. Назначение проекта задано README. Операция функции ограничена очисткой пробелов по краям. Обработку календаря, отправку сообщения и назначение ответственного эти материалы не реализуют. Именно такая узкая карточка позволит заметить выдуманные возможности в отчёте. Если вы взяли существующий учебный проект, выпишите соответствующие факты по его файлам и отметьте места, где сведений недостаточно.

Затем подготовьте ожидаемую структуру отчёта навыка: назначение, файлы, подтверждённая точка входа, зависимости, неизвестные детали и вопросы перед изменениями. Для каждого факта ожидайте путь к файлу или обозначение источника. Пустое поле лучше оставить вопросом к вам. Если точка входа не установлена по материалам, отчёт должен объяснить, что ещё нужно прочитать. Это редакционный критерий упражнения, который вы явно записываете в инструкцию.

Откройте созданный read-project и сравните его тело с этой карточкой. Инструкция должна требовать чтение материалов, а затем отчёт. Вставьте условие: неизвестные сведения сохранять как неизвестные. Отдельно запретите изменение исходных файлов во время обзора. Если вы хотите, чтобы отчёт сохранялся в файл, задайте допустимое имя и согласуйте это действие в своей задаче. Для первого опыта можно ограничиться ответом в диалоге.

Запуск и разбор первого отчёта

Проверьте видимость навыка в панели и начните с явного запуска. В текущей документации QwenLM описан прямой вызов по зарегистрированному имени; для read-project используйте /read-project, если навык зарегистрирован так. Через панель выберите тот же навык. Запишите, каким способом запускали его и какой проект был открыт. Сравнение этих сведений поможет отделить ошибку обнаружения от ошибки самой инструкции.

Передайте задачу: Прочитай учебный проект и подготовь обзор по навыку read-project. Файлы изменять не требуется. Неизвестные сведения оставь вопросами. Для фактов укажи исходные файлы. После ответа сравните текст с контрольной карточкой. Начните с назначения проекта: оно должно соответствовать README. Затем прочитайте описание функции. Если агент утверждает, что функция нормализует внутренние пробелы, сопоставьте это с её фактическим кодом.

Сверяйте каждый путь в отчёте с каталогом. Упоминание отсутствующего calendar.py или сервиса рассылки — конкретное расхождение. Запишите его вместе с предложением отчёта и соответствующим входом. Далее проверьте неизвестные детали. Время встречи не было задано; имя ответственного тоже отсутствует. Если в отчёте появились точный час или человек, инструкция допустила необоснованное заполнение. Исправьте именно этот пункт, сохранив исходный пример.

Проверьте поведение файлов своим обычным способом сравнения. Сохранённый diff или сопоставление копий показывает, были ли внесены изменения. Сообщение агента «ничего не менял» используйте вместе с этой проверкой. Если файлы изменились, остановите опыт, восстановите учебное состояние и уточните границы в навыке. Похожий ответ при случайном запуске обычного диалога не доказывает применение навыка; сведения о запуске и поведение проверяются вместе.

Для первой правки навыка выберите одно наблюдаемое расхождение. Например, отчёт не отделил неизвестную точку входа от факта. Добавьте правило об источниках и неизвестности, затем повторите обзор на том же проекте. Сравните отчёты по выбранному критерию и проверьте остальные блоки. Исправление формата может случайно убрать сведения о зависимостях, поэтому оценка проводится по всей контрольной карточке.

Удачный первый отчёт означает, что ваше упражнение прошло в этой сессии. Он не показывает пригодность навыка для любого репозитория. Для следующего опыта измените учебный вход и заранее обновите контрольную карточку. Указание «после запуска всегда правильный отчёт» не стоит записывать в описание навыка: так в обещание превращается ограниченный результат вашего опыта. Назовите конкретную процедуру и способ её проверки.

Упражнение с неполными и противоречивыми материалами

Подготовьте вариант проекта, где README описывает функцию, которую вы ещё не реализовали. Например, добавьте обещание сохранять заметку в файл, оставив app.py прежним. Рядом сохраните предыдущий README. Контрольное различие известно вам заранее: описание содержит будущую возможность, код её не подтверждает. Навык должен заметить расхождение или пометить статус неопределённым по прочитанным материалам.

Запустите обзор той же процедурой и сохраните отчёт. Найдите фразу о сохранении заметки. Если она представлена как работающая возможность, сопоставьте её с кодом и попросите уточнить основание. Нужный результат — описание того, что написано в README и что видно в реализации. Агент может предложить проверить другие файлы; такое предложение должно оставаться планом чтения, пока оно не выполнено.

Теперь подготовьте вариант без README. Перед запуском определите, какие сведения ещё можно получить из функций и файлов. Назначение проекта может быть менее определённым, но состав каталога остаётся наблюдаемым. Отчёт должен сократить уверенность там, где исчезло основание. Если агент воспроизводит прежнее назначение без пояснения, сохраните наблюдение и проверьте исходное состояние сессии. Для сравнения можно открыть отдельную сессию и повторить тот же вход.

Третий вариант — файл tests содержит только план проверок. В нём есть ожидаемые входы, но нет выполненного запуска. Проследите, чтобы отчёт не превратил этот план в сообщение «тесты проходят». В навыке полезно явно различить найденные проверки, выполненные проверки и предложенные проверки. Для каждого статуса требуйте основание: файл, команда и фактический результат, если выполнение было разрешено.

После этих опытов соберите таблицу расхождений: вход, ожидаемое ограничение, фактическая фраза отчёта, необходимая правка инструкции. Здесь не требуется числовой рейтинг модели. Польза таблицы в том, что каждое правило связано с наблюдением. Если вы добавляете запрет на выдуманные функции, сохраняйте именно тот учебный вход, на котором проблема проявилась. Следующее изменение навыка можно проверить на тех же материалах.

Описание навыка как условие применения

Перечитайте description глазами человека, который получил задачу впервые. Фраза «помогает с проектами» описывает почти любую работу и плохо устанавливает границы. В нашем упражнении конкретнее написать: «Обзор незнакомого репозитория перед изменениями: прочитать описание, точку входа и зависимости, вернуть отчёт со ссылками на файлы». Так в описании появляются действие, вход и момент применения.

Рядом запишите задачи, для которых этот навык использовать не планируете. Исправление ошибки, оформление релизной заметки и смена провайдера могут потребовать другого порядка. Для такого задания ваш обзор способен дать контекст, но он не выполняет само изменение. В инструкции обозначьте точку остановки: после отчёта ждать конкретной задачи. Это редакционное решение для безопасного знакомства с проектом.

Проверьте описание разными формулировками своей задачи. Сначала явно попросите обзор репозитория. Затем попросите объяснить назначение учебного проекта. Потом задайте отдельную просьбу исправить функцию. Сохраняйте сведения об активации, фактические действия и результат. Автоматический выбор зависит от клиентской сессии и модели; описание лишь задаёт условие, а наблюдаемое срабатывание проверяется в вашем окружении.

Если близкая формулировка не привела к применению навыка, сначала проверьте видимость и явный вызов. Когда явный запуск работает, можно уточнять description. Добавляйте слова, которыми вы действительно называете работу, и убирайте расплывчатые обещания. После изменения повторите предыдущие задания. Более широкое описание может помочь одному случаю и одновременно начать вмешиваться в другой. Это повод снова проверить границы.

Сохраните небольшой набор таких заданий рядом с навыком как редакционные случаи. Для каждого укажите желаемый порядок и способ наблюдения. Эти случаи полезны при следующих правках и передаче команде. Они не являются опубликованным бенчмарком Qwen и не задают универсальную частоту срабатывания. Результаты записывайте после своих действительных запусков, сохраняя выбранный проект, состояние файлов и текст задачи.

Второй учебный навык: заметка об изменении

Когда обзор проекта стал понятным, можно создать другой навык с новым результатом. В этом упражнении результатом будет черновик заметки об изменении функции. Он должен описывать фактическую правку и её проверку. Подготовьте две версии app.py: в исходной функция убирает пробелы по краям, в изменённой она дополнительно схлопывает пробельные последовательности внутри строки. Сохраните обе версии самостоятельно и определите ожидаемое поведение до обращения к агенту.

В отдельном текстовом файле запишите запрос автора изменения: привести внутренние пробелы к единому разделителю и сохранить слова. Затем создайте записку о проверках. Если проверки ещё не запускались, укажите именно этот статус. Если вы выполнили их сами, приложите команду, вход и фактический результат. Учебный сценарий редакция не выполняла. Эти документы становятся входом для новой процедуры; сообщение о выполненных тестах появляется только после вашего собственного запуска.

Назовите второй навык change-note. Для заголовка достаточно конкретного имени и описания: составить заметку о правке по двум версиям файла и записи проверок. В теле потребуйте сопоставить версии, описать изменённое поведение, отделить проверенный результат от плана и перечислить открытые вопросы. Назначение навыка отличается от обзора репозитория: он начинает с данных о конкретной правке и заканчивает черновиком заметки.

Пример редакционного тела инструкции:

# Заметка об изменении

Прочитай исходную и изменённую версии файла, запрос автора и запись проверок.
Опиши фактическое изменение поведения со ссылкой на строки или фрагменты.
Раздели выполненные проверки, предложенные проверки и неизвестные сведения.
Составь короткую заметку для пользователя функции.
Не назначай дату выпуска, номер версии и результат теста по догадке.
Исходные файлы не изменяй. Верни черновик и вопросы перед его принятием.

Выбор точных слов в этой инструкции — редакционное решение. Проверьте, что каждый пункт соответствует доступному входу. Если в вашем примере нет строк исходной версии, навык не должен обещать сопоставление по ним. Вместо этого обозначьте недостающие материалы и остановите составление окончательной заметки. Такое правило сохраняет связь результата с основанием и делает отказ полезным.

Проверка заметки по двум версиям

Сначала запустите навык на полном учебном входе. В результате ищите понятное описание: обработка пробелов внутри строки изменилась, остальные слова должны сохраниться. Сравните эту формулировку с кодом. Если заметка обещает обработку пунктуации, перевод текста или исправление орфографии, найдите основание в изменённых строках. Когда основания нет, запишите конкретное лишнее обещание и исправьте инструкцию.

Далее сверьте блок проверок. Файл с планом тестов содержит намерение, а запись запуска содержит наблюдение. Навык должен сохранить эту разницу. Если агент написал «проверки успешно пройдены» при одном плане, покажите ему исходную записку и потребуйте обозначить статус. После уточнения проверьте весь черновик: обещание даты или номера выпуска тоже могло появиться без данных.

Для контрольного отказа уберите изменённую версию файла и повторите задачу. Условие известно заранее: полноценное сравнение теперь не имеет обоих входов. Полезный результат — список недостающих материалов и запрос на них. Если вместо этого получилась уверенная заметка о правке, сохраните ответ как случай для следующей редакции навыка. Автоматическое создание красивого текста в этом опыте не равно выполнению процедуры.

Ещё один случай — пользовательская записка описывает желаемое изменение шире фактического кода. Например, автор попросил нормализовать все пробельные символы, но правка заменяет только обычный пробел. Попросите навык отделить намерение от реализации. После ответа сравните оба блока с входом. Так можно проверить, сохраняет ли инструкция неизвестность и расхождение, которое важно перед принятием заметки.

Шаблон результата рядом с навыком

Составьте собственный шаблон заметки и положите его рядом с SKILL.md. Дайте блокам понятные названия: изменилось, осталось прежним, выполненные проверки, ограничения и вопросы. В самом навыке укажите относительное имя шаблона и назначение. Дополнительный файл должен помогать конкретной работе; перечень случайных справок усложняет выбор материала. После изменения шаблона проверьте пример заново.

В каждом блоке предусмотрите явное состояние отсутствующих данных. Для проверок это может быть «запуск не предоставлен», для выпуска — «дата не согласована». Эти фразы выбраны редакцией для учебного случая. Они помогают заметить, когда модель заменяет отсутствие сведений уверенной формулировкой. Сравнивайте итоговый текст с шаблоном и входными файлами одновременно: заполненная структура сама по себе не подтверждает правильность содержания.

Если шаблон начинает разрастаться, проверьте необходимость каждого поля. Заметка для пользователя функции и технический отчёт ревью решают разные задачи. Для первого достаточно поведения и известных ограничений. Для второго нужны детали изменения и основания замечаний. Выберите результат заранее и уберите поля, которые принадлежат другой работе. Так тело навыка задаёт один порядок принятия результата.

Передача навыка и сохранение основания

Перед передачей проектного навыка прочитайте его так, словно не видели упражнение. Все необходимые материалы должны быть названы в инструкции, а способ получения входа — понятен. Проверьте относительные пути к шаблону и примерам. Уберите ссылки на личные папки и реальные секреты. Команда получает процедуру вместе с учебными материалами и критериями; личные сведения о вашем окружении туда не требуются.

Приложите к навыку удачный вход и случаи, на которых инструкция требовала правки. Подпишите, какой дефект они показывают: выдуманная функция, смешение плана с результатом, пропуск неизвестности или выход за разрешённые действия. Получатель может повторить эти случаи в своём окружении и сравнить поведение. Итог своего повторения он записывает отдельно. Такой порядок сохраняет происхождение правил и помогает следующему редактору понять их назначение.

После принятия полезно указать человека, который отвечает за процедуру в вашей команде, и обстоятельства пересмотра. Это организационная рекомендация редакции, которую можно применить к собственной работе. Например, новый формат входных документов или смена ожидаемого результата требуют просмотра шаблона. Перенос навыка в репозиторий делает файл доступным коллегам, но понятность и полезность инструкции нужно проверять на их задачах.

Когда остановить правку навыка

Остановитесь, если новая версия инструкции исправила один случай ценой потери другого обязательного результата. Вернитесь к контрольным входам и сравните наблюдения. Для read-project факты должны иметь основания в файлах, а изменения остаются за границей обзора. Для change-note нужны две версии и честный статус проверок. Сначала восстановите эти условия, затем расширяйте применение.

Отложите дополнительные функции, когда не можете назвать их отдельный проверяемый результат. «Навык для всего проекта» быстро превращается в набор разнонаправленных указаний. Следующее расширение лучше сформулировать как конкретную работу с входом и критерием принятия. Созданные учебные материалы сохраняйте: они позволяют проверить, как изменение инструкции повлияло на уже понятные случаи.

В финальной записи опыта укажите выбранный навык, текст задания, состояние файлов, способ запуска и фактический результат. Отдельно перечислите выполненные проверки и оставшиеся вопросы. Если запуска не было, подпишите материал как проект инструкции. Если прошёл только явный вызов, не утверждайте проверку автоматического выбора. Такая запись даёт честный итог вашей работы и оставляет следующему участнику ясный шаг для продолжения.

Проверка условий принятия перед переносом

Перед переносом навыка составьте короткий лист принятия. Для обзора проекта укажите наличие ссылок на реальные файлы, сохранение неизвестных сведений и отсутствие правок исходников. Для заметки об изменении укажите сравнение обеих версий, честный статус проверок и отсутствие выдуманного выпуска. Каждое условие должно проверяться по материалам вашего опыта. Если вы не можете назвать источник наблюдения, пока оставьте его открытым вопросом.

Пройдите лист по последнему результату и приложите основание к каждому принятому пункту. Путь в отчёте подтверждается существующим файлом. Статус теста подтверждается записью действительного запуска. Отсутствие правок подтверждается сравнением состояния. Полезно сохранить и неудачный случай: он показывает, для какой границы потребовалось изменить инструкцию. Получателю навыка так проще понять, что именно он должен повторить в своём окружении.

После следующего изменения инструкции вернитесь к тому же листу и контрольным входам. Отметьте, какие условия сохранились и где появилось расхождение. Выберите следующую правку по конкретному дефекту, затем повторите проверку. Перенос становится понятным, когда вместе с файлом есть его назначение, подготовленный вход и способ принятия результата. Это организационный итог вашего упражнения; общего обещания качества модели он не устанавливает.

Частые вопросы

Как настроить навыки Qwen Code с нуля?
Создайте файл по технической основе выше, затем проверьте явный запуск на подготовленном учебном входе.

Где хранить свой навык?
Выберите личную или проектную область по кругу пользователей. Фактический путь запишите рядом с контрольными случаями.

Как проверить описание навыка?
Сравните подходящие и соседние задачи, сохраняя сведения об активации и реальные действия. Одного похожего ответа недостаточно.

Как вызвать навык?
Откройте панель /skills или используйте прямое зарегистрированное имя. Запишите выбранный способ для повторения опыта.

Что делать, если результат неверный?
Сопоставьте его с контрольной карточкой, назовите конкретное расхождение, исправьте один пункт и проверьте остальные случаи.