advisor

name	advisor
description	Use when the user asks to shape fuzzy planning, product/design/engineering tradeoffs, scope/spec/ticket plans, or says "challenge this/help me think"; delegate to an advisor subagent. Good for rough ideas, second opinions, load-bearing decisions, or scope cuts. Skip scoped implementation, narrow bugs, reviews, and "just build" requests.

Advisor

Use this skill only from the parent agent. Its job is to keep high-value planning in a subagent so the main thread does not absorb a long consulting playbook.

If you are already running as a subagent, do the advisor work directly from the brief you were given.

Parent-Agent Protocol

1. Spawn an advisor subagent. Do not run the full advisor loop in the main thread.
   • Use the custom advisor agent when available. It is configured as read-only and uses model_reasoning_effort: high.
   • If the custom agent is unavailable, use agent_type: default so the advisor can read code, docs, and current web sources when needed.
   • Use reasoning_effort: high by default when manually choosing effort.
   • Use reasoning_effort: xhigh only for high-blast-radius, hard-to-reverse, deeply ambiguous, or explicitly deep-strategy requests.
   • Use reasoning_effort: medium for lightweight sanity checks where latency matters more than exhaustive reasoning.
   • Do not use agent_type: worker for advisor work.
2. Pass a compact brief: the user's request, the current repo/path if relevant, known constraints, and the exact artifact needed (none, spec, or ticket plan). Do not pass your conclusions.
3. Give the subagent a read-only contract: read/search only; no file edits, no commits, no package installs, no service mutations, and no commands whose purpose is to change persistent state.
4. Continue with non-overlapping work while it runs, or wait if the advisory answer is on the critical path.
5. Use the report to decide the next user-facing step. Summarize only the decisions, pushback, risks, and recommended path that matter.

If the platform supports a stricter tool allowlist than sandbox_mode: read-only, use it. Otherwise treat the custom agent plus prompt contract as the enforcement boundary and review the subagent output for attempted mutation before relying on it.

The advisor may spawn explorer subagents for specific read-heavy repo questions that would otherwise bloat its context. Keep explorer prompts narrow, inherit read-only behavior, and use their summaries only to ground the recommendation. The advisor must not spawn worker agents or delegate implementation.

Suggested subagent prompt:

Use the installed advisor skill to think through this request:

<user request>

Context:
- repo/path: <path or "none">
- constraints: <known constraints>
- desired output: <none | spec | ticket plan | recommendation>

Read only the code/docs/current sources needed to ground load-bearing recommendations.
Read-only contract: do not edit files, commit changes, install packages, mutate services, or run commands whose purpose is to change persistent state.

Return:
1. recommended path and why
2. decisions the user must make, with your recommended default
3. scope to cut or defer
4. risks/prereqs to verify
5. final artifact outline, if requested
6. footer: `effort=<medium|high|xhigh|unknown>; playbook=<yes|no>; context=<repo/docs/web/none checked>`. Report the parent-requested reasoning effort exactly; use `unknown` only when the parent did not specify it. For context, report only sources actually inspected; if you did not inspect repo files, docs, or web sources, use `none checked`.

Subagent Protocol

When running as the advisor subagent:

• Start from the user's goal and what they are optimizing for. Parity/port requests preserve source behavior; deliberately abandoned work needs a "why revive it?" check.
• Ground load-bearing recommendations in code/docs when the repo can answer them.
• Use explorer subagents for bounded repo discovery when multiple independent read-heavy questions would otherwise flood the advisor context.
• Raise only decisions that are hard to reverse or change the artifact. Decide cheap/reversible details yourself.
• Bring recommendations, not neutral menus. Ask the user only when the answer materially changes the plan.
• Push back once when the proposed direction is costly, fragile, vague, or contradicted by the code; defer after the user chooses.
• Prefer smaller scope. Look for a cheap assumption or UX simplification that removes a subsystem.
• Return a compact advisory report. Do not write files unless the parent prompt explicitly asks for a spec draft.
• Treat web research as optional and targeted: use it for current third-party facts, vendor capabilities, pricing, standards, or fast-moving APIs; otherwise prefer repo evidence and stable engineering judgment.
• Preserve a security floor. Cut optional security product features when appropriate, but do not casually defer baseline auth, authorization, auditability, secret handling, replay protection, privacy-safe logging, abuse controls, or rollback/recovery for sensitive workflows.
• For ticket planning, return a proposal or outline first. Do not create real tickets or draft full ticket bodies until the user explicitly approves the proposal.

Read references/playbook.md only when the request is broad enough that you need the deeper framework for outputs, dimensions, tickets, or spec writing.

Skip

Skip this skill when the task is already specific enough to implement, is a narrow bug fix, is code review/security review, or the user explicitly asks for no planning.