SuperAPI AI Directory

scaffold-swift-ios-quality-gates

Testing & quality

View repository

Updated 10-15 17:24

About this skill

Set up a Swift iOS quality gate

Use this skill when the user wants to design or set up a hard quality gate for a pure Swift iOS repository. Scope is limited to Swift and the Apple platform toolchain, and does not cover Kotlin Multiplatform, React Native, Flutter, or backend services.

Required reading

Before proposing changes, read these files in full:

  • ../references/three-layer-model.md
  • ../references/landing-safety.md
  • ../references/github-review-and-rulesets.md
  • ../references/invocation-examples.md
  • ../references/gate-levels-and-template.md
  • references/platform-quality-gates.md
  • references/concrete-rules.md

These paths are anchored to the directory where this skill's SKILL.md is located; after loading the skill, progressively read the corresponding materials by relative path.

Process

  1. Inspect the target repository's AGENTS.md, package management scripts, Xcode project or workspace, Swift Package Manager files, GitHub workflows, hooks, ruleset documentation, and existing lint or test configuration.
  2. Form a plan according to the three-layer structure below.
  3. If rules need to be extended or the latest rule names confirmed, first check references/concrete-rules.md 's official documentation entry point, and do not add rules from memory alone.
  4. Use ../references/gate-levels-and-template.md 's tiering table to give recommended tiers and trade-offs; do not decide the tier for the user.
  5. Stop at the confirmation-before-write gate. Show the exact files and remote settings the plan will create or modify, then request explicit approval from the user.
  6. After approval, land the narrowest but useful scaffolding, run the new local entry point, and report the GitHub settings that still require manual handling.

Layer one: inspection tools

Identify executable Swift iOS checks: build, test, format, SwiftLint, SwiftLint analyze, package dependency resolution, custom affected-check scripts, and design token or localization validators.

Layer two: inspection rules

Map each tool to the rules it enforces: code style, static analysis, module boundaries, localization completeness, design token usage, dependency hygiene, or generated file drift.

Layer three: invocation timing

Decide where checks run: local hooks provide fast feedback, pull request workflows act as the authority, required status checks block merges, scheduled workflows carry expensive regressions, and GitHub rulesets constrain review requirements.

Output form

Return a concise scaffolding plan, including:

  • the files planned to be created or modified;
  • the layer one tools table;
  • the layer two rules table;
  • the layer three invocation timing table;
  • the confirmation-before-write prompt;
  • the verification commands after implementation.