feat(desktop): auto-update bundled skills on app launch
Skills installed via Paseo desktop never updated after first run, so users were stuck on already-fixed skill content. On every launch, if the paseo base skill is present in `~/.agents/skills/`, sync each bundled skill (incl. `references/`) into agents, claude (via symlink/ junction), and codex — overwriting only files whose content differs. Files on disk that are not in the bundle are left alone; deprecation goes through tombstones (e.g. `paseo-orchestrate` redirects to `paseo-epic`). Also refreshes the bundled skill set: drops `paseo-chat`, adds `paseo-advisor` and `paseo-epic`, and turns `paseo-orchestrate` into a tombstone redirecting to `paseo-epic`. Adds a desktop test job to CI on Ubuntu and Windows so the junction/symlink path is exercised on both platforms.
This commit is contained in:
+36
-114
@@ -6,154 +6,76 @@ user-invocable: true
|
||||
|
||||
# Committee Skill
|
||||
|
||||
You are forming a committee to step back from the current problem and get fresh perspective.
|
||||
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
|
||||
|
||||
Load the **Paseo skill** first — it contains the CLI reference for all agent commands and waiting guidelines.
|
||||
Read the **paseo** skill. Contrast is the point of a committee, so pick across providers deliberately rather than using whatever the default category would resolve to.
|
||||
|
||||
## What Is a Committee
|
||||
## Composition
|
||||
|
||||
Two agents — **Opus 4.6** (`--thinking on`) and **GPT 5.4** (`--thinking medium`) — launched in parallel to plan a solution. Fresh context, no implementation baggage, proper root cause analysis.
|
||||
Two members with different reasoning styles:
|
||||
|
||||
They stay alive after planning for Phase 3 review — they hold only the plan, so they catch implementation drift.
|
||||
- **Claude Opus** with extended thinking on
|
||||
- **Codex GPT-5.4** with thinking on
|
||||
|
||||
**The purpose is to step back, not to double down.** The committee may propose a completely different approach.
|
||||
Override only when the user explicitly asks for different members.
|
||||
|
||||
## Your Role
|
||||
## Hard rules
|
||||
|
||||
You drive the full lifecycle: plan → implement → review. You are a middleman between the user and the committee. Do not yield back to the user until the cycle is complete. If the user needs to weigh in on a divergence, ask them — but don't stop the process.
|
||||
- **No edits.** Every prompt to a committee member ends with the no-edits suffix:
|
||||
|
||||
## No Anxiety
|
||||
```
|
||||
This is analysis only. Do NOT edit, create, or delete any files. Do NOT write code.
|
||||
```
|
||||
|
||||
**Once you call `paseo wait`, trust the wait.** Do not poll logs, read output early, send hurry-up messages, interrupt deep analysis, or give up because it's taking long.
|
||||
- **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.
|
||||
|
||||
GPT 5.4 can reason for 15–30 minutes. Opus does extended thinking. Long waits mean the agent found something worth thinking about. Let it finish.
|
||||
## Phase 1: Plan
|
||||
|
||||
If the CLI has a bug, the user will tell you.
|
||||
|
||||
## No-Edits Suffix
|
||||
|
||||
Every prompt to a committee member — initial, follow-up, or review — **must** end with this suffix. They will start editing code if you don't.
|
||||
|
||||
```
|
||||
NO_EDITS="This is analysis only. Do NOT edit, create, or delete any files. Do NOT write code."
|
||||
```
|
||||
|
||||
All example prompts below include `$NO_EDITS` — always expand it.
|
||||
|
||||
## Phase 1: Get a Plan
|
||||
|
||||
### Write the prompt
|
||||
|
||||
Describe the **overall problem**, not just the immediate symptom:
|
||||
Write a problem-level prompt:
|
||||
|
||||
- High-level goal and acceptance criteria
|
||||
- Constraints
|
||||
- Symptoms (if a bug)
|
||||
- What you've tried and why it failed
|
||||
- Explicitly ask for root cause analysis
|
||||
- What you tried and why it failed
|
||||
- Explicit: "do root cause analysis"
|
||||
- Explicit: "use think-harder — state assumptions, ask why three levels deep, check whether you're patching a symptom or removing the problem"
|
||||
|
||||
```bash
|
||||
prompt="We're trying to [high-level goal]. Constraints: [X, Y, Z]. Acceptance criteria: [A, B, C].
|
||||
Create both agents in parallel via Paseo with `[Committee] <task>` titles and the same prompt. Wait for both — not just whichever finishes first.
|
||||
|
||||
We've been stuck on this. Here's what we've tried and why it didn't work:
|
||||
- [approach 1] — failed because [reason]
|
||||
- [approach 2] — partially worked but [issue]
|
||||
Read both responses. Challenge them — do not accept at face value:
|
||||
|
||||
Step back from these attempts. Do root cause analysis — the fix might not be for [immediate symptom] at all, it might be structural.
|
||||
- "Why does <underlying thing> happen? Symptom or cause?"
|
||||
- Verify any assumption the plan makes about the code.
|
||||
- "What did you considered and reject?"
|
||||
|
||||
Use the think-harder approach: state your assumptions, ask why at least 3 levels deep for each, and check whether you're patching a symptom or removing the problem. What's the right approach?
|
||||
Send follow-ups until the plan addresses root cause.
|
||||
|
||||
$NO_EDITS"
|
||||
```
|
||||
Synthesize:
|
||||
|
||||
### Launch both members
|
||||
|
||||
Same prompt to both, `[Committee]` prefix for identification:
|
||||
|
||||
```bash
|
||||
opus_id=$(paseo run -d --mode bypassPermissions --provider claude/opus --thinking on --name "[Committee] Task description" "$prompt" -q)
|
||||
gpt_id=$(paseo run -d --mode full-access --provider codex/gpt-5.4 --thinking medium --name "[Committee] Task description" "$prompt" -q)
|
||||
```
|
||||
|
||||
### Wait for both
|
||||
|
||||
Wait for **both** agents — not just the first one that finishes.
|
||||
|
||||
```bash
|
||||
paseo wait "$opus_id"
|
||||
paseo wait "$gpt_id"
|
||||
```
|
||||
|
||||
### Read and challenge
|
||||
|
||||
```bash
|
||||
paseo logs "$opus_id"
|
||||
paseo logs "$gpt_id"
|
||||
```
|
||||
|
||||
**Do not accept output at face value.** Use the **think-harder** framework to challenge their output. Before synthesizing:
|
||||
|
||||
1. **Ask "why" 2–3 levels deep.** "Fix X because Y is broken" — why is Y broken? Is Y a root cause or a consequence?
|
||||
2. **Challenge assumptions.** If the plan assumes something about the code, make the agent verify it.
|
||||
3. **Symptom vs cause.** "Are we fixing the consequence or the cause?"
|
||||
4. **Probe alternatives.** "What did you consider and reject?"
|
||||
|
||||
```bash
|
||||
paseo send "$opus_id" "You said [X]. Why does [underlying thing] happen in the first place? Are we patching a symptom? $NO_EDITS"
|
||||
paseo wait "$opus_id"
|
||||
paseo logs "$opus_id"
|
||||
```
|
||||
|
||||
Keep pushing until the plan addresses the root cause.
|
||||
|
||||
### Synthesize and confirm
|
||||
|
||||
- Convergence → merge into unified plan.
|
||||
- Convergence → unified plan.
|
||||
- Significant divergence → involve the user.
|
||||
|
||||
Send the merged plan back for confirmation. Multi-turn if needed — keep going until consensus.
|
||||
|
||||
```bash
|
||||
paseo send "$opus_id" "Merged plan: [plan]. Concerns? $NO_EDITS"
|
||||
paseo send "$gpt_id" "Merged plan: [plan]. Concerns? $NO_EDITS"
|
||||
```
|
||||
Confirm the merged plan with both members. Multi-turn until consensus.
|
||||
|
||||
## Phase 2: Implement
|
||||
|
||||
Implement the plan yourself — unless the user said **"delegate"**, in which case launch an implementer:
|
||||
Default: implement yourself. If the user said **"delegate"**, launch one impl agent and pass the merged plan.
|
||||
|
||||
```bash
|
||||
impl_id=$(paseo run -d --mode full-access --provider codex/gpt-5.4 --name "[Impl] Task description" "Implement the following plan end-to-end. [plan]" -q)
|
||||
paseo wait "$impl_id"
|
||||
```
|
||||
|
||||
Committee agents stay clean — not involved in implementation.
|
||||
The committee stays clean — not involved in implementation.
|
||||
|
||||
## Phase 3: Review
|
||||
|
||||
Send the committee the changes for review. They anchor against the plan and catch drift.
|
||||
Send the diff to the committee:
|
||||
|
||||
```bash
|
||||
review_prompt="Implementation is done. Review changes against the plan. Flag drift or missing pieces. $NO_EDITS"
|
||||
> Implementation is done. Review changes against the plan. Flag drift or missing pieces. <no-edits suffix>
|
||||
|
||||
paseo send "$opus_id" "$review_prompt"
|
||||
paseo send "$gpt_id" "$review_prompt"
|
||||
Apply feedback yourself, or send to the impl agent. Repeat 2 → 3 until consensus.
|
||||
|
||||
paseo wait "$opus_id"
|
||||
paseo wait "$gpt_id"
|
||||
|
||||
paseo logs "$opus_id"
|
||||
paseo logs "$gpt_id"
|
||||
```
|
||||
|
||||
### Iterate
|
||||
|
||||
Send committee feedback to the implementer (or apply yourself). Repeat Phase 2 → 3 until the committee confirms the implementation matches the plan.
|
||||
|
||||
After ~10 iterations without convergence, start a fresh committee with full context of what was tried — the current committee's context may have drifted too far.
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user