Провести фичу от идеи до проверенного тикета одной командойTake a feature from idea to a verified ticket with one commandПровести фічу від ідеї до перевіреного тікета однією командою

ШагиStepsКроки

1. Наберите /spec-all и однострочное описание идеи либо продолжите тикет командой /spec-all ID. С идентификатором он читает текущий статус и входит в конвейер на нужной стадии; если план уже утверждён, с исследования он не начинает. Draft (например, заготовка от /park) входит на /spec ID: тот сохраняет идентификатор и раскрывает тикет на месте.Type /spec-all followed by a one-line description of the idea, or resume a ticket with /spec-all ID. With an ID it reads the current status and re-enters at the right stage; it never restarts from research when the plan is already approved. A Draft (for example a /park stub) re-enters at /spec ID, which keeps its id and expands it in place.Наберіть /spec-all і однорядковий опис ідеї або продовжте тікет командою /spec-all ID. З ідентифікатором він читає поточний статус і входить у конвеєр на потрібній стадії; якщо план уже затверджено, з дослідження він не починає. Draft (наприклад, заготовка від /park) входить на /spec ID: той зберігає ідентифікатор і розгортає тікет на місці.
2. Перед любой церемонией он оценивает размер задачи и одной строкой называет выбранный путь. Опечатка или одна константа - в /quick, узкий понятный баг - в /fix, тикет не заводится. PRIMITIVE-задача (не больше 3 файлов, без новых публичных типов, без изменений схемы, DI и маршрутов, детерминированная) получает спеку из трёх разделов (Problem / Approach / Done criteria) и реализуется сразу. Всё остальное - COMPLEX и идёт по конвейеру.It sizes the task before spending any ceremony and states the path in one line. A typo or one-constant change goes to /quick, a narrow well-understood bug to /fix, and no ticket is opened. A PRIMITIVE task (at most 3 files, no new public types, no schema, DI or route changes, deterministic) gets a three-section spec (Problem / Approach / Done criteria) and is implemented directly. Anything else is COMPLEX and runs the pipeline.Перед будь-якою церемонією він оцінює розмір задачі й одним рядком називає обраний шлях. Одруківка чи одна константа - до /quick, вузький зрозумілий баг - до /fix, тікет не заводиться. PRIMITIVE-задача (не більше 3 файлів, без нових публічних типів, без змін схеми, DI й маршрутів, детермінована) отримує спеку з трьох розділів (Problem / Approach / Done criteria) і реалізується одразу. Усе інше - COMPLEX і йде конвеєром.
3. /research собирает свидетельства (файлы, символы, ограничения, внешние источники) и сохраняет их. Если изменение видно пользователю, а решение о расположении, формулировке или запасном варианте не принято, следом идёт /ui-clarify, и это остановка: нерешённая неоднозначность интерфейса блокирует сборку, а тикет фиксирует её как BlockQuestions со списком нерешённого в заметке на строке статуса./research gathers the evidence (files, symbols, constraints, external references) and persists it. If the change is user-facing and a placement, wording or fallback decision is unresolved, /ui-clarify runs next, and that one is a stop: unresolved UI ambiguity blocks the build, and the ticket records it as BlockQuestions with the unresolved list as its note on the status line./research збирає свідчення (файли, символи, обмеження, зовнішні джерела) і зберігає їх. Якщо зміна видима користувачеві, а рішення про розташування, формулювання чи запасний варіант не ухвалено, далі йде /ui-clarify, і це зупинка: невирішена неоднозначність інтерфейсу блокує збірку, а тікет фіксує її як BlockQuestions зі списком невирішеного в примітці на рядку статусу.
4. /spec пишет стратегическое что и зачем, без путей к файлам и сигнатур, записывает переход в Approved и передаёт ход /spec-tech. Останавливается он, только если обязательный пункт исследования всё ещё Open. Чтобы прочитать спеку до начала работ, запустите /spec отдельно./spec writes the strategic what and why, with no file paths and no signatures, records the Approved flip and chains to /spec-tech. It stops only if a required research item is still Open. To read the spec before anything is built, run /spec alone./spec пише стратегічне що й навіщо, без шляхів до файлів і сигнатур, записує перехід у Approved і передає хід /spec-tech. Зупиняється він, лише якщо обов'язковий пункт дослідження досі Open. Щоб прочитати спеку до початку робіт, запустіть /spec окремо.
5. /spec-tech превращает спеку в поэтапный проверяемый план: каждый шаг кончается статической проверкой, и ни одна фаза не использует то, что произведёт более поздняя. Ему нужен Approved или выше, а Draft он отклоняет, не повышая. Он передаёт ход /spec-dev, если не остался непроверенный блокер перед реализацией. Последняя фаза плана всегда docs-cleanup: если §8 спеки требует пользовательских документов, /surfaces обновляет там каждую поверхность до аудита./spec-tech turns the spec into a phased, verifiable plan: every step ends in a static check, and no phase consumes what a later phase produces. It needs Approved or later and refuses a Draft instead of promoting it. It chains to /spec-dev unless an unchecked pre-implementation blocker remains. The plan's last phase is always docs-cleanup; if §8 of the spec requires user docs, /surfaces updates every surface there, before the audit./spec-tech перетворює спеку на поетапний перевірний план: кожен крок закінчується статичною перевіркою, і жодна фаза не використовує те, що вироблятиме пізніша. Йому потрібен Approved або вище, а Draft він відхиляє, не підвищуючи. Він передає хід /spec-dev, якщо не лишився неперевірений блокер перед реалізацією. Остання фаза плану завжди docs-cleanup: якщо §8 спеки вимагає користувацьких документів, /surfaces оновлює там кожну поверхню до аудиту.
6. /spec-dev выполняет по одному шагу, запускает проверку шага до того, как отметить его готовым, и жёстко останавливается на первой неоднозначности или сбое. Он ведёт статус от Tactical через In Progress к Implemented или к BlockNeedUserTest, если ручная проверка входит в приёмку, и тогда добавляет раздел ## Manual checks с пунктом [ ] на всё, что должен увидеть человек./spec-dev executes one step at a time, runs each step's check before marking it done and hard-stops on the first ambiguity or failure. It moves the status from Tactical through In Progress to Implemented, or to BlockNeedUserTest when manual testing is part of acceptance, adding a ## Manual checks section with a [ ] line per thing a human must see./spec-dev виконує по одному кроку, запускає перевірку кроку до того, як позначити його готовим, і жорстко зупиняється на першій неоднозначності чи збої. Він веде статус від Tactical через In Progress до Implemented або до BlockNeedUserTest, якщо ручна перевірка входить до приймання, і тоді додає розділ ## Manual checks із пунктом [ ] на все, що має побачити людина.
7. /spec-check сверяет сборку с реальностью и ставит итоговый статус: Verified, Partial или Broken (с передачей хода /spec-fix), либо BlockNeedUserTest, пока открыт ручной сигнал. Для проверки руками выполните ручной тест (или /prove, если агент может добраться до цели), отметьте каждый пункт ## Manual checks с тем, что вы увидели, и снова запустите /spec-check, чтобы дойти до Verified./spec-check audits the build against reality and sets the final status: Verified, Partial or Broken (chaining to /spec-fix), or BlockNeedUserTest while a manual signal is open. For a hands-on check, do the manual test (or /prove it where the agent can reach the target), tick each ## Manual checks line with what you saw, then run /spec-check again to reach Verified./spec-check звіряє збірку з реальністю й ставить підсумковий статус: Verified, Partial або Broken (з передачею ходу /spec-fix), чи BlockNeedUserTest, поки відкритий ручний сигнал. Для перевірки руками виконайте ручний тест (або /prove, якщо агент може дістатися цілі), позначте кожен пункт ## Manual checks із тим, що ви побачили, і знову запустіть /spec-check, щоб дійти до Verified.

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

• ТикетTicketТікет
• СтатусStatusСтатус
• Лестница проверокValidation ladderДрабина перевірок