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, confirms the reframed requirements, 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 and explicitly confirm the final reframing.
• 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:

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.
4. The Skill converges. Interviewing stops when answers no longer change the reframing, usually after four to eight questions rather than a fixed quota.
5. You confirm the reframing. The Skill shows the concrete problem, exact requirements, goals, non-goals, and constraints. 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.
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 through the main session. The relay is bounded; if it cannot finish, the run reports its partial state instead of looping indefinitely.

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 user-confirmed reframed problem.
• Verifiable requirements, goals, non-goals, and constraints.
• A clear verdict that distinguishes verified evidence from judgment.
• 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.
• 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.