Две ручные проверки на фичу в iOS-пайплайне

Акшай Пимприкар выложил на GitHub Pragma: сборку для iOS-разработки под Claude Code, в которой человек одобряет работу дважды за фичу, после /spec и после /plan. В комплекте 15 слэш-команд, три workflow для GitHub Actions и вспомогательные скрипты; обкатку автор показывает на приложении FinanceTracker с 94 смерженными PR.

Коротко

• Ручные точки принятия решения только две: после /spec, где агент предлагает 2–3 варианта подхода, и после /plan, превращающего одобренную спецификацию в пошаговый план задач; всё остальное выполняют агенты и CI.
• Три слоя ставятся независимо: команды в .claude/commands, workflow pr-checks.yml, ui-tests.yml и release.yml в .github/workflows, скрипты выбора симулятора и контроля покрытия в scripts, поэтому можно взять весь набор или только команды.
• Проверки /gates, /review и /test идут локально до открытия PR, затем те же проверки независимо повторяются в GitHub Actions, где порог покрытия задан на уровне 60% с предупреждением ниже 80%.

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

Пайплайн собран из девяти команд основного цикла и шести утилитарных

/spec предлагает 2–3 варианта подхода и сохраняет спецификацию, /plan разбивает её на задачи, /feature выполняет план, /gates проверяет сборку, полный набор тестов и соответствие архитектуре до открытия PR, /review публикует вердикт как настоящее ревью на GitHub. /test дописывает тесты после статуса APPROVED, а /release поднимает версию, обновляет changelog и создаёт тег.

Внутри /feature каждая задача идёт по строгому TDD: сначала падающий тест, затем минимальный код, затем полный прогон набора и один коммит на задачу. При красных тестах агент не переходит к следующей задаче. Утилитарные команды закрывают побочные задачи: /design задаёт визуальные токены, /status восстанавливает состояние работы, /trim-context чистит накопленный контекст.

Автор соотносит этапы с классификацией Мартина Фаулера из эссе «Harness Engineering for Coding Agent Users»: /spec и /plan работают как направляющие до действия, /gates, /review и /test как сенсоры обратной связи, а /bugfix как контур восстановления. Сам Фаулер называет проверку поведенческой корректности нерешённой задачей.

Три workflow в GitHub Actions повторяют локальные проверки, а загрузка в TestFlight закомментирована

В проект ставятся три workflow для GitHub Actions. pr-checks.yml запускается на PR в develop или main и прогоняет модульные и интеграционные тесты с порогом покрытия 60% и предупреждением ниже 80%, а ui-tests.yml прогоняет UI-тесты и на PR, и на push в те же ветки.

Третий workflow, release.yml, реагирует на теги вида v*.*.*, прогоняет полный набор тестов в конфигурации Release и создаёт GitHub Release. Загрузка в TestFlight в нём описана, но закомментирована: для неё нужны членство в Apple Developer Program, сертификат распространения и ключ App Store Connect API.

Отдельную сборку вместо встроенных режимов планирования автор объясняет двумя пунктами: те же проверки независимо повторяются в GitHub Actions, где их нельзя пропустить повторным запуском агента с другим промптом, а контекст в .claude/context не сбрасывается на границе разговора. Встроенные режимы в Cursor, Windsurf и GitHub Copilot он называет разумным выбором по умолчанию для команд, уже работающих в этих IDE.

Память пайплайна лежит в четырёх файлах каталога .claude/context

Институциональная память пайплайна хранится в четырёх файлах каталога .claude/context: invariants.md с правилами, которые агент не вправе нарушить, decisions.md с журналом выбранных подходов и причин, feature-log.md с перечнем выпущенных фич и rejections.md с отклонёнными вариантами. Каждый агент читает эти файлы перед работой, а invariants.md требуется заполнить до первого запуска /feature.

Установка идёт двумя путями. Плагинный вариант ставится тремя командами внутри Claude Code и по ходу /pragma:init задаёт вопросы об архитектуре и ключевых ограничениях, заполняя CLAUDE.md и invariants.md. Скрипт scripts/setup.sh копирует те же файлы и подставляет имя приложения, но оставляет оба шаблона незаполненными.

По умолчанию сборка рассчитана на MVVM с репозиториями, SwiftData для хранения, Swift Testing для модульных тестов и XCUITest для UI, а также на синхронизируемые группы файлов Xcode 16, из-за которых project.pbxproj не редактируется вручную. Значения переопределяются в CLAUDE.md проекта. Ветвление построено по gitflow: feature, fix и spec отходят от develop, hotfix от main, а main тегируется только на релизе.

Обкатка на FinanceTracker и отдельный навык Работоспособность автор демонстрирует на FinanceTracker, приложении на SwiftUI и SwiftData, где спецификации и планы предшествуют каждой фиче с первого коммита, а скриншоты собраны в README. Отдельно поставляется навык deterministic-pr-gates: проверки перед PR как набор команд с однозначным исходом, без обращения к модели за оценкой диффа. Сроки дальнейших релизов Pragma не объявлены.