alamops-skills

(alamops) Use whenever the user wants their iOS app checked against Apple's App Store Review Guidelines, or asks if Apple will reject something. Triggers — "check this against the app store guidelines", "will Apple reject this?", pre-submission audit, App Store readiness, pre-flight before TestFlight or App Store Connect upload, "why does Apple keep rejecting my app", rule compliance (3.1.1, 4.8, 5.1.1, etc.), or asking if a specific change is allowed (moving subs off IAP to Stripe/external checkout, adding analytics/tracking/attribution SDKs, social login, new permission, privacy manifest, ATT, account deletion, IAP/subscriptions). Works on any iOS-shipping codebase — native Swift/SwiftUI/UIKit/Xcode, React Native, Expo, Flutter, Capacitor/Ionic, Unity. Fetches live guidelines from developer.apple.com, then returns rejection-risk findings keyed by guideline number with severity, file:line evidence, and fixes. Read-only. Not for general bug/perf code review and not for implementing features.

(alamops) Analyzes a product/business from its public-facing materials (landing, pricing, onboarding, docs, app/UI, screenshots), separates real value from claimed value, generates 5–8 concrete buyer personas, ranks them across abundance / pain / urgency / WTP / retention / strategic leverage, recommends a primary ICP plus secondary and weak-fit segments, pressure-tests positioning and pricing against alternatives, and proposes messaging, landing-page, onboarding, demo, and product-experience improvements. Saves Markdown artifacts under `docs/` (personas, ICP analysis, positioning, product-experience). Read-only on source; prefers strategic clarity over flattery. Use when asked to analyze a business/product, generate personas, find or rank an ICP, pressure-test positioning or pricing, review a landing page or onboarding, or get a buyer-side strategic critique.

(alamops) Performs a thorough, read-only code review on any source of changes — a pull request, a git diff, uncommitted edits in the working tree, recent commits on the current branch, or code that was just produced or discussed in the conversation. Flags bugs, security issues (tenant isolation, authz gaps, atomicity, retry safety, multi-step flow completeness, RLS / row-policy self-recursion), performance issues (in-memory aggregation, sequential fan-out, partial-period comparisons), consistency issues (including schema ↔ code column-reference drift), and blast-radius gaps. Returns structured findings (category, severity, file, line, suggestion) without modifying any code. Use whenever the user asks for a code review, PR review, diff review, feedback on pending or recent changes, or a critique of code just written in this session.

(alamops) Senior Technical PM that turns a PRD, brief, ticket, or conversation into a small set of deep, end-to-end dev/QA tasks. Performs mandatory deep repo-context analysis (entry points, data models, utilities, API patterns, sibling code paths) before drafting, asks one structured pass of clarifying questions, then writes each task with problem, business rules, technical goals, dependencies, file paths, related existing code, data model, API specs, non-functional requirements, implementation guide, error handling, blast radius, testing, acceptance criteria, QA steps, and design specs. Layer-prefixed titles (`[Full-Stack]`, `[Backend+DB+Tests]`, `[Frontend+Backend+Tests]`, `[DevOps]`). No time, effort, or staffing estimates. Saves an INDEX plus one task file under `docs/tasks/<feature-slug>/`; read-only on source code. Use when asked to create, draft, scaffold, or break down dev/QA tasks, engineering tickets, sprint tasks, or implementation tickets from a PRD, spec, or feature description.

(alamops) The go-to skill for building and shipping a whole feature — not just planning, speccing, or reviewing one. Fire it whenever the user types `/implement`, `/implement <task>`, or `/implement --config`, and whenever they ask in plain words to "actually build", ship, deliver, or drive a feature from start to finish — dig through the codebase, grill them on the unknowns, write a plan, then write the code, review it, and add and run tests until green. Same skill when they hand over an existing plan or PRD and say "drive the whole implementation", when the build should fan out across parallel background agents, when one feature spans several surfaces at once (API, web, mobile), or when they just want to choose which model runs each step (model routing / agents config), even with no task attached. Skip it for a single pinpointed edit or typo, a lone code or diff review, explaining existing code, turning a PRD into tickets, or git chores like rebases and merge conflicts.