/with-advisor

With Advisor: Expert Pair Programming

Spawn expert advisor(s) that monitor your work and give proactive domain feedback. You stay in control — advisors supplement your judgment.

Usage

/with-advisor "implement OAuth login with JWT tokens"
/with-advisor "optimize the slow database queries"
/with-advisor "design a plugin system for the CLI"

Tasks

1. Validate arguments

The command requires a task description.

**No arguments:**

Usage: /with-advisor "task description"

Example: /with-advisor "implement OAuth login with JWT tokens"

Stop here. Do not proceed.

2. Assess task complexity

If the overhead of spawning advisors exceeds the benefit, refuse:

Task is too simple for advisors. Just do it directly.

Stop here. Do not proceed. Otherwise, continue.

3. Select advisor expertise

Analyze the task and decide which advisor expertise adds value. Think about:

• What domain knowledge would catch mistakes you'd miss?
• What expertise would improve the design, not just the code?

**Rules:**

• Max 2 advisors
• Only spawn a second if genuinely different expertise is needed
• Frame advisors around the **problem** being solved, not the tool being built

Examples:

| Task | Advisors | Why | |------|----------|-----| | "implement OAuth login" | Security Expert, Auth Domain Expert | Security-sensitive, unfamiliar domain | | "optimize database queries" | Performance Expert | Specific domain expertise | | "refactor the auth module" | Codebase Patterns Expert | Large change, consistency matters | | "add WebSocket support" | Distributed Systems Expert | Real-time, concurrency concerns | | "migrate to TypeScript" | TypeScript Migration Expert | Large scope, many gotchas |

4. Create team and spawn advisors

Use Agent Teams (TeamCreate + Task tool) to spawn each advisor.

**Team setup:**

• Team name: `advisor-session` (or similar short name)
• Create tasks for tracking
• If a team named `advisor-session` already exists (user ran `/with-advisor` before), ask: "Advisors from a previous session are still active. Replace them with new advisors? [Yes / No]". If Yes, shut down existing advisors first (SendMessage with `type: shutdown_request`), delete the team, then create a new one. If No, stop here.

**For each advisor, spawn a teammate with this prompt:**

You are an advisor specialized in [DOMAIN]. Do NOT write or edit code.

First: run /catchup to understand the project and current work.

Then: research best practices in your domain for the current task:
Task: [TASK DESCRIPTION]

Send your initial assessment to the team lead, then go idle.

How you collaborate with Main:

1. BEFORE implementation: Main shares a planned approach with you.
   Challenge it — poke holes, suggest alternatives, flag risks.
   Be direct: "This won't work because..." or "Consider X instead".
   If Main decides to proceed despite your objection, accept the decision.
   Monitor for consequences during implementation instead.

2. DURING implementation: Main will ask you at decision points.
   Give a clear recommendation, not a list of options.
   If Main doesn't ask but you spot something in a diff — speak up.

3. PROGRESS UPDATES: Main sends updates after significant changes.
   Read the latest git diff and changed files.
   Focus on your specialty, skip the rest. Be concise.

Your specialty: [DOMAIN DESCRIPTION]

**Spawn configuration:**

• `subagent_type`: `general-purpose` (needs access to read files, run git commands, search)
• Do NOT use `mode: plan` — advisors need Bash access for `git diff`, `git status`, and web search
• Run advisors in background so Main can continue working

**If spawning fails** (TeamCreate or Task tool returns an error):

Failed to spawn advisor: [error]. Continuing without advisors.
You can retry with /with-advisor "[same task]".

Continue working on the task without advisors. Do not retry automatically.

5. Challenge approach with advisors

**Wait for advisors to finish onboarding** (they send an initial assessment). While waiting, formulate your approach (step 1 below) — but do NOT start implementing. If the advisor hasn't sent their assessment yet after you've formulated and shared your approach, tell the user "Waiting for advisor..." and **end your turn.** The advisor's message will arrive as a new conversation turn.

Before writing any code:

1. Formulate your planned approach — how you intend to solve the task (structure, key decisions, sequence) 2. Share it with each advisor via SendMessage:

My planned approach for [task]:

[Approach summary — what you'll build, how, key decisions]

Challenge this before I start. What am I missing? What would you do differently?

3. **Wait for advisor feedback. This is the highest-value phase — do NOT skip it.**

• Tell the user: "Waiting for advisor feedback on approach..." and **end your turn.** Do NOT use sleep loops.
• The advisor's response will arrive as a new conversation turn automatically.
• Only proceed without feedback if the **user** explicitly says to start (e.g., "just start", "don't wait").

4. Incorporate feedback (or decide to proceed anyway — you're in control). 5. **Identify upcoming decision points.** Based on your approach and the advisor's feedback, list 2-4 decisions you'll face during implementation where the advisor's expertise would help. 6. Tell the user:

Approach discussed with advisors. Key feedback:
- [summary of advisor input]

Decision points I'll check with the advisor during implementation:
- [decision 1]
- [decision 2]

Starting implementation.

6. Implement with advisor collaboration

Now implement. You are Main — you do the work.

Tell the user:

You'll see advisor messages inline. Act on them or ignore them — your call.
To stop: say "stop advisors" anytime.

**IMPORTANT: Consult the advisor at decision points — don't just implement and send progress updates.**

The biggest risk is falling into a "implement everything, then se