skills

(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 test until green. Same skill when they hand over a 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 (API, web, mobile), or 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, git chores like rebases and merge conflicts, or scoping a standalone time-boxed spike whose output is an answer, not shipped code.

(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) 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) 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) 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.

(alamops) Drafts a Product Requirements Document (PRD) from any combination of inputs — a written description, the conversation, supporting media, a few provided files, linked docs/tickets, or a whole repository (either as enrichment or as the primary source when reverse-engineering existing code). Acts as a senior CPO collaborator who surfaces unknowns as clarifying questions before writing, then produces a Markdown PRD covering problem, goals, personas, functional and non-functional requirements, timeline, success metrics, risks, blast radius, stakeholders, appendices, and glossary. Saves to `docs/<unique-name>.md` without modifying code. Use whenever the user asks to create, write, draft, generate, or reverse-engineer a PRD, product spec, product requirements doc, or feature brief.