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) Runs a hard buyer-persona roleplay to pressure-test a sales pitch, message, or positioning. Impersonates a skeptical buyer (provided by the user, or chosen as the strongest skeptic from a prior business-review / personas doc) and forces the seller to earn every step — demanding numbers, proof, differentiation, and pricing logic. After every in-character reply, returns a coaching block covering what landed, what missed, which objection was triggered, hidden buying signals, and what to do next. Saves the full transcript and lessons to `docs/ROLEPLAY_NOTES.md` when the session ends. Use whenever the user asks to roleplay a buyer, simulate a sales call, practice a pitch, pressure-test their messaging, or run a "tough customer" / "skeptical investor" / "objection drill" exercise.