From yalla
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).
How this skill is triggered — by the user, by Claude, or both
Slash command
/yalla:yalla-planThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
4-agent adversarial planning. Produces a plan grounded in the actual codebase, challenged by a red-team, sliced into tracer bullets, mapped to public test seams, and approved by the user before any code is written.
4-agent adversarial planning. Produces a plan grounded in the actual codebase, challenged by a red-team, sliced into tracer bullets, mapped to public test seams, and approved by the user before any code is written.
Planning must be incident-aware without becoming a universal checklist. Identify the changed workflow's success invariant, scan prior incidents/learnings for the touched subsystem, and activate only the risk gates that match the diff.
Planning must also be operator-readable for non-trivial work. Apply the operator-understanding protocol (see ${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/) and choose light, default, or deep understanding mode based on risk. The plan should explain the business/user behavior before code details.
$REPO and $BASE_BRANCH come from .claude/YALLA.md (repo: / base_branch:), with $REPO auto-detected via gh repo view --json nameWithOwner -q .nameWithOwner when blank and $BASE_BRANCH defaulting to main.
<task_input> $ARGUMENTS </task_input>
Requires a task description. If invoked from /yalla or /yalla-team, the issue number and description are already available.
Before spawning agents, read:
.claude/YALLA.md${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/TASK-CLASSIFICATION.md${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/VERTICAL-SLICES.md${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/TEST-SEAMS.md${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/ARCHITECTURE-DEPTH.md${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/ARTIFACTS.md${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/PROJECT-CHECKS.md${CLAUDE_PLUGIN_ROOT}/knowledge/product/PRODUCT-INTENT-FRAMEWORK.md${CLAUDE_PLUGIN_ROOT}/knowledge/product/ASSUMPTION-TESTING.md${CLAUDE_PLUGIN_ROOT}/knowledge/product/INTENDED-VS-IMPLEMENTED.mdIf the task has unresolved domain language, ask one precise question at a time before final plan approval. If the task is a bug/perf regression and no .pipeline/diagnosis.json exists, run the diagnosis protocol before writing the full plan.
TeamCreate: team_name = "yalla-plan-issue-###"
| Teammate | Type | Job |
|---|---|---|
| codebase-analyst | general-purpose (sonnet) | Read .claude/YALLA.md, your conventions doc (CLAUDE.md / AGENTS.md), ${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/PROJECT-CHECKS.md, relevant docs/decisions, relevant architecture docs, affected files, and relevant docs/incidents / docs/learnings entries. Report domain terms, interfaces, seams, schemas, conventions, prior incident failure modes, and any code/doc drift. Do NOT propose solutions. |
| solution-architect | general-purpose (sonnet) | Design technical approach using deep modules and real seams. Research via WebSearch/context7. Propose interfaces, data flow, dependency strategy, vertical slices, and which architecture docs must change or stay unchanged. |
| spec-validator | general-purpose (sonnet) | Walk through as end-user. Define the success invariant, map happy, error, abuse, and edge paths, identify the most likely negative-path test, and convert behavior into testable acceptance criteria, highest correct test seams, and architecture-doc claims that need test evidence. When Product Intent applies, define the intended user/business outcome, metric/proxy, MVP boundary, and intended-vs-implemented proof needed. For features that grant access, move money, or bind identity: required to map the abuse path explicitly AND state whether a human-review gate is needed (default: yes for security-sensitive grants). |
| red-team | general-purpose (sonnet) | Challenge every assumption. Find security holes, performance issues, shallow modules, fake seams, missing repro loops, over-engineering, PRD/code/docs mismatches, and untested product assumptions. Be specific — "X will fail when Y because Z", not "this might not work". |
Read ${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/TEAMMATE-PROMPTS.md for exact spawn prompts.
Round 1 — Parallel Research: All 4 research independently. Codebase analyst scans repo. Architect proposes approach. Spec validator maps flows. Red team prepares objections.
Round 2 — Challenge: Red team challenges architect's proposal. Spec validator challenges analyst's patterns. Architect responds and iterates. All share via SendMessage.
Round 3 — Converge: Lead collects all findings. Red team does final pass on remaining risks. Lead synthesizes into unified plan.
Write to plans/active/issue-###-[slug].md, plus plans/active/issue-###.plan.json when useful for review/resume, with this structure:
# issue-###: [title]
## Problem
[What's broken or missing — grounded in codebase evidence from analyst]
## Task Classification
- Type: [tiny-hotfix|bug|perf|feature|refactor|architecture|ui-prototype|logic-prototype|docs|hotfix]
- Scope mode: [EXPANSION|HOLD|REDUCTION]
- Required gates: [diagnosis, vertical_slices, test_seams, review]
- Phase split required: [true|false and why]
- Risk tier: [low|medium|high]
- Evidence mode: [minimal|standard|strict]
- Product intent gate: [applies|n/a and why]
## Domain Language
- [Canonical project terms from your conventions doc (CLAUDE.md / AGENTS.md), .claude/YALLA.md, docs]
- Avoided terms: [if any]
## Existing Evidence
- Codebase patterns: [files/modules]
- ADRs/decisions respected: [docs/decisions/...]
- Architecture docs read: [docs/architecture/...]
- Architecture/code alignment: [aligned | docs-drift | code-drift | intentional-change-updates-docs]
- Architecture docs to update in this PR: [paths or `none`]
- Prior incidents/learnings relevant: [docs/incidents or docs/learnings]
## Architecture Alignment
- Source-of-truth docs: [`docs/architecture/...` — why each applies]
- Code sources checked: [paths]
- PRD promise: [what behavior the PRD/plan commits to]
- Alignment verdict: `aligned` | `docs-drift` | `code-drift` | `intentional-change-updates-docs`
- Required doc updates: [paths or `none`]
- Test evidence required: [which acceptance criteria prove the architecture claims]
- Review gates: [architecture-check, architecture-docs-check, doc-alignment-check as applies]
## Interfaces and Test Seams
- [Public interface] — [invariants/error modes] — [highest correct test seam]
## Approach
[Technical decisions from architect, refined after red-team challenges]
[Pseudo-code for key functions]
## Success Invariant
[From spec-validator — what must be true before the workflow can be marked successful]
## Product Intent
- Applies: [true/false and why]
- Intended outcome: [user/business outcome, not implementation output]
- Target user/context: [who this helps and when]
- Metric/proxy: [how we know it worked]
- MVP boundary: [smallest shipped slice that preserves the intent]
- Top kill-assumptions:
- [assumption] — [cheapest validation/proof]
- Intended-vs-implemented proof: [tests/evidence/review checks that prove code matches intent]
## Incident Regression Map
- Related incidents/learnings: [paths, or "none found"]
- Failure modes this PR must not repeat
- Regression guard required
## Risk-Triggered Gates
- success-invariant-check: [always]
- operator-understanding-check: [applies/N/A and why]
- async-reliability-check: [applies/N/A and why]
- schema-migration-check: [applies/N/A and why]
- identity-routing-check: [applies/N/A and why]
- payment-integrity-check: [applies/N/A and why]
- intended-vs-implemented-check: [applies/N/A and why]
- email-delivery-check: [applies/N/A and why]
- generated-artifact-check: [applies/N/A and why]
- ui-journey-check: [applies/N/A and why]
- architecture-docs-check: [applies/N/A and why]
- doc-alignment-check: [applies/N/A and why]
## Vertical Slices
### Slice 1: [demoable behavior]
Type: AFK | HITL
Blocked by: None | Slice N
User-visible outcome: [what works after this slice]
Public interface: [route/endpoint/function]
Test seam: [highest correct seam]
Acceptance criteria:
- [ ] [testable behavior]
Files likely affected:
- `path` — why
## Files Affected
[From analyst — exact paths with what changes in each]
## Operator Understanding
- **Problem in plain English:**
- **Why it existed:**
- **Solution in plain English:**
- **Key tradeoff:**
- **What this impacts:**
- **What could go wrong:**
- **How we verified it:**
- **Understanding depth:** light/default/deep
- **Teach-back needed:** yes/no/pending and why
## Acceptance Criteria
[Testable checklist — from spec validator's user flow mapping]
## Edge Cases
[From spec validator — specific scenarios, not generic "handle errors"]
## Abuse Path (REQUIRED if feature grants access, moves money, or binds identity)
[From spec validator — how a malicious actor would attempt to bypass intended controls]
[Must answer: "Does this need a human-review gate before access is granted?"]
[If yes — describe the pending-review intermediate state]
## Risks
[From red team — unresolved objections for user to decide]
[Each risk: what could go wrong + proposed mitigation or "user decides"]
## Artifact Manifest
- `plans/active/issue-###.plan.json`
- `.pipeline/architecture-alignment.json`
- `.pipeline/product-intent.json`
- `.pipeline/acceptance-trace.json`
- `.pipeline/test-evidence.json`
- `.pipeline/review-results.json`
The JSON plan must follow ${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/ARTIFACTS.md and include issue_id, task_type, phase_split_required, risk_tier, evidence_mode, domain_terms, architecture_docs, interfaces, vertical_slices, and risks.
Good:
## Risks
- **Wrong-account write:** The integration MCP connects to a test account, but the
live code path reads production keys from the local env. Using the MCP to create
records would write them to the wrong account. Mitigation: use the production key
with a direct API call instead.
- **Rate limit on webhook endpoint:** No rate limiting on the public webhook route.
An attacker could flood it. Mitigation: add an edge middleware rate limit, or accept
the risk since upstream retries are bounded.
Bad:
## Risks
- There might be some edge cases we haven't thought of
- Performance could be an issue
Send shutdown_request to all 4 teammates. Wait for confirmations. TeamDelete.
Present plan summary via AskUserQuestion:
deepLoop on Iterate until approved.
After approval:
${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/AGENT-BRIEF.md..pipeline-state.json..pipeline/acceptance-trace.json with every acceptance criterion in status: "pending".If Agent Teams fails, fall back to parallel one-shot sub-agents:
Continue from Step 3 (Write Plan).
.claude/YALLA.md, your conventions doc (CLAUDE.md / AGENTS.md), docs/decisions, or architecture docsdocs/architecture/* filenpx claudepluginhub iwo-szapar/yalla --plugin yallaProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.