yalla

onboard

Guided Yalla project onboarding. Use this skill whenever the user says /onboard, "set up yalla", "onboard this repo to yalla", "configure yalla", "show onboarding status", "what is missing for yalla", or wants a visual dashboard of Yalla setup. It checks .claude/YALLA.md, project commands, task labels, issue template, autopilot readiness, and generates an HTML dashboard showing done vs missing steps.

product-intent

Product-intent gate for non-trivial product, GTM, pricing, onboarding, user/admin journey, access, delivery, generated artifact, or workflow changes. Use before /yalla planning or inside strategy-to-build handoffs when the work needs outcome framing, load-bearing assumptions, cheapest validation, MVP scope, kill criteria, or intended-vs-implemented review. Do NOT use for tiny bugfixes, isolated tests, dependency bumps, mechanical refactors, or docs edits that do not define future product behavior.

yalla-audit

Post-mortem diagnostic on a completed /yalla or /yalla-team run. Checks issue-based artifacts, PR evidence, review quality, and shipping discipline. Use after a run produced mediocre results, after a production incident traced to a yalla-shipped change, or periodically to improve the pipeline. Do NOT use during an active run.

yalla-plan

4-agent adversarial planning with red-team. Produces a grounded plan with concrete approach, files affected, acceptance criteria, and addressed risks. Use standalone for planning without full pipeline, or invoked by /yalla and /yalla-team. Do NOT use when the task is trivial (plan directly in /yalla).

Code & Development Listed

yalla-review

Adversarial code review with binary pass/fail checks. Each reviewer answers one specific question about the code. Any Fail blocks shipping. Use standalone for reviewing changes, or invoked by /yalla and /yalla-team. Do NOT use when changes haven't been tested yet (run tests first).

yalla-simplify-audit

Whole-repo audit for avoidable complexity, dead abstractions, custom stdlib/native behavior, unnecessary dependencies, and minimum-diff opportunities. Use when the user says audit for bloat, repo simplify audit, what can we delete, or /yalla-simplify-audit.

yalla-simplify

Review the current diff only for avoidable complexity and minimum-diff violations. Finds what to delete, replace with stdlib/native/existing code, or shrink. Use when the user says simplify, over-engineered, what can we delete, minimum diff, or /yalla-simplify.

Code & Development Listed

yalla-team

Full autonomous coding team for complex changes. This is now a thin wrapper around /yalla with mandatory subagent use for planning, build/test separation, and review separation. Use only when the task is too broad or risky for a single-agent /yalla run. Uses GitHub Issues (`issue-###`) only.

Code & Development Listed

yalla

Adaptive autonomous pipeline: classify -> track -> plan -> work -> test -> review -> compound -> ship. Uses GitHub Issues as the canonical engineering task store (`issue-###`). Use when building any feature, fix, or change that needs tracking inside this repo. Do NOT use for docs/config-only changes (use /quick) or when you just need task tracking without autonomous execution (use /begin).