Плагин Pragma ведёт фичу в iOS от идеи до релиза

Pragma, набор из 15 команд Claude Code для разработки под iOS, оставляет инженеру два ручных одобрения на фичу: после /spec и после /plan. Остальные шаги ведут агентские команды и три сценария GitHub Actions, следует из описания в репозитории проекта на Github.

Коротко

• Установка идёт как плагин внутри Claude Code, команда /pragma:init MyApp копирует команды, файлы контекста, сценарии CI и вспомогательные скрипты в репозиторий и подставляет имя приложения по всему набору файлов.
• Проверки идут в два круга: локальные /gates и /review перед PR, затем те же условия независимо повторяет CI, где для тестов задан порог покрытия не ниже 60 процентов, а предупреждение выдаётся при значении ниже 80.
• Контекст между сессиями хранится в четырёх файлах .claude/context, где записаны нерушимые правила, принятые решения, журнал фич и отклонённые подходы, поэтому конец диалога не обнуляет накопленное.

Ставка здесь не на генерацию кода, а на слой принуждения вокруг него. Судя по описанию, ценность в том, что проверки вынесены за пределы диалога с агентом: переформулировать промпт и получить зелёный результат в GitHub Actions нельзя. Для одиночного разработчика это ближе к командной бюрократии, чем к ускорению, выигрыш, вероятно, проявляется на длинной дистанции, когда объём кода перерастает то, что удерживается в одной сессии.

Агент не переходит к следующей задаче, пока тесты красные

/spec предлагает 2–3 подхода на выбор и сохраняет спецификацию, /plan превращает утверждённый документ в план по задачам. После одобрения обоих /feature исполняет план: сначала падающий тест, затем минимальная реализация, затем прогон всего набора тестов и один коммит на задачу. К следующей задаче агент не переходит, пока тесты красные.

/gates проверяет сборку, полный набор тестов и соответствие архитектуре до открытия PR, отслеживая в том числе TODO и FIXME, имена веток, CHANGELOG и разрастание абстракций. /review публикует вердикт как обычное ревью на GitHub, /test пишет тесты после вердикта APPROVED, а /pr-followup сцепляет обе команды сразу после открытия PR.

Отдельные ветки покрывают починку и выпуск: /bugfix сначала пишет регрессионный тест и только потом правит код, а /release 1.0.0 поднимает версию, обновляет changelog, открывает PR в main и ставит git-тег. Утилиты вроде /status и /trim-context восстанавливают состояние работы и подчищают накопленный контекст.

Три сценария GitHub Actions повторяют локальные проверки независимо от агента

pr-checks.yml запускается на PR в develop или main и прогоняет модульные и интеграционные тесты с требованием покрытия не ниже 60 процентов и предупреждением при значении ниже 80. ui-tests.yml срабатывает на тех же PR и на пуш в обе ветки и запускает тесты интерфейса приложения.

release.yml привязан к пушу тега вида v*.*.*: прогоняет полный набор тестов в конфигурации Release и создаёт GitHub Release. Вспомогательные скрипты из каталога scripts отвечают за выбор симулятора и контроль покрытия в CI. Все три слоя, команды, CI и скрипты, независимы, набор можно взять целиком или ограничиться командами.

Ветвление задано по gitflow: main тегируется только на релизе, develop собирает фичи, ветки feature/, fix/ и spec/ отходят от develop, hotfix/ от main, а release/ уходит в main с обратным вливанием в develop. Под свой проект набор настраивается заменой имени модуля в файлах команд и полей YOUR_PROJECT и YOUR_SCHEME в трёх сценариях.

Конвейер обкатан на FinanceTracker с 94 смерженными PR

Речь о приложении на SwiftUI и SwiftData, которое, как пишет автор, с первого коммита строилось по этой схеме: 94 смерженных PR, спецификации и планы предшествуют каждой фиче, скриншоты собраны в README приложения. Автор проекта, Akshay Pimprikar, работает ведущим инженером по iOS.

Память конвейера лежит в .claude/context: invariants.md с правилами, которые агент не вправе нарушить, decisions.md с выбранным подходом и причиной по каждой спецификации, feature-log.md с перечнем выпущенных фич и rejections.md с отвергнутыми вариантами. При установке скриптом scripts/setup.sh CLAUDE.md и invariants.md остаются шаблонами, а /pragma:init опрашивает разработчика об архитектуре и ключевых ограничениях и заполняет их по ответам. Заполнить invariants.md нужно до первого запуска /feature.

По умолчанию набор рассчитан на MVVM с репозиториями, SwiftData для хранения, Swift Testing для модульных и интеграционных тестов и XCUITest для интерфейсных, а также на синхронизируемые группы файлов Xcode 16 с запретом на правку project.pbxproj. Значения переопределяются в CLAUDE.md.

Чего пока нет в release.yml

Выгрузка в TestFlight описана в release.yml, но закомментирована: для неё нужны членство в Apple Developer Program, сертификат распространения и ключ API App Store Connect, в файле показано, что именно добавить. Сроков, когда этот шаг перестанет быть опциональным, автор не называет. Отдельно от конвейера доступен навык deterministic-pr-gates: скриптуемые проверки перед PR, где каждый шаг это реальная команда с исходом «прошло» или «не прошло», без обращения к модели за оценкой диффа.