Two approvals per feature: Pragma's Claude Code iOS pipeline

Pragma, a scaffold published on GitHub by iOS engineer Akshay Pimprikar, installs 15 Claude Code slash commands, three GitHub Actions workflows and a persistent context directory into an iOS repository, cutting a feature down to two human approvals. It was built alongside FinanceTracker, a production SwiftUI and SwiftData app with 94 merged PRs behind it.

At a glance

• The engineer signs off after /spec proposes two or three approaches and again after /plan converts the chosen spec into tasks; /feature, /gates, /review and /test then run unattended.
• Three workflows install alongside the commands: pr-checks.yml demands unit and integration tests with coverage at or above 60% and warns below 80%, ui-tests.yml runs UI tests, release.yml fires on v*.*.* tags.
• Four files under .claude/context hold invariants, spec decisions, a feature log and rejected approaches, so constraints and dead ends survive session boundaries instead of resetting at the end of a conversation.

Spec-driven modes already ship inside Cursor, Windsurf and GitHub Copilot, so the interesting part of Pragma is not the specs but where enforcement lives. Moving the checks into GitHub Actions appears to be an answer to the obvious failure mode of agent pipelines, where a gate that only the agent enforces can be reprompted away. The cross-session context files read as the same instinct applied to memory.

A plugin install seeds CLAUDE.md, the shell script leaves it as a template

Inside Claude Code, the sequence is /plugin marketplace add akshaypimprikar/pragma, /plugin install pragma@pragma and /pragma:init MyApp. The init command copies commands, context files, CI workflows and support scripts, substitutes the app name throughout, and interviews the engineer for the architecture and key-constraints content.

The alternative is cloning the repository and running ./scripts/setup.sh with an app name and a project path. That route copies the same files but leaves CLAUDE.md and .claude/context/invariants.md as templates to fill in before /feature runs for the first time.

The three layers are independent: 15 slash commands in .claude/commands, the workflow set in scaffold/.github/workflows, and scripts handling simulator selection and coverage enforcement for CI. A standalone skill, deterministic-pr-gates, works in projects that adopt none of the rest.

GitHub Actions re-runs the checks that /gates already ran locally

pr-checks.yml and ui-tests.yml trigger on pull requests to develop or main, with ui-tests.yml also running on pushes to either branch. release.yml fires on tag pushes matching v*.*.*, runs the full suite in Release configuration and creates a GitHub Release.

/gates verifies build, test suite and architecture compliance locally before a PR opens, covering TODO and FIXME markers, branch naming, CHANGELOG entries, coverage and abstraction bloat. The same checks then re-run in Actions, where rerunning the agent with a different prompt cannot skip them.

The README maps the stages onto Martin Fowler's harness taxonomy from his April 2026 piece on harness engineering: /spec and /plan as feedforward guides, /gates, /review and /test as feedback sensors for maintainability, architecture fitness and behavioural correctness. Fowler calls that last sensor still unsolved for most agent harnesses.

Every task in a plan begins with a failing test and ends with one commit

/feature executes an approved plan task by task: write the failing test and confirm it fails for the right reason, implement the minimal code, run the full suite, then commit. The agent does not move to the next task while tests are red.

/review posts its architecture verdict as a real GitHub review, /test writes tests once that review reports APPROVED, and /pr-followup chains the two automatically after a PR opens. /bugfix writes a regression test before the fix, and /release handles the version bump, changelog, PR to main and git tag.

Defaults assume MVVM with repositories, SwiftData for persistence, Swift Testing for unit and integration tests with XCUITest for UI, and Xcode 16 synchronized file groups, so project.pbxproj is never edited. Branching follows gitflow, with spec/* branches carrying spec and plan documents.

TestFlight upload stays commented out

release.yml ships with the TestFlight upload block documented but disabled, and enabling it requires an Apple Developer Program membership, a distribution certificate and an App Store Connect API key. The commented block shows what to add, though the repository gives no timeline for turning that stage on by default. The full screenshot set for FinanceTracker sits in that project's README.