reconcile について
変更後に、担当領域のシステムグラフとコードを照合するスキルです。グラフの記述を実装と突き合わせ、別の場所にある設計根拠を移し、未解決の差異を追跡事項として記録します。
主な機能
- 01コードに基づくグラフノードの確認
- 02名称と証拠の整合
- 03手順と単発タスクの区別
- 04設計根拠をグラフへ移行
- 05クライアント呼び出しと辺の比較
- 06未解決の構造的緊張の記録
活用シーン
- 01マージ後のグラフ照合
- 02外部 API や SDK の記述監査
- 03クライアント呼び出しと辺の整合
- 04古いグラフ記録の整理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ iskron-ai/ skills --skill reconcileインストール後、Claude Code で/reconcileを入力して読み込まれたか確認します。
README(原文)English
プロジェクトの README よりこの README の日本語訳はまだありません。以下は英語の原文です。日本語の紹介はページ上部をご覧ください。
Reconcile — сверка кода и графа
Граф — выведенное описание реальности, и код — та реальность, по которой оно выведено чаще всего. Между ними всегда бежит зазор: код ушёл вперёд за время задачи, граф оброс узлами, чьих денотатов больше нет, комментарии пересказывают то, чему место в графе. Reconcile — такт, которым делатель этот зазор закрывает, в обе стороны и в своей области ответственности, не во всём графе.
Когда. Три повода, и первый — главный: (1) конец каждой сущностной задачи — работа не кончена мержем, она кончена сверкой следа: что задача сделала истинным, то граф говорит, что перестало быть истинным — то он больше не утверждает; (2) явная просьба — «приведи граф в порядок», «сверь с кодом»; (3) плановая уборка области, когда ориентация показывает копящиеся напряжения. Это не разведка перед работой (то — entry и ориентация) и не проектирование (то — design): reconcile идёт по следам уже совершённого.
Протокол — проходки
После мержа различи код и практику. Сверь карту и узлы отгруженного; мерж сам не переводит крию в vartamana. Старт практики и вопрос исполнителю без свидетельства — по weaving, «Переходы носителей»; проверь эту границу в проходке модусов.
0 · Встань в своём контуре и сверься с методом. iskron_orient(realm=..., focus=свой контур) — границы области, её крии, феномены, открытые вимарши. Затем методологическая сверка: каким правилам следует этот граф — прочти его канон или спроси стюарда; уборка по выдуманным правилам хуже пыли. Сверка чужих областей — не твоя: замеченное там отдай вимаршей их стюарду (posed_to), не правкой.
1 · Прямая проходка: узлы против кода. Каждый узел области — четыре вопроса:
- Существует ли ещё то, что он утверждает? Для узлов внешних поверхностей (чужой API, SDK, CLI, схема вендора) — особенно: вендор поднимает версию молча. Сверяй наблюдением, не памятью; наблюдения не взял — опусти эпистемику. Ушедшее — в онтику
atita(история остаётся), исчезнувшее бесследно —nashta; удаление — для записи, которая не несла различения: узел неверного типа, чья запись лжёт самой формой (проходка 2), дубль, пустое понятие; ложный тезис не удаляют, а опровергают и хранят (три судьбы записи — writing, справочник модусов). - Имя ещё отвечает коду? Имя узла — первый тезис о нём (正名): код переименовал сущность — граф переименовывает узел, не заводит второй.
- Модусы честны? Эпистемика — по средству познания и выделенной заявке:
pratyakshitaоб утверждении, чей предмет в коде с тех пор менялся, а свидетельство не обновлялось, — выше видимого сейчас; сверь (и подними) или понизь по названному основанию — предмет ушёл, свидетельство не относится к нынешнему коду. Свежесть свидетельства относится к заявке: возраст сам модуса не понижает, решение и принцип по давности не слабеют. - Кто его тянет? Спроси, какая крия сломается, если узел исчезнет. Ни одна — это укрытие, не запись (sinn для того, что действует; одинокая стрелка
context); молчание реестра натяжений его не оправдывает — детекторы меряют структуру, не несущесть. Укрытие не удаляй бездумно: смысл без носителя переткай в несущий узел — upadhi при крие, которая через него действует; склад без смысла — вatita.
2 · Различение крии и задачи — здесь путают чаще всего. Крия утверждает повторяемый переход: всякий её прогон ест ту же ahara и производит ту же utpatti — сборка, деплой, миграция как процедура, ритуал сессии. Задача — разовое деяние: у каждого прогона свои вход и выход, и повторяемого перехода она не утверждает. Задача, записанная крией, лжёт типом: её «результат» вырождается в феномен-ярлык состояния — сироту по устройству. Признак для проверки в один взгляд: спроси у «крии», что она съест и произведёт в следующий прогон; нет ответа — это задача. Носитель разовой задачи — не узел, а поручение в деле (справка двери iskron cases.md, «Разовая задача — слово в деле»). В граф идёт то, что задача меняет, — переходы системы в модусах замысла и решения по ним; крупная, со своим телосом, — собственное превращение. Найденную задачу-крию перепиши так же: что она меняла — узлами переходов (повторяемый — крией, результат — феноменом, который настоящая крия производит), открытые вопрошания перецепи якорем, феномены-ярлыки сними вместе с ней, а недоделанное — поручением в деле на узле предмета; вимаршей задачу не подменяй.
3 · Обратная проходка: код против графа. Многословный комментарий — обоснование решения, отброшенные альтернативы, устройство интеграции, пересказанные словами в коде, — это узел графа, живущий не дома: его не найдёт поиск, не тронет проходка 1, не прочтёт сосед по контуру. Перенеси смысл в граф и оставь в коде референс: адрес графа и номер узла — «(граф <адрес графа>, узел #N)», адрес дословно из iskron_realm(action="list"): отображаемое имя графа не резолвится. Граница, чтобы не впасть в обратную крайность: механика шага — словами в комментарии; смысл, обоснование, поле интеграции — в графе с референсом из кода. Комментарий «закрываем сокет до renameSync, иначе ловим EBUSY на Windows» — механика, остаётся словами. Комментарий на полстраницы «почему мы выбрали очередь, а не вебхуки, и что было с ретраями» — смысл, уезжает в граф. И не всё подряд: кусочек кода без судьбоносного смысла не заслуживает узла — референс ставится там, где читателю без графа не понять зачем, а не как.
3a · Инвентарь клиента против рёбер — на мерже, тронувшем модуль-клиент. Вызов в коде потребителя без ребра в графе не рвёт ничего — его не видят ни ворота записи, ни детектор; прошивка мерится извне графа (правило поставки, дословно: «Прошивка вызовов потребителя мерится извне графа: инвентарь клиента против рёбер на такте сверки, и обход обещает покрытие лишь в его меру»). Шаг: сними инвентарь зовомых путей из модуля-клиента (параметры нормализованы; вызовы с нелитеральным путём учтены явно — литеральный grep обещает покрытие, а даёт выборку, и обязан называть себя так), возьми список URL-типов, на которые крии твоего контура держат utpatti, и сведи разность в обе стороны, различая три рода: вызов без ребра при живом деянии — ткачество, минуты; вызов без деяния вовсе — проектирование, design; ребро без вызова — снять либо пометить снятым. Скрипт инвентаря живёт в репозитории потребителя и вправе стоять гейтом CI; остаток — вимаршами на своих носителях. Обход поля интеграции по твоему контуру обещает покрытие только после прогона с нулевой разностью и до следующего мержа, тронувшего клиент; вне этого окна он возвращает выборку и в отчёте интеграции так и зовётся.
4 · У каждого варианта три исхода, и все три — запись. Принятый вариант живёт узлами решения. Отброшенный — узлом в visarjana: рассмотрели, отпустили, причина в теле. Отвергнутый — в virodha, а переживший настоящий спор — вимаршей prati-paksha, где позднее свидетельство сможет поднять его снова. Код вправе референсировать отброшенное так же, как принятое: строка «не кэшируем: граф <адрес графа> #N» сильнее абзаца. Незаписанное отвергнутое — самая дорогая потеря: следующий делатель проходит тот же тупик.
5 · Напряжения и финал. iskron_orient(lens="tensions", focus=свой контур) — что осталось структурно: leaked, relay-gap, сироты — это работа weaving, делай её здесь же, пока контекст горяч. Поведенческие заявки, поднятые проходками («этот узел теперь снова pratyakshita»), — через reality-audit, не на глаз. Закрой такт отчётом долгов: что сверено, что перенесено, что осталось, — и остаток не рассказом, а вимаршами на своих носителях: долг, записанный вопрошанием, переживёт сессию; долг, рассказанный в чате, умрёт с ней.