Version 4.5.1

.agents/skills/app-store-changelog/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: app-store-changelog
+description: Create user-facing App Store release notes by collecting and summarizing all user-impacting changes since the last git tag (or a specified ref). Use when asked to generate a comprehensive release changelog, App Store "What's New" text, or release notes based on git history or tags.
+---
+
+# App Store Changelog
+
+## Overview
+Generate a comprehensive, user-facing changelog from git history since the last tag, then translate commits into clear App Store release notes.
+
+## Workflow
+
+### 1) Collect changes
+- Run `scripts/collect_release_changes.sh` from the repo root to gather commits and touched files.
+- If needed, pass a specific tag or ref: `scripts/collect_release_changes.sh v1.2.3 HEAD`.
+- If no tags exist, the script falls back to full history.
+
+### 2) Triage for user impact
+- Scan commits and files to identify user-visible changes.
+- Group changes by theme (New, Improved, Fixed) and deduplicate overlaps.
+- Drop internal-only work (build scripts, refactors, dependency bumps, CI).
+
+### 3) Draft App Store notes
+- Write short, benefit-focused bullets for each user-facing change.
+- Use clear verbs and plain language; avoid internal jargon.
+- Prefer 5 to 10 bullets unless the user requests a different length.
+
+### 4) Validate
+- Ensure every bullet maps back to a real change in the range.
+- Check for duplicates and overly technical wording.
+- Ask for clarification if any change is ambiguous or possibly internal-only.
+
+## Output Format
+- Title (optional): "What’s New" or product name + version.
+- Bullet list only; one sentence per bullet.
+- Stick to storefront limits if the user provides one.
+
+## Resources
+- `scripts/collect_release_changes.sh`: Collect commits and touched files since last tag.
+- `references/release-notes-guidelines.md`: Language, filtering, and QA rules for App Store notes.

.agents/skills/app-store-changelog/references/release-notes-guidelines.md

@@ -0,0 +1,34 @@
+# App Store Release Notes Guidelines
+
+## Goals
+- Produce user-facing release notes that describe visible changes since the last tag.
+- Include all user-impacting changes; omit purely internal or refactor-only work.
+- Keep language plain, short, and benefit-focused.
+
+## Output Shape
+- Prefer 5 to 10 bullets total for most releases.
+- Group by theme if needed: New, Improved, Fixed.
+- Each bullet should be one sentence and start with a verb.
+- Avoid internal codenames, ticket IDs, or file paths.
+
+## Filtering Rules
+- Include: new features, UI changes, behavior changes, bug fixes users would notice, performance improvements with visible impact.
+- Exclude: refactors, dependency bumps, CI changes, developer tooling, internal logging, analytics changes unless they affect user privacy or behavior.
+- If a change is ambiguous, ask for clarification or describe it as a small improvement only if it is user-visible.
+
+## Language Guidance
+- Translate technical terms into user-facing descriptions.
+- Avoid versions of "API", "refactor", "nil", "crash log", or "dependency".
+- Prefer "Improved", "Added", "Fixed", "Updated" or action verbs like "Search", "Upload", "Sync".
+- Keep tense present or past: "Added", "Improved", "Fixed".
+
+## Examples
+- "Added account switching from the profile menu."
+- "Improved timeline loading speed on slow connections."
+- "Fixed media attachments not opening in full screen."
+
+## QA Checklist
+- Every bullet ties to a real change in the range.
+- No duplicate bullets that describe the same change.
+- No internal jargon or file paths.
+- Final list fits App Store text limits for the target storefront if provided.

.agents/skills/app-store-changelog/scripts/collect_release_changes.sh

@@ -0,0 +1,33 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+since_ref="${1:-}"
+until_ref="${2:-HEAD}"
+
+if [[ -z "${since_ref}" ]]; then
+  if git describe --tags --abbrev=0 >/dev/null 2>&1; then
+    since_ref="$(git describe --tags --abbrev=0)"
+  fi
+fi
+
+range=""
+if [[ -n "${since_ref}" ]]; then
+  range="${since_ref}..${until_ref}"
+else
+  range="${until_ref}"
+fi
+
+repo_root="$(git rev-parse --show-toplevel)"
+
+printf "Repo: %s\n" "${repo_root}"
+if [[ -n "${since_ref}" ]]; then
+  printf "Range: %s..%s\n" "${since_ref}" "${until_ref}"
+else
+  printf "Range: start..%s (no tags found)\n" "${until_ref}"
+fi
+
+printf "\n== Commits ==\n"
+git log --reverse --date=short --pretty=format:'%h|%ad|%s' ${range}
+
+printf "\n\n== Files Touched ==\n"
+git log --reverse --name-only --pretty=format:'--- %h %s' ${range} | sed '/^$/d'

.agents/skills/apple-hig-page-controls/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: apple-hig-page-controls
+description: "Apply Apple Human Interface Guidelines for page controls (dot indicators): when to use them, where to place them, how many pages are appropriate, and how to avoid common misuse. Use when building or reviewing paged UI in UIKit or SwiftUI."
+---
+
+# Apple HIG: Page Controls
+
+Use this skill when designing or reviewing a dot-style page indicator in iOS.
+
+## Source
+
+- Primary page: https://developer.apple.com/design/human-interface-guidelines/page-controls
+- Related API: https://developer.apple.com/documentation/uikit/uipagecontrol
+
+## What A Page Control Is
+
+- A page control communicates position within a flat set of peer pages.
+- It appears as equally spaced dots, with one active dot for the current page.
+- Page movement is sequential (next/previous), typically driven by swipe gestures.
+- It is not for direct random access to an arbitrary page by tapping a specific dot.
+
+## When To Use It
+
+- Use it when pages are siblings of the same content type (for example, onboarding cards or photo pages).
+- Use it when users benefit from seeing progress through a small, linear set.
+
+## When Not To Use It
+
+- Do not use it for hierarchical navigation.
+- Do not use it when users need nonsequential jumps across many items.
+
+## Quantity Guidance
+
+- Keep page counts modest.
+- Around 10+ dots becomes hard to scan quickly.
+- Around 20+ pages becomes slow to traverse linearly.
+- If page count is large, switch to a pattern that supports direct navigation (for example, grid or list).
+
+## Placement Guidance
+
+- Place the control centered near the bottom.
+- Position it between content and the bottom edge so it remains visible without obscuring key content.
+- Avoid collisions with bottom overlays (metadata chips, action buttons, toolbars, safe-area content).
+
+## Implementation Notes
+
+### UIKit
+
+- Prefer system `UIPageControl`.
+- Keep `numberOfPages` and `currentPage` synced with the paged content container.
+- If content is scroll-driven, update the current page during paging callbacks.
+
+### SwiftUI
+
+- For `TabView` with `.page`, verify indicator visibility against safe area and bottom overlays.
+- If overlap occurs, adjust surrounding layout first; replace the system indicator only if necessary.
+
+## Review Checklist
+
+- Are pages truly peers (not hierarchical)?
+- Is navigation intentionally sequential?
+- Is page count small enough for dot-based scanning?
+- Is the indicator centered and clearly visible at the bottom?
+- Does it avoid overlap with metadata/action overlays on all target devices?
+- Is the active page indicator always in sync with visible content?

.agents/skills/github/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: github
+description: "Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries."
+---
+
+# GitHub Skill
+
+Use the `gh` CLI to interact with GitHub. Always specify `--repo owner/repo` when not in a git directory, or use URLs directly.
+
+## Pull Requests
+
+Check CI status on a PR:
+```bash
+gh pr checks 55 --repo owner/repo
+```
+
+List recent workflow runs:
+```bash
+gh run list --repo owner/repo --limit 10
+```
+
+View a run and see which steps failed:
+```bash
+gh run view <run-id> --repo owner/repo
+```
+
+View logs for failed steps only:
+```bash
+gh run view <run-id> --repo owner/repo --log-failed
+```
+
+## API for Advanced Queries
+
+The `gh api` command is useful for accessing data not available through other subcommands.
+
+Get PR with specific fields:
+```bash
+gh api repos/owner/repo/pulls/55 --jq '.title, .state, .user.login'
+```
+
+## JSON Output
+
+Most commands support `--json` for structured output.  You can use `--jq` to filter:
+
+```bash
+gh issue list --repo owner/repo --json number,title --jq '.[] | "\(.number): \(.title)"'
+```