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/EmergeTools/Pow 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.

GO — Healthy across the board

• Last commit 4w ago
• 11 active contributors
• Distributed ownership (top contributor 39% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{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 EmergeTools/Pow repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/EmergeTools/Pow.

What it runs against: a local clone of EmergeTools/Pow — 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 EmergeTools/Pow | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 57 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of EmergeTools/Pow. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/EmergeTools/Pow.git
#   cd Pow
#
# 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 EmergeTools/Pow and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "Example/Pow Example/PowExampleApp.swift" \\
  && ok "Example/Pow Example/PowExampleApp.swift" \\
  || miss "missing critical file: Example/Pow Example/PowExampleApp.swift"
test -f "Example/Pow Example/ExampleList.swift" \\
  && ok "Example/Pow Example/ExampleList.swift" \\
  || miss "missing critical file: Example/Pow Example/ExampleList.swift"
test -f "Example/Pow Example/Examples/Example.swift" \\
  && ok "Example/Pow Example/Examples/Example.swift" \\
  || miss "missing critical file: Example/Pow Example/Examples/Example.swift"
test -f ".github/workflows/build.yml" \\
  && ok ".github/workflows/build.yml" \\
  || miss "missing critical file: .github/workflows/build.yml"
test -f "0.x.x to 1.0.0 Update Guide/README.md" \\
  && ok "0.x.x to 1.0.0 Update Guide/README.md" \\
  || miss "missing critical file: 0.x.x to 1.0.0 Update Guide/README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 57 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~27d)"
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/EmergeTools/Pow"
  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).

Pow is a Swift Package that provides reusable SwiftUI visual effects and transitions—including changes effects (animations that trigger on value updates), transitions (entrance/exit animations), and haptic feedback. It solves the problem of building delightful, polished animations in SwiftUI without writing custom modifier code for common patterns like jump, pulse, shake, glow, spray, and anvil transitions. Package-based monorepo: Sources/Pow/ contains effect implementations (modifiers for change effects and transitions), Example/ contains a full Xcode project demonstrating all effects organized into folders (Change Effects, Conditional Effects, Transitions, Screens), and .github/workflows/ manages CI. Effects are exposed as SwiftUI view modifiers (.changeEffect, transition-based APIs).

iOS/macOS app developers building SwiftUI interfaces who want to add sophisticated visual polish (animations, particle effects, haptics) to buttons, state changes, and screen transitions without implementing animation primitives from scratch. Also used by designers and developers at Emerge Tools to showcase performance-conscious effects.

Production-ready and actively maintained. The library has transitioned from closed-source to open-source (v1.0.0), includes a comprehensive example app, multi-platform support (iOS 15+, macOS 12+, visionOS), documented migration guide, and CI/CD pipeline via GitHub Actions. The codebase is substantial (~413K Swift lines) with clear module structure.

Low-risk for adoption. The project is maintained by Emerge Tools (a reputable iOS tooling company), has a single clear dependency vector (SwiftUI/Foundation), and includes explicit platform version requirements. Main risk: the open-source transition happened at v1.0.0, so breaking API changes should be minimal going forward. No test files visible in the provided structure is a minor quality gap.

The project recently completed its v0.x.x to v1.0.0 transition (evidenced by the migration guide directory), open-sourced the codebase on GitHub, and is maintaining it with CI/CD checks on pull requests. Current focus appears to be stabilizing the public API post-open-source and supporting multiple platforms including the new visionOS.

Clone the repository and open the example app: git clone https://github.com/EmergeTools/Pow.git && cd Pow/Example && open 'Pow Example.xcodeproj'. To use Pow in your own project, add it via Xcode's File > Add Package dialog with URL https://github.com/EmergeTools/Pow, or add .package(url: "https://github.com/EmergeTools/Pow", from: Version(1, 0, 0)) to your Package.swift.

Daily commands: Open Example/Pow Example.xcodeproj in Xcode and run the scheme "Pow Example" on iOS 15+ simulator or device. The example app auto-displays all effects categorized in ExampleList.swift. To integrate into your project: import Pow and use .changeEffect(.spray { ... }, value: someValue) or .transition(.anvil) on views.

• Example/Pow Example/PowExampleApp.swift — Entry point for the example app demonstrating all Pow effects; shows integration patterns for SwiftUI effects
• Example/Pow Example/ExampleList.swift — Central hub organizing all effect categories (Change Effects, Conditional Effects, Transitions); guides developers through available APIs
• Example/Pow Example/Examples/Example.swift — Base protocol/component for all effect examples; defines the canonical pattern for demonstrating Pow effects
• .github/workflows/build.yml — CI/CD pipeline configuration; shows how the library is tested and built automatically
• 0.x.x to 1.0.0 Update Guide/README.md — Major version migration guide documenting breaking changes and API redesigns; essential for understanding architectural evolution

• Example App (PowExampleApp.swift) (SwiftUI, NavigationStack/NavigationView) — Navigation root; coordinates display of example list and individual effect demonstrations
  • Failure mode: App fails to launch or navigation breaks; users cannot browse effects
• Example Protocol & Templates — Establishes canonical pattern for effect demonstrations; ensures consistency across 40+ examples

Add a new Change Effect example

1. Create a new Swift file in Example/Pow Example/Examples/Change Effects/ following the pattern of existing examples (e.g., GlowExample.swift) (Example/Pow Example/Examples/Change Effects/NewEffectExample.swift)
2. Define a struct conforming to the Example protocol with @State for trigger state and a preview section (Example/Pow Example/Examples/Example.swift)
3. Add the example to the ExampleList.swift switch statement under the appropriate category (Example/Pow Example/ExampleList.swift)

Add a new Transition effect example

1. Create a new Swift file in Example/Pow Example/Examples/Transitions/ (e.g., MyTransitionExample.swift) (Example/Pow Example/Examples/Transitions/MyTransitionExample.swift)
2. Implement Example protocol with @State to toggle view visibility and apply .transition() modifier (Example/Pow Example/Examples/Example.swift)
3. Register the example in ExampleList.swift transitions case statement (Example/Pow Example/ExampleList.swift)

Add audio feedback to an effect

1. Add a new .m4a audio file to Example/Pow Example/Sounds/ directory (Example/Pow Example/Sounds/newsound.m4a)
2. Reference the sound in your effect example using the existing sound loading pattern from SoundEffectsExample.swift (Example/Pow Example/Examples/Change Effects/SoundEffectsExample.swift)
3. Trigger audio playback synchronously with the visual effect animation (Example/Pow Example/Examples/Change Effects/SoundEffectsExample.swift)

Create a new complex screen example

1. Create a new file in Example/Pow Example/Examples/Screens/ (e.g., MyScreenExample.swift) (Example/Pow Example/Examples/Screens/MyScreenExample.swift)
2. Build a full layout combining multiple effects from Change Effects and Transitions folders (Example/Pow Example/Examples/Screens/CheckoutExample.swift)
3. Add to ExampleList.swift under screens section (Example/Pow Example/ExampleList.swift)

• SwiftUI — Modern declarative UI framework native to iOS; provides view modifiers for composable animations and transitions
• ViewModifier protocol — Core SwiftUI pattern for wrapping views with effects; allows easy composition of multiple animations on single views
• AVFoundation/AudioToolbox — Enables synchronized sound effects with visual animations for multisensory feedback
• Xcode Package Manager — Simplifies distribution and dependency management for Swift packages across projects

• Effect examples organized by category (Change, Transition, Conditional) rather than by target view type

  • Why: Mirrors the conceptual organization of Pow library itself; easier to discover related effects
  • Consequence: Developers must understand animation categories to find relevant examples; may require browsing multiple examples

• Single example app bundled in the repository rather than separate documentation site

  • Why: Ensures examples stay synchronized with library versions; provides runnable reference implementation
  • Consequence: Documentation is code-based; requires running Xcode to explore effects interactively

• Sound effects stored as .m4a files rather than generated programmatically

  • Why: Provides high-quality, pre-optimized audio feedback; simpler integration into SwiftUI
  • Consequence: Larger app bundle size; less flexibility for dynamic sound generation

• Does not provide real-time effect parameter tuning UI (effects are pre-configured examples)
• Not a comprehensive animation framework (focused on delightful micro-interactions, not complex orchestrated sequences)
• Does not support Android or cross-platform development
• Not designed for game development or physics-based animations
• Does not include performance profiling or memory analysis tools

The library transitioned from closed-source to open-source at v1.0.0, so if you're migrating from an older paid version, consult the Update Guide carefully—API and naming may have changed significantly. No test suite is visible in the provided structure, so effects reliability depends on the example app demos and user feedback. The library uses @State/@Binding observation, so change effects may not fire for all value change patterns (e.g., if using computed properties without proper state invalidation).

• SwiftUI View Modifiers & Composition — Pow's entire architecture is built on stacking modifiers (.changeEffect, .transition); understanding modifier chaining and when they apply is essential to using Pow correctly
• Change Detection via @State & @Binding — Change effects rely on SwiftUI's state invalidation mechanism to trigger; knowing how @State changes propagate determines when effects fire
• Core Animation Timing & Curves — Pow effects use CABasicAnimation primitives under the hood; understanding duration, delay, easing (linear, easeInOut) helps predict effect behavior and customize timing
• Particle Effects & Emitter Pattern — Effects like .spray() emit multiple animated particles; the emitter pattern and particle lifecycle management is core to Pow's visual complexity
• Haptic Feedback Integration — Some Pow effects include haptic responses (e.g., impact, notification); knowing when and how to trigger haptics via CHHapticEngine elevates perceived quality
• SwiftUI Transition Protocol & Custom Transitions — Transition effects (Anvil, Blinds, etc.) implement SwiftUI's custom transition API; understanding insertion/removal phases is needed to extend or debug transitions

• pointfreeco/swift-composable-architecture — Complementary state management for SwiftUI apps that use Pow effects; TCA users often pair complex animations with Redux-like state
• airbnb/lottie-ios — Alternative animation approach for SwiftUI using Lottie JSON files; Pow targets simpler built-in effects while Lottie handles complex motion graphics
• EmergeTools/Emerge — Companion tool by same maintainers; provides performance profiling for apps using Pow effects to ensure animations don't degrade startup time

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.

Add comprehensive unit tests for all effect modifiers in Sources/Pow

The repo contains many SwiftUI effect modifiers (Jump, Ping, Pulse, Rise, Shake, Shine, Spin, Spray, Glow, etc.) demonstrated in Example/Pow Example/Examples but there is no visible Tests directory. Adding XCTest cases for each effect modifier would ensure correctness, prevent regressions, and serve as executable documentation for how each effect behaves programmatically.

• [ ] Create Tests directory structure mirroring Sources/Pow organization
• [ ] Add unit tests for Change Effects (Jump, Ping, Pulse, Rise, Shake, Shine, Spin, Spray, Glow modifiers)
• [ ] Add unit tests for Conditional Effects (PushDown, Repeat, Smoke modifiers)
• [ ] Add unit tests for Transition effects (Anvil, Blinds, Blur, Boing, Clock, FilmExposure, Flicker, Flip, Glare, Iris, Move, Poof, Pop, Skid, Snapshot, Swoosh, Vanish, Wipe)
• [ ] Configure .github/workflows/build.yml to run tests on every push/PR

Create API documentation for SwiftUI modifiers using DocC

With 20+ effect modifiers across the library, contributors and users need clear documentation on parameters, behavior, and usage. The repo lacks .swift documentation comments and DocC support. Adding comprehensive documentation would improve discoverability and reduce support burden.

• [ ] Add documentation comments (///) to all public effect modifier functions in Sources/Pow
• [ ] Document each modifier's parameters, return value, and availability
• [ ] Create a Sources/Pow/Pow.docc/Pow.md overview page with categorized effect examples
• [ ] Add DocC tutorials for Change Effects, Conditional Effects, and Transitions folders
• [ ] Configure build.yml to generate and validate DocC on CI

Add iOS target version tests in CI workflow

The README shows Swift Package Index badges indicating support for multiple platforms and Swift versions, but .github/workflows/build.yml visibility is limited. The library likely needs validation across minimum supported iOS versions (especially with the 0.x.x to 1.0.0 Update Guide suggesting breaking changes). Add explicit version testing to catch compatibility regressions.

• [ ] Review current build.yml to identify what iOS/Swift versions are tested
• [ ] Add matrix testing for minimum supported iOS version (e.g., iOS 14+) and latest stable versions
• [ ] Add matrix testing for Swift 5.5+ versions mentioned in Package.swift
• [ ] Add explicit macOS/tvOS/watchOS/visionOS target builds if supported
• [ ] Configure workflow to fail if any version combination breaks

• Add unit tests for the effect modifiers: create a Tests/ directory with XCTest cases covering each effect type (GlowEffect, ShakeEffect, etc.) to verify animation duration, scale factors, and rotation values match documented specs
• Document each effect's customization parameters: many examples in Example/Pow Example/Examples/ show .spray { symbol } or .glow() but lack inline documentation—add DocC comments to effect types explaining available parameters like duration, intensity, and color
• Expand visionOS support examples: the README mentions visionOS beta 6 support but no dedicated visionOS examples exist—add vision-specific effect demos or document platform-specific behavior in Example app

The Pow repository is a SwiftUI effects library with a strong security posture. The codebase is primarily composed of example code, asset files, and Swift source files. No critical or high-severity vulnerabilities were identified during static analysis. The project follows standard iOS/macOS development practices with proper code organization. Minor recommendations exist for enhancing security practices in CI/CD and dependency management.

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.