If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/uraimo/Awesome-Swift-Playgrounds shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 5w ago
• 29+ active contributors
• Other licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 68% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live uraimo/Awesome-Swift-Playgrounds repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/uraimo/Awesome-Swift-Playgrounds.

What it runs against: a local clone of uraimo/Awesome-Swift-Playgrounds — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in uraimo/Awesome-Swift-Playgrounds | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 68 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of uraimo/Awesome-Swift-Playgrounds. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/uraimo/Awesome-Swift-Playgrounds.git
#   cd Awesome-Swift-Playgrounds
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of uraimo/Awesome-Swift-Playgrounds and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "uraimo/Awesome-Swift-Playgrounds(\\.git)?\\b" \\
  && ok "origin remote is uraimo/Awesome-Swift-Playgrounds" \\
  || miss "origin remote is not uraimo/Awesome-Swift-Playgrounds (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 68 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~38d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/uraimo/Awesome-Swift-Playgrounds"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Awesome-Swift-Playgrounds is a curated directory of 156+ Swift interactive playgrounds organized by topic, maintained as Git submodules in the playgrounds/ directory. It solves the problem of discovering quality, functional Swift learning resources by collecting and cataloging playgrounds from the community across categories like algorithms, UIKit, graphics, audio, and machine learning. Flat directory structure: playgrounds/ contains 60+ subdirectories named after contributors (e.g., playgrounds/BradLarson/, playgrounds/FlexMonkey/), each holding one or more playground submodules. Top-level metadata lives in README.md (organized by category tags), playgrounds.swift (likely a data file for parsing), and .github/PULL_REQUEST_TEMPLATE for governance. No build artifacts or compiled code—pure source indexing.

Swift learners and educators who want to explore interactive code examples without building from scratch; developers preparing for WWDC scholarships; instructors curating Swift curriculum materials.

Moderately mature: the repo has 156 indexed playgrounds, uses CI via .travis.yml, and maintains active contribution guidelines in CONTRIBUTING.md. However, the project appears to be a curation list rather than an actively developed library, with updates driven by community PRs rather than core feature work. It's stable and reliable for discovery, but not high-velocity development.

Low technical risk: this is a metadata/index project, not a library with runtime dependencies. Primary risks are submodule drift (playgrounds in playgrounds/*/ directories may become unmaintained upstream) and compatibility lag—the README notes many playgrounds target Swift 3, which is outdated. Single-maintainer burden on curation and testing compatibility across Xcode versions.

Activity is organic and PR-driven: contributors submit new playgrounds or improvements via the CONTRIBUTING.md guidelines, reviewed by the maintainer. No visible active development branch or major features—the project evolves through incremental additions to the curated list and submodule updates.

git clone --recursive https://github.com/uraimo/Awesome-Swift-Playgrounds.git
cd Awesome-Swift-Playgrounds
# Or if you cloned without --recursive:
git submodule update --init

Then open any .playground file in the subdirectories with Xcode.

Daily commands: Not applicable—this is a curation repository, not executable code. To use playgrounds: clone as above, navigate to playgrounds/<contributor>/<playground>.playground, and open with Xcode (double-click or right-click → Open With → Xcode).

• README.md: Master index organized by category with tags; all playground links, descriptions, and contribution guidelines live here
• .gitmodules: Defines all submodule references to playgrounds in playgrounds/* directories; critical for git clone --recursive to work
• CONTRIBUTING.md: Defines contribution workflow and vetting criteria for new playground submissions
• .github/PULL_REQUEST_TEMPLATE: Standardizes PR format for contributors adding or updating playgrounds
• playgrounds.swift: Likely a structured data export or parser for the playground catalog; check if this feeds automated tools or validation
• .travis.yml: CI configuration; defines tests/checks run on PRs (likely validates submodule integrity or README syntax)

For adding/updating playgrounds: edit README.md to add a link and category tag in the appropriate section (e.g., under ### UIKit And Graphics), commit as a submodule addition in .gitmodules, and submit a PR. For curating existing entries: verify playground runs in current Xcode, update compatibility tag (🍁 Swift 4+, ⏳ pre-Swift 3), and PR the README change.

Submodule update footguns: forgetting --recursive on first clone leaves playgrounds/ empty; git submodule update --init is required if you clone without it. Swift version drift: many playgrounds predate Swift 4; Xcode version constraints are implicit (no swift-version file). Broken upstream playgrounds: if a submodule playground is deleted upstream, it breaks the index and requires manual cleanup. No automated CI that validates each playground still compiles in current Xcode.

• Git Submodules — This entire repo is structured around submodules; understanding git submodule update --init and .gitmodules is essential to clone and manage the 60+ playground repositories
• Swift Playground Format — Playground directories (.playground, .playgroundbook) are Xcode's native interactive development format; knowing their structure (Sources/, Resources/, contents.xcplayground) is needed to author or debug entries
• Semantic Versioning of Swift Language — Playgrounds are tagged by Swift version (Swift 3, Swift 4+, pre-3); understanding breaking changes between versions (e.g., protocol syntax, Collection APIs) is critical for curation and compatibility testing
• CI/CD for Metadata Validation — .travis.yml runs checks on this repo; understanding how CI can validate README structure, submodule health, and link integrity helps maintain the curated list
• Xcode Build System and Target Dependencies — Many playgrounds embed frameworks (UIKit, SpriteKit, CoreImage, Metal) as implicit dependencies; knowing how Xcode resolves and links these in playground context is key to troubleshooting broken entries

• apple/swift-playground-pages — Official Apple repository for Swift Playground book authoring tools; relevant for understanding .playground format and PlaygroundBook structure used by some entries
• wwdc/swift-student-challenge — Mirrors the WWDC student submissions referenced in this repo's top section; complementary source of curated playgrounds for scholarship applicants
• swift-lang/swift — The Swift language repository; essential context for understanding Swift version compatibility (3, 4, 5+) tags used throughout this curation
• Alamofire/Alamofire — High-quality Swift networking library often used in playgrounds; representative of polished playground-friendly codebases referenced in this list
• realm/realm-swift — Example of a mature Swift framework with playground examples; many curated playgrounds depend on or reference Realm patterns

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create automated submodule validation workflow in .github/workflows/

The repo contains 150+ playgrounds as git submodules in playgrounds/ directory. Many may have broken links, outdated Swift versions, or removed repositories. A GitHub Actions workflow could periodically validate that each submodule in .gitmodules still exists, is accessible, and clones successfully. This prevents stale references from accumulating.

• [ ] Create .github/workflows/validate-submodules.yml with a job that parses .gitmodules
• [ ] Add logic to test-clone each submodule URL to verify accessibility
• [ ] Set workflow to run on schedule (weekly) and on pull requests modifying .gitmodules
• [ ] Report broken submodules as workflow annotations or PR comments

Add Swift version compatibility matrix to README and create PLAYGROUND_TEMPLATE.md

The README states 'all playgrounds are compatible with Swift 3' but the repo clearly has 150+ entries spanning many years. Xcode versions and Swift compatibility vary significantly. Create a standardized template and guidance document so new playground submissions include Swift version metadata, allowing better curation and filtering.

• [ ] Create PLAYGROUND_TEMPLATE.md with required metadata fields (Swift version, Xcode version, category, description)
• [ ] Update CONTRIBUTING.md to reference this template and require version info in submissions
• [ ] Add a compatibility key to each submodule entry or create a playgrounds.json data file with version info
• [ ] Update README.md with a 'Compatibility' section showing version distribution across the 156 playgrounds

Implement playgrounds.swift code generation from structured data source

The playgrounds.swift file appears to be a generated index, but there's no visible build process or automation. Instead of manually maintaining this file alongside .gitmodules, create a script that auto-generates it from a canonical data source (YAML/JSON) to prevent drift and ensure the badge count (156) stays accurate.

• [ ] Create a playgrounds-data.yml or playgrounds.json file with structured metadata (title, author, folder, description, swift_version)
• [ ] Write a Python/Swift script in scripts/ or as a GitHub Action that generates playgrounds.swift from this data file
• [ ] Add validation to ensure .gitmodules entries match the data file
• [ ] Add this generation step to CONTRIBUTING.md so contributors know to update the data file, not playgrounds.swift directly

• Add a Swift version compatibility check script: create a shell/Swift script in the root that iterates playgrounds/ and reports which .playground files compile/run in the current Xcode version, then flag pre-Swift 3 entries for the contributor to update the tag in README.md.
• Audit and update the ⏳ Pre-Swift 3 Playground tagged entries in README.md: pick 5 older playgrounds (e.g., from playgrounds/FlexMonkey/ or playgrounds/MacMark/), test in current Xcode, update or remove entries if they no longer compile, submit a PR with test results.
• Create a PLAYGROUNDS_INDEX.json file: parse README.md category structure and export to structured JSON (name, author, category, tags, URL) to enable automated tooling and validation; add a simple script to regenerate this on each PR to catch README formatting issues.

This is a curated collection repository with minimal security risk. It is primarily a list aggregator of Swift playgrounds with no executable code, dependencies, or infrastructure components of its own. The main security considerations are related to the integrity of external submodule sources and ensuring no sensitive data is accidentally included in any referenced playground files. No hardcoded secrets, injection vulnerabilities, or misconfigured infrastructure were detected. The repository follows good practices by having CONTRIBUTING.md guidelines and clear documentation.

• Low · Use of Git Submodules Without Integrity Verification — .gitmodules, playgrounds/ directory. The repository uses git submodules to manage external playground repositories (.gitmodules file present). Without additional verification mechanisms, this could potentially allow supply chain attacks if upstream repositories are compromised. No evidence of submodule pinning to specific commits with signature verification was found. Fix: Ensure all submodules reference specific commit hashes rather than branches. Consider implementing signed commits and verifying GPG signatures for critical dependencies. Document the verification process in CONTRIBUTING.md.
• Low · Potential Information Disclosure via Directory Listing — playgrounds/ directory and all subdirectories. The extensive directory structure with 100+ playground directories is publicly accessible. While not inherently a vulnerability, this exposes the complete structure of all included playgrounds, which could aid attackers in identifying specific projects to target. Fix: No action required if intentional. This is consistent with a curated public collection. Ensure sensitive data is not included in any playground files.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.