Paseo Committee
Spin up a two-agent committee from contrasting providers to step back, run root-cause analysis, and produce a plan when you are stuck, looping, or tunnel-visioning on a hard problem.
Overview
paseo-committee is a journey-wide agent skill that forms two contrasting high-reasoning agents for root-cause analysis and planning—usable whenever a solo builder needs to step back before committing when stuck, looping,
Install
npx skills add https://github.com/getpaseo/paseo --skill paseo-committeeWhat is this skill?
- Pairs one planning/research-strength provider with one contrasting high-reasoning provider from ~/.paseo/orchestration-p
- Hard no-edits rule on every committee prompt—analysis only, no file or code changes
- Explicit trust-the-wait policy—no polling or hurry-ups while long-reasoning models run (15–30 minutes noted for GPT-5.4-
- Committee may propose a completely different approach instead of doubling down on the current path
- Requires reading the parent paseo skill before forming members; agents stay alive for review after implementation
- 2 committee members with deliberate provider contrast
- Mandatory no-edits suffix on every committee prompt
Adoption & trust: 1.2k installs on skills.sh; 8k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are repeating the same fix, narrowing on one hypothesis, or cannot see a credible plan for a hard problem with a single agent thread.
Who is it for?
Solo builders already using Paseo who want a structured dual-agent planning session with enforced analysis-only guardrails and configurable provider contrast.
Skip if: Quick one-shot code edits, tasks that need immediate file changes, or teams that will not read orchestration preferences or the parent paseo skill first.
When should I use this skill?
Use when stuck, looping, tunnel-visioning, or facing a hard planning problem; user-invocable with optional $ARGUMENTS context.
What do I get? / Deliverables
You get a parallel, provider-contrasted analysis plan without accidental repo edits, with optional post-implementation review from the same committee members.
- Parallel analysis and plan from two committee members
- Optional post-implementation review with the same agents
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Committee reframes MVP scope when you keep adding features instead of proving one hypothesis.
Two providers disagree on integration architecture so you pick a plan before writing more glue code.
Pre-launch review stays analytical while committee compares release-risk narratives without touching the repo.
Production incident loops on symptoms until committee runs structured root-cause analysis.
Recurring user-reported bugs get a step-back plan instead of another hotfix thread.
How it compares
Use instead of asking one model to “try harder”—this is a deliberate multi-provider committee ritual, not a generic chain-of-thought prompt.
Common Questions / FAQ
Who is paseo-committee for?
Indie and solo builders orchestrating multiple AI coding agents through Paseo who need a formal committee when progress stalls on planning or debugging-style reasoning problems.
When should I use paseo-committee?
Whenever you are stuck, looping, tunnel-visioning, or facing a hard planning problem—in Validate while scoping, in Build while designing integrations or agent flows, in Ship when launch prep feels blocked, or in Operate when production issues need root-cause thinking before more
Is paseo-committee safe to install?
The skill itself mandates analysis-only prompts with no file edits; review the Security Audits panel on this Prism page and your orchestration config before enabling multi-agent runs that may use network-backed providers.
Workflow Chain
Requires first: paseo
SKILL.md
READMESKILL.md - Paseo Committee
# Committee Skill Two agents from contrasting providers, fresh context, planning a solution in parallel. They stay alive for review after implementation. The purpose is to step back, not double down. The committee may propose a completely different approach. **User's additional context:** $ARGUMENTS ## Prerequisites Read the **paseo** skill. Before choosing committee members, read `~/.paseo/orchestration-preferences.json` unless the user explicitly named providers in this request. Do not create committee agents until you have read it. Contrast is the point of a committee, so pick across providers deliberately using the configured preferences rather than hardcoded defaults. ## Composition Two members with different reasoning styles, selected from orchestration preferences: - one planning/research-strength provider - one contrasting high-reasoning provider Override only when the user explicitly asks for different members. ## Hard rules - **No edits.** Every prompt to a committee member ends with the no-edits suffix: ``` This is analysis only. Do NOT edit, create, or delete any files. Do NOT write code. ``` - **Trust the wait.** Do not poll, send hurry-ups, or interrupt. GPT-5.4 can reason 15–30 minutes; Opus does extended thinking. Long waits mean it found something worth thinking about. - **You are the middleman.** Drive plan → implement → review without yielding to the user, except for divergences that need their call. ## Phase 1: Plan Write a problem-level prompt: - High-level goal and acceptance criteria - Constraints - Symptoms (if a bug) - What you tried and why it failed - Explicit: "do root cause analysis" - Explicit: "state assumptions, ask why three levels deep, check whether you're patching a symptom or removing the problem" Create both agents in parallel via Paseo with `[Committee] <task>` titles and the same prompt. Wait for both — not just whichever finishes first. Read both responses. Challenge them — do not accept at face value: - "Why does <underlying thing> happen? Symptom or cause?" - Verify any assumption the plan makes about the code. - "What did you considered and reject?" Send follow-ups until the plan addresses root cause. Synthesize: - Convergence → unified plan. - Significant divergence → involve the user. Confirm the merged plan with both members. Multi-turn until consensus. ## Phase 2: Implement Default: implement yourself. If the user said **"delegate"**, launch one impl agent and pass the merged plan. The committee stays clean — not involved in implementation. ## Phase 3: Review Send the diff to the committee: > Implementation is done. Review changes against the plan. Flag drift or missing pieces. <no-edits suffix> Apply feedback yourself, or send to the impl agent. Repeat 2 → 3 until consensus. After ~10 iterations without convergence, start a fresh committee with the full history of what was tried — the current committee's context may have drifted too far.