yalla-teamlisted

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.
iwo-szapar/yalla · ★ 1 · Code & Development · score 77

Install: claude install-skill iwo-szapar/yalla

# /yalla-team Use `/yalla-team` when a complex change benefits from multiple independent agents. It follows the same GitHub Issue protocol, artifact policy, merge policy, and review gates as `/yalla`. Default shipping policy: create a PR only. Do not merge unless the user explicitly approved auto-merge in this run. For non-trivial work, apply the operator-understanding protocol (see `${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/`) across planning, build summaries, review, compound, and PR output. The goal is decision-useful operator understanding, scaled by risk, not mandatory teaching theater. The orchestrator role and exact subagent prompts live in `${CLAUDE_PLUGIN_ROOT}/agents/yalla-lead.md` and `${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/TEAMMATE-PROMPTS.md`. ## Hard Rules - Canonical ID format is `issue-###`. - Do not invent a parallel ID scheme for new work; reference issues by `issue-###`. - GitHub Issues are the canonical task store. (An optional SQL task store is described in `${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/SQL-TEMPLATES.md`; only use it if `.claude/YALLA.md` sets `tracking_mode: db`.) - Creator != reviewer: the context that writes code does not do final review. ## Flow 1. Run `/yalla` Pre-Flight, Classify, and Track phases. 2. Use `${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/TEAMMATE-PROMPTS.md` for exact subagent prompts and `${CLAUDE_PLUGIN_ROOT}/agents/yalla-lead.md` for orchestration. 3. Planning: spawn codebase analyst, solution architect, spec validator, and red