Take a feature from an idea to a checked result

Функции в этом руководствеFunctions in this guideФункції в цьому посібнику

Изучить область, прежде чем её менятьInvestigate an area before you change itВивчити ділянку, перш ніж її змінюватиОдин продуманный проход чтения оставляет черновое досье и, для тикета, долговечные выводы, чтобы никто не искал одно и то же пять раз.One deliberate reading pass leaves a scratch dossier and, for a ticket, durable findings, so nobody greps the same things five times.Один продуманий прохід читання лишає чорнове досьє і, для тікета, довговічні висновки, щоб ніхто не шукав те саме п'ять разів.
Превратить описание фичи в утверждённую стратегическую спекуTurn a feature description into an approved strategic specПеретворити опис фічі на затверджену стратегічну спеку/spec пишет, что и зачем нужно в фиче, без имён классов и путей к файлам, утверждает и передаёт /spec-tech. Мелкую задачу делает на месте./spec writes the what and why of a feature with no class names or file paths, approves it and passes it to /spec-tech. A small task is built in place./spec пише, що й навіщо потрібно у фічі, без назв класів і шляхів до файлів, затверджує та передає /spec-tech. Дрібну задачу робить на місці.
Разбить утверждённую спеку на поэтапный план с проверкой каждого шагаTurn an approved spec into a phased plan with a check on every stepРозбити затверджену спеку на поетапний план із перевіркою кожного кроку/spec-tech пишет тактический план: индекс и файлы фаз, каждый шаг кончается статической проверкой, а порядок фаз сам проверяется до смены статуса./spec-tech writes the tactical plan: an index and phase files, each step ending in a static check, with the phase order self-reviewed before the status flips./spec-tech пише тактичний план: індекс і файли фаз, кожен крок закінчується статичною перевіркою, а порядок фаз сам перевіряється до зміни статусу.
Выполнить тактический план по одному проверенному шагуImplement a tactical plan one verified step at a timeВиконати тактичний план по одному перевіреному кроку/spec-dev идёт по плану шаг за шагом, проверяет каждый шаг до отметки о готовности и жёстко останавливается на первом сбое или неоднозначности, не угадывая./spec-dev runs the plan step by step, checks each step before marking it done and hard-stops on the first failure or ambiguity instead of guessing forward./spec-dev іде за планом крок за кроком, перевіряє кожен крок до позначки про готовність і жорстко зупиняється на першому збої чи неоднозначності, не вгадуючи.
Обновить все места, где пользователь встречает изменение, под одним именемUpdate every place a user meets a change, under one nameОновити всі місця, де користувач зустрічає зміну, під одним іменем/surfaces перечисляет все места, где пользователь встречает изменение, до правок, затем выравнивает каждое затронутое под одним именем в каждой авторской локали./surfaces lists every place a user meets a change before any edit, then makes each touched one say the same thing, under one name, in every authored locale./surfaces перелічує всі місця, де користувач зустрічає зміну, до правок, потім вирівнює кожне зачеплене під одним іменем у кожній авторській локалі.
Проверить реализацию по спеке и выставить статус тикета по фактуAudit a build against its spec and set the ticket status from realityПеревірити реалізацію за спекою й виставити статус тікета за фактомСверяет тикет с тем, что реально лежит в файлах, и выставляет статус: Verified, Partial или Broken, а пока открыта ручная проверка, BlockNeedUserTest.Audits a ticket against what the files really contain and sets its status: Verified, Partial or Broken, or BlockNeedUserTest while a manual check is open.Звіряє тікет із тим, що справді лежить у файлах, і виставляє статус: Verified, Partial чи Broken, а поки відкрита ручна перевірка, BlockNeedUserTest.
Провести фичу от идеи до проверенного тикета одной командойTake a feature from idea to a verified ticket with one commandПровести фічу від ідеї до перевіреного тікета однією командоюОценивает размер задачи, затем по очереди запускает исследование, спеку, план, реализацию и аудит, останавливаясь только на настоящих решениях.Sizes the task, then runs research, spec, plan, build and audit in order, pausing only where a real decision is needed.Оцінює розмір задачі, потім по черзі запускає дослідження, спеку, план, реалізацію й аудит, зупиняючись лише на справжніх рішеннях.
Провести тикет по жизненному циклу с проверкой на каждом шагеMove a ticket through the lifecycle with a gate at every stepПровести тікет життєвим циклом із перевіркою на кожному кроціТикет - это один Markdown-файл со строкой статуса. Каждый навык требует входной статус и выдаёт выходной, поэтому этап нельзя пропустить на глаз.A ticket is one Markdown file with a status line. Each skill requires an entry status and produces an exit status, so no stage is skipped on a hunch.Тікет - це один Markdown-файл із рядком статусу. Кожна навичка вимагає вхідний статус і видає вихідний, тож етап не можна пропустити на око.

ШагиStepsКроки

Оцените размер задачи до заведения тикета. Берите самую нижнюю ступень, которая ещё доказывает изменение: /quick для опечатки, /fix для известного бага, спека PRIMITIVE из трёх разделов для небольшого детерминированного изменения и полный конвейер COMPLEX, только когда остались настоящие неизвестные. Дальше в руководстве идёт именно конвейер. Ступени и переходы между статусами описаны в жизненном цикле.Size the task before you open a ticket. Take the lowest rung that still proves the change: /quick for a typo, /fix for a known bug, a three-section PRIMITIVE spec for a small deterministic change, and the full COMPLEX pipeline only when real unknowns remain. The rest of this guide is that pipeline. The rungs and the status gates are in the lifecycle.Оцініть розмір задачі до заведення тікета. Беріть найнижчий щабель, який ще доводить зміну: /quick для одруківки, /fix для відомого багу, спека PRIMITIVE з трьох розділів для невеликої детермінованої зміни й повний конвеєр COMPLEX, лише коли лишилися справжні невідомі. Далі в посібнику йде саме конвеєр. Щаблі та переходи між статусами описано в життєвому циклі.
Сначала изучите область командой /research, например /research T0123 best strategy for full-text search over filenames. Слово в форме идентификатора тикета привязывает запуск к тикету: отобранные выводы сохраняются в его папке research/, а черновое досье остаётся в scratch. Без идентификатора ничего не хранится вне досье. Статус исследование не меняет.Investigate first with /research, for example /research T0123 best strategy for full-text search over filenames. A token shaped like a ticket id binds the run to the ticket: curated findings are saved under its research/ folder, while the rough dossier stays in scratch. Without an id nothing is kept outside the dossier. Research changes no status.Спершу вивчіть ділянку командою /research, наприклад /research T0123 best strategy for full-text search over filenames. Слово у формі ідентифікатора тікета прив'язує запуск до тікета: відібрані висновки зберігаються в його теці research/, а чорнове досьє лишається в scratch. Без ідентифікатора нічого не зберігається поза досьє. Статус дослідження не змінює.
Опишите «что и зачем» командой /spec: /spec add CSV export to the monthly report. Она выдаёт идентификатор тикета, пишет стратегическую спеку (проблема, цели, ограничения, открытые вопросы, риски, критерии готовности) без имён классов и путей к файлам и переводит её из Draft в Approved. Чтобы развернуть существующий Draft, например заглушку от /park, передайте его идентификатор (/spec T0042): тот же идентификатор, тот же файл. Если обязательный пункт исследования в §6 всё ещё Open, она перечисляет такие пункты и спрашивает, продолжать ли.Write the what and why with /spec: /spec add CSV export to the monthly report. It allocates the ticket id, writes the strategic spec (problem, goals, constraints, open questions, risks, done criteria) with no class names or file paths, and moves it from Draft to Approved. To expand an existing Draft, such as a /park stub, pass its id (/spec T0042): same id, same file. If a required research item in §6 is still Open, it lists those items and asks before it goes on.Опишіть «що й навіщо» командою /spec: /spec add CSV export to the monthly report. Вона видає ідентифікатор тікета, пише стратегічну спеку (проблема, цілі, обмеження, відкриті питання, ризики, критерії готовності) без назв класів і шляхів до файлів та переводить її з Draft до Approved. Щоб розгорнути наявний Draft, наприклад заглушку від /park, передайте його ідентифікатор (/spec T0042): той самий ідентифікатор, той самий файл. Якщо обов'язковий пункт дослідження в §6 досі Open, вона перелічує такі пункти й питає, чи продовжувати.
Превратите утверждённую спеку в план командой /spec-tech: /spec-tech T0042. Ей нужен Approved или выше: Draft она отклоняет, а не повышает, поэтому сначала разверните его через /spec T0042. Она пишет INDEX.md (с разделом ## Plan revisions) и по файлу PHASE_NN__slug.md на фазу, упорядочивает фазы так, чтобы ни одна не потребляла то, что произведёт более поздняя, сама проверяет свой план и ставит спеке Tactical. Неотмеченный блокер до реализации в INDEX.md останавливает передачу в сборку.Turn the approved spec into a plan with /spec-tech: /spec-tech T0042. It needs Approved or later: a Draft is refused, not promoted, so expand it with /spec T0042 first. It writes INDEX.md (with its ## Plan revisions) and one PHASE_NN__slug.md per phase, orders the phases so none consumes what a later one produces, reviews its own plan and sets the spec to Tactical. An unchecked pre-implementation blocker in INDEX.md stops the hand-off to the build.Перетворіть затверджену спеку на план командою /spec-tech: /spec-tech T0042. Їй потрібен Approved або вище: Draft вона відхиляє, а не підвищує, тож спершу розгорніть його через /spec T0042. Вона пише INDEX.md (із розділом ## Plan revisions) і по файлу PHASE_NN__slug.md на фазу, впорядковує фази так, щоб жодна не споживала те, що вироблятиме пізніша, сама перевіряє свій план і ставить спеці Tactical. Невідмічений блокер до реалізації в INDEX.md зупиняє передачу в збірку.
Соберите результат командой /spec-dev: /spec-dev T0042. Она идёт по одному шагу и отмечает шаг [x] done, только если его проверка прошла в этом запуске, с записью в ## Step Log фазы. На неоднозначности, проваленной проверке или зоне только для чтения она останавливается и докладывает, а не угадывает. Тикет заканчивает на Implemented или, если в приёмку входит ручное тестирование, на BlockNeedUserTest, и тогда в спеке появляется раздел ## Manual checks. Коммитов она не делает; --dry-run печатает план и ничего не записывает.Build it with /spec-dev: /spec-dev T0042. It runs one step at a time and marks a step [x] done only when its check passed in this run, with a line in the phase's ## Step Log. On an ambiguity, a failed check or a read-only zone it stops and reports instead of guessing. The ticket ends at Implemented, or at BlockNeedUserTest when manual testing is part of the acceptance, and then the spec gains a ## Manual checks section. It never commits; --dry-run prints the plan and writes nothing.Зберіть результат командою /spec-dev: /spec-dev T0042. Вона йде по одному кроку й позначає крок [x] done, лише якщо його перевірка пройшла в цьому запуску, із записом у ## Step Log фази. На неоднозначності, проваленій перевірці чи зоні лише для читання вона зупиняється й доповідає, а не вгадує. Тікет закінчує на Implemented або, якщо до приймання входить ручне тестування, на BlockNeedUserTest, і тоді в спеці з'являється розділ ## Manual checks. Комітів вона не робить; --dry-run друкує план і нічого не записує.
Обновите все места, где пользователь встречает изменение. Последняя фаза плана всегда docs-cleanup, и если §8 спеки требует пользовательских документов, они пишутся через /surfaces: сначала она печатает таблицу всех поверхностей, правит строки с пометкой «затронуто», каждую авторскую локаль в той же правке, затем ищет по ним ключевое существительное и сообщает счётчики. Изменение, которого никто не видит, сразу заканчивается строкой surfaces: not user-visible - <reason>. Ничего не публикует.Update every place a user meets the change. The plan's last phase is always docs-cleanup, and when §8 of the spec requires user docs, they are written through /surfaces: it prints a table of every surface first, edits the rows marked touched with each authored locale in the same edit, then greps the key noun across them and reports the counts. A change nobody can see ends at once with surfaces: not user-visible - <reason>. It publishes nothing.Оновіть усі місця, де користувач зустрічає зміну. Остання фаза плану завжди docs-cleanup, і якщо §8 спеки вимагає користувацьких документів, вони пишуться через /surfaces: спершу вона друкує таблицю всіх поверхонь, править рядки з позначкою «зачеплено», кожну авторську локаль у тій самій правці, потім шукає по них ключовий іменник і повідомляє лічильники. Зміна, якої ніхто не бачить, одразу завершується рядком surfaces: not user-visible - <reason>. Нічого не публікує.
Проверьте результат командой /spec-check: /spec-check T0042. Она сверяет файлы со спекой, сборку не запускает и выставляет статус по найденному: Verified, Partial, Broken или, пока открыт ручной пункт, BlockNeedUserTest. Результаты попадают в блок ## Last Audit и перезаписываются при каждом запуске. На Partial и Broken она передаёт ход /spec-fix: тот закрывает пункты, не требующие решений, остальные перечисляет дословно и заново запускает аудит, так что статус всегда берётся из файлов, а не из самой правки.Audit the result with /spec-check: /spec-check T0042. It compares the files with the spec, runs no build and sets the status from what it finds: Verified, Partial, Broken or, while a manual item is open, BlockNeedUserTest. Findings go into the ## Last Audit block, overwritten on every run. On Partial or Broken it hands over to /spec-fix: that closes the action items needing no decision, lists the rest word for word and re-runs the audit, so the status always comes from the files, never from the fix.Перевірте результат командою /spec-check: /spec-check T0042. Вона звіряє файли зі спекою, збірку не запускає й виставляє статус за знайденим: Verified, Partial, Broken або, поки відкритий ручний пункт, BlockNeedUserTest. Результати потрапляють у блок ## Last Audit і перезаписуються за кожного запуску. На Partial і Broken вона передає хід /spec-fix: той закриває пункти, що не потребують рішень, решту перелічує дослівно й знову запускає аудит, тож статус завжди береться з файлів, а не з самої правки.
Если тикет не может двигаться, поставьте ему статус блокировки и заметку в одну строку на самой строке статуса, после дефиса: BlockNeedUserTest, BlockByOtherTask, BlockQuestions или BlockExternal. При BlockNeedUserTest вы отмечаете каждую строку [ ] раздела ## Manual checks спеки датой и тем, что увидели (агенты не отмечают, доказательство может дать /prove), и снова запускаете /spec-check. Чтобы снять любую блокировку, уберите причину, отметьте это и продвиньте тикет ровно на один уровень.When a ticket cannot move, give it a block status and a one-line note on the status line, after a hyphen: BlockNeedUserTest, BlockByOtherTask, BlockQuestions or BlockExternal. For BlockNeedUserTest you tick each [ ] line of the spec's ## Manual checks with the date and what you saw (agents never tick, /prove can give evidence), then re-run /spec-check. To clear any block, remove the cause, note it and advance exactly one level.Якщо тікет не може рухатись, поставте йому статус блокування і нотатку в один рядок на самому рядку статусу, після дефіса: BlockNeedUserTest, BlockByOtherTask, BlockQuestions або BlockExternal. За BlockNeedUserTest ви позначаєте кожен рядок [ ] розділу ## Manual checks спеки датою й тим, що побачили (агенти не позначають, доказ може дати /prove), і знову запускаєте /spec-check. Щоб зняти будь-яке блокування, приберіть причину, позначте це й просуньте тікет рівно на один рівень.
Всю линию одной командой ведёт /spec-all: /spec-all и однострочная идея либо /spec-all T0042, чтобы продолжить. Сначала она оценивает размер задачи и отправляет опечатку в /quick, а узкий баг в /fix. Затем запускает /research (и /ui-clarify, пока не решён вопрос, видимый пользователю: это остановка), после этого те же стадии в том же порядке и останавливается только там, где нужно настоящее решение. Чтобы просмотреть результат между стадиями, запускайте навыки по одному или передайте --dry-run тем, что его принимают: /spec-tech, /spec-dev, /spec-fix.For the whole line in one command, use /spec-all: /spec-all plus a one-line idea, or /spec-all T0042 to resume. It sizes the task first and sends a typo to /quick and a narrow bug to /fix. It runs /research (and /ui-clarify when a user-facing decision is open, a real stop), then the same stages in the same order, and stops only where a real decision is needed. To review between stages, run the skills one by one, or pass --dry-run to those that take it: /spec-tech, /spec-dev, /spec-fix.Всю лінію однією командою веде /spec-all: /spec-all і однорядкова ідея або /spec-all T0042, щоб продовжити. Спершу вона оцінює розмір задачі й відправляє одруківку до /quick, а вузький баг до /fix. Далі запускає /research (і /ui-clarify, якщо не вирішено питання, видиме користувачеві: це справжня зупинка), після цього ті самі стадії в тому самому порядку й зупиняється лише там, де потрібне справжнє рішення. Щоб переглянути результат між стадіями, запускайте навички по одній або передайте --dry-run тим, що його приймають: /spec-tech, /spec-dev, /spec-fix.

Что вы должны увидетьWhat you should seeЩо ви маєте побачити

Один файл тикета в каталоге планов вместе с тактической папкой, статус которого совпадает с файлами: Verified либо Partial, Broken или статус блокировки, где блок ## Last Audit или заметка говорят, что осталось. Места, где пользователь встречает изменение, обновлены вместе, а все стадии читали и писали этот же файл.One ticket file in the plan directory, with its tactical folder, whose status matches the files: Verified, or Partial, Broken or a block status with a ## Last Audit block or a note that says what is left. The places a user meets the change were updated together, and every stage read and wrote that same file.Один файл тікета в каталозі планів разом із тактичною текою, статус якого збігається з файлами: Verified або Partial, Broken чи статус блокування, де блок ## Last Audit або нотатка кажуть, що лишилося. Місця, де користувач зустрічає зміну, оновлено разом, а всі стадії читали й писали цей самий файл.

Довести фичу от идеи до проверенного результатаTake a feature from an idea to a checked resultДовести фічу від ідеї до перевіреного результату

Функции в этом руководствеFunctions in this guideФункції в цьому посібнику

ШагиStepsКроки

Термины на этой страницеTerms on this pageТерміни на цій сторінці