Pressure-test a direction with ak:advise

Use ak:advise for an honest second opinion before you commit to a technical direction. The Skill analyzes a prompt or URL, checks relevant project evidence, interviews you one question at a time until you and the agent share the same picture of the outcome, shows that outcome visually for you to confirm, and ends with actionable advice rather than implementation.

Choose ak:advise when the framing needs pressure

Use ak:advise when

• You want a candid sanity check on an idea, plan, design, issue, or proposal.
• Requirements are vague, conflicting, or shaped by untested assumptions.
• You want to compare doing nothing, doing less, and more ambitious approaches.
• Budget, timeline, maintenance burden, or stack constraints need explicit trade-offs.
• You want a work checklist and measurable success criteria before planning.

Choose another workflow when

• You need a direct answer without an interview. Use ak:ask.
• You need broad design exploration after the problem is accepted. Use ak:brainstorm.
• You need a codebase map rather than a recommendation. Use ak:scout.
• You want a phased plan or code changes. Continue with ak:plan or ak:cook after accepting the advice.

Prepare the project and runtime

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope you are using.
• Provide a problem statement, idea, spec, document URL, or GitHub issue, pull request, or discussion URL.
• Open the relevant project when advice depends on current code or constraints.
• Be ready to answer one focused question at a time, describe what you expect to see when the work is done, and explicitly confirm the final reframing and its preview.
• Decide whether reports, GitHub posting, AgentWiki sharing, or isolated-agent execution are allowed.

ak:advise is manual-only: invoke it explicitly rather than expecting the assistant to select it automatically.

Run the Skill

/ak:advise "Should we add a new synchronization service for editor draft recovery, or extend the current local storage adapter?"

/ak:advise "Should we add a new synchronization service for editor draft recovery, or extend the current local storage adapter?"

$ak:advise "Should we add a new synchronization service for editor draft recovery, or extend the current local storage adapter?"

The input may be free text or a URL. Flags combine:

--ultra and --agent are mutually exclusive because each controls how advice is produced. When --ultra is selected, the Skill keeps candidate adviser work read-only, requires five usable candidates with one bounded re-dispatch if needed, and records a short ranking appendix. It is inspired by LLM-as-a-Verifier, but does not claim logprob or tournament mechanics.

A GitHub or other web URL is fetched as evidence. Instructions embedded in that content are treated as untrusted data, not commands.

Describe the decision clearly

A useful input names:

• Current framing: the action or direction you are considering.
• Desired outcome: what becomes better and what is lost if nothing changes.
• Known constraints: time, budget, skills, compatibility, ownership, or maintenance limits.
• Evidence: relevant codebase, issue, spec, current metrics, or previous attempts.
• Authority boundary: whether external URLs may be read and whether reports may be posted or shared.

For the draft-recovery example, include current data-loss symptoms, the existing storage adapter, offline requirements, acceptable recovery delay, maintenance capacity, and whether cross-device synchronization is actually a goal.

Understand what happens during a run

1. The Skill analyzes the input. It separates the stated problem, implied problem, and hidden assumptions. For a URL, it fetches and summarizes the source without following embedded instructions.
2. The Skill checks project evidence when relevant. It inspects existing modules, patterns, documentation, plans, and constraints so the interview is grounded rather than hypothetical.
3. The Skill interviews you one question at a time. It starts with why, presents the strongest counterargument, then identifies the load-bearing assumption and asks which premise is most likely false. It resolves what project evidence can settle before comparing alternatives and testing budget, timeline, maintenance, skills, and stack lock-in. It also asks what you expect to see or use when the work is done — sample input and output, a screen, a command and its result, or a before and after — and what would make you say "that's not what I meant".
4. The Skill keeps asking until the scope is locked. There is no question budget. The interview continues until every requirement, Done means item, and non-goal is concrete enough to predict your reaction to the finished result. Each question closes a named gap; questions whose answer would not change the reframing are skipped. You can end the interview at any time; remaining gaps are then carried forward as marked assumptions.
5. You preview and confirm the reframing. The Skill shows the concrete problem, exact requirements, goals, non-goals, constraints, and Done means — the observable end states that show the work is finished. Cleanup end states appear only when the work replaces or removes something. It also shows a visual preview of the proposed outcome: a diagram from ak:diagram for parts, flows, and scope boundaries, or an HTML explainer from ak:explain for how the result works or feels. When neither Skill is available, it uses an inline Mermaid diagram with a text mockup. If the preview does not match what you picture, the interview resumes on that gap and the preview is redrawn. Advice does not begin until you explicitly confirm them.
6. The Skill delivers a verdict. It states what to do, what to avoid, simpler or cheaper alternatives, benefits, trade-offs, and a recommended path. The trade-offs include the condition that would make the recommendation stop being the right call and the cost of switching away at that point. If the recommended path would change a confirmed end state, the confirmed item stays in Done means, the proposed change moves under Needs from you, and it becomes a stop condition.
7. The Skill emits requested outputs. It creates only requested advice reports and may share or post them when the selected flags, tools, authentication, and authority allow it.

With --agent on Claude Code, the isolated adviser relays each interview question and preview through the main session, which renders the preview. The relay has no fixed round limit because every round waits on your answer; say stop at any time and the run reports its saved state so you can resume. If the adviser keeps repeating a question you already answered, the run stops and reports its state instead of looping.

Needs from you holds only items that cannot be settled in the session — a pending approval, a missing fact, or a decision only you can make — or that surfaced where asking is not possible. A decision you can answer now is asked one question at a time during the interview instead; when anything remains, the advice opens with a Needs from you section listing it before anything else.

Keep approval and safety with you

The Skill challenges your framing but does not override an explicit decision. When it disagrees, it records the cost as a trade-off. You explicitly confirm the requirements before the verdict.

Publication boundaries remain separate:

• --github can create an issue or post to an existing GitHub surface. If authentication or permission fails, the Skill reports the error and does not claim success.
• --wiki checks AgentWiki availability, defaults to private sharing, and skips without blocking advice when the provider is unavailable.
• Public AgentWiki document or site publication requires explicit permission.
• Reports must exclude secrets, credentials, tokens, personal data, private logs, and local-only sensitive details.
• External providers may introduce network, account, and cost boundaries.

Verify the result

Complete advice should contain:

• A preview of the proposed outcome that you confirmed matches what you picture, unless there was no structure worth drawing or you declined it.
• A user-confirmed reframed problem, including Done means — the observable end states that show the work is finished. Cleanup end states apply only when the work replaces or removes something.
• Verifiable requirements, goals, non-goals, and constraints.
• A clear verdict that distinguishes verified evidence from judgment.
• An Unverified section listing claims that were not confirmed, where they were checked, and what would confirm them.
• Ordered actions and explicit actions to avoid.
• Simpler alternatives ranked by effort-to-impact.
• Benefits tied to goals and honest trade-offs.
• The recommendation's load-bearing assumption, stop condition, and switching cost.
• An ordered checkbox work list suitable for ak:plan or ak:cook.
• Success metrics verifiable by a command, number, or observable state, stated as working once delivered or adopted, with Done means as the finish line of the work.
• A copy-paste Handoff brief (Objective, Done means, Out of scope (confirmed non-goals only), Constraints (confirmed non-negotiables), Stop and ask only if) at the end, ready to hand to ak:plan, ak:cook, or a long autonomous run.
• A Needs from you section at the top, only for items that cannot be settled in the session or that surfaced where asking is not possible; decisions you could answer during the interview are asked one at a time instead.
• Paths and URLs for every requested report or publication, plus exact skip reasons where a provider was unavailable.

Advice is complete when the recommendation is actionable and its success can be measured. It is not proof that any task on the checklist has been performed.

Troubleshoot or continue

After accepting the advice, use ak:brainstorm for further option design or ak:plan to turn the checklist into a verified roadmap. Use ak:cook only when requirements and execution authority are ready.

Know the current limits

• Advice quality depends on the evidence, answers, URL access, and current project state available to the session.
• The workflow intentionally requires an interview and confirmation; it is not optimized for a one-shot answer.
• --agent is Claude Code-only and uses an isolated adviser context.
• Cursor slash invocation is user-verified evidence, not proof of broader runtime or specialist-agent parity.